Хабрахабр

[Перевод] Создаем инфраструктуру как код с GitLab и Ansible

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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


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

Результаты

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

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

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


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

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


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

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


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

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

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


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

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

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

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

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

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

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

Магия GitLab CI

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

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

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

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

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


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


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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть