21.02.2025 09:32
Wahrsager 0 11 Источник

Привет, Хабр! Продолжу серию статей об эффективном использовании 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.

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

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

Ansible-service (A-service)

Что такое A-service и как мы его формируем достойна отдельной статьи, поэтому, будет рассказано позже. В приближении, это playbook разворачивания хоста и его сервиса с заложенной конфигурацией. К примеру: развернуть Ubuntu 22 и GitLab 16.11.10 только указав для хоста имя A-service и версию вложенного приложения, в данном случае Gitlab.

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

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

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

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[].

Комментарии (0)