company_banner

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

Автор оригинала: Sara Kassabian, Brad Downey
  • Перевод


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


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


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


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


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

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


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


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


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


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



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


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


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


Когда будете готовы, нажмите кнопку 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, чтобы реализовать инфраструктуру как код. Полное руководство смотрите в видео:


Southbridge
564,94
Обеспечиваем стабильную работу highload-проектов
Поделиться публикацией

Похожие публикации

Комментарии 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

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

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

          Самое читаемое