Comments 10
Gitlab-ci должнен выглядеть как-то так
ansible_play:
variables:
GIT_STRATEGY: none
stage: deploy
tags:
- ansible
script:
- "curl -X POST -s -k -u admin:LKAmflkj0813LAj1m 'https://awx.domain.local/api/v2/job_templates/Update files from git/launch/' --insecure"
«Update files from git» это template в awx.
Плюс ещё и в том, что можно прикрутить выполнение по плану, ручное выполнение. Ну и статус там тоже пишется.
Можно их вынести в отдельную группу/репозитории и инклудить в своем проекте…
Или дальше «выполнит проверку в тестовом окружении». Вы себе представляете тестовое окружение для нормальной сети? У меня вот в сети только зарегистрировано больше 1500 сервисов и часто они взаимосвязаны. Типов оборудования в сети — много. Кто мне все это сэмулирует в тесте?
Теоретики…
Соглашусь и не соглашусь. Соглашусь в том ключе, что действительно воссоздать продакшен инфраструктуру в тесте практически не реально точно. С другой стороны, это и не нужно для большинства задач. Достаточно здравого смысла, декомпозиции задачи и проверки того, что ты делаешь (хотя бы ад-хок — половина администрирования на этом держится). Также такой процесс вносит дополнительную сложность в пайплайн ввода изменений в систему(ы) — потому что надо сначала протестировать что будет, развернуть стенды и только после этого катить на прод, что в случае гарантированно неломающих изменений ОЧЕНЬ ДОРОГО.
Не соглашусь, т.к. нам нужно как-то двигаться в светлое будущее с очень сложными информационными системами. И старые подходы начинают с какого-то момента переставать работать. В случае инфры с 1500 разнородных компонентов при внесении изменений почти наверянка что-то будет ломаться, а без тестирования — даже не поймешь как эти изменения обкатывать. В общем, целое непаханное поле для бурной деятельности.
Главное — не допускать ошибок как местечковый провайдер в Америке, который положил КлаудФлейр или Яндекс, положивший пол-инета из-за некорректной настройки маршрутизаторов, но в этих случаях помимо недосмотра инженеров есть момент технической несовершенности протоколов, на которых фурыкает современный интернет, что и неудивительно, т.к. база закладывалась 30+ лет назад, когда таких масштабов не было и никто даже о них не мог подумтаь.
Сам я пользуюсь Ansible для рутинных однотипных задач, просто редактируя плейбук через nano и запуская его из командной строки. Со всеми этими gitlab-ками и прочими ci/cd инструментами не знаком, в статье, видимо, рассчитано, что я уже знаю что, зачем и почему используется.
Вопрос, в чем преимущество использования GitLab в сравнении с простым запуском ansible плейбука из командной строки? Что мне даст gitlab?
Очевидно, что возможность строить существенно более сложный пайплайн и наглядно его визуализировать. Лишними не будут функции ревью, merge request и опций тестовых прогонов. К сожалению, гитлаб — это не автомагический инструмент и без помощи кодера он не в состоянии решить какую-либо сколь общую задачу, как, например, создание тестового стенда для проверки изменений конфигурации в маршрутизаторах. Но как платформа для создания такого продукта в рамках отдельно взятой компании, команды или проекта — почему нет
А автотесты для сети как будут выглядеть? CI без автоматической проверки так себе удовольствие…
Я могу попбровать потроллить и спросить, как будут выглядеть тесты для ad-hoc команды по заливке обновленного конфига для циски? Или все надеются, что оператор (или администратор) не ошибется? Как мне кажется, что проблема не гитлабе и не в CI/CD. А накостылить нужное количество "предохранителей" можно всегда (начиная от линтеров и проверяльщиков валидности конфига по синтаксису и кончая заливкой конфига в какой-либо тестовый стенд, стоимость восстановления которого не так высока, как риски упячить всю инфру)
Создаем инфраструктуру как код с GitLab и Ansible