Вся мощь GitLab CI в демонстрации плейбуков Ansible при подходе «инфраструктура как код».

GitLab CI — это эффективный инструмент для самых разных сценариев, включая инфраструктуру как код. GitLab можно использовать с разными инструментами, но в этой демонстрации мы возьмем Ansible, потому что именно его чаще всего используют разработчики при подходе «инфраструктура как код». Вот демо с двумя маршрутизаторами ^[1] из курса по сетям Ansible ^[2].

Прелесть GitLab CI ^[3] в том, что код из плейбука Ansible ^[4] можно изменять и поставлять, не устанавливая никаких зависимостей локально. Демо-проект, который вызывает обновление строк SNMP на всех устройствах каждый месяц в соответствии с нашей политикой безопасности, можно полностью выполнить на GitLab.com ^[5], нашем сервисе размещения кода.

Для начала откройте плейбук Ansible, где есть 4 задачи:

• Gather router facts — сбор фактов о маршрутизаторах.
• Display version — отображение версии
• Display serial number — отображение серийного номера
• Configure SNMP — настройка SNMP.

В этом демо мы сосредоточимся на настройке строк SNMP, для которой нужно выполнить несколько простых шагов.

Начинаем с доски задач

Любой план на GitLab начинается одинаково: с задачи ^[6]. Итак, первый шаг рабочего процесса GitLab — проверить доску задач в проекте ansible-demo ^[7]. На доске задач ansible-demo ^[8] мы уже видим задачу: изменить строки SNMP на всех маршрутизаторах ^[9]. В задаче есть ссылка на wiki-страницу политики безопасности GitLab, где сказано, что строки SNMP нужно обновлять каждый месяц, и для операций «только для чтения» и «чтение и запись» должны быть разные строки.

Политика безопасности GitLab предписывает обновлять строки SNMP каждый месяц.

Потом нужно проверить, что команды для настройки строк SNMP в демо с двумя маршрутизаторами ^[1] не нарушают политику безопасности GitLab, описанную в задаче.

Команды для настройки строк SNMP доступны в плейбуке Ansible.

Потом вернитесь к задаче, назначьте ее себе и смените ярлык с to-do на doing на правой панели или просто перетащите задачу на доске из одного столбца в другой.

Создание мердж-реквеста

Теперь нужно создать из задачи мердж-реквест. Убедитесь, что у мердж-реквеста есть флаг Work in Progress (WIP) ^[10], чтобы он не попал в мастер преждевременно. Вместо локального подключения мы используем GitLab Web IDE ^[11], потому что изменения в строках SNMP незначительны.

• Откройте раздел демо CI/CD.
• Перейдите в плейбук Ansible.
• Измените раздел SNMP следующим образом:
• Обратите внимание, что для RO и RW настроены разные строки в соответствии с политикой безопасности GitLab ^[12], описанной в задаче ^[13].

Коммит изменений

Вы обновили строку SNMP по инструкции, а теперь нужно закоммитить изменения. Откройте параллельное сравнение изменений, чтобы убедиться, что мердж-реквест содержит последний коммит.

^[14]
Инструмент параллельного сравнения наглядно показывает изменения.

Результаты

Коммит изменений автоматически запустит пайплайн GitLab CI. Он выполнит следующие задачи:

• Проверка синтаксиса.
• Пробные прогоны.
• Тестирование изменений в лабораторной/искусственной среде.

Мы видим прогресс и выходные данные каждого задания в пайплайне GitLab CI, который обновляет SNMP.

^[15]
Выходные данные вашей задачи показывают, что обновления SNMP в искусственной среде прошли успешно.

Все эти задачи будут запущены и задокументированы в мердж-реквесте.

^[16]
Галочки показывают, что задача в пайплайне GitLab CI выполнена.

Затем войдите в маршрутизаторы для демо и посмотрите изменения.

^[17]
Изменения строк SNMP RO и RW отражены в маршрутизаторах.

Ревью мердж-реквеста

Можно выполнить дополнительный шаг — одобрение мердж-реквеста ^[18]. Если вы настроите одобрение, несколько пользователей смогут проверить изменения, прежде чем они попадут в продакшен.

^[19]
Мердж-реквест можно настроить так, чтобы другой пользователь проверял ваши труды, прежде чем они окажутся в мастере.

Передача в мастер

Изменения можно передать в мастер сразу после тестирования. Мастер — это главная ветвь, которая содержит код рабочей среды.

Когда будете готовы, нажмите кнопку Resolve Work In Progress. Затем нажмите Merge.

Когда вы разрешите статус WIP, мердж-реквест можно будет отправить в мастер, а задачу — закрыть.

Новый пайплайн прогонит все тесты, которые вы выполнили на дополнительном шаге запуска плейбука в продакшене.

Следите за прогрессом и логами на экране пайплайна. Когда процесс завершится, войдите в рабочие маршрутизаторы и убедитесь, что строки SNMP изменились.

Магия GitLab CI

Все это возможно благодаря магии GitLab CI. Пайплайны GitLab CI — это ряды последовательных задач, которые выполняют все необходимое для тестирования и реализации кода Ansible.

Вся конфигурация GitLab CI умещается в простом файле YAML, который хранится в репозитории .gitlab-ci.yml.

В этой демонстрации файл .gitlab-ci.yml содержит 3 этапа.

1. Deploy (развертывание): создает имитацию сети с двумя маршрутизаторами в AWS с помощью Ansible.
2. Demo (демо): выполняет плейбук, который изменит строки SNMP.
3. Destroy (уничтожение): уничтожает имитацию сети с двумя маршрутизаторами.

GitLab CI запускается с базовым образом. В этом случае мы используем образ Docker, который содержит весь необходимый код и зависимости Ansible. Укажите команды, которые будут выполняться на каждом этапе, и зависимости.

Простой файл YAML содержит три этапа GitLab CI.

Этап демонстрации GitLab CI, на котором выполняется плейбук Ansible.

Мы заглянули внутрь пайплайна и увидели, как можно использовать GitLab CI, чтобы создать инфраструктуру как код, даже не устанавливая зависимости Ansible на компьютер. Это лишь один пример того, как можно использовать GitLab CI, чтобы реализовать инфраструктуру как код. Полное руководство смотрите в видео:

Автор: nAbdullin

Источник ^[20]