Как понять, что пора переписать свой Ansible playbook?
Все мы знаем, что конфигурация - это живой организм. Когда-то ты писал маленький playbook на пару тасков, а через полгода он превратился в монстра на 500 строк, который страшно трогать. Вот признаки, что пора остановиться и переписать:
1. Copy-paste вместо ролей.
Если в нескольких playbook-ах повторяется один и тот же блок задач - это крик о помощи. Вынеси это в роль.
2. Нет структуры.
Папка
3. Много условностей.
Когда в тасках появляются километровые
4. Сложно тестировать.
Если каждый прогон - это боль и сюрпризы на проде, самое время добавить Molecule и хотя бы минимальные тесты.
5. Никто не хочет трогать.
Если команда боится открывать файл, значит, он уже не решает задачи, а создает их.
Совет: не бойся переписывать. В Ansible, как и в коде, рефакторинг - это норма. Маленькие, модульные роли проще поддерживать, тестировать и читать.
Подпишись 👉@devopslib
Все мы знаем, что конфигурация - это живой организм. Когда-то ты писал маленький playbook на пару тасков, а через полгода он превратился в монстра на 500 строк, который страшно трогать. Вот признаки, что пора остановиться и переписать:
1. Copy-paste вместо ролей.
Если в нескольких playbook-ах повторяется один и тот же блок задач - это крик о помощи. Вынеси это в роль.
2. Нет структуры.
Папка
playbooks/ превращается в свалку из файлов с именами new.yml, fix2.yml. Пора завести нормальную структуру с ролями и группировкой по окружениям.3. Много условностей.
Когда в тасках появляются километровые
when, это знак, что playbook делает слишком много за раз. Лучше разделить.4. Сложно тестировать.
Если каждый прогон - это боль и сюрпризы на проде, самое время добавить Molecule и хотя бы минимальные тесты.
5. Никто не хочет трогать.
Если команда боится открывать файл, значит, он уже не решает задачи, а создает их.
Совет: не бойся переписывать. В Ansible, как и в коде, рефакторинг - это норма. Маленькие, модульные роли проще поддерживать, тестировать и читать.
Подпишись 👉@devopslib
👍2
В хабе на Хабр «Разработка публичных облаков» — свежие статьи
от инженеров MWS Cloud Platform⬜️ .
➡️ Создаем S3-хранилище с нуля. Ультимативный лонгрид про современный S3-ландшафт и нашу архитектуру Object Storage.
➡️ Multus в Kubernetes. Как мы подключили поды к сервисам в overlay-сети с IPv4 и зачем это вообще понадобилось.
➡️ DHCP-сервер облака. Как мы раздаём один и тот же IP в изолированных сетевых пространствах (VRF), какие используем опции и как мониторим доступность DHCP-серверов.
➡️ Development Platform. Зачем мы пишем общие библиотеки и компоненты, как развиваем внутренний open source и с помощью каких инструментов общаются сервисы MWS Cloud Platform и их создатели.
Если вам интересны архитектурные решения для настоящего highload'а — эти материалы будут вам полезны.
🔗 Подпишись на облачный хаб MWS — там регулярно рассказываем, как строим новое облако с нуля.
от инженеров MWS Cloud Platform
Если вам интересны архитектурные решения для настоящего highload'а — эти материалы будут вам полезны.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Мониторинг — это не только графики
Мы все любим красивые дашборды: CPU, RAM, диск, трафик… Но сколько раз вы смотрели на Grafana, а проблему всё равно приходилось искать вручную?
Вот что реально делает мониторинг полезным:
- Алерты с контекстом. Сообщение “CPU > 90%” бесполезно, если не понятно на каком сервисе, с чем связано и что делать.
- Трассировка. Логи и метрики без распределённого трейса — как карта без маршрута. Jaeger, Tempo и OpenTelemetry — must have.
- SLO, а не SLA. Забудьте про “uptime 99.9%”. Важно понимать, что реально чувствует пользователь, и строить алерты на основе опыта, а не железа.
- Автоматизация реакции. PagerDuty и OpsGenie хорошо, но скрипт, который сам перезапустит упавший сервис, иногда спасает нервы.
Мониторинг — это не про цифры. Это про быстрое понимание: что сломалось, почему и что делать прямо сейчас.
Подпишись 👉@devopslib
Мы все любим красивые дашборды: CPU, RAM, диск, трафик… Но сколько раз вы смотрели на Grafana, а проблему всё равно приходилось искать вручную?
Вот что реально делает мониторинг полезным:
- Алерты с контекстом. Сообщение “CPU > 90%” бесполезно, если не понятно на каком сервисе, с чем связано и что делать.
- Трассировка. Логи и метрики без распределённого трейса — как карта без маршрута. Jaeger, Tempo и OpenTelemetry — must have.
- SLO, а не SLA. Забудьте про “uptime 99.9%”. Важно понимать, что реально чувствует пользователь, и строить алерты на основе опыта, а не железа.
- Автоматизация реакции. PagerDuty и OpsGenie хорошо, но скрипт, который сам перезапустит упавший сервис, иногда спасает нервы.
Мониторинг — это не про цифры. Это про быстрое понимание: что сломалось, почему и что делать прямо сейчас.
Подпишись 👉@devopslib
🔥2👍1