Во многом потому, что процесс создания статического стенда нового окружения сводится к простому Ctrl-C Ctrl-V. В каждый Kubernetes-кластер вкатывается Argo CD terraform-ом, и проекты просто переносятся с небольшими изменениями. Возможно, это займет чуть больше времени, чем создание шаблонов для Kustomize, но в итоге выглядит более наглядно, удобно и структурировано.
Как отслеживать статус – все видно в интерфейсе Argo CD. По умолчанию стратегия деплоя – RollingUpdate, и это не позволит подняться новому релизу, если не пройдет health-check. Argo CD не вносит никаких изменений в GitOps-репозиторий, поэтому можно добавить в пайплайн джобу для отката на предыдущий тег в случае проблем с релизом.
На самом деле, в данный момент мы занимаемся введением в эксплуатацию Argo Rollouts как инструмента для реализации канареечного деплоя. Это позволит более гибко управлять релизами приложений.
Не совсем. В GitLab с монорепозиторием можно работать удобно, но для деплоя мы выбрали pull-модель и GitOps. Мы минимизировали количество шагов в пайплайне. Конфигурация ресурсов в кластере хранится в отдельном репозитории и автоматически синхронизируется контроллером ArgoCD.
Для развертывания одной ВМ это может и не совсем удобно, но в облаке Yandex Cloud может быть развернута достаточно сложная инфраструктура с различными каталогами, сетями и разграничением доступа к ним. В этом случае как раз важно указывать, какой ресурс в каком каталоге и в какой подсети будет создаваться.
К тому же такого рода идентификаторы являются уникальными в рамках всего облака, и их явное указание поможет позволить избежать ошибочного создания ресурса из-под другого аккаунта в другом облаке, указав идентификационные данные аккаунта с доступом в другое облако.
С подсетями тоже есть такой момент, что могут быть созданы разные подсети, с доступом в Интернет и без него. В результате, указав идентификатор сети, мы можем выбрать, будет ли ВМ иметь доступ в Интернет или только к хостам в той же сети.
Как уже отметил коллега: в таком случае для общих сервисов лучше использовать каталог common/infra. И там разворачивать инфраструктурные сервисы, общие для остальных окружений: Сontainer Registry, хранилище метрик наподобие Victoria, Elastic для сбора логов и так далее.
Во многом потому, что процесс создания статического стенда нового окружения сводится к простому Ctrl-C Ctrl-V. В каждый Kubernetes-кластер вкатывается Argo CD terraform-ом, и проекты просто переносятся с небольшими изменениями. Возможно, это займет чуть больше времени, чем создание шаблонов для Kustomize, но в итоге выглядит более наглядно, удобно и структурировано.
Как отслеживать статус – все видно в интерфейсе Argo CD. По умолчанию стратегия деплоя – RollingUpdate, и это не позволит подняться новому релизу, если не пройдет health-check. Argo CD не вносит никаких изменений в GitOps-репозиторий, поэтому можно добавить в пайплайн джобу для отката на предыдущий тег в случае проблем с релизом.
На самом деле, в данный момент мы занимаемся введением в эксплуатацию Argo Rollouts как инструмента для реализации канареечного деплоя. Это позволит более гибко управлять релизами приложений.
На данный момент с помощью ArgoCD мы выкатываем как инфраструктурные, так и бизнесовые приложения.
Спасибо!
Thomas_Hanniball прикольно, спасибо😂
На самом деле мы назвались в честь математика Давида Гильберта)
что было в Легаси - остается в Легаси 😃
Не совсем. В GitLab с монорепозиторием можно работать удобно, но для деплоя мы выбрали pull-модель и GitOps. Мы минимизировали количество шагов в пайплайне. Конфигурация ресурсов в кластере хранится в отдельном репозитории и автоматически синхронизируется контроллером ArgoCD.
Сергей, спасибо за полезное дополнение!)
Спасибо за комментарий! Рад, что статья полезна)
Для развертывания одной ВМ это может и не совсем удобно, но в облаке Yandex Cloud может быть развернута достаточно сложная инфраструктура с различными каталогами, сетями и разграничением доступа к ним. В этом случае как раз важно указывать, какой ресурс в каком каталоге и в какой подсети будет создаваться.
К тому же такого рода идентификаторы являются уникальными в рамках всего облака, и их явное указание поможет позволить избежать ошибочного создания ресурса из-под другого аккаунта в другом облаке, указав идентификационные данные аккаунта с доступом в другое облако.
С подсетями тоже есть такой момент, что могут быть созданы разные подсети, с доступом в Интернет и без него. В результате, указав идентификатор сети, мы можем выбрать, будет ли ВМ иметь доступ в Интернет или только к хостам в той же сети.
Как уже отметил коллега: в таком случае для общих сервисов лучше использовать каталог common/infra. И там разворачивать инфраструктурные сервисы, общие для остальных окружений: Сontainer Registry, хранилище метрик наподобие Victoria, Elastic для сбора логов и так далее.