«У меня был случай, когда Argo CD управлял сам собой, и я по глупости запустил синхронизацию его чарта для обновления, не проверив как следует diff. Это привело к удалению и пересозданию Application CRD.
В итоге Argo CD снёс вообще все приложения, которые этим CRD управлялись, — а это около 280 сервисов в разных кластерах.
и
«У меня была похожая история, только сервисов было поменьше. Экспериментировал с приложениями Argo CD прямо на проде — удалил одно, чтобы запустить другое. А он в итоге прибил всё, даже пространство имён.
Хочу подсветить важный аспект: OpenTelemetry Gateway становится единой точкой отказа для всей телеметрии. При его падении, например при неправильном конфиге, теряются одновременно метрики, логи и трейсы — именно когда они больше всего нужны для разбора инцидента. При проблемах на стороне Tempo, Prometheus, Loki у OpenTelemetry будет переполнятся память и возможно он упадет. Этот риск нужно учитывать.
Формулировка "релиз на мне" говорит о слабой автоматизации и недостатке формализованных процессов. В зрелых DevOps-командах релиз ― это нажатие кнопки через CI/CD-процессы, а не ручная работа одного человека. Если кто-то год не релизил и процесс всё ещё сложен или слабо документирован, значит, и команда, и практики DevOps нуждаются в пересмотре. Лучше использовать trunk-based development вместо git flow или github flow, поскольку trunk-based development упрощает процессы интеграции, ускоряет выпуск изменений и снижает риски, связанные с долгоживущими ветками. Решение ― автоматизация релизов, актуализация документации и работа по trunk-based development: тогда роль отдельного человека исчезнет сама собой.
модули тут не играют особой роли- именно потому что они в нашем случае это код, а подход предпологает отделение данных и управление именно через данные.
Terraform модули, а также terragrunt — предполагает отделение данных и управление именно через данные.
Выгода достигаеться от наличия в гите множества плоских конфигов в которых только флаги или переменнные.
Что за плоские конфиги?
Просто представьте что терраформ для вас черная коробка- и все что вам надо знать - для создания нового кластера кубернетеса в новом регионе вам надо скопировать один yaml файл и отредактировать его, сохранить- и все остальное выполниться без вас. Еще раз этот файл не содержит код, а только кастомизацию в виде переменных и флагов.
для создания нового кластера кубернетеса в новом регионе вам надо скопировать один terragrunt.hcl файл и отредактировать его, сохранить- и все остальное выполниться без вас. Еще раз этот файл не содержит код, а только кастомизацию в виде переменных и флагов.
Суть подхода в том, чтобы описывать инфраструктуру с помощью данных — YAML, JSON, переменных
Не вижу отличий от Infrastructure as Code
а не менять код конфигурации вручную при малейшем изменении.
Не пойму эту мысль.
Вы просто меняете параметр(переменную), а все необходимые действия выполняет заранее написанный код или сервис.
Это terraform модули, helm чарты или operator в k8s.
В отличие от Infrastructure as Code (IaC), где изменения чаще всего касаются самого кода
Инфраструктура как код (Infrastructure as Code, IaC) — это подход к автоматизации и управлению инфраструктурой через использование кода. А используете через чистый terraform, через terraform модули, это личное дело каждого.
IaD предлагает отделить данные от логики.
Это terraform модули, helm чарты или operator в k8s.
Прочитав статью могу сказать что вы придумали terraform модули, helm чарты, operator в k8s.
1) Как может быть managed kubernetes, если вы облака не используете? 4) Вот список фич gitlab premium, которые могли бы закрыть часть проблем из статьи: • Merge Request Analytics - детальная аналитика кода, метрики производительности - что то вроде DORA метрик • Advanced Search - глобальный поиск по коду, коммитам, issues • Push Rules - продвинутые правила для коммитов и веток • Approval Rules - обязательные аппрувы от конкретных людей/групп
6) У вашей компании есть деньги на дорогой ELK и датадог, а на еще одного devops инженера денег нет. 9) Речь не бекенд, фронтенд 10) а oncall/pagerduty или аналог используется?
Соотношение кол-ва devops инженеров к разработчикам? Может ли разработчик сделать самостоятельно review стенд? У вас микросервисы или монолит?
Компания относится к банкам или финансам? Есть ли персональные или банковские данные?
Добавьте пожалуйста в статью технические детали: Используются ли облачные провайдеры или свое железо? Используется ли Kubernetes? Если используется Kubernetes, то какой? самосбор или managed решение? Используется ли платный GitLab ? Какие CI/CD инструменты используются для автоматизации сборки и деплоя? Какие инструменты мониторинга и логирования применяются в продакшене? Есть ли метрики Dora? Как часто происходят релизы? Какие метрики отслеживаются для оценки производительности приложений? Используется ли helm? Как организован incident management? Пишите ли постмортемы?
Соотношение кол-ва devops инженеров к разработчикам? Может ли разработчик сделать самостоятельно review стенд?
На s3 может складывать лампы и восстанавливаться из s3?
Нашел https://github.com/openstf/stf
А stf это ваша разработка или open source?
In line with Canonical’s commitment to enable the latest features and hardware support, Ubuntu 25.10 ships with the latest Linux kernel, version 6.17.
Обновленная команда
Вот бы посмотреть визуальную Android/Gradle сборку
и
можно в этот список добавить как у Skyscanner были удалены все приложения во всех namespace:
У Skyscanner в системе развёртывания ArgoCD была предпринята попытка синхронизировать конфигурацию кластеров. В отсутствие валидных пространств имён в новой конфигурации началось массовое удаление всех 478 сервисов во всех пространствах имён и в регионах по всему миру.
Спасибо за пост. А через код можно настроить postgresus ?
А есть ли какая нибудь утилита, которой указываешь Postgresql и она показывает в выводе какие типы данных нужно поправить?
Большое спасибо за утилиту. Сделайте пожалуйста бинарник в релизах github.
Пока что много забот. Надо найти время посмотреть.
Спасибо за подробный разбор.
Хочу подсветить важный аспект: OpenTelemetry Gateway становится единой точкой отказа для всей телеметрии. При его падении, например при неправильном конфиге, теряются одновременно метрики, логи и трейсы — именно когда они больше всего нужны для разбора инцидента. При проблемах на стороне Tempo, Prometheus, Loki у OpenTelemetry будет переполнятся память и возможно он упадет. Этот риск нужно учитывать.
Формулировка "релиз на мне" говорит о слабой автоматизации и недостатке формализованных процессов. В зрелых DevOps-командах релиз ― это нажатие кнопки через CI/CD-процессы, а не ручная работа одного человека. Если кто-то год не релизил и процесс всё ещё сложен или слабо документирован, значит, и команда, и практики DevOps нуждаются в пересмотре. Лучше использовать trunk-based development вместо git flow или github flow, поскольку trunk-based development упрощает процессы интеграции, ускоряет выпуск изменений и снижает риски, связанные с долгоживущими ветками. Решение ― автоматизация релизов, актуализация документации и работа по trunk-based development: тогда роль отдельного человека исчезнет сама собой.
Я хочу сказать, что практическое применение этого подхода это terraform модули, terragrunt, helm чарты, operator в k8s.
Terraform модули, а также terragrunt — предполагает отделение данных и управление именно через данные.
Что за плоские конфиги?
для создания нового кластера кубернетеса в новом регионе вам надо скопировать один terragrunt.hcl файл и отредактировать его, сохранить- и все остальное выполниться без вас. Еще раз этот файл не содержит код, а только кастомизацию в виде переменных и флагов.
Спасибо за пост. Вопрос
Не вижу отличий от Infrastructure as Code
Не пойму эту мысль.
Это terraform модули, helm чарты или operator в k8s.
Инфраструктура как код (Infrastructure as Code, IaC) — это подход к автоматизации и управлению инфраструктурой через использование кода. А используете через чистый terraform, через terraform модули, это личное дело каждого.
Это terraform модули, helm чарты или operator в k8s.
Прочитав статью могу сказать что вы придумали terraform модули, helm чарты, operator в k8s.
готово
Достойных opensource self-hosted альтернатив не вижу.
1) Как может быть managed kubernetes, если вы облака не используете?
4) Вот список фич gitlab premium, которые могли бы закрыть часть проблем из статьи:
• Merge Request Analytics - детальная аналитика кода, метрики производительности - что то вроде DORA метрик
• Advanced Search - глобальный поиск по коду, коммитам, issues
• Push Rules - продвинутые правила для коммитов и веток
• Approval Rules - обязательные аппрувы от конкретных людей/групп
6) У вашей компании есть деньги на дорогой ELK и датадог, а на еще одного devops инженера денег нет.
9) Речь не бекенд, фронтенд
10) а oncall/pagerduty или аналог используется?
Соотношение кол-ва devops инженеров к разработчикам?
Может ли разработчик сделать самостоятельно review стенд?
У вас микросервисы или монолит?
Компания относится к банкам или финансам? Есть ли персональные или банковские данные?
Добавьте пожалуйста в статью технические детали:
Используются ли облачные провайдеры или свое железо?
Используется ли Kubernetes?
Если используется Kubernetes, то какой? самосбор или managed решение?
Используется ли платный GitLab ?
Какие CI/CD инструменты используются для автоматизации сборки и деплоя?
Какие инструменты мониторинга и логирования применяются в продакшене?
Есть ли метрики Dora?
Как часто происходят релизы?
Какие метрики отслеживаются для оценки производительности приложений?
Используется ли helm?
Как организован incident management?
Пишите ли постмортемы?
Соотношение кол-ва devops инженеров к разработчикам?
Может ли разработчик сделать самостоятельно review стенд?