Структура управления

Содержание

Структура управления#

Базовая концепция Ansible основана на создании сценариев автоматизации, интерпретируемых управляющим узлом (control node) для выполнения требуемых операций на управляемых узлах (managed nodes).

Базовая концепция имеет множество реализаций.

Терминология#

Базовая концепция уже содержит в себе определение управляющего и управляемого узлов, но кроме этого существует понятие целевого узла. Важно разграничить эти термины для улучшения восприятия дальнейшего описания компонентов и процессов. Использование Ansible в составе Astra Automation также накладывает некоторые ограничения в определении этих терминов:

Управляющий узел (control node) – это узел (рабочая станция, ВМ, контейнер) под управлением Astra Linux Special Edition, на котором установлен Ansible Core с необходимыми дополнительными компонентами для управления выполнением сценариев автоматизации.

Такой узел содержит следующие ключевые компоненты автоматизации:
- программное обеспечение в виде Ansible Core, расширяемое с помощью коллекций Ansible;
- описание инвентаря, содержащее информацию об управляемых узлах;
- наборы сценариев автоматизации (playbooks), определяющие действия, которые необходимо выполнить на целевых узлах.
Управляемый узел (managed node) – это сервер, устройство или иной ресурс, состояние которого Ansible изменяет или контролирует с помощью сценариев автоматизации.

Таким узлом можно управлять путем непосредственного выполнения команд из состава сценариев или опосредованно через целевой узел.
Целевой узел (target node) – это узел, на котором непосредственно выполняется задача из сценария автоматизации и который имеет средства взаимодействия с управляемым узлом через некоторый API. В общем случае он выполняет роль промежуточного узла (proxy) или шлюза (gateway).

Схемы реализации структуры управления#

Следующие схемы иллюстрируют различные варианты структуры управления.

Обобщенная схема#

В общем случае в выполнении каждой задачи сценария участвуют три типа узлов, упомянутые ранее.

Можно выделить следующие варианты реализации целевого узла:

совпадает с управляемым узлом – задача сценария выполняется на самом управляемом узле;
совпадает с управляющим узлом – задача сценария выполняется на управляющем узле, например путем запуска модуля, который через определенный API выполняет необходимые действия на управляемом узле;
отдельный узел, на котором выполняется задача сценария, например путем запуска модуля, который через определенный API выполняет необходимые действия на управляемом узле.

Управляемый узел является целевым#

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

../../_images/target-in-managed-light.svg

../../_images/target-in-managed-dark.svg

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

Любой сервер или компьютер с операционной системой Linux или Unix, поскольку они имеют встроенные средства удаленного управления через SSH.

Требования к целевому узлу:
- Убедиться, что у вас есть доступ по SSH с помощью некоторой учетной записи и выполнены определенные настройки SSH.
- Для исполнения заданного модуля необходима соответствующая поддержка – runtime environment. Чаще всего используют модули Python, которые могут требовать наличия определенной версии Python на целевом узле.
Сервер или компьютер с операционной системой Windows. Для этого необходимо выполнить определенные требования как на управляющем, так и на целевых узлах.

Требования к управляющему узлу:
- Для управления целевыми узлами по протоколу WinRM необходимо установить пакет pywinrm для Python.
- Необходимо установить коллекцию ansible.windows, которая содержит модули для управления Windows.
Требования к целевому узлу:
- Установлена поддерживаемая версия Windows, которой может быть Windows Server 2016+ или Windows 10+.
- Установлены сервисы PowerShell 5.1 и .NET Framework 4.6+.
- Настроен протокол WinRM, открытый на прием запросов по HTTPS, обычно по порту TCP 5986. Необходима учетная запись, которую будет использовать управляющий узел при посылке запросов по этому протоколу.
Требования к описанию инвентаря:
- Необходимо явно указать WinRM как способ подключения к управляемым узлам: ansible_connection=winrm.

Управляющий узел является целевым#

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

../../_images/target-in-control-light.svg

../../_images/target-in-control-dark.svg

Примером реализации такой структуры является управление облачными ресурсами в Yandex Cloud с помощью коллекции astra.yandexcloud.

Выбор целевого узла#

Данная тема является достаточно сложной для начинающих изучать Ansible, так как предполагает понимание структуры сценария и задачи внутри сценария, начальных знаний о коллекциях и других аспектах Ansible. В то же время она является логическим продолжением описания структуры управления. Если тема представляется сложной, изучите предварительно отмеченные здесь связанные темы.

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

Обработка задачи средствами Ansible происходит в следующем порядке:

До начала выполнения задачи Ansible определяет список целевых узлов и групп узлов через директиву hosts, заданную на уровне сценария. В том числе в качестве целевого узла можно указать localhost. Узлы, на которые указывает переменная hosts, должны содержаться в описании инвентаря (inventory), который обычно формируют статически, но также можно создать динамически с помощью сценария, предшествующего рассматриваемому.

При выполнении задачи список целевых узлов может быть изменен как описано далее.
Ansible выполняет разбор задачи (parse task), где основное внимание уделяется анализу указанного модуля, его параметрам и директиве назначения целевого узла (если она есть). На этом шаге Ansible определяется какое из его расширений для управления активностью (action plugin) должно управлять выполнением задачи:
- По умолчанию применяется встроенное расширение normal, которое подготавливает модуль задачи и его параметры для передачи на целевой узел.
- Вместе с модулем может идти специальное расширение которое имеет такое же название, что и сам модуль, и присутствует в одной коллекции с модулем. Примерная структура коллекции с модулем my_service:
```
my_namespace/my_collection/
├── plugins/
    ├── modules/
    │   └── my_service.py
    ├── action/
        └── my_service.py
```
  Нигде явно не указано, что надо пользоваться конкретным расширением my_service. Ansible определяет это по совпадению названий расширения и модуля. Используемое расширение определяет дальнейшие действия и целевые узлы.
На этом шаге целевые узлы могут быть переопределены с помощью директивы delegate_to, явно указывающей на целевой узел, которым может быть как внешний, так и локальный узел.
Action plugin подготавливает модуль и необходимые параметры для выполнения задачи. Action plugin может выбирать целевые узлы, например фильтрацией узлов, заданных на уровне сценария.
Action plugin с помощью расширения типа connection передает подготовленный модуль на целевой узел.
Целевой узел выполняет задачу и возвращает результат выполнения в формате JSON в action plugin.

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