ДОПОЛНЕНИЕ: Я не сторонник такого метода, который был описан в статье. Считаю, что практичнее и удобнее использовать ArgoCD. Тем не менее, на одном из проектов использовалась связка git pull - crontab. Мне стало интересно, почему было реализовано именно так, и это сподвигло меня к написанию поста. Для обсуждения прошу в комментарии.

Инфраструктура как код, GitOps, автоматизация — все эти слова давно перестали быть модными терминами и стали частью повседневной жизни инженера. Но вместе с этим появляются и вопросы: а всегда ли нужно внедрять тяжелые инструменты? Например, зачем нужен ArgoCD, если можно просто настроить cron с git pull на нужный сервер?

Попробуем разобраться, в чём разница между этими подходами, какие задачи они решают, где их границы применимости и, главное, в каких случаях cron — это «дешево и сердито», а когда он становится «дешево, но больно».

Что такое cron с git pull?

Самый простой способ автоматизировать обновление состояния кластера или сервера из git — это скрипт, который по расписанию делает git pull, а затем применяет конфигурации. Например, для Kubernetes это может быть kubectl apply -f. Для простого веб-приложения — просто перезапуск сервиса.

Это может выглядеть так:

*/5 * * * * cd /opt/config && git pull && kubectl apply -f .

Плюсы:

• Простота. Можно настроить за 10 минут.

• Минимум зависимостей. Cron есть почти в любой Unix-системе.

• Полный контроль над тем, что происходит.

Минусы:

• Нет истории применений, откатов, контроля за тем, что реально изменилось.

• Нет встроенной проверки состояния (всё ли применилось, запустилось ли приложение, упал ли под).

• Проблемы при конфликтах — если git pull не проходит из-за конфликта, обновления зависают.

• Сложно масштабировать и поддерживать при росте количества сервисов.

• Нет визуализации, нет аудита, нет ролевой модели.

Что такое ArgoCD?

ArgoCD — это инструмент для внедрения GitOps в Kubernetes. Он синхронизирует состояние кластера с тем, что описано в git-репозитории. Работает в режиме pull: сам ArgoCD периодически опрашивает git и применяет изменения.

Особенности:

• Интерфейс: есть веб-UI, CLI, REST API.

• Отслеживание состояния — показывает, насколько текущее состояние отличается от желаемого.

• Поддержка helm, kustomize, jsonnet и plain manifests.

• Возможность отката к предыдущему коммиту.

• RBAC: доступ к приложениям можно ограничить.

• Поддержка множественных кластеров из одного ArgoCD.

Плюсы:

• Надежная синхронизация. Если кто-то вручную внёс изменения в кластер, ArgoCD всё вернёт как было в git.

• Видимость. Можно посмотреть, какие приложения в каком состоянии.

• Безопасность. Можно дать доступ только на просмотр или только на одни приложения.

• Автоматизация. Простой путь к CI/CD через GitOps.

Недостатки:

• Более сложная настройка по сравнению с cron.

• Требует запуска в кластере Kubernetes (или как минимум доступа к нему).

• Иногда избыточен для маленьких проектов или проектов не в Kubernetes.

Сравнение подходов

Где cron уместен?

Есть случаи, когда cron — это нормально. Например:

• Небольшой pet-проект, где 1–2 конфигурационных файла.

• Не Kubernetes, а просто перезапуск systemd-сервисов.

• Эксперименты или временные стенды.

• Когда не хочется тянуть за собой весь Kubernetes и CI/CD стек.

Но даже тут стоит предусмотреть механизмы:

• Проверка ошибок git pull и kubectl apply.

• Уведомления в случае сбоя (например, через mail или Telegram API).

• Логирование в файл с ротацией.

• Возможность отката — хотя бы через git checkout на конкретный коммит.

Когда cron становится проблемой

Рассмотрим реальный кейс. Допустим, у вас десяток приложений, каждое в своём namespace. На каждое настроен cron, который тянет свой репозиторий и применяет манифесты. Кто-то случайно закоммитил неправильный ingress — поломался доступ ко всем сервисам. Cron отработал — никто не заметил. Разбирайтесь теперь по логам, руками находите коммиты, применяйте kubectl rollout undo, если повезло.

В ArgoCD в этой же ситуации вы бы:

1. Увидели в UI, что приложение не синхронизировано или находится в ошибке.

2. Перешли на коммит назад одной кнопкой.

3. Получили уведомление в Slack/Telegram.

4. Могли бы ввести ручное подтверждение перед деплоем в прод.

Заключение

Cron с git pull — это рабочий и простой подход. Иногда даже оправданный. Но только до тех пор, пока не начинаются проблемы: рост количества сервисов, ошибки в манифестах, необходимость аудита и безопасности. ArgoCD решает все эти задачи из коробки, хотя и требует немного большего порога входа.

Если вы начинаете проект или делаете MVP — начните с cron. Но держите в голове, что это временное решение. Как только инфраструктура станет сложнее, переходите на GitOps-инструменты — ArgoCD, Flux или аналогичные. Это инвестиция в стабильность, масштабируемость и сон DevOps-инженера.