Southbridge corporate blog
System administration
Server Administration
DevOps
Comments 10
0
Можно пойти несколько дальше и поставить 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.
Плюс ещё и в том, что можно прикрутить выполнение по плану, ручное выполнение. Ну и статус там тоже пишется.
+1
Так может плейбуки хранить в гитлабе же? Зачем эта отдельная сущность, да ещё и так коряво вызываемая?
Можно их вынести в отдельную группу/репозитории и инклудить в своем проекте…
+3
как же все это «замечательно». Вы пишите, что CI автоматически выполнит проверку синтаксиса. А где это у вас показано? Какими средствами это делается? Зафигачить строку SNMP — ничего страшного, потенциально. А вот ошибиться в синтаксисе acess-list-а и потом его недоделанный повесить на интерфейс — к долгой дороге.

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

Теоретики…
+1

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

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

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

0

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

0

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

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

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

Only those users with full accounts are able to leave comments. , please.