Конфигуратор. Связываем хосты в единую инфраструктуру, используя функциональность Ansible inventory

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

В предыдущей статье я показывал, как мы формируем сети и располагаем в них хосты, используя Ansible inventory. Напомню на примере двух сетей — subnet_srv и dmz:

subnet_dmz:   hosts:     bind-vm:       servicename: bind subnet_srv:   hosts:     gitlab-vm:       servicename: gitlab       serviceversion: "16.11.10"     dc-vm:       servicename: dc       serviceversion: "2.4"

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

Конфигурация хоста

Хост конфигурируем переменными Ansible. Для удобства вся конфигурация разделена на три пула переменных:

1. Полученные из основного Ansible inventory file. Отличительные особенности:

   • Основные переменные, с помощью которых мы конфигурируем информационные системы.

   • Все переменные жестко регламентированные.

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

2. Сформированные на основе переменных Ansible inventory file. Отличительная особенность:

   1. Мы их не изменяем, но можем использовать для конфигурации Ansible-service (А-service)* при разработке. К примеру, FQDN любого хоста можно автоматически получать из hostname и домена (поддомена), которые мы задаем в основном файле inventory.

3. Заданные в Ansible-service (А-service). Отличительные особенности:

   • Применяется для настройки ролей и коллекций, используемых в нашем плейбуке A-service.

   • Может формироваться из двух других пулов переменных, описанных выше.

   • Не используется в динамической конфигурации.

В рамках статьи рассмотрим только первый и второй пул переменных.

Пример настройки хоста:

all:   vars:     domain: 'zu.stf'   children:     subnet_srv:       vars:         external_router: router1         cidrip: 10.125.0.225/27       hosts:         gitlab:           number_in_subnet: 6           # dns: 'bind'           # dc: 'dc'           servicename: gitlab           serviceversion: "16.11.10"

• Основное: смотрим, какой A-service нужно запустить, по названию переменной servicename. Это gitlab.

• Для развертывания виртуальной машины и подключения нужны IP-адрес и учетные данные:

  • IP-адрес получаем из переменных cidrip (подсеть) и number_in_subnet (номер по порядку в допсети).

  • Учетные данные заложены во втором пуле переменных. Они соответствуют шаблону ОС на платформе, с помощью которых развертывается виртуальная машина.

• A-service проверяет переменную версии приложения — serviceversion. Будет развернута именно указанная версия.

• В качестве имени машины будет использовано имя хоста inventory.

Получили: развернута машина на Ubuntu 22 (шаблон по умолчанию) с IP-адресом 10.125.0.231 и установленным GitLab версии 16.11.10.

Конфигурация хоста со ссылками на другие хосты

Как вы заметили, в YAML-коде выше были закомментированы строки:

          # dns: 'bind'           # dc: 'dc' 

В этих параметрах указано, какой хост является DNS-сервером (куда ходить за резолвом), а какой — контроллером домена (где будет выполняться аутентификация пользователей для GitLab). Полный файл YAML будет выглядеть следующим образом:

all:   vars:     domain: 'zu.stf'   children:      subnet_dmz:       vars:         external_router: router1         cidrip: 10.12.0.1/27       hosts:         bind:           number_in_subnet: 3           servicename: bind     subnet_srv:       vars:         external_router: router1         cidrip: 10.125.0.225/27       hosts:         gitlab:           number_in_subnet: 6           # dns: 'bind'           # dc: 'dc'           servicename: gitlab           serviceversion: "16.11.10"         dc:           number_in_subnet: 7           dns: 'bind'           servicename: dc

Рассмотрим настройку DNS:

1. A-service, который запускал установку GitLab, проверяет наличие переменной dns. 

2. Из переменной dns получаем имя хоста — bind.

3. Через стандартный словарь Ansible — hostvars[‘bind’] — получаем IP-адрес.

4. При настройке сети машины с GitLab указываем полученный IP-адрес.

Рассмотрим настройку контроллера домена:

1. A-service, который запускал установку GitLab, проверяет наличие переменной dc.

2. Из переменной dc получаем имя хоста — dc.

3. Через стандартный словарь Ansible — hostvars[‘dc’] — получаем IP-адрес и учетные данные.

4. Для подключения GitLab к контроллеру домена заходим в контроллер через делегирование и создаем учетную запись для аутентификации.

5. Добавляем созданную учетную запись на GitLab.

Конфигурация хоста с помощью параметров других хостов

Мы уже использовали переменные других хостов inventory для настройки целевого хоста через переменную hostvars[].

К примеру, можно было не создавать в A-service GitLab учетную запись для контроллера домена, а получать все хосты, для которых нужно создать учетные данные, в A-service dc. Но нам это не подошло, так как сервис GitLab мы устанавливаем после контроллера домена. У вас может быть своя приоритизация установки A-service.

Введем новую сущность — артефактные переменные.

Артефактные переменные

При развертывании сервисов могут оставаться артефакты: переменные, учетные данные, ключи и т. п. Все данные, которые можно в дальнейшем использовать, мы сохраняем в качестве переменных Ansible inventory хоста в ./host_vars установленного хоста. Их мы и называем артефактными переменными. 

Рассмотрим пример установки workstation и iTop.

Для работы workstation нам нужно:

• Добавить рабочую станцию в домен.

• Создать учетную запись на контроллере домена.

Для работы iTop нужны:

• Учетная запись на контроллере домена.

• Учетная запись от workstation.

YAML-конфигурация будет выглядеть следующим образом:

all:   vars:     domain: 'zu.stf'   children:      subnet_dmz:       vars:         external_router: router1         cidrip: 10.12.0.1/27       hosts:         bind:           number_in_subnet: 3           servicename: bind     subnet_srv:       vars:         external_router: router1         cidrip: 10.125.0.225/27       hosts:         ws1:           number_in_subnet: 4           dns: 'dc'           dc: 'dc'           itop: 'itop'           servicename: workstation         itop:           number_in_subnet: 8           dns: 'dc'           dc: 'dc'           servicename: itop          dc:           number_in_subnet: 7           dns: 'bind'           servicename: dc

Настройка workstation:

1. Настройка DNS (как для GitLab).

2. Добавление доменного пользователя (как для GitLab).

3. Сохранение учетных данных, сгенерированных на контроллере домена, в ./host_vars/aduser.yml в переменной aduser_list.

Настройка iTop:

1. Настройка DNS (как для GitLab).

2. Добавление доменного пользователя (как для GitLab).

3. Поиск хостов, у которых значение параметра hostvars[‘item’].itop совпадает с именем хоста iTop.

4. Добавление найденных пользователей в базу iTop для аутентификации.

5. Настройка iTop на контроллере домена.

6. Проверка того, что все пользователи, которых нужно указать в iTop, добавлены.

Итог

1. Определили формат конфигурирования хоста:

   • внутренних параметров (версия приложения, IP-адрес);

   • статических параметров, зависящих от других хостов (DNS, контроллера домена);

   • динамических параметров (доменных пользователей для iTop), зависящих от других хостов.

2. Рассмотрели сценарии конфигурирования хоста.

3. Определили расположение переменных конфигурирования (это необходимо не только для настройки, но и для разработки).

4. Описали важность такой переменной, как hostvars[].