Статьи

Запуск Ansible Playbooks от Дженкинс

Июль 18, 2017

Ansible Playbooks

Ansible playbooks используются для выполнения многоэтапной процедуры на одном или нескольких удаленных компьютерах. Примером таких процедур может быть любой из следующих:

  • Изменяется логический набор системных уровней.

  • Развертывание на удаленных машинах.

  • Некоторые изменения конфигурации приложения, уже развернутого на удаленных компьютерах.

Сборник пьес не всегда должен выполняться на удаленной машине. Иногда это могут быть операции без сервера, такие как выполнение чего-либо с корзиной AWS S3 или подготовка виртуальных машин с использованием API, предоставляемых инструментом виртуализации или поставщиком общедоступного облака.

Вся процедура, которую выполняет Ansible playbook, делится на несколько задач. Как правило, каждая задача выполняется с помощью модуля Ansible или некоторой системной команды. Задачи могут быть определены непосредственно в сборнике пьес или ролях. Роль — это в основном набор задач многократного использования, которые выполняют полную процедуру. Например, Java может понадобиться для запуска разных приложений. В такой ситуации установка Java определяется как роль, которую может использовать любая книга воспроизведения для установки приложения, требующего Java, и, следовательно, зависимость Java может быть легко реализована.

Управление конфигурациями в Ansible

Ansible обычно называется системой управления конфигурацией (CM) и может использоваться для управления информацией среды обо всех стеках приложений и связанных ресурсах в компании. Роли и сборники игр должны быть рассчитаны на использование данных конфигурации, доступных в Ansible.

Хорошо спроектированные роли и сборники заданий настроены для работы с несколькими средами. Конфигурации, специфичные для среды, могут быть выведены из системы и поддерживаться в модулях vars, как в следующем примере:

envs:
   env1:
      app_server: app01.domain
      db_server: db01.domain
   env2:
      app_server: app02.domain
      db_server: db02.domain

В этом примере, книга воспроизведения может быть запущена в любой из сред, env1 или env2 , и книга воспроизведения может использовать связанные параметры конфигурации, определенные в Ansible, для внесения таких изменений:

  • Подключитесь к базе данных и внесите некоторые изменения в схему.

  • Обновление конфигурационный файл приложения , который имеет app_server и / или db_server элемент конфигурации в нем.

Модули vars загружаются в Ansible как структуры данных Python. В данном случае envs будет многоуровневым словарем, а параметр db_server для env2 может называться:

envs['env2']['db_server']

Когда playbook выполняется, вам нужно указать, в какой среде он работает. Один из способов сделать это — указать имя среды из командной строки, используя параметр extrasars Ansible playbook , как в этом примере:

$ ansible-playbook -i HOSTS-LIST install-app.yml -u USER -kK --extra-vars="env=env2"

В известной среде легко определить значение db_server в playbook как:

envs[env]['db_server']

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

Также необходимо указать список хостов, с которыми будет работать playbook. Если не существует базы данных управления конфигурациями (CMDB) или CMDB-подобной системы, которая могла бы динамически предоставлять списки хостов, рекомендуется хранить эту информацию в Ansible, как показано ниже, в модуле vars:

envs:
   env1:
      app_server: app01.domain
      db_server: db01.domain
      hosts:
         - host1-env1.domain
         - host2-env1.domain
         - app01.domain
         - db01.domain
   env2:
      app_server: app02.domain
      db_server: db02.domain
      hosts:
         - host1-env2.domain
         - host2-env2.domain
         - app02.domain
         - db02.domain

Если у вас есть список хостов в структуре данных YAML, такой, как эта, легко получить эту информацию в виде списка динамически с помощью простого скрипта Python, как показано в следующем примере.

#!/usr/bin/python

import sys
import yaml

env=sys.argv[1]
f=open('envs.yml')
envs=yaml.load(f)
hosts=envs['envs'][env]['hosts']
for host in hosts: print host

Значения элемента конфигурации и список хостов, сгенерированный таким образом, могут использоваться в качестве параметров при выполнении playbook.

Дженкинс как пользовательский интерфейс в Playbook

Дженкинс можно использовать в качестве интерфейса к сборнику пьес следующим образом:

  • Для сбора значений extra-vars необходимо запустить playbook с помощью формы работы Jenkins.

  • Для создания списков хостов и элементов конфигурации из модулей Ansible vars или из любого репозитория, к которому можно получить доступ с сервера Jenkins.

  • Для управления учетными данными, которые могут быть извлечены и внедрены в среду, в которой playbook запускает сценарии.

Настройка Playbook на Дженкинс

Трудно предоставить точные шаги по настройке Ansible playbook на Jenkins, потому что это зависит от того, как вы управляете playbooks и как SSH-доступ между хостами настроен в вашей организации. Для реализации стратегий, описанных здесь, достаточно того, кто знает как Ansible, так и Jenkins.

Настройка доступа без пароля

Задания Jenkins выполняются пользователем jenkins . Таким образом, доступ к SSH без пароля должен быть настроен для Дженкинс , чтобы получить доступ к удаленному компьютеру , как Jenkins или какой — либо другой учетной записи службы.

Пользователь, который входит в систему на удаленном компьютере, также должен иметь доступ sudo без пароля на этом компьютере.

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

Создать работу Дженкинса для запуска Playbook

Создайте проект в стиле фристайл в Jenkins и определите параметры для каждого элемента ввода, предоставленного в playbook, используя опцию extra-vars . Тип параметра в форме работы Jenkins будет зависеть от доступности данных. В примере, который мы рассматривали,  env  может быть параметром выбора с возможными значениями env1  и env2 .

Генерация входных значений для Playbook

Перед запуском playbook, значения для необходимых параметров должны быть собраны программно. Они являются дополнением к пользовательским данным из формы вакансии. В основном, есть два предмета, которые нужно получить:

  1. Закрытый ключ для SSH-ин на удаленных машинах. Закрытый ключ может быть настроен временно, если закрытые ключи управляются в некотором зашифрованном хранилище, включая функцию управления учетными данными Jenkin. Если закрытый ключ доступен на сервере Jenkins в статическом расположении, этот шаг не требуется.

  2. Список удаленных машин, на которых будет запускаться playbook. Это может быть получено из модуля vars, как описано выше.

Настройка Playbook из командной строки

Выполнение playbook определяется в разделе Build > Execute Shell задания. Генерация входных значений и выполнение playbook описаны в этом разделе, и это будет выглядеть так:

#env is Jenkins build parameter
$ `gen-hosts-list $env` > /path/to/hosts_list

$ ansible-playbook /path/to/install-app.yml -i /path/to/hosts_list -u AUTO_USER --private-key=/path/to/private-key

Преимущества использования Jenkins

  • Большинство сложностей, связанных с запуском playbook, могут быть закодированы в форме Jenkins и Execute Shell. Это позволило бы операционному персоналу, имеющему небольшой опыт или вообще не имеющему опыта работы с Ansible, запускать playbooks.

  • Журнал сборки Jenkins является отличным ресурсом для отслеживания и аудита изменений, внесенных в конкретную среду.

  • У Дженкинса есть хороший интерфейс для групповых заданий, представлений с вкладками, которые помогут организовать ваши пьесы. Jenkins также позволяет задокументировать задание и параметры в одном интерфейсе формы. Удобнее ссылаться на документацию в самой форме, чем искать эту информацию в вики.

Накладные расходы с использованием Jenkins

При настройке, как описано здесь, нет никакого реального недостатка в использовании Jenkins для запуска playbooks, потому что playbooks не нуждаются в каких-либо дополнительных изменениях, чтобы запускаться из Jenkins, и они все равно могут выполняться из командной строки, если это необходимо.

Чтобы иметь возможность исполнять Ansible playbooks, как предлагается, вот несколько дополнительных подготовительных действий, которые увеличивают накладные расходы:

  • Установите и настройте Ansible на экземпляре Jenkins, который будет использоваться для настройки пользовательского интерфейса для книг воспроизведения.

  • Настройте SSH-доступ без пароля между сервером Jenkins и удаленными компьютерами. Поскольку это обычно не может быть сделано на лету, этот метод выполнения playbooks лучше подходит для запуска процедур на известных машинах, таких как периодические развертывания.

  • Если такие секреты, как пароль и ключи API, не обрабатываются должным образом, у них больше шансов попасть в журналы сборки, что следует предотвратить. Принятие дополнительных мер безопасности может увеличить накладные расходы.

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

105
Share: