Описание инвентаря

Описание инвентаря#

Для развертывания платформы с помощью утилиты aa-setup необходимо предоставить для нее полное описание всех узлов платформы в виде файла инвентаря.

../../../_images/day0-model-green.svg ../../../_images/day0-topology-green.svg ../../../_images/day0-nodes-green.svg ../../../_images/day0-inventory-blue.svg ../../../_images/day0-offline-white.svg ../../../_images/day0-offline-dark.svg

По умолчанию утилита использует файл inventory, который был создан при подготовке установочного узла. Теперь необходимо отредактировать этот файл так, чтобы он содержал параметры целевой инфраструктуры. Для этого рассмотрим более подробно параметры инвентаря по каждому компоненту Astra Automation. Начнем с общих настроек (General на диаграмме):

../../../_images/general-blue1.svg ../../../_images/gateway-white1.svg ../../../_images/gateway-dark1.svg ../../../_images/autoexec-white1.svg ../../../_images/autoexec-dark1.svg ../../../_images/content-white1.svg ../../../_images/content-dark1.svg ../../../_images/eda-white1.svg ../../../_images/eda-dark1.svg ../../../_images/tls-white1.svg ../../../_images/tls-dark1.svg ../../../_images/postgres-white1.svg ../../../_images/postgres-dark1.svg ../../../_images/redis-white1.svg ../../../_images/redis-dark1.svg

Если необходимо сразу перейти на какой-либо шаг, выберите соответствующий блок диаграммы.

Описание инвентаря следует правилам Ansible с использованием формата INI или YAML. В зависимости от используемого формата название файла должно иметь одно из следующих расширений:

  • формат INI:

    • .ini;

    • .cfg;

  • формат YAML:

    • .yml;

    • .yaml.

Примечание

Если расширение не указано, утилита развертывания интерпретирует файл как имеющий формат INI.

Утилита aa-setup по умолчанию использует файл инвентаря inventory в формате INI, расположенный в одном из следующих каталогов:

  • /opt/rbta/aa/astra-automation-setup/ – при использовании интернет-репозиториев ПАО Группа Астра;

  • в корневом каталоге распакованного архива – при развертывании без доступа к интернету.

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

Чтобы использовать другой файл инвентаря, при запуске утилиты aa-setup укажите путь к нему в значении аргумента --inventory (-i), например:

sudo ./aa-setup --inventory /var/aa/setup-settings.ini

sudo ./aa-setup --inventory /var/aa/setup-settings.yaml

Компоненты платформы#

Настройки отдельных компонентов платформы задаются в соответствующих секциях файла инвентаря:

INI

YAML

Описание

[automationgateway]

automationgateway.hosts

Узлы шлюза платформы

[automationcontroller]

automationcontroller.hosts

Узлы плоскости управления (Automation Controller)

[execution_nodes]

execution_nodes.hosts

Узлы плоскости исполнения

[automationhub]

automationhub.hosts

Узлы Private Automation Hub

[automationedacontroller]

automationedacontroller.hosts

Узлы контроллера Event-Driven Automation

[database]

database.hosts

Узел СУБД, развертываемой средствами платформы

[redis]

redis.hosts

Узлы кластера Redis (режим cluster; совмещаются с узлами Platform Gateway, Private Automation Hub и контроллера Event-Driven Automation)

[automationdashboard]

automationdashboard.hosts

Узел необязательного компонента Automation Dashboard, если он устанавливается вместе с платформой из офлайн-пакета

[<group>:vars]

<group>.vars

Параметры настройки узлов конкретной группы <group>

[all:vars]

all.vars

Параметры настройки узлов и платформы в целом

После заголовка секции указывают параметры узлов платформы.

Важно

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

Важно

Указывать localhost или IP-адрес 127.0.0.1 в качестве узла платформы нельзя: предварительная проверка утилиты aa-setup завершается ошибкой (ERROR: Ansible inventory file contains localhost). Для каждого узла необходимо указывать FQDN или IP-адрес, доступный с установочного узла и других узлов платформы.

Тем же запуском утилита aa-setup устанавливает и Automation Dashboard, если платформа развертывается из офлайн-пакета. Группу [automationdashboard] и параметры этого компонента описывают средства аналитики.

Средства аналитики#

Automation Dashboard является дополнительным компонентом. Для его установки необходима группа [automationdashboard] и связанные с ней глобальные переменные.

В группе [automationdashboard] необходимо указать один узел, на котором будет установлен Automation Dashboard. Для этого компонента необходим отдельный узел, так как совмещать компоненты платформы на одном узле в этой модели развертывания нельзя. Требования к узлу приведены в инструкции по развертыванию средств аналитики.

[automationdashboard]
dashboard1.example.com

[all:vars]
dashboard_admin_password='<dashboard_admin_password>'
dashboard_pg_password='<dashboard_pg_password>'

automationdashboard:
  hosts:
    dashboard1.example.com:

all:
  vars:
    dashboard_admin_password: <dashboard_admin_password>
    dashboard_pg_password: <dashboard_pg_password>

Здесь:

  • <dashboard_admin_password> – пароль администратора Automation Dashboard;

  • <dashboard_pg_password> – пароль пользователя базы данных Automation Dashboard.

Установочный узел должен иметь доступ по SSH к узлу Automation Dashboard, а узел Automation Dashboard – сетевой доступ к Platform Gateway по HTTPS и к базе данных, указанной в описании инвентаря.

Настройка порта HTTPS, сертификата TLS и публичного имени DNS для Automation Dashboard приведена в инструкции по добавлению компонента; эти параметры можно задать уже на этом шаге, до первоначального развертывания платформы.

Automation Dashboard устанавливается только из офлайн-пакета. При развертывании из deb-пакетов утилита aa-setup определяет наличие офлайн-пакета сама – по каталогу bundle/, который находится в каталоге утилиты, – поэтому отдельная переменная для этого не требуется. Если такого каталога нет или группа [automationdashboard] пуста, компонент не устанавливается.

При добавлении Automation Dashboard к уже развернутой платформе дополните описание инвентаря этой платформы параметрами, приведенными ранее. Процедура добавления Automation Dashboard к уже развернутой платформе приведена в отдельной инструкции.

Учетная запись администратора#

У платформы одна учетная запись администратора, общая для Platform Gateway, Automation Controller, Private Automation Hub и контроллера Event-Driven Automation. Ее задают в глобальных переменных:

  • admin_username – название учетной записи, обязательный параметр;

  • admin_password – пароль, обязательный параметр;

  • admin_email – адрес электронной почты.

[all:vars]
admin_username='admin'
admin_password='<admin_password>'
admin_email='admin@example.com'

---
all:
  vars:
    admin_username: admin
    admin_password: <admin_password>
    admin_email: admin@example.com

Здесь <admin_password> – пароль администратора платформы.

Важно

Значения по умолчанию у переменных admin_username и admin_password отсутствуют. Если хотя бы одна из них не задана или пуста, предварительная проверка утилиты развертывания прерывает установку и не запрашивает значение.

Важно

Значения учетных данных заключайте в кавычки. Разбор описания инвентаря не берет значения буквально. Для формата INI утилита развертывания применяет ast.literal_eval, для формата YAML – правила скаляров, поэтому пароль 1e3 дошел бы до компонента как 1000.0, а значение yes – как True. Утилита сравнивает значение до и после разбора и прерывает установку, если текст изменился; пароль из одних цифр при этом остается допустимым.

Примечание

Покомпонентные переменные учетных данных устарели и игнорируются: automationgateway_admin_username, automationcontroller_admin_username, automationhub_admin_username, automationedacontroller_admin_username, их исторические формы с окончанием _admin_user, а также соответствующие переменные *_admin_password. Если такая переменная задана, предварительная проверка выводит предупреждение и предлагает перенести значение в admin_username или admin_password.

Повторный запуск утилиты развертывания обновляет пароль администратора в Automation Controller, Platform Gateway и контроллере Event-Driven Automation, поэтому пароль можно изменить и после первоначального развертывания. В Private Automation Hub пароль уже созданной учетной записи так не меняется, поэтому для его смены дополнительно задают automationhub_force_change_admin_password=true. Иначе после смены admin_password в Private Automation Hub останется прежний пароль.

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

Реквизиты доступа к узлам#

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

  • ansible_user – название учетной записи пользователя, используемой для подключения к узлу (по умолчанию – учетная запись текущего пользователя);

  • ansible_ssh_private_key_file – путь к файлу приватного ключа SSH.

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

[automationcontroller]
node1.example.com
node2.example.com

[all:vars]
ansible_user='admin'
ansible_ssh_private_key_file='ssh-keys/ssh_key'

---
automationcontroller:
  hosts:
    node1.example.com:
    node2.example.com:
  vars:
    ansible_user: admin
    ansible_ssh_private_key_file: ssh-keys/ssh_key

Если реквизиты для доступа к узлам различаются, укажите их в параметрах соответствующих узлов, например:

[automationcontroller]
node1.example.com  ansible_user=alex  ansible_ssh_private_key_file=ssh-keys/node1_key
node2.example.com  ansible_user=john  ansible_ssh_private_key_file=ssh-keys/node2_key

[execution_nodes]
node3.example.com  ansible_user=jack  ansible_ssh_private_key_file=ssh-keys/node3_key

---
automationcontroller:
  hosts:
    node1.example.com:
      ansible_user: alex
      ansible_ssh_private_key_file: ssh-keys/node1_key
    node2.example.com:
      ansible_user: john
      ansible_ssh_private_key_file: ssh-keys/node2_key
execution_nodes:
  hosts:
    node3.example.com:
      ansible_user: jack
      ansible_ssh_private_key_file: ssh-keys/node3_key

Доступ к реестру образов#

При развертывании с доступом к интернету утилита развертывания загружает образы среды исполнения из внешнего реестра образов. Если реестр требует аутентификации, задайте реквизиты доступа глобальными переменными:

[all:vars]
registry_username='<username>'
registry_password='<token>'

---
all:
  vars:
    registry_username: "<username>"
    registry_password: "<token>"

Здесь:

  • <username> – название учетной записи для доступа к внешнему реестру образов;

  • <token> – токен, созданный на портале Automation Hub, или пароль указанной учетной записи.

Условия, при которых утилита развертывания использует эти реквизиты, приведены в справочнике.

Защита конфиденциальных данных с помощью Ansible Vault#

Для защиты указанных в описании инвентаря конфиденциальных данных рекомендуется вынести их в отдельный файл и зашифровать с помощью утилиты ansible-vault.

Преимущества такого подхода:

  • Конфиденциальные данные не хранятся в открытом виде. Зашифрованный файл можно безопасно хранить и передавать.

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

  • Конфиденциальные данные обновляются отдельно от основной конфигурации.

Для защиты конфиденциальных данных выполните следующие действия:

  1. Убедитесь, что на рабочей станции установлен пакет ansible. Утилита aa-setup использует встроенный Ansible, поэтому отдельная утилита ansible-vault может отсутствовать даже на подготовленном установочном узле. При отсутствии пакета установите его:

    sudo apt install ansible --yes

  2. В каталоге утилиты развертывания создайте файл формата YAML и добавьте в него необходимые переменные. В их значениях укажите конфиденциальные данные в открытом виде.

    В этом примере файл с конфиденциальными данными называется secrets.yml. Пример содержимого:

    ---
ac_username: superadmin
ac_password: p@ssW0rD!
postgresql_ac_username: user3532
postgresql_ac_password: pgPa5Sw0r0
postgresql_pah_username: user9853
postgresql_pah_password: s$949d9fK

    Предупреждение

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

  3. Зашифруйте файл secrets.yml:

    sudo ansible-vault encrypt secrets.yml

    По запросу введите пароль для защиты содержимого файла secrets.yml.

  4. В описании инвентаря вместо конфиденциальных данных укажите названия соответствующих переменных из файла secrets.yml. Для доступа к значениям переменных используйте синтаксис шаблонов Jinja.

    Для примера выше:

    [all:vars]
admin_username='{{ ac_username }}'
admin_password='{{ ac_password }}'
pg_username='{{ postgresql_ac_username }}'
pg_password='{{ postgresql_ac_password }}'
automationhub_pg_username='{{ postgresql_pah_username }}'
automationhub_pg_password='{{ postgresql_pah_password }}'

    ---
# ...
all:
  vars:
    admin_username: "{{ ac_username }}"
    admin_password: "{{ ac_password }}"
    # ...
    pg_username: "{{ postgresql_ac_username }}"
    pg_password: "{{ postgresql_ac_password }}"
    # ...
    automationhub_pg_username: "{{ postgresql_pah_username }}"
    automationhub_pg_password: "{{ postgresql_pah_password }}"

  5. На этапе развертывания платформы при запуске утилиты aa-setup необходимо добавить ключ --ask-vault-pass и передать после -- аргумент --extra-vars, например:

    sudo ./aa-setup --inventory /var/aa/setup-settings.ini --ask-vault-pass -- --extra-vars @secrets.yml

    sudo ./aa-setup --inventory /var/aa/setup-settings.yml --ask-vault-pass -- --extra-vars @secrets.yml

    Примечание

    Символ @ перед названием файла secrets.yml является частью синтаксиса и указывает, что значения переменных нужно загрузить из указанного файла.

  6. Введите пароль, которым защищен файл secrets.yml.

Дальнейшие шаги#

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

Примечание

Создаваемое описание инвентаря и зашифрованный файл с конфиденциальной информацией необходимо сохранить для дальнейшего использования – как для развертывания платформы, так и для ее реструктуризации при необходимости.