Comments 18
client-1 Ubuntu 18.04
client-2 CentOS 7
Эти ОС уже устарели и для них не выпускаются обновления. Так что лучше использовать Ubuntu 24.04 и Oracle Linux 9.
Ansible-pull
Получается, что на каждом сервер мы должны иметь свои инсталляцию Ansible? Если да, то это плохой вариант, т.к. обслуживать большое количество инсталляций Ansible очень неудобно.
Как по мне у ansible-pull две проблемы:
1. Как понять, что какая-то джоба упала?
Проверять логи на всех серверах? Проверять логи в ELK? Писать какую-то свою метрику и настраивать алёртинг на неё? Всё-таки это не очень удобно.
2. Что делать с заданиями, которые являются частью сервера, но не должны выполняться на нём.
Как пример, мы автоматом создаём DNS имя для сервера, таску для выполнения нужно имя сервера и его ip, однако где хранить креды для изменения DNS зоны? Разливать на все хосты? Не самое лучшее решение.
Согласен, падение джобы узла без доработок незаметно. Нужны системы сбора и анализа логов, с кредами надо думать.
Почему бы не использовать сам гитлаб в качестве запускатора?
У него есть свой шедулер, есть возможность задавать разные значения для одноименных переменных на разных окружениях, есть достаточно простая интеграция с волтом
Раскатываем на машину ансибл, гит и раннер гитлаба, регистрируем шелл-раннер, настраиваем права и добавляем новую джобу для нового сервера из какого-нибудь шаблона
У нас появляется история джоб со всеми логами, автоматические оповещения на почту при падениях (или, при желании, кастомные нотификации в какую-нибудь телегу) + удобный менеджмент и система хранения секретов через переменные + прочие приятности и полезности нормальной CI-системы
Всё зависит от масштабов и условий. Если речь идёт о нескольких серверах в стабильной сети, использование GitLab Runner действительно может быть удобнее. Однако в случае сотен узлов, разбросанных географически, где некоторые элементы инфраструктуры могут быть временно недоступны, гитлаб раннер уже не будет таким надёжным.
Кроме того, при большом количестве раннеров возможна высокая нагрузка на GitLab, что приведёт к снижению его производительности или даже сбоям
В saltstack к слову можно настроить рассылку алертов если применение конфигов завершилось неудачей
Посмотрите в сторону любого оркестратора k8s, nomad, mesos что там живое еще…
Ansible знаю слабо. В описанном варианте Ansible подключается по ssh к root@localhost?
+1 за гитлабраннер который делает все что надо
Salt не?
Какие-то откровенно устаревшие и неоптимальные решения. Зачем cron, если есть systemd-timer с нормальным логированием и гораздо более гибкой логикой? Зачем конвейер с tee /var/log/... если сам ансибл нативно умеет выводить в структурированный лог результат своего выполнения?
Ansible-pull и GitLab CI/CD: когда лучше тянуть, чем толкать