DevOps

Вебинар «Анализ требований и их влияние на архитектуру» ✔️ 16 июня в 20:00 МСК в рамках старта курса «System Design» от Otus. Вебинар будет полезен разработчикам, архитекторам, техническим лидам и системным аналитикам. Узнайте, как требования формируют архитектуру систем и почему их правильная проработка критична для стабильности решений. На вебинаре разберем: ✅ Как эффективно собирать и фиксировать требования ✅ Как требования влияют на архитектуру системы ✅ Как учитывать функциональные и нефункциональные требования при проектировании Мы рассмотрим реальные примеры, которые помогут вам построить более стабильные и надежные приложения. 🚀 Регистрация: https://vk.cc/cMQtq1 А еще, успей воспользоваться 🏷10% скидкой на курс «System Design» и 🎁 бонусным промокодом SD_5 . Выгодные условия действуют с 12 по 15 июня включительно! Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Балансировка и геораспределение: как создать быстрое и надёжное приложение для всего мира На вебинаре разберём, как крупные компании — такие как Netflix, Amazon и другие — делают свои сервисы доступными для пользователей по всему миру без задержек и сбоев. На вебинаре вы: — Как работают балансировщики и «умные» прокси. — Что такое геораспределение и зачем оно критично для масштабируемых сервисов. — Как грамотно распределять трафик между дата-центрами. — Частые ошибки при проектировании глобальных систем — и как их избежать. 👉 Регистрация и подробности о курсе Highload Architect: https://vk.cc/cMOgUE Бесплатное занятие приурочено к старту курса Highload Architect, обучение на котором позволит освоить решения, которые выдерживают большое количество запросов в секунду и правильно оптимизировать работоспособность серверов. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

«Прогрессивная доставка инфраструктуры с помощью Kargo и Argo CD» – Engin Diri, Pulumi С момента выхода Kargo я изучаю возможность использовать его не только для доставки и продвижения приложений, но и для постепенного развёртывания инфраструктуры. С помощью Kubernetes-ориентированных инструментов, таких как Crossplane или Pulumi, мы описываем инфраструктуру как код и можем плавно развертывать её сначала в наших управляющих кластерах, а затем последовательно продвигать изменения через разные этапы без необходимости в дополнительных скриптах CD. Позвольте показать, как Kargo помогает платформенным инженерам упростить и автоматизировать прогрессивный релиз изменений в инфраструктуре на всех стадиях. В этом докладе будут рассмотрены основы работы с Kargo и примеры интеграции с инструментами Infrastructure as Code. * Описание проблемы: необходимость безопасного и контролируемого релиза изменений в инфраструктуре * Решение: использование Kargo для поэтапного развёртывания (Progressive Delivery) * Инструменты IaC: Crossplane, Pulumi * Преимущества: * автоматизация продвижения конфигурации между окружениями * отказ от «волшебных» CD-скриптов * единый pipeline для приложений и инфраструктуры Настройка Kargo вместе с Argo CD позволяет интегрировать управление приложениями и инфраструктурой в единую платформу progressive delivery, минимизируя риски и ускоряя итерации. источник #devops #девопс Подпишись 👉@i_DevOps

Pipeline инфраструктуры (Infra Pipeline) Этот workflow описывает сквозной CI/CD-pipeline для сборки и деплоя инфраструктуры, включая quality gates (детекторы и оценку рисков). Ветвление (Branching) Рекомендуется создавать короткоживущие feature-ветки (локальные копии основной ветки trunk/main). В них выполняются изолированные изменения. На локальную ветку нет жёстких ограничений, но вы как разработчик обязаны регулярно синхронизировать её с основной (через rebase или merge), чтобы избежать merge conflicts. Основная ветка (mainline/trunk) Mainline (или trunk) служит для сборки и публикации deployable артефактов. Любой merge в неё может автоматически попасть в staging или production. Поэтому ветка должна быть постоянно в deployable-состоянии. Для этого в CI/CD pipeline настраиваются quality gates: статический анализ кода, unit- и интеграционные тесты, security scans, оценка рисков 🔒. Trunk остаётся locked до прохождения всех проверок и подтверждения безопасности изменения. https://medium.com/@tusharmurudkar/devops-infrastructure-pipeline-beab47e7b876 #devops #девопс Подпишись 👉@i_DevOps

Нужно выкатить новую фичу, но нет уверенности, что всё пойдет как надо? А еще… 🔻 Слабый мониторинг или его нет совсем. 🔻 Непонятно, почему система тормозит. 🔻 Клиенты жалуются на ошибки и долгое время ответа. Знакомо? Приглашаем на онлайн-интенсив по Service mesh от Слёрм, на котором вы: 👉 решите реальные бизнес-кейсы; 👉 поймёте принцип работы и в будущем сможете применить знания на любом решении; 👉 научитесь искать причины проблем. Даты проведения: 27-29 июня. Спикеры: – Александр Лукьянченко, руководитель юнита PaaS в Авито – Виталий Лихачев, SRE в крупном голландском тревелтехе – Георг Гаал, CTO AEnix Специальные условия группам от 3-х человек. 👉 Программа и запись на интенсив по ссылке.

Переезд с облака на свои сервера: взгляд со стороны инфраструктуры и бизнеса Привет, коллеги! Сегодня я отойду от прежнего стиля написания статей. До этого момента я писал больше про хард скиллы, но в последнее время я начал расширять свой кругозор и изучать процессы в компании под разными углами, в том числе с точки зрения бизнеса. Переезд с облака на свои сервера — это не просто техническая миграция, а настоящая проверка на прочность для всей команды и бизнеса в целом. В статье я постараюсь объяснить, опираясь на свой опыт, почему облачные решения не всегда оказываются универсальным спасением, с какими неожиданными сложностями мы столкнулись и какие компромиссы пришлось принимать. Это история не только про железо и Hard‑скиллы, но и про людей, процессы и принятие решений в условиях ограниченного бюджета и рисков. https://habr.com/ru/articles/914438/ #devops #девопс Подпишись 👉@i_DevOps

systemd: как писать юниты с элегантной перезагрузкой Разработка системы с элегантным завершением работы может оказаться той ещё пляской с бубном. В идеальном мире каждый сервис управлялся бы юнитом systemd. ExecStart запускала бы процесс, обрабатывающий SIGTERM, а ExecStop оповещало бы процесс и осуществляло блокировку, которая бы корректно завершала процесс и его ресурсы. Однако многие программы завершаются некорректно, а то и вовсе сбивают все настройки при закрытии. В этой статье мы рассмотрим поведение systemd при завершении работы и методы написания юнитов systemd для выборочной очистки (custom cleanup) перед закрытием. https://www.psdn.io/posts/systemd-shutdown-unit/ #devops #девопс Подпишись 👉@i_DevOps

❕ Приглашаем на урок по работе с чувствительными данными в Kubernetes-кластере! ⏺Открытый урок K8S + Vault — как получать секреты? Бесплатно 17 июня в 20:00 МСК. Урок в рамках старта курса «Инфраструктурная платформа на основе Kubernetes» от Otus. Поймете, как организовать безопасное и масштабируемое взаимодействие между Kubernetes и HashiCorp Vault. Разберём подход dynamic secrets и инструмент External Secrets Operator для интеграции секретов из Vault в кластер. На уроке вы узнаете: - как Kubernetes работает с секретами по умолчанию и его ограничения; - способы интеграции Kubernetes и Vault; - что такое External Secrets Operator и почему его выбирают для production-сред; - пошаговую схему подключения Vault к K8s. ➡️ Регистрация на вебинар: https://vk.cc/cMHhuk Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Почему нельзя парсить вывод ls(1) Команда ls(1) достаточно хорошо справляется с отображением атрибутов одного файла (по крайней мере, в некоторых случаях), но когда просишь у неё список файлов, возникает огромная проблема: Unix позволяет использовать в имени файла почти любой символ, в том числе пробелы, переносы строк, точки, символы вертикальной черты, да и практически всё остальное, что вы можете использовать как разделитель, за исключением NUL. Существуют предложения по «исправлению» этой ситуации внутри POSIX, но они не помогут в решении текущей ситуации (см. также, как правильно работать с именами файлов). Если в качестве стандартного вывода не используется терминал, в режиме по умолчанию ls разделяет имена файлов переносами строк. И никаких проблем не возникает, пока не встретится файл, в имени которого есть перенос строки. Так как очень немногие реализации ls позволяют завершать имена файлов символаи NUL, а не переносами строк, это не позволяет получить безопасным образом список имён файлов при помощи ls (по крайней мере, портируемым способом). https://habr.com/ru/articles/823298/ #devops #девопс Подпишись 👉@i_DevOps

Bash-совет: анализ неудачных SSH-логинов и бан «горячих» IP 🔒🐚 Хотите быстро узнать, какие IP вызывают максимум неудачных попыток входа в SSH, и оперативно заблокировать самых настырных? Ниже скрипт:

#!/usr/bin/env bash
# ssh_fail_analyzer.sh
# Анализ неудачных SSH-попыток и вывод TOP-10 IP

LOG_FILE="/var/log/auth.log"       # путь к логам (для CentOS: /var/log/secure)
TOPN=10                            # сколько IP показывать

echo "Топ $TOPN IP с неудачными SSH-входами:"
grep -E "Failed password for" "$LOG_FILE" \
  | grep -oP '(?<=from )[\d\.]+' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -n "$TOPN"

Как это работает 1. grep -E "Failed password for" Ищем все строки с неудачными попытками. 2. grep -oP '(?<=from )\[\d.]+' С помощью PCRE-регулярки достаём только IP-адреса после слова "from". 3. sort | uniq -c | sort -rn Сортируем, считаем вхождения и выводим в порядке убывания. 4. head -n "\$TOPN" Ограничиваем результат топ-10. 🛠 Можно добавить в crontab ежедневный запуск и автоматическую отправку отчёта на почту или сразу бан «горячих» IP через iptables:

# в crontab: каждый день в 00:10
10 0 * * * /path/to/ssh_fail_analyzer.sh | mail -s "SSH Fail Report" admin@example.com

Или сразу блокировать подозрительные IP, если они превысили порог:

THRESHOLD=50
for ip in $(grep -E "Failed password for" "$LOG_FILE" \
              | grep -oP '(?<=from )[\d\.]+' \
              | sort | uniq -c \
              | awk -v t="$THRESHOLD" '$1 > t {print $2}'); do
  iptables -I INPUT -s "$ip" -j DROP
  echo "$(date): Заблокирован $ip за превышение $THRESHOLD неудачных попыток" >> /var/log/ssh_ban.log
done

👉@bash_srv

Стили взаимодействия микросервисов: 5 секретов, которые изменят ваш подход к backend-разработке Взаимодействие между микросервисами — это больше, чем просто REST или RPC. Это фундамент архитектуры, от которого зависит масштабируемость, надёжность и производительность всей системы. 📌 Что будет на вебинаре: — 5 ключевых стилей взаимодействия микросервисов: REST, gRPC, event-driven, messaging, CQRS; — Сравнение: синхронное vs. асинхронное взаимодействие — плюсы, минусы, типичные ошибки; — Когда использовать брокеры сообщений и какую роль играют очереди; — Советы по построению отказоустойчивых коммуникаций между сервисами; — Как логировать и отслеживать взаимодействия между микросервисами; 👉 Регистрация и подробности о курсе Highload Architect: https://vk.cc/cMHfWt Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

📺 Kubernetes Уроки 1 - Что такое Kubernetes? Запуск локального кластера Kubernetes. Minikube 2 - Запуск Kubernetes кластера на AWS, используя eksctl 3 - Запуск Kubernetes кластера на AWS, используя Terraform 4 - Как использовать kubectl с несколькими Kubernetes кластерами 5 - Как установить Kubernetes Dashboard 6 - Создание объекта Pod. Запуск контейнеров в Kubernetes 7 - Метки, аннотации и пространства имён в Kubernetes 8 - ReplicationController и ReplicaSet в Kubernetes 9 - Deployment в Kubernetes. Стратегии обновления приложенийн 10 - Service в Kubernetes - Часть 1. Type: ClusterIP. Endpoints Всего доступно 49 уроков #devops #девопс Подпишись 👉@i_DevOps

Целостность и безопасность конвейера в DevSecOps Это третий пост из серии глубокого погружения в архитектуру программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как совокупности ориентированных на технологии и автоматизированных процессов. Обязательно ознакомься также с первой и второй частью! На данном этапе мы разобрали, как управлять уже существующими уязвимостями и как предотвращать появление новых. Теперь у нас есть жизненный цикл разработки ПО (SDLC), который обеспечивает создание программного обеспечения, безопасного «с самого начала». Осталось лишь разобраться, как обеспечить исполнение и защиту созданной нами архитектуры. В этой статье мы узнаем, как добавить целостность и безопасность в системы, задействованные в нашем SDLC. Эти процессы должны быть незаметны для наших разработчиков — они просто выступают в роли предохранительных ограждений, гарантируя, что остальная часть архитектуры используется правильно и не подвергается нежелательным вмешательствам. https://blog.gitguardian.com/pipeline-integrity-and-security-in-devsecops/ #devops #девопс Подпишись 👉@i_DevOps

Безопасность по умолчанию: программное обеспечение в DevSecOps Это второй пост в серии, посвящённой архитектуре программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как набора технологически управляемых автоматизированных процессов. Если вы не читали первый пост, обязательно ознакомьтесь с ним! В этой статье речь пойдёт скорее не о принятии решений, а об опыте разработчиков. Мы узнаем, как снабдить наших инженеров программного обеспечения инструментами, которые позволят им самостоятельно обеспечивать безопасность своего кода, и как поддержать их с помощью автоматизации. Прежде чем приступать, хочу ещё раз озвучить своё основное утверждение по DevSecOps:

«Моя задача — внедрить процесс разработки программного обеспечения с безопасностью по умолчанию, который даст командам инженерии возможность самостоятельно отвечать за безопасность своих цифровых продуктов. Мы добьёмся успеха с помощью контролей и обучения, а также снизим трение и сохраним скорость разработки благодаря технологически управляемой автоматизированной архитектуре DevSecOps.»

https://blog.gitguardian.com/secure-by-design-software-in-devsecops/ #devops #девопс Подпишись 👉@i_DevOps

Жизненный цикл управления уязвимостями в DevSecOps Это первый пост из серии, которая будет глубоко погружаться в архитектуру программы DevSecOps. Цель этой серии — представить целостный обзор DevSecOps как совокупности технологически управляемых, автоматизированных процессов. Какие инструменты и технологии играют роль в DevSecOps? Как мы можем использовать технологии, чтобы настроить команды разработчиков на успех? Как мы выстраиваем роли и зоны ответственности для обеспечения слаженности, безопасности и скорости? На эти и другие вопросы мы ответим по мере развития серии. Последние три года я в профессиональной роли строил программу DevSecOps в своей компании с нуля. Возможно, отдельные части этой серии не будут напрямую применимы к вашей организации, но её ключевые идеи и общий подход всё равно могут оказаться полезными. Следующее заявление о миссии отражает мой подход к DevSecOps:

«Моя задача — внедрить процесс разработки программного обеспечения по принципу secure-by-design, который предоставляет командам разработчиков возможность самостоятельно отвечать за безопасность своих цифровых продуктов. Мы добьёмся успеха за счёт контроля и обучения, а благодаря технологически ориентированной и автоматизированной архитектуре DevSecOps снизим трение и сохраним высокую скорость работы.»

https://blog.gitguardian.com/vulnerability-management-lifecycle-in-devsecops/ #devops #девопс Подпишись 👉@i_DevOps

❔ Как серверные приложения и микросервисы взаимодействуют через сеть? Хотите научиться подбирать правильные протоколы для вашей системы? Откройте для себя все особенности работы с сетевыми протоколами на открытом уроке курса «System Design». Мы подробно рассмотрим HTTP/2, HTTP/3, gRPC и WebSocket, а также научим выбирать оптимальные технологии для вашего проекта. 🚀 Знание сетевых протоколов — ключ к построению стабильных, быстрых и масштабируемых веб-приложений. Пройдите урок и получите навыки, которые улучшат архитектуру ваших решений. ⏺ Встречаемся 10 июня в 20:00 МСК ➡️ Регистрация уже открыта: https://vk.cc/cMCIx6 Урок проходит в преддверии старта курса «System Design». Участники вебинара получат скидку на курс, плюс дополнительный 🎁 промокод SD_5 до 16.06. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Оповещение об аномалиях в Prometheus Изучаем, как настраивать оповещения об аномалиях для сезонных данных в Prometheus. В Auto Trader мы стремимся создавать оповещения, которые большинство сможет использовать «из коробки», а не жестко прописывать их под конкретные сценарии. Мы хотим, чтобы вы могли развернуть сервис и сразу получить отдачу от платформы — особенно когда речь идет об отслеживании и оповещениях по вашим «Golden Signals» или управлении затратами. https://bookflow.ru/opoveshhenie-ob-anomaliyah-v-prometheus/ #devops #девопс Подпишись 👉@i_DevOps

Полное руководство по Docker Secrets Даже если вы использовали Docker для небольших или локально разработанных программ, вы могли обнаружить, что он может быть довольно трудным для решения более сложных задач. Особенно это касается управления секретами и совместного использования - областей, которые часто упускаются из виду при работе с контейнерными приложениями. https://earthly.dev/blog/docker-secrets/ #devops #девопс Подпишись 👉@i_DevOps

🚀 Разгоняем kube-prometheus-stack: секретный ингредиент в Observability 🔥 9 июня в 20:00 мск — бесплатный вебинар «Разгоняем kube-prometheus-stack». Мониторинг не должен тормозить, особенно когда что-то идёт не так. Что разберём: – как ускорить отклик Grafana при работе с большими объёмами данных, – что замедляет Prometheus и как с этим бороться, – как сократить сетевой трафик мониторинга без потерь, – как не положить observability-инфру при инциденте, – и какие архитектурные подходы помогают сделать мониторинг отказоустойчивым. Оптимизируйте kube-prometheus-stack и держите руку на пульсе — даже в условиях пиковых нагрузок. 👉 Регистрируйтесь здесь: https://vk.cc/cMB9gr Занятие приурочено к старту курса "Observability: мониторинг, логирование, трейсинг", на котором вы научитесь строить эффективные системы мониторинга, работать с Prometheus, Grafana, ELK и другими инструментами, визуализировать метрики. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

CI/CD на GitHub Actions и GitLab CI для самых маленьких. Часть 3 Как запускать пайплайн только для нужных веток, хранить секреты в безопасности и управлять окружениями — просто, наглядно, с примерами. Если вы уже настроили первый workflow — самое время сделать его умнее 🚀 Если вы дошли до этой части в серии, то вы уже знакомы с базовыми принципами CI/CD и даже настроили свой первый простой пайплайн. Поздравляю! Вы сделали важный шаг в мир автоматизации разработки. Но как и в программировании, где после "Hello World" начинается настоящее обучение, в CI/CD после базовой настройки открывается целый мир возможностей. Часть 1 https://t.me/i_DevOps/2948 Часть 2 https://t.me/i_DevOps/2950 https://habr.com/ru/articles/915370/ #devops #девопс Подпишись 👉@i_DevOps