Комментарии 10
Можно пойти несколько дальше и поставить ansible awx. В нём создаём templat'ы (это playbooks с параметрами) и их стартуем через gitlab-ci.
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.
Плюс ещё и в том, что можно прикрутить выполнение по плану, ручное выполнение. Ну и статус там тоже пишется.
Так может плейбуки хранить в гитлабе же? Зачем эта отдельная сущность, да ещё и так коряво вызываемая?
Можно их вынести в отдельную группу/репозитории и инклудить в своем проекте…
как же все это «замечательно». Вы пишите, что CI автоматически выполнит проверку синтаксиса. А где это у вас показано? Какими средствами это делается? Зафигачить строку SNMP — ничего страшного, потенциально. А вот ошибиться в синтаксисе acess-list-а и потом его недоделанный повесить на интерфейс — к долгой дороге.

Или дальше «выполнит проверку в тестовом окружении». Вы себе представляете тестовое окружение для нормальной сети? У меня вот в сети только зарегистрировано больше 1500 сервисов и часто они взаимосвязаны. Типов оборудования в сети — много. Кто мне все это сэмулирует в тесте?

Теоретики…

Соглашусь и не соглашусь. Соглашусь в том ключе, что действительно воссоздать продакшен инфраструктуру в тесте практически не реально точно. С другой стороны, это и не нужно для большинства задач. Достаточно здравого смысла, декомпозиции задачи и проверки того, что ты делаешь (хотя бы ад-хок — половина администрирования на этом держится). Также такой процесс вносит дополнительную сложность в пайплайн ввода изменений в систему(ы) — потому что надо сначала протестировать что будет, развернуть стенды и только после этого катить на прод, что в случае гарантированно неломающих изменений ОЧЕНЬ ДОРОГО.
Не соглашусь, т.к. нам нужно как-то двигаться в светлое будущее с очень сложными информационными системами. И старые подходы начинают с какого-то момента переставать работать. В случае инфры с 1500 разнородных компонентов при внесении изменений почти наверянка что-то будет ломаться, а без тестирования — даже не поймешь как эти изменения обкатывать. В общем, целое непаханное поле для бурной деятельности.
Главное — не допускать ошибок как местечковый провайдер в Америке, который положил КлаудФлейр или Яндекс, положивший пол-инета из-за некорректной настройки маршрутизаторов, но в этих случаях помимо недосмотра инженеров есть момент технической несовершенности протоколов, на которых фурыкает современный интернет, что и неудивительно, т.к. база закладывалась 30+ лет назад, когда таких масштабов не было и никто даже о них не мог подумтаь.

Мне вот не совсем понятно, кто-то спользует это на реальной сети?
Сам я пользуюсь Ansible для рутинных однотипных задач, просто редактируя плейбук через nano и запуская его из командной строки. Со всеми этими gitlab-ками и прочими ci/cd инструментами не знаком, в статье, видимо, рассчитано, что я уже знаю что, зачем и почему используется.
Вопрос, в чем преимущество использования GitLab в сравнении с простым запуском ansible плейбука из командной строки? Что мне даст gitlab?

Очевидно, что возможность строить существенно более сложный пайплайн и наглядно его визуализировать. Лишними не будут функции ревью, merge request и опций тестовых прогонов. К сожалению, гитлаб — это не автомагический инструмент и без помощи кодера он не в состоянии решить какую-либо сколь общую задачу, как, например, создание тестового стенда для проверки изменений конфигурации в маршрутизаторах. Но как платформа для создания такого продукта в рамках отдельно взятой компании, команды или проекта — почему нет

А автотесты для сети как будут выглядеть? CI без автоматической проверки так себе удовольствие…

Я могу попбровать потроллить и спросить, как будут выглядеть тесты для ad-hoc команды по заливке обновленного конфига для циски? Или все надеются, что оператор (или администратор) не ошибется? Как мне кажется, что проблема не гитлабе и не в CI/CD. А накостылить нужное количество "предохранителей" можно всегда (начиная от линтеров и проверяльщиков валидности конфига по синтаксису и кончая заливкой конфига в какой-либо тестовый стенд, стоимость восстановления которого не так высока, как риски упячить всю инфру)

Вы думаете администраторы критичных бизнес приложений не ошибаются? Вопрос к hw-only архитектуре сетей, в то время как в принципе уже есть возможность на white box поднимать виртуальные устройства и делать откат при непрохождении автотеста…

Я ничего не думаю. Я просто уверен, что если что-то может пойти не так (в принципе), то оно пойдет не так. К этому же относится и то, что люди имеют тенденцию ошибаться (и нейрохирурги, кстати, тоже могут).

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

22 февраля 2008 г.

Местоположение

Россия

Численность

31–50 человек

Дата регистрации

15 ноября 2012

Блог на Хабре