Автоматизация: от Ansible до стабильной инфраструктуры 🚀

Решил впервые разобраться с Ansible и зафиксировать для себя основные принципы. На картинке ниже — мой «базовый набор» для DevOps: от идемпотентности до инструментов безопасности IaC. ​Но теория — теорией, а на практике всё интереснее. ​Сегодня пробовал применить эти знания для настройки внутренней инфраструктуры: нужно было поднять сервис Semaphore внутри сети Tailscale. И тут стало понятно, что автоматизация работает только тогда, когда сеть, DNS и прокси настроены так же чисто, как и сам YAML-плейбук. ​Что усвоил из этой практики:

DNS — это не магия, а кэш. Даже если nslookup видит IP, браузер может «залипнуть» на старых путях. Иногда решение не в перенастройке всего подряд, а в простой очистке DNS-кеша системы и браузера.

Безопасность (IaC) — это не только Checkov или Trivy. Это еще и правильные правила UFW. Я закрыл прямой доступ к порту приложения (3002), оставив только Caddy в качестве точки входа. Теперь сервис надежно спрятан за прокси.

Приватность против публичности. Для внутренних доменов в Tailscale выбрал tls internal вместо попыток выпустить публичные сертификаты Let's Encrypt. Это надежнее для закрытой сети, а вопрос с «небезопасным соединением» в браузере решается одним кликом «Доверять». ​Мой вывод: Хороший код — это лишь половина дела. Настоящая стабильность начинается с архитектуры, где каждый элемент (от прокси до правил фаервола) стоит на своем месте. ​Коллеги, интересно ваше мнение: какой «золотой стандарт» вы используете для настройки проксирования внутренних сервисов? Ставите публичные сертификаты через DNS-01 или предпочитаете доверять внутренним CA? Давайте обсудим в комментариях! 👇

Автоматизация: от Ansible до стабильной инфраструктуры 🚀 | Сетка — социальная сеть от hh.ru