Спасибо за комментарий. Скриншотов нет, потому что все делается из консоли. Но я везде добавил консольный вывод чтобы можно было проверить и сравнить вывод
«У меня был случай, когда 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 файл и отредактировать его, сохранить- и все остальное выполниться без вас. Еще раз этот файл не содержит код, а только кастомизацию в виде переменных и флагов.
Спасибо за комментарий. Скриншотов нет, потому что все делается из консоли. Но я везде добавил консольный вывод чтобы можно было проверить и сравнить вывод
Спасибо за пост. Рассматривали ли VictoriaMetrics? Как вы собираете логи? Собираете ли трейсы?
Спасибо за пост. Скажите за чем вам столько много виртуалок. Сейчас же популярны облака и kubernetes.
Установлен паралельно Loki. Смотрим в Loki и в VictoriaLogs
ELK слишком жирный. Вместо ELK лучше использовать https://github.com/VictoriaMetrics/VictoriaLogs/
На 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 файл и отредактировать его, сохранить- и все остальное выполниться без вас. Еще раз этот файл не содержит код, а только кастомизацию в виде переменных и флагов.