Search
Write a publication
Pull to refresh

Comments 17

Я не понял, вы на арго сд перешли потому что неудобно в гитлабе работать через монорепозиторий?

Не совсем. В GitLab с монорепозиторием можно работать удобно, но для деплоя мы выбрали pull-модель и GitOps. Мы минимизировали количество шагов в пайплайне. Конфигурация ресурсов в кластере хранится в отдельном репозитории и автоматически синхронизируется контроллером ArgoCD.

Ансиблом pods не деплоите? Слышал что в старых проектах до сих пор используют.

А расскажите лучше про конфликты, ошибки и т.п.

Например, когда удаляется/меняется ключевая зависимость, типа persistent volume, т.е. в целом нештатные ситуации в процессе достижения той самой консистентности.

в провайдере IT-решений Hilbert Team.

Есть H заменит на D, то получится Dilbert Team, а Dilbert - это название серии комиксов и имя их главного героя. В них рассказывается об офисной жизни. Дилберт — собирательный образ инженера, работающего в хайтек-компании и любящего технологии больше, чем людей.

А у меня в памяти всплыл Bill Gilbert, кто близок к миру ZX Spectrum наверняка вспомнят ))

На самом деле с ArgoCD существует гораздо больше проблем, чем кажется на первый взгляд, но это действительно большой шаг вперёд по сравнению с описанной Push-моделью. Удачи в расширении области применения GitOps-подхода!

Спасибо за пост. Какие приложения выкатываете? бизнес приложения или инфраструктурные?

На данный момент с помощью ArgoCD мы выкатываем как инфраструктурные, так и бизнесовые приложения.

Всё можно было очень сильно сжать, потому что про сам ArgoCD у вас почти и нет ничего.

Интереснее другое: как отслеживать статус апгрейда и автоматически откатываться при проблемах. Ничего про это не нашел.

Как отслеживать статус – все видно в интерфейсе Argo CD. По умолчанию стратегия деплоя – RollingUpdate, и это не позволит подняться новому релизу, если не пройдет health-check. Argo CD не вносит никаких изменений в GitOps-репозиторий, поэтому можно добавить в пайплайн джобу для отката на предыдущий тег в случае проблем с релизом.

На самом деле, в данный момент мы занимаемся введением в эксплуатацию Argo Rollouts как инструмента для реализации канареечного деплоя. Это позволит более гибко управлять релизами приложений.

Почему для выкатки бизнес приложений начали использовать gitops подход? Для бизнес приложений нужны dev/uat/staging/perfomance/prod сдеды для тестирования на разных стадиях разработки.

Во многом потому, что процесс создания статического стенда нового окружения сводится к простому Ctrl-C Ctrl-V. В каждый Kubernetes-кластер вкатывается Argo CD terraform-ом, и проекты просто переносятся с небольшими изменениями. Возможно, это займет чуть больше времени, чем создание шаблонов для Kustomize, но в итоге выглядит более наглядно, удобно и структурировано.

Sign up to leave a comment.