Как работать с Docker Networking: концепции и применение
👩💻 Автор статьи описывает классический случай из практики с Docker: разработчик запускает контейнер, подключается к нему через
На деле Docker уже делает всю работу – ниже расскажем об основном, подробнее найдете в статье.
👀 Почему проблема возникла?
При установке Docker создает дефолтный сетевой мост (network-bridge), где он выстраивает коммуникацию по временным IP таким образом, что многоконтейнерные приложения становятся неудобными: разработчик не находит сервисы по имени, и каждый перезапуск меняет адреса контейнеров.
⏺ Как решать?
Для устранения проблемы автор предлагает использовать user-defined bridge сети. При создании такой сети Docker автоматически включает внутренний DNS, и контейнеры получают постоянные hostname. Всё, что потребуется от разработчика – запустить контейнеры и подключить их к одной сети, чтобы приложение могло обращаться к базе по имени к БД, независимо от IP и рестарта контейнера.
Контейнеры с user-defined bridge
Контейнер со статическим IP и объявленная сеть
Для выполнения данного решения разработчик создает пользовательскую bridge-сеть с объявленным пулом адресов (subnet) и назначением контейнеру фиксированного IPv4 через ipv4_address. Так, мы обеспечиваем предсказуемую адресацию, полезную для интеграции с системой, которая зависит от IP. При этом сеть сохраняет встроенный DNS Docker, позволяющий обращаться к контейнерам по имени.
🚀 Вывод: для многоконтейнерных приложений не стоит использовать дефолтный bridge. Создавайте собственные сети или пользуйтесь Docker Compose, чтобы надёжно связать сервисы по их именам, а не по временным IP-адресам.
#devops #docker #dockercompose #networking #containers
localhost и…возникает проблема. Веб-сервис развёрнут в одном контейнере, БД — в отдельном. Как настроить сетевое взаимодействие между ними? На деле Docker уже делает всю работу – ниже расскажем об основном, подробнее найдете в статье.
При установке Docker создает дефолтный сетевой мост (network-bridge), где он выстраивает коммуникацию по временным IP таким образом, что многоконтейнерные приложения становятся неудобными: разработчик не находит сервисы по имени, и каждый перезапуск меняет адреса контейнеров.
Для устранения проблемы автор предлагает использовать user-defined bridge сети. При создании такой сети Docker автоматически включает внутренний DNS, и контейнеры получают постоянные hostname. Всё, что потребуется от разработчика – запустить контейнеры и подключить их к одной сети, чтобы приложение могло обращаться к базе по имени к БД, независимо от IP и рестарта контейнера.
Контейнеры с user-defined bridge
services:
app2:
image: nginx
networks:
- mybridge
app3:
image: alpine
command: ["sh", "-c", "while true; do sleep 3600; done"]
networks:
- mybridge
networks:
mybridge:
driver: bridge
Контейнер со статическим IP и объявленная сеть
Для выполнения данного решения разработчик создает пользовательскую bridge-сеть с объявленным пулом адресов (subnet) и назначением контейнеру фиксированного IPv4 через ipv4_address. Так, мы обеспечиваем предсказуемую адресацию, полезную для интеграции с системой, которая зависит от IP. При этом сеть сохраняет встроенный DNS Docker, позволяющий обращаться к контейнерам по имени.
services:
app:
image: nginx
networks:
custom_net:
ipv4_address: 172.20.0.10
networks:
custom_net:
driver: bridge
ipam:
config:
- subnet: 172.20.0.0/24
#devops #docker #dockercompose #networking #containers
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤9👍9🔥6
Логирование и мониторинг — топ-3 инструмента для DevOps в 2025
🗣 Несложно представить ситуацию: трафик на пике, API выдает 500-е ошибки. Вы заходите на сервер по SSH, суматошно переходите из директории в директорию, пытаетесь разобраться в веренице логов микросервисов и в конце находите виновника. Спустя время сбой устранили, но вопрос остался – «неужели нельзя проще?». Отвечаем – можно, с инструментами observability.
🚀 Топ-3 инструмента для логирования и мониторинга:
1.Grafana Loki
Плюсы:
• Минимальные расходы: Loki не индексирует содержимое логов, используя только метки (labels) — как в Prometheus. Это снижает потребление CPU, RAM и дискового пространства.
• Тесная интеграция с Prometheus и Grafana: Если вы уже используете Grafana или Prometheus, например в рамках KubePrometheusStack, то вам может быть полезна возможность просматривать логи там же, где и метрики.
• Простота развёртывания и масштабирования: monolithic mode идеально подходит для старта, так как объединяет в рамках одно бинарного файла все компоненты Loki. Но как только вам его не хватает, советуем перейти на микросервисный режим, разделив Distributor, Ingester, Querier и Compactor на отдельные сервисы
• Гибкий язык запросов: LogQL похож на PromQL, что позволяет проводить агрегаций и подсчёт ошибок за период времени, а затем выводить панели с количеством ошибок, рейтами и распределениями в Grafana.
💬 Что учесть
Однако, Loki разработан для фильтрации логов на основе меток и регулярных выражений, а не для глубокого полнотекстового поиска и не позволяет справляться со сложным анализом логов.
2. Elastic Stack
Плюсы:
• Настройка на всех уровнях: от сбора данных с помощью Logstash или Beats до запросов и дашбордов в Kibana — почти все можно настроить
• Мощный поиск и аналитика: Elasticsearch обеспечивает быстрый полнотекстовый поиск и агрегацию в больших масштабах
• Работа в реальном времени: данные индексируются и становятся доступны для поиска почти мгновенно
Гибкость индексации и управления данными: в Elasticsearch есть возможность настраивать ILM (Index Lifecycle Management) - автоматически перемещать "тёплые" и "холодные" данные между нодами, удалять старые индексы по политике.
💬 Что учесть:
Операционные затраты могут быть высокими, а расходы на облачные услуги быстро растут при производственном масштабе.
3. OpenSearch
Плюсы:
• Полный open-source: OpenSearch является решением с открытым кодом без лицензионных рисков.
• Гибкость в сборе и анализе логов: поддерживает SQL и PPL, а также обладает встроенным observability-стеком
• Alerting-plugin — в отличие от ElasticSearch, OpenSearch из коробки позволяет строить гибкие триггеры и уведомления.
• Активное сообщество и поддержка AWS: он поддерживается AWS, Capital One, Red Hat, SAP и другими.
👩💻 Подборки репозиториев:
https://github.com/grafana/grafana – интеграция с Grafana с дашбордами и алертингом;
https://github.com/grafana/loki – репозиторий для агрегации логов
https://github.com/elastic – у Elastic на GitHub свыше 800 репозиториев, включая ядро Elasticsearch и множество интеграций и плагинов.
#DevOps #Observability #Grafana #Elastic
1.Grafana Loki
Плюсы:
• Минимальные расходы: Loki не индексирует содержимое логов, используя только метки (labels) — как в Prometheus. Это снижает потребление CPU, RAM и дискового пространства.
• Тесная интеграция с Prometheus и Grafana: Если вы уже используете Grafana или Prometheus, например в рамках KubePrometheusStack, то вам может быть полезна возможность просматривать логи там же, где и метрики.
• Простота развёртывания и масштабирования: monolithic mode идеально подходит для старта, так как объединяет в рамках одно бинарного файла все компоненты Loki. Но как только вам его не хватает, советуем перейти на микросервисный режим, разделив Distributor, Ingester, Querier и Compactor на отдельные сервисы
• Гибкий язык запросов: LogQL похож на PromQL, что позволяет проводить агрегаций и подсчёт ошибок за период времени, а затем выводить панели с количеством ошибок, рейтами и распределениями в Grafana.
Однако, Loki разработан для фильтрации логов на основе меток и регулярных выражений, а не для глубокого полнотекстового поиска и не позволяет справляться со сложным анализом логов.
2. Elastic Stack
Плюсы:
• Настройка на всех уровнях: от сбора данных с помощью Logstash или Beats до запросов и дашбордов в Kibana — почти все можно настроить
• Мощный поиск и аналитика: Elasticsearch обеспечивает быстрый полнотекстовый поиск и агрегацию в больших масштабах
• Работа в реальном времени: данные индексируются и становятся доступны для поиска почти мгновенно
Гибкость индексации и управления данными: в Elasticsearch есть возможность настраивать ILM (Index Lifecycle Management) - автоматически перемещать "тёплые" и "холодные" данные между нодами, удалять старые индексы по политике.
Операционные затраты могут быть высокими, а расходы на облачные услуги быстро растут при производственном масштабе.
3. OpenSearch
Плюсы:
• Полный open-source: OpenSearch является решением с открытым кодом без лицензионных рисков.
• Гибкость в сборе и анализе логов: поддерживает SQL и PPL, а также обладает встроенным observability-стеком
• Alerting-plugin — в отличие от ElasticSearch, OpenSearch из коробки позволяет строить гибкие триггеры и уведомления.
• Активное сообщество и поддержка AWS: он поддерживается AWS, Capital One, Red Hat, SAP и другими.
https://github.com/grafana/grafana – интеграция с Grafana с дашбордами и алертингом;
https://github.com/grafana/loki – репозиторий для агрегации логов
https://github.com/elastic – у Elastic на GitHub свыше 800 репозиториев, включая ядро Elasticsearch и множество интеграций и плагинов.
#DevOps #Observability #Grafana #Elastic
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍10🔥6❤3
Лучшие из худших сообщений коммитов
⏺ Всем DevOps! Хорошие новости – сегодня пятница, значит скоро нас ждет перерыв от дейликов. Плохие – всё еще нужно писать сообщения коммитов после деплоя и релизов. Представляем зал славы лучших из худших сообщений коммитов, где собраны нестандартные варианты из рабочих репозиториев. Расширенный сборник найдёте здесь.
👀 Вот сейчас точно исправил
Именно так выглядели коммиты DevOps-инженера автора статьи каждый раз, когда нужно было «быстренько что-нибудь установить».
👀 Всё, что надо было, сделал
Классическое сообщение тиммейтов при поступлении срочной задачи, которую закрыть надо было ещё вчера.
👀 Хроники борьбы с билдом
Попыток было в разы больше.
👀 Пожалуйста, работай…
Признайтесь, были и такие моменты в работе.
👀 Эпоха до ESLint
Кто бы что ни говорил, а проблема «казнить нельзя помиловать» актуальна.
Какие находки из коммитов помните вы?
#git #commits #commitmessages #devops
"fix"
"fix-final"
"ok final fix"
"fix final final"
"fixed previous fix"
Именно так выглядели коммиты DevOps-инженера автора статьи каждый раз, когда нужно было «быстренько что-нибудь установить».
"did the needful"
Классическое сообщение тиммейтов при поступлении срочной задачи, которую закрыть надо было ещё вчера.
"attempt to fix the build"
"ok, fix the build"
Попыток было в разы больше.
"please work"
Признайтесь, были и такие моменты в работе.
"added a coma, now works fine"
Кто бы что ни говорил, а проблема «казнить нельзя помиловать» актуальна.
Какие находки из коммитов помните вы?
#git #commits #commitmessages #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤15👍10🔥6
Good practices: конфигурации в Kubernetes
Конфигурации – основа рабочей нагрузки Kubernetes. Опытные инженеры знают, что достаточно пропущенной кавычки, неактуальной API-версии или смещённого отступа в YAML для возникновения проблемы при деплое. Представляем подборку good practices с советами по стабилизации кластера — для новичков и опытных пользователей. Подробнее читайте здесь.👀
Общие practices:
⏺ Используйте актуальную версию API
Kubernetes быстро развивается и обновляется. Менее актуальные API не работают корректно и приводят к сбоям при деплое. Проверяйте версию API, используя следующую команду:
⏺ Храните конфиги под версионным контролем
Не применяйте файлы манифеста с десктопа, храните их в системе контроля версий, например, в Git. Если что-то сломается – вы быстро откатитесь к прошлому коммиту.
⏺ Пишите конфиги в YAML, не в JSON
Технически работают оба формата для обмена и хранения данных, но YAML более удобен, по словам автора. В YAML используйте только true/false, т.к. yes/no/on/off могут парситься по-разному. Для надёжности берите в кавычки всё, что похоже на булево значение (например, "yes").
⏺ Группируйте связанные объекты
Если ресурсы – часть одного сервиса, храните их в одном файле YAML-манифеста. Так легче отслеживать, ревьювить и разворачивать изменения.
Применяйте эту команду, чтобы задеплоить всё в папке:
🚀 Стандартизированные конфигурации упрощают управление кластером и берегут нервы администратора. Следуйте базовым принципам: контроль версий, единая система меток, отказ от использования отдельных Pod-ов без контроллеров. Так, вы значительно сократите время на диагностику и устранение ошибок.
#kubernetes #k8s #clustermanagment #devops
Конфигурации – основа рабочей нагрузки Kubernetes. Опытные инженеры знают, что достаточно пропущенной кавычки, неактуальной API-версии или смещённого отступа в YAML для возникновения проблемы при деплое. Представляем подборку good practices с советами по стабилизации кластера — для новичков и опытных пользователей. Подробнее читайте здесь.
Общие practices:
Kubernetes быстро развивается и обновляется. Менее актуальные API не работают корректно и приводят к сбоям при деплое. Проверяйте версию API, используя следующую команду:
kubectl api-resources
Не применяйте файлы манифеста с десктопа, храните их в системе контроля версий, например, в Git. Если что-то сломается – вы быстро откатитесь к прошлому коммиту.
Технически работают оба формата для обмена и хранения данных, но YAML более удобен, по словам автора. В YAML используйте только true/false, т.к. yes/no/on/off могут парситься по-разному. Для надёжности берите в кавычки всё, что похоже на булево значение (например, "yes").
Если ресурсы – часть одного сервиса, храните их в одном файле YAML-манифеста. Так легче отслеживать, ревьювить и разворачивать изменения.
Применяйте эту команду, чтобы задеплоить всё в папке:
kubectl apply -f configs/
#kubernetes #k8s #clustermanagment #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍4🔥3
Как развернуть Prometheus через systemd и запустить базовый мониторинг
👨💻 Возвращаемся с инструментами по observability и SRE. Prometheus – это система мониторинга с открытым исходным кодом, которую можно использовать для сбора и отслеживания различных метрик из экспортеров в Time Series Database (TSDB). Сегодня разберем, как настроить и запустить Prometheus и управлять через systemd на сервере Ubuntu или Debian. Для инженеров single-node установка позволяет использовать Prometheus как базовую систему мониторинга без лишних инфраструктурных настроек.
⏺ Шаг 1. Подготовка пользователя и загрузка Prometheus
Создаем отдельного пользователя для Prometheus:
Выбираем версию для вашей системы и скачиваем бинарь:
Меняем права на папку, чтобы Prometheus мог работать безопасно:
⏺ Шаг 2. Настройка systemd-сервиса
Создаем файл /etc/systemd/system/prometheus.service с таким содержимым:
⏺ Шаг 3. Запуск и управление Prometheus
Активируем сервис и запускаем его:
Проверяем статус и логи сервиса:
Теперь Prometheus работает как системный сервис, собирает метрики и готов к подключению экспортеров.
⏺ Шаг 4. Дальнейшие шаги
⁃ Настройка AlertManager для уведомлений.
⁃ Подключение экспортеров для серверов, контейнеров и приложений.
⁃ Использование Grafana для визуализации метрик.
🗂 Подробнее о настройке алертов: Prometheus Alerting
Вывод: такой минимальный setup позволяет быстро поднять Prometheus для тестов и PoC, понять, как работает TSDB, и интегрировать систему мониторинга в DevOps-процессы.
#sre #observability #prometheus #monitoring #devops
Создаем отдельного пользователя для Prometheus:
sudo useradd -M -U prometheus
Выбираем версию для вашей системы и скачиваем бинарь:
wget https://github.com/prometheus/prometheus/releases/download/v2.40.0-rc.0/prometheus-2.40.0-rc.0.linux-amd64.tar.gz
tar -xzvf prometheus-2.40.0-rc.0.linux-amd64.tar.gz
sudo mv prometheus-2.40.0-rc.0.linux-amd64 /opt/prometheus
Меняем права на папку, чтобы Prometheus мог работать безопасно:
sudo chown prometheus:prometheus -R /opt/prometheus
Создаем файл /etc/systemd/system/prometheus.service с таким содержимым:
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target
[Service]
User=prometheus
Group=prometheus
Restart=on-failure
ExecStart=/opt/prometheus/prometheus \
--config.file=/opt/prometheus/prometheus.yml \
--storage.tsdb.path=/opt/prometheus/data \
--storage.tsdb.retention.time=30d
[Install]
WantedBy=multi-user.target
Активируем сервис и запускаем его:
sudo systemctl daemon-reload
sudo systemctl start prometheus.service
sudo systemctl enable prometheus.service
Проверяем статус и логи сервиса:
sudo systemctl status prometheus.service
sudo journalctl -u prometheus.service -f
Теперь Prometheus работает как системный сервис, собирает метрики и готов к подключению экспортеров.
⁃ Настройка AlertManager для уведомлений.
⁃ Подключение экспортеров для серверов, контейнеров и приложений.
⁃ Использование Grafana для визуализации метрик.
Вывод: такой минимальный setup позволяет быстро поднять Prometheus для тестов и PoC, понять, как работает TSDB, и интегрировать систему мониторинга в DevOps-процессы.
#sre #observability #prometheus #monitoring #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤11👍6🔥5
Свежие новостные релизы, которые ещё не успели настояться
Срединедельный DevOps!🚀 Сегодня поговорим о сбое Cloudflare, рассмотрим превью AWS DevOps Agent и релизы AWS re:Invent 2025 в области безопасности.
⏺ Не опять, а снова: сбой в Cloudflare, ошибка 500
Cloudflare частично оказалась недоступной на 25 минут в прошлую пятницу. Во время инцидента примерно треть запросов вела на пустую страницы с кодом ошибки 500. В этот раз, причиной стала проблема в коде на языке Lua, которая применяется в системе фильтрации трафика WAF для блокирования вредоносных запросов. В логах отображалось:
Изменение было отменено в 09:12 UTC, и после отката нормальная обработка трафика восстановилась.
⏺ AWS DevOps Agent (preview): выявление и локализация причин инцидентов.
AWS представила превью AWS DevOps Agent, ИИ-агента для расследования и предотвращения инцидентов.
Интеграция с Datadog MCP Server обеспечивает доступ к логам, метрикам и трассировкам, что позволяет агенту автоматически сопоставлять данные из AWS и Datadog. В демонстрации агент за минуты выявил суть проблемы всплеска 5XX ошибок API Gateway. Ранние пользователи отмечают сокращение MTTR с часов до минут. Подробнее здесь.
⏺ re:Invent 2025: релизы инструментов и обновления
На re:Invent 2025 AWS представила ряд обновлений в области безопасности, управления идентификацией, тарификации, а также состоялись релизы тулзов: IAM Policy Autopilot, инструмент для генерации IAM-политик на основе детерминированного анализа приложений, Org-level S3 Block Public Access, расширение блокировки публичного доступа на уровне организации, TLS Proxy, новый сервис прокси для TLS-инспекции. Прочитать об обновлениях можно здесь.
#devops #cloudflare #aws #awsdevopsagent
Срединедельный DevOps!
Cloudflare частично оказалась недоступной на 25 минут в прошлую пятницу. Во время инцидента примерно треть запросов вела на пустую страницы с кодом ошибки 500. В этот раз, причиной стала проблема в коде на языке Lua, которая применяется в системе фильтрации трафика WAF для блокирования вредоносных запросов. В логах отображалось:
[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)
Изменение было отменено в 09:12 UTC, и после отката нормальная обработка трафика восстановилась.
AWS представила превью AWS DevOps Agent, ИИ-агента для расследования и предотвращения инцидентов.
Интеграция с Datadog MCP Server обеспечивает доступ к логам, метрикам и трассировкам, что позволяет агенту автоматически сопоставлять данные из AWS и Datadog. В демонстрации агент за минуты выявил суть проблемы всплеска 5XX ошибок API Gateway. Ранние пользователи отмечают сокращение MTTR с часов до минут. Подробнее здесь.
На re:Invent 2025 AWS представила ряд обновлений в области безопасности, управления идентификацией, тарификации, а также состоялись релизы тулзов: IAM Policy Autopilot, инструмент для генерации IAM-политик на основе детерминированного анализа приложений, Org-level S3 Block Public Access, расширение блокировки публичного доступа на уровне организации, TLS Proxy, новый сервис прокси для TLS-инспекции. Прочитать об обновлениях можно здесь.
#devops #cloudflare #aws #awsdevopsagent
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5🔥4❤2🤯1
Не делайте так: мой пятничный деплой
👀 Снова пятница, пора сворачиваться и надеяться, что ни один pipeline не применит изменения, способные снести пол-инфры. Расскажем поучительную историю о DevOps-инженере, который решил выполнить развертывание в пятницу, после рефакторинга Terraform-модулей. Не судите автора статьи слишком строго, он обычный человек, который на кофеине нажал «Deploy».
💬 Что произошло в пятницу?
•15:47 – запуск развертывания после рефактора Terraform-модулей.
Изменение – автор переименовал одну переменную, которая используется в сорока семи местах, в трёх окружениях. Но проверка линтером пройдена. Что может пойти не так?
•16:02 – запуск GitHub Actions, а дальше...пайплайн упал, в Terraform появился неожиданный
•16:07 – сообщения о падении staging и подозрительные изменения в проде, возгласы: "КТО ДЕПЛОИЛ В ПЯТНИЦУ?!". Автор попытался отключить роутер, но было поздно – имя уже в коммите.
•16:11 – созвон в зуме, SRE подключился со вздохом, бэкэнд-разработчик присоединился с пивом, CTO – с пляжа на Бали.
•16:20-16:45 – откат коммита, повторный прогон пайплайна, окружение восстановлено.
После – постмортем без прямых обвинений с коллективной критикой в виде смайликов и пассивно-агрессивных мемов.
❌ Проблема заключалась в том, что при рефакторинге конфигурации автор изменил имя без полного анализа зависимостей и проверки влияния на все окружения. Изменения затронули многочисленные модули и окружения, но не были синхронизированы между собой. Сопутствующими факторами стали недостаточная верификация
✅ Уроки, которые автор не усвоил (а должен был):
•Не деплоить в пятницу
•Всегда перепроверять
•Подготовить воспроизводимый плана отката, желательно, без слёз.
•Внедрить автоматическую валидацию переменных и контрактов модулей (schema/validation) и тесты на согласованность именований.
Пятничный деплой: храбрость или безрассудство? Делитесь вашими историями ниже.
#deploy #devops #terraform #postmortem
•15:47 – запуск развертывания после рефактора Terraform-модулей.
Изменение – автор переименовал одну переменную, которая используется в сорока семи местах, в трёх окружениях. Но проверка линтером пройдена. Что может пойти не так?
•16:02 – запуск GitHub Actions, а дальше...пайплайн упал, в Terraform появился неожиданный
destroy -план. Уведомления в Slack накрыли волной. •16:07 – сообщения о падении staging и подозрительные изменения в проде, возгласы: "КТО ДЕПЛОИЛ В ПЯТНИЦУ?!". Автор попытался отключить роутер, но было поздно – имя уже в коммите.
•16:11 – созвон в зуме, SRE подключился со вздохом, бэкэнд-разработчик присоединился с пивом, CTO – с пляжа на Бали.
•16:20-16:45 – откат коммита, повторный прогон пайплайна, окружение восстановлено.
После – постмортем без прямых обвинений с коллективной критикой в виде смайликов и пассивно-агрессивных мемов.
terraform plan во всех средах и отсутствие автоматизированных проверок. •Не деплоить в пятницу
•Всегда перепроверять
terraform plan для каждого окружения перед применением.•Подготовить воспроизводимый плана отката, желательно, без слёз.
•Внедрить автоматическую валидацию переменных и контрактов модулей (schema/validation) и тесты на согласованность именований.
Пятничный деплой: храбрость или безрассудство? Делитесь вашими историями ниже.
#deploy #devops #terraform #postmortem
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9🤯6🔥3❤1
От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую
В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете
Как внедрить подход?
⏺ Развертывание базового окружения (Infra Space)
1. Добавляем репозиторий Helm:
2. Разворачиваем базовое окружение для инфраструктуры:
3. Устанавливаем Helm-чарт через ConfigHub:
• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).
⏺ Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:
2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.
⏺ Клонирование и создание Вариантов (Variants)
Variant – это копия Config Unit, которая создается через операцию Clone.
1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.
⬆️ Так, мы получаем цепочку конфигураций:
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]
Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».
⏺ Мгновенный доступ к конфигурациям
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:
Dev
Prod
Получаем готовый YAML, а не шаблон или переменную.
⏺ Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:
Поиск уязвимых образов
Поиск образов
👀 Подводные камни и что делать:
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.
Делимся полезными ресурсами:
⚙️ Интеграция ConfigHub-workflow с CI/CD (build → render → store → apply), примеры для GitHub Actions/GitLab CI и рекомендации по кэшированию здесь.
❕ How-to по Variants и GitOps (ArgoCD/Flux) – синхронизация «данных-конфигураций» с Git и кластерами (Kustomize в ArgoCD), подробнее тут.
#confighub #kubernetes #helm #devops
В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете
helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.Как внедрить подход?
1. Добавляем репозиторий Helm:
helm repo update
2. Разворачиваем базовое окружение для инфраструктуры:
cub space create infra
3. Устанавливаем Helm-чарт через ConfigHub:
cub helm install --space infra \
--use-placeholder=false \
--namespace monitoring \
prometheus prometheus-community/kube-prometheus-stack \
--version 79.6.1
• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).
1. Создаем пространства для каждого целевого окружения:
cub space create dev
cub space create prod2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.
Variant – это копия Config Unit, которая создается через операцию Clone.
1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]
Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:
Dev
cub unit get --space dev prometheus --data-only
Prod
cub unit get --space prod prometheus --data-only
Получаем готовый YAML, а не шаблон или переменную.
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:
Поиск уязвимых образов
cub unit list --space "*" \
--resource-type monitoring.coreos.com/v1/Prometheus \
--where-data "spec.image ~ '.*registry.compromised.com.*'"
Поиск образов
cub unit list --space "*" \
--resource-type monitoring.coreos.com/v1/Prometheus \
--where-data "spec.image ~ '.*quay.io.*'"
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.
Делимся полезными ресурсами:
#confighub #kubernetes #helm #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍12❤5🔥4👎2
Анонсы и прогнозы: Docker с Dynamic MCP, Rust в Linux, тренды.
Срединедельный DevOps! Обсудим прогнозы и ключевые события уходящего года: развитие DevOps-инструментов, Rust в Linux, рост трафика с ИИ и лучшие кейсы цифровизации.
⏺ Docker Desktop 4.5 и Dynamic MCP
Docker Desktop – приложение для локальной разработки, которое позволяет разработчику собирать, запускать и администрировать контейнеризованные приложения. Представили экспериментальную функцию Dynamic MCP в версии Docker Desktop 4.5. При её использовании ИИ-агенты находят и подключают MCP-серверы в реальном времени. Dynamic MCP начинает работу при подключении клиента к MCP Toolkit, а шлюз MCP предоставляет агентам набор инструментов (mcp-find, mcp-add и др.), с помощью которых им удается обнаружить, добавить и управлять серверами в ходе работы. Подробнее об особенностях функции читайте тут, а с примером использования – на GitHub.
⏺ Эксперимент признан успешным: Rust в проекте ядра Linux
Эксперимент по внедрению Rust в ядро Linux, начатый в версии 6.1 в 2022 году и в котором приняли участие 173 разработчика, официально завершён. Ведущий разработчик Rust для Linux Мигель Охеда опубликовал патч для удаления из документации к ядру предупреждения о характере поддержки. Язык уже используется в производственной среде, поддерживается рядом крупных дистрибутивов Linux. Стоит учитывать, что поддержка Rust пока не охватывает все возможные конфигурации ядра, архитектуры и инструментальные цепочки. Так, часть сценариев, включая смешанные сборки с GCC и LLVM, полноценная поддержку GCC остаётся экспериментальной. Значительный объём работы предстоит как в самом ядре, так и в смежных проектах – upstream Rust, GCC и других компонентах экосистемы. Ознакомиться с комментарием можно здесь.
⏺ Cloudflare: 19% годового роста трафика и растущая доля ИИ-ботов
По результатам отчёта Cloudflare за 2025 год наблюдается рост глобального интернет-трафика на 19%. Из ключевых особенностей выделяем автоматизированных агентов и сервисов ИИ, которые составляют значительную часть прироста. Подобные изменения сказываются на структуре трафика и порождают требования к новой, безопасной инфраструктуре. В отчёте представлена информация по усилению угроз безопасности и снижению устойчивости сервисов. Cloudflare зафиксировала 25 крупных распределённых DDoS-атак, которые привели к сбоям и ограничению доступа сервисов. В качестве оптимального решения компания внедрила постквантовое шифрование для 52% TLS 1.3-трафика. Подготовка к будущему, в котором квантовые компьютеры обойдут системы шифрования, началась уже сейчас. Подробности об интернет сервисах, HTTP версиях, IPv6 можете прочесть здесь.
⏺ «Лидеры Цифрофизации – 2025»: номинация лучший кейс
Внедрение цифровых технологий в процессы бизнеса и управления не потеряют актуальности в 2026-м. Портал TECH совместно с бизнес-клубом Global при поддержке «Деловой России» и «Ассоциация "Руссофт"» опубликовал результаты рейтинга «Лидеры Цифрофизации – 2025», задачей которого являлось отображение лидирующих российских IT-компаний в сфере финансовых услуг, научно-исследовательской деятельности, инженерии и разработки. Победителем в лидеры номинации «Лучший кейс» стал проект по внедрению 1С, системы ML Sense в ММНИО. В число лидеров вошёл кейс «TargetADS» IT-интегратора Nixys по разработке сервиса проверки качества инвентаря, антифрода с выявлением неревантных показов, кликов, что позволило оптимизировать расход рекламного бюджета. Ознакомиться с результатами рейтинга TECH можно здесь.
#docker #dynamicmcp #rust #linux #devops
Срединедельный DevOps! Обсудим прогнозы и ключевые события уходящего года: развитие DevOps-инструментов, Rust в Linux, рост трафика с ИИ и лучшие кейсы цифровизации.
Docker Desktop – приложение для локальной разработки, которое позволяет разработчику собирать, запускать и администрировать контейнеризованные приложения. Представили экспериментальную функцию Dynamic MCP в версии Docker Desktop 4.5. При её использовании ИИ-агенты находят и подключают MCP-серверы в реальном времени. Dynamic MCP начинает работу при подключении клиента к MCP Toolkit, а шлюз MCP предоставляет агентам набор инструментов (mcp-find, mcp-add и др.), с помощью которых им удается обнаружить, добавить и управлять серверами в ходе работы. Подробнее об особенностях функции читайте тут, а с примером использования – на GitHub.
Эксперимент по внедрению Rust в ядро Linux, начатый в версии 6.1 в 2022 году и в котором приняли участие 173 разработчика, официально завершён. Ведущий разработчик Rust для Linux Мигель Охеда опубликовал патч для удаления из документации к ядру предупреждения о характере поддержки. Язык уже используется в производственной среде, поддерживается рядом крупных дистрибутивов Linux. Стоит учитывать, что поддержка Rust пока не охватывает все возможные конфигурации ядра, архитектуры и инструментальные цепочки. Так, часть сценариев, включая смешанные сборки с GCC и LLVM, полноценная поддержку GCC остаётся экспериментальной. Значительный объём работы предстоит как в самом ядре, так и в смежных проектах – upstream Rust, GCC и других компонентах экосистемы. Ознакомиться с комментарием можно здесь.
По результатам отчёта Cloudflare за 2025 год наблюдается рост глобального интернет-трафика на 19%. Из ключевых особенностей выделяем автоматизированных агентов и сервисов ИИ, которые составляют значительную часть прироста. Подобные изменения сказываются на структуре трафика и порождают требования к новой, безопасной инфраструктуре. В отчёте представлена информация по усилению угроз безопасности и снижению устойчивости сервисов. Cloudflare зафиксировала 25 крупных распределённых DDoS-атак, которые привели к сбоям и ограничению доступа сервисов. В качестве оптимального решения компания внедрила постквантовое шифрование для 52% TLS 1.3-трафика. Подготовка к будущему, в котором квантовые компьютеры обойдут системы шифрования, началась уже сейчас. Подробности об интернет сервисах, HTTP версиях, IPv6 можете прочесть здесь.
Внедрение цифровых технологий в процессы бизнеса и управления не потеряют актуальности в 2026-м. Портал TECH совместно с бизнес-клубом Global при поддержке «Деловой России» и «Ассоциация "Руссофт"» опубликовал результаты рейтинга «Лидеры Цифрофизации – 2025», задачей которого являлось отображение лидирующих российских IT-компаний в сфере финансовых услуг, научно-исследовательской деятельности, инженерии и разработки. Победителем в лидеры номинации «Лучший кейс» стал проект по внедрению 1С, системы ML Sense в ММНИО. В число лидеров вошёл кейс «TargetADS» IT-интегратора Nixys по разработке сервиса проверки качества инвентаря, антифрода с выявлением неревантных показов, кликов, что позволило оптимизировать расход рекламного бюджета. Ознакомиться с результатами рейтинга TECH можно здесь.
#docker #dynamicmcp #rust #linux #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍9🔥4❤3👎1
Пятничное чтиво от DevOps FM
Сегодня поговорим об инфраструктурных мелочах с большими последствиями.
👀 Что могло пойти не так, но с версией Kubernetes 1.35 будет работать корректно
• Под уверенно занял порт на хосте, а потом мы выяснили, что все процессы внутри работали как root. Хорошо, что теперь это можно настроить.
• Для распределённой задачи требуется 10 рабочих подов, а запустилось только 5. Что с этим делает Kubernetes 1.35?
• Образ на узле, ресурсов хватает, но под не стартует – kubelet проверяет наличие imagePullSecrets.
• Кластер не поднялся после обновления узлов. При чём тут cgroup v1 и релиз 1.35? Читайте в статье.
👀 5 ошибок DevOps стартапа (версия 2025)
• DevOps как набор инструментов
Контуры процессов, технический стек внедрены, а совместной ответственности и быстрой обратной связи всё ещё нет.
• Команды работают разрозненно
Разработка, эксплуатация и безопасность живут в своих мирах – потом долго ищут виноватых и чинят одно и то же.
• Гонка за скоростью без прозрачности.
Релизы частые, но без мониторинга и логов проблемы находят пользователи, а не команда.
• Ручные операции там, где давно нужна автоматизация.
Деплой «по инструкции», инфраструктура «на память», подборка ошибок – человеческих и повторяющихся.
• Безопасность на «потом»
Сканирование, политики и контроль доступа подключают после инцидента, когда уже поздно.
Подробности читайте здесь.
👀 Побойтесь DevOps-а…
Компания искала DevOps-инженера, чтобы навести порядок в инфраструктуре, и наняла специалиста с полными правами на продовые серверы. Прошло время и сотрудничество прекратили: доступы отозвали, пароли сменили, учётки заблокировали. Спустя пять дней прод внезапно упал: сервисы недоступны, логи выглядели «разорванными», массовая утечка данных. В ходе внутреннего расследования выяснили – до увольнения был создан скрытый пользователь с правами root, через VPN добавлена отложенная cron-задача на уничтожение системы, а после срабатывания последовал шантаж с требованием выкупа. Как всё закончилось? Читайте здесь.
🚀 Приятного чтения! Пусть все инциденты сегодня будут только на Habr.
#пятничноечтиво #kubernetes #devops #security
Сегодня поговорим об инфраструктурных мелочах с большими последствиями.
• Под уверенно занял порт на хосте, а потом мы выяснили, что все процессы внутри работали как root. Хорошо, что теперь это можно настроить.
• Для распределённой задачи требуется 10 рабочих подов, а запустилось только 5. Что с этим делает Kubernetes 1.35?
• Образ на узле, ресурсов хватает, но под не стартует – kubelet проверяет наличие imagePullSecrets.
• Кластер не поднялся после обновления узлов. При чём тут cgroup v1 и релиз 1.35? Читайте в статье.
• DevOps как набор инструментов
Контуры процессов, технический стек внедрены, а совместной ответственности и быстрой обратной связи всё ещё нет.
• Команды работают разрозненно
Разработка, эксплуатация и безопасность живут в своих мирах – потом долго ищут виноватых и чинят одно и то же.
• Гонка за скоростью без прозрачности.
Релизы частые, но без мониторинга и логов проблемы находят пользователи, а не команда.
• Ручные операции там, где давно нужна автоматизация.
Деплой «по инструкции», инфраструктура «на память», подборка ошибок – человеческих и повторяющихся.
• Безопасность на «потом»
Сканирование, политики и контроль доступа подключают после инцидента, когда уже поздно.
Подробности читайте здесь.
Компания искала DevOps-инженера, чтобы навести порядок в инфраструктуре, и наняла специалиста с полными правами на продовые серверы. Прошло время и сотрудничество прекратили: доступы отозвали, пароли сменили, учётки заблокировали. Спустя пять дней прод внезапно упал: сервисы недоступны, логи выглядели «разорванными», массовая утечка данных. В ходе внутреннего расследования выяснили – до увольнения был создан скрытый пользователь с правами root, через VPN добавлена отложенная cron-задача на уничтожение системы, а после срабатывания последовал шантаж с требованием выкупа. Как всё закончилось? Читайте здесь.
#пятничноечтиво #kubernetes #devops #security
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍7❤5🔥4🤔2
Начинаем год с обсуждения насущной проблемы – есть ли простой способ предоставления информации об используемых сертификатах TLS?
Вопрос цифровой безопасности волнует разработчиков, инженеров и администраторов из-за сокращения срока действия SSL/TLS-сертификатов. Процесс запущен ещё в апреле 2025, когда большинство участников CA/Browser Forum, в число которых входят Google, Apple, Mozilla и Microsoft, сообщили, что уже 15 марта использовать SSL/TLS-сертификаты по прошествии 200 дней будет невозможно. Крис Зибенманн рассуждает, в какие программы можно эффективно внедрить автоматическое отслеживание срока действия TLS-сертификатов и приходит к двум решениям:
1. В большинство приложений должна быть встроена автоматическая система отчетности в формате метрик, сообщений в логах или задан дополнительный параметр командной строки. Автор подчеркивает, что во встроенных метриках некоторых программ не хватает отчетности по времени ‘notAfter’.
2. В других, более «сложных» программах потребуется регистрировать имена файлов при первом использовании и надеяться, что они кэшируют загруженные сертификаты, а не «перечитывают» их каждый раз.
Подробнее читайте здесь.
#devops #tls
Вопрос цифровой безопасности волнует разработчиков, инженеров и администраторов из-за сокращения срока действия SSL/TLS-сертификатов. Процесс запущен ещё в апреле 2025, когда большинство участников CA/Browser Forum, в число которых входят Google, Apple, Mozilla и Microsoft, сообщили, что уже 15 марта использовать SSL/TLS-сертификаты по прошествии 200 дней будет невозможно. Крис Зибенманн рассуждает, в какие программы можно эффективно внедрить автоматическое отслеживание срока действия TLS-сертификатов и приходит к двум решениям:
1. В большинство приложений должна быть встроена автоматическая система отчетности в формате метрик, сообщений в логах или задан дополнительный параметр командной строки. Автор подчеркивает, что во встроенных метриках некоторых программ не хватает отчетности по времени ‘notAfter’.
2. В других, более «сложных» программах потребуется регистрировать имена файлов при первом использовании и надеяться, что они кэшируют загруженные сертификаты, а не «перечитывают» их каждый раз.
Подробнее читайте здесь.
#devops #tls
2👍5❤2🔥2
Приятного прослушивания и пятниц без инцидентов
#подкаст #devops #kubernetes #eks
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤3🔥3👍2
Релизы и безопасность
Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.
⏺ Cozystack v0.41.0: MongoDB
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений
⏺ Опасайтесь VoidLink
На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения. VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются
⏺ Бесконечность не предел: MX Linux 25.1 «Infinity»
Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки
#devops #cozystack #mxlinux #kubernetes #platformengineering
Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений
resourcesPreset apiServer по умолчанию до large и увеличения порог startup-probe для kube-apiserver. Подробнее о релизе – тут. На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения. VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются
LD_PRELOAD, загружаемые модули ядра (LKM) и eBPF. Подробнее - здесь. Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки
dual-init (systemd + sysvinit) в едином ISO-образе, что сокращает количество сборок, systemd теперь обновляется через Debian, а не через отдельный MX-пакет, что упрощает поддержку. Для желающих установить – инструкция тут.#devops #cozystack #mxlinux #kubernetes #platformengineering
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5❤2🔥2
Новые Ops-ы: как мы дошли с Dev-а до Fin-a
В эту пятницу закрываем следующие таски: зачиллиться на дежурке (отдыхающим, просьба не завидовать👨💻 ), не завалить прод и окунуться в историю. Если не задумывались, как от DevOps-а за 18 лет мы дошли до FinOps, зачем нам DevSec и ML – давайте разбираться вместе.
⏺ DevOps умер, да здравствует DevOps!
Традиционно, считаем, что DevOps начал свой путь с модели Agile. Но мало кто упоминает пре-DevOps эру Waterfall (1970-1990-е), тёмное время для инженеров. Команды работали изолированно, Dev лишь «передавал» продукт Ops на запуск. Длинные циклы, редкие релизы, а ошибки дорого обнаруживать и ещё дороже исправлять. К счастью, в начале нулевых Agile сократил цикл от идеи до кода и дал возможность быстро тестировать гипотезы. Что было дальше, знаем: этапы роста первого (и основного) Ops-а – тут. Кстати, если вы думаете, что DevOps умирает, прочтите заметку о текущем «здоровье» – здесь.
Когда скорость разработки пришла в норму, появилась новая проблема – безопасность в CI/CD.
⏺ Зачем нужна безопасность? Роль Sec-а в DevOps
Если DevOps-инженеры сосредоточены на том, как быстрее вывести приложение на рынок, этап тестирования безопасности, закономерно, уходит в конец рабочего цикла. В десятых годах 21-го века по мере совершенствования инструментов и развития процессов стало ясно – ни один отдел ИБ не успевает проверить все релизы. На помощь пришла методология DevSecOps которая устраняет уязвимости, обнаруженные в быстро меняющихся средах DevOps. В уходящем году мы успели поговорить о мифах DevSecOps, но главный вопрос открыт – что ждет DevSec сегодня? Всё об использовании инструментов 2026 читайте – тут, и там.
Как мы радовались первым чат-ботам и грезили о светлом будущем в мире ИИ. Стоило немного разобраться в его влиянии на воркфлоу и изменения цикла разработки.
⏺ MLops – новый этап развития в поставке ПО
Казалось бы, процесс разработки отлажен, безопасность обеспечили, так еще и автоматизированные помощники появились. Около 8-ми лет назад компании радовались новой реальности и внедряли практики машинного обучения в рабочие процессы. Результат довольно предсказуем – около 85% проектов в области AI и ML так и не дошли до продакшена. В 2026 команды сталкиваются с техническими проблемами и сбоями в CI/CD пайплайнах и обновленной инфраструктуре (вектора DBs). Подробнее о развитии MLops – тут, а ТОП-10 инструментов ML в Ops 2026 года – здесь.
Наконец, проблемы решены, можем расслабиться… подумало сообщество, но «слишком хорошо» превратилось в «плохо».
⏺ Что такое FinOps-культура и как она полезна команде?
Когда инфраструктура требовала масштабирования, её просто наращивали, и это почти не требовало объяснений. Теперь ресурсы растут соразмерно стоимости, и каждое техническое решение внезапно требует пояснений и обоснований. Оптимизация расходов – не дополнительная опция или задача под звездочкой, а новая реальность. FinOps Foundation отмечает, что компании, которые используют FinOps-практики, экономят 20–30% затрат в облаке и одновременно повышают вовлечённость команд. Team-lead инфраструктурного отдела, DevOps-инженер Nixys Пётр Рукин совместно с Практиками FinOps обозначили, кто должен заниматься внедрением культуры, как это осуществить и что с этого получают инженеры – на Habr.
А вы готовы к следующему Ops? Какие практики, по вашему мнению, станут обязательными в будущем?
#devops #devsecops #mlops #finops
В эту пятницу закрываем следующие таски: зачиллиться на дежурке (отдыхающим, просьба не завидовать
Традиционно, считаем, что DevOps начал свой путь с модели Agile. Но мало кто упоминает пре-DevOps эру Waterfall (1970-1990-е), тёмное время для инженеров. Команды работали изолированно, Dev лишь «передавал» продукт Ops на запуск. Длинные циклы, редкие релизы, а ошибки дорого обнаруживать и ещё дороже исправлять. К счастью, в начале нулевых Agile сократил цикл от идеи до кода и дал возможность быстро тестировать гипотезы. Что было дальше, знаем: этапы роста первого (и основного) Ops-а – тут. Кстати, если вы думаете, что DevOps умирает, прочтите заметку о текущем «здоровье» – здесь.
Когда скорость разработки пришла в норму, появилась новая проблема – безопасность в CI/CD.
Если DevOps-инженеры сосредоточены на том, как быстрее вывести приложение на рынок, этап тестирования безопасности, закономерно, уходит в конец рабочего цикла. В десятых годах 21-го века по мере совершенствования инструментов и развития процессов стало ясно – ни один отдел ИБ не успевает проверить все релизы. На помощь пришла методология DevSecOps которая устраняет уязвимости, обнаруженные в быстро меняющихся средах DevOps. В уходящем году мы успели поговорить о мифах DevSecOps, но главный вопрос открыт – что ждет DevSec сегодня? Всё об использовании инструментов 2026 читайте – тут, и там.
Как мы радовались первым чат-ботам и грезили о светлом будущем в мире ИИ. Стоило немного разобраться в его влиянии на воркфлоу и изменения цикла разработки.
Казалось бы, процесс разработки отлажен, безопасность обеспечили, так еще и автоматизированные помощники появились. Около 8-ми лет назад компании радовались новой реальности и внедряли практики машинного обучения в рабочие процессы. Результат довольно предсказуем – около 85% проектов в области AI и ML так и не дошли до продакшена. В 2026 команды сталкиваются с техническими проблемами и сбоями в CI/CD пайплайнах и обновленной инфраструктуре (вектора DBs). Подробнее о развитии MLops – тут, а ТОП-10 инструментов ML в Ops 2026 года – здесь.
Наконец, проблемы решены, можем расслабиться… подумало сообщество, но «слишком хорошо» превратилось в «плохо».
Когда инфраструктура требовала масштабирования, её просто наращивали, и это почти не требовало объяснений. Теперь ресурсы растут соразмерно стоимости, и каждое техническое решение внезапно требует пояснений и обоснований. Оптимизация расходов – не дополнительная опция или задача под звездочкой, а новая реальность. FinOps Foundation отмечает, что компании, которые используют FinOps-практики, экономят 20–30% затрат в облаке и одновременно повышают вовлечённость команд. Team-lead инфраструктурного отдела, DevOps-инженер Nixys Пётр Рукин совместно с Практиками FinOps обозначили, кто должен заниматься внедрением культуры, как это осуществить и что с этого получают инженеры – на Habr.
А вы готовы к следующему Ops? Какие практики, по вашему мнению, станут обязательными в будущем?
#devops #devsecops #mlops #finops
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥7👍6❤3
Чем запомнился январь? Релизы Jenkins, Cluster API в Kubernetes и альтернативы Ingress-nginx
Всем DevOps! В эту среду сосредоточимся на изменения в политике безопасности Jenkins, новые сценарии обновлений в Cluster API и обсуждение альтернатив Ingress-nginx.
⏺ Jenkins – изменения в политике безопасности, RPM-пакетировании для Red Hat и openSUSE
В релизе Jenkins 2.528.3 добавили поддержку Java 25 для контроллера и агентов, а также образы Windows Server 2022 для контейнеров. Для LTS RPM и DEB репозиториев введён новый GPG-ключ, который администраторам нужно принять при обновлении. Серьёзные изменения версии 2.528.3 коснулись управления Content Security Policy через интерфейс и API для плагинов. Пакеты Jenkins для Red Hat и openSUSE объединены в единый RPM-репозиторий с новым адресом: https://pkg.jenkins.io/rpm-stable/ . Для прошлых LTS-версий Jenkins (2.528.3 и раньше) сохранён отдельный архивный репозиторий: https://pkg.jenkins.io/redhat-stable-legacy/ .Больше о релизе – тут.
⏺ Cluster API v1.12 – обновления «на месте» и «в цепочке»
В блоге Kubernetes вышла статья о новой версии Cluster API, инструменте для декларативного управления жизненным циклом кластеров. Подобно тому, как в Kubernetes можно использовать StatefulSets или Deployments для управления группой pod-ов, в Cluster API можно использовать MachineDeployments для управления группой nod-ов. В релизе представлены обновления
⏺ Архив Ingress-nginx: какие альтернативы?
В уходящем году команда проекта Ingress-nginx сообщила о прекращении поддержки в марте 2026, подробнее писали тут. В блоге CNCF опубликовали статью о преимуществах и недостатках перехода на другой контроллер входящего трафика (Cilium Ingress, Traefik, HAProxy Ingress), или внедрения Kubernetes Gateway API. На примере Cilium Ingress первый вариант был признан самым быстрым: вы вносите минимальные изменения в манифесты приложений, CI/CD и работаете со встроенной функцией мониторинга. По версии CNCF переход на Gateway API от Cilium – самый оптимальный. Как мигрировать на Cillium Ingress – тут, а подробнее о переходе на Gateway API – здесь.
#devops #kubernetes #cloudnative #opensource
Всем DevOps! В эту среду сосредоточимся на изменения в политике безопасности Jenkins, новые сценарии обновлений в Cluster API и обсуждение альтернатив Ingress-nginx.
В релизе Jenkins 2.528.3 добавили поддержку Java 25 для контроллера и агентов, а также образы Windows Server 2022 для контейнеров. Для LTS RPM и DEB репозиториев введён новый GPG-ключ, который администраторам нужно принять при обновлении. Серьёзные изменения версии 2.528.3 коснулись управления Content Security Policy через интерфейс и API для плагинов. Пакеты Jenkins для Red Hat и openSUSE объединены в единый RPM-репозиторий с новым адресом: https://pkg.jenkins.io/rpm-stable/ . Для прошлых LTS-версий Jenkins (2.528.3 и раньше) сохранён отдельный архивный репозиторий: https://pkg.jenkins.io/redhat-stable-legacy/ .Больше о релизе – тут.
В блоге Kubernetes вышла статья о новой версии Cluster API, инструменте для декларативного управления жизненным циклом кластеров. Подобно тому, как в Kubernetes можно использовать StatefulSets или Deployments для управления группой pod-ов, в Cluster API можно использовать MachineDeployments для управления группой nod-ов. В релизе представлены обновления
in-place через update-extensions, теперь изменения применяются к существующим нодам без пересоздания, и chained upgrades для обновления несколько минорных версий без ручного вмешательства. Смотрите на GitHub – подробности о релизе, преимущества обновлений.В уходящем году команда проекта Ingress-nginx сообщила о прекращении поддержки в марте 2026, подробнее писали тут. В блоге CNCF опубликовали статью о преимуществах и недостатках перехода на другой контроллер входящего трафика (Cilium Ingress, Traefik, HAProxy Ingress), или внедрения Kubernetes Gateway API. На примере Cilium Ingress первый вариант был признан самым быстрым: вы вносите минимальные изменения в манифесты приложений, CI/CD и работаете со встроенной функцией мониторинга. По версии CNCF переход на Gateway API от Cilium – самый оптимальный. Как мигрировать на Cillium Ingress – тут, а подробнее о переходе на Gateway API – здесь.
#devops #kubernetes #cloudnative #opensource
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9🔥5❤4
Ingress NGINX: замены нет или миграция возможна?
👤 На Reddit-е обсудили прекращение поддержки Ingress NGINX, работу кластеров, которые не получают обновления безопасности, а пользователи поделились своим негодованием и возможностями миграции. Статья CNCF по альтернативам – чуть выше, а полный тред – здесь.
Реакцию пользователей на новость можно уместить в один комментарий:
⏺ Теперь перейдем к решениям, инженеры разделились на два лагеря: первый не обновляется, т.к. не видит смысла в «лишней» работе:
⏺ Второй – использует Gateway API и дает рекомендации по альтернативам:
👀 Из интересного, Кэт Косгров (K8s Steering Committee) и Табита Сэйбл (SIG Security) в подкасте предположили, что не все инженеры в курсе, поддерживаются ли их кластеры Ingress NGINX, на что пользователи справедливо отметили:
💬 Что думаете об альтернативах, уже перешли на Gateway API? Делитесь опытом в комментариях.
#devops #reddit #k8s #ingress-nginx
Реакцию пользователей на новость можно уместить в один комментарий:
Kubrador
kubectl apply -f divorce.yaml
ах да, классическая смерть open source: «пожалуйста помогите нам» в течение 4-х лет –> «ладно, с нас хватит» –> «стоп, почему никто не помогает 🙁 » в то время, как 50% кластеров k8s внезапно понимают, что они живут в доме, построенном на фундаменте надежд и молитв.
32b1b46b6befce6ab149
Да ну конечно, люди используют Ingress NGINX. Я тоже не обновляюсь.
На данный момент никакого аналога с прежним функционалом нет и миграция займет много времени.
Полностью переехать на Gateway API нельзя, многие public чарты всё ещё используют Ingress. Лично я не нашёл такого аналога, чтобы точь-в-точь (если он вообще есть, потому что даже у nginx-ingress немного другие аннотации), поэтому пользуюсь тем, что есть.
Плюс, не вижу смысла, нельзя мигрировать без прерывания трафика.
Rahomka
Всё равно на проблему вообще, мы не обновляемся
mirrax
Вопрос к тем, кто не обновляется, в чем проблема? Что вы такого делаете, что прям зависит от аннотаций NGINX? Вы не сможете разобраться со всем этим у другого провайдера или использовать Gateway?
EpicDan
Вы же не обязаны использовать встроенные Ingress'ы в public чартах, можно для каждого приложения добавить HTTPRoute через Gateway API, работает нормально.
pilchardus_
Мне кажется, больше 50% k8s кластеров на NGINX, лол. Лично я переезжаю на Traefik на этой неделе.
me1337
Я переехал на F5 NGINX Ingress – без проблем, всё завелось.
FluidIdea
Лично мне нравятся Envoy Gateway (EG) или kgateway, по бенчмаркам хороши. Traefik – не единственный вариант.
edeltoaster
Я уже полностью переехал на Gateway API и Envoy Gateway. Плюс собрал свой кастомный образ с расширением Go-native от Coraza. Управление входящим трафиком стало заметно лучше, пока доволен.
Kabrandon
Не так легко узнать, работаете ли вы с Ingress NGINX? Может, вы не мейнтейнер? Если работаете с кластерами напрямую, вы по-любому знаете, на каком ingress контролере. Сомневаюсь, что вы работаете в таком случае.
Uncommon_senze
Легко понять, используете ли вы его, он не развертывается и не настраивается сам. Но да, проблема большая.
#devops #reddit #k8s #ingress-nginx
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥8❤4👍3👎1
Slash-команды в GitHub Copilot CLI
👩💻 Всем DevOps! Сегодня рассмотрим slash-команды, которые помогают быстрее работать с кодом и управлять контекстом прямо в терминале. Так, вы экономите время на тестировании, исправлении багов и переключении между задачами. Обзор команд – ниже.
👀 Чем полезен инструмент?
GitHub Copilot CLI доступен в режиме public preview с сентября 2025 года. Инструмент пригодится при работе вне IDE: с серверами через SSH, контейнерами, CI/CD-пайплайнами, репозиториями. GitHub Copilot CLI нужен для взаимодействия внутри GitHub без переключения контекста. Подробнее – тут. Slash-команды обеспечивают быструю установку MCP-сервера, выбор ИИ-модели под текущий запрос. По сути, мы говорим о фиксированных промтах, инструкциях, которые вводим через префикс и
Подборка:
⏺ Команды управления сессией:
⏺ Работа с директориями и файлами:
⏺ Настройки и конфигурация
⏺ Внешние сервисы
📎 Подробнее о каждой команде – здесь и в GitHub Docs.
#devops #github
GitHub Copilot CLI доступен в режиме public preview с сентября 2025 года. Инструмент пригодится при работе вне IDE: с серверами через SSH, контейнерами, CI/CD-пайплайнами, репозиториями. GitHub Copilot CLI нужен для взаимодействия внутри GitHub без переключения контекста. Подробнее – тут. Slash-команды обеспечивают быструю установку MCP-сервера, выбор ИИ-модели под текущий запрос. По сути, мы говорим о фиксированных промтах, инструкциях, которые вводим через префикс и
/ в CLI. Подборка:
/clear – очистить контекст текущей сессии. Используется при смене задач, репозиториев или если накопленный контекст начинает влиять на подсказки./exit, /quit – завершить сессии, выход из CLI/session, /usage – посмотреть информацию о сессии и статистика использования. Полезны для аудита активности, мониторинга действий Copilot/add-dir <directory> – добавить директорию для доступа Copilot. Ограничивает область видимости и повышает безопасность./list-dirs – показать список директорий, доступных Copilot./cwd [directory] – показать или сменить рабочую директорию./model [model] – выбрать модель Copilot для CLI./theme [show|set|list] – управлять темой терминала, единый стиль для команды./reset-allowed-tools – сбросить разрешения на использование инструментов. Полезна для аудита./agent – выбрать Copilot-агента для отдельных задач./delegate <prompt> – делегировать задачи агенту с pull-request-ом./share [file|gist] – экспортировать сессии в Markdown или GitHub Gist для документации или передачи коллегам./login, /logout – войти/выйти из CLI, управлять доступом, сменить пользователя /mcp [show|add|edit|…] – управлять конфигурацией MCP-серверов, обновить CI/CD прокси-конфигурации и enterprise настройки./user [show|list|switch] – управлять пользователями GitHub в терминале. /help – список всех команд. /feedback — сообщить об ошибках команде GitHub.#devops #github
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍3🔥2❤1🤔1
🔧Чиним кластеры: игра по освоению Kubernetes
В эту пятницу отправляемся в приключение! На GitHub вышел K8sQuest для тех, кто устал читать доки и хочет разобраться, как дебажить в проде на практике. В игре представлены 5 миров и 50 уровней, где предстоит разбираться с реальными проблемами внутри кластера:
⏺ Мир 1: CrashLoopBackOff, ImagePullBackOff, pending поды, метки, порты
⏺ Мир 2: Deployments, HPA, пробы работспособности и готовности, откаты
⏺ Мир 3: Сервисы, DNS, Ingress, Сетевые политики
⏺ Мир 4: PVs, PVCs, StatefulSet-ы, ConfigMap-ы, Секреты
На 50-м уровне воцарится хаос: море ошибок, шторм неопределённости :) Будет интересно новичкам и опытным инженерам.
🚀 Делитесь в комментариях, до какого уровня дошли! Желаем хороших выходных, а дежурным – спокойных смен.
#devops #k8s #пятница
В эту пятницу отправляемся в приключение! На GitHub вышел K8sQuest для тех, кто устал читать доки и хочет разобраться, как дебажить в проде на практике. В игре представлены 5 миров и 50 уровней, где предстоит разбираться с реальными проблемами внутри кластера:
На 50-м уровне воцарится хаос: море ошибок, шторм неопределённости :) Будет интересно новичкам и опытным инженерам.
#devops #k8s #пятница
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍12🔥9❤4