actions

Действие (action) — некая сущность, с помощью которой можно описать действие над объектом ADCM. Такое действие в конечном счете представляет собой запуск Ansible playbook с определенными параметрами при определенных условиях.

Пример

 

---
- type: cluster
  name: control
  version: 1
  description: "Monitoring and Control Software"

  actions:
    install:
      display_name: "Install Monitor Server"
      description: |
         By click on this button you install monitoring and controlling server ...
      type: job
      script_type: ansible
      script: ansible/site.yaml
      allow_to_terminate: true
      params:
        ansible_tags: install
        jinja2_native: true
      states:
        available:
          - created
        on_success: installed
        on_fail: created
      config:
        quorum:
          type: integer

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

allow_for_action_host_group

Action может содержать опциональное логическое свойство allow_for_action_host_group, предназначенное для управления возможностью запуска action для группы хостов. Значение по умолчанию — false. Если свойство allow_for_action_host_group принимает значение true, то запуск action возможен для группы хостов.

actions:
  upgrade:
    type: job
    script_type: ansible
    script: ansible/site.yaml
    allow_for_action_host_group: true

Ограничения использования свойства allow_for_action_host_group:

allow_in_maintenance_mode

Action может содержать опциональное логическое свойство allow_in_maintenance_mode, предназначенное для управления возможностью запуска action в режиме обслуживания. Значение по умолчанию — false. Если свойства allow_in_maintenance_mode и allow_maintenance_mode принимают значение true, запуск action становится возможным даже в том случае, если объект или один из его хостов находится в режиме обслуживания.

allow_to_terminate

Action может содержать опциональное логическое свойство allow_to_terminate, предназначенное для управления возможностью принудительной остановки action и входящих в него job. Значение по умолчанию — false. Если свойство allow_to_terminate принимает значение true, пользователь может приостановить выполнение action. При этом:

  • При приостановке job завершается выполнение запущенной на текущий момент subjob (подзадачи), которая прерывает выполнение Ansible playbook, что приводит к завершению выполнения всей job.

  • При приостановке subjob (иконка skip default dark skip default light) прерывается выполнение Ansible playbook с запуском последующей subjob без прерывания выполнения job.

Во всех остальных случаях остановка action запрещена.

Свойство allow_to_terminate применяется ко всем subjob, из которых состоит action. При остановке одной из таких subjob выполнение action продолжается со следующей subjob. Таким образом, указание свойства allow_to_terminate для action эквивалентно указанию данного свойства для всех его subjob.

config

Action может содержать опциональное свойство config. Это свойство определяет список значений для параметров конфигурации. При запуске action в веб-интерфейсе ADCM значения указанных параметров конфигурации будут запрошены у пользователя перед стартом action.

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

{{ job.config.quorum }}

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

config_jinja

Action может содержать опциональное свойство config_jinja. Это свойство указывает на файл в формате Jinja (поддерживается в версиях ADCM 2.xx).

ПРИМЕЧАНИЕ
Свойство config_jinja считается устаревшим и не поддерживается начиная с версии контракта 2.0 (contract_version: 2). Для работы с динамическими конфигурационными параметрами action рекомендуется использовать config_template.

Свойство config_jinja предназначено для работы с динамическими конфигурационными параметрами. В этом случае динамичность понимается как возможность отображения (либо скрытия) определенного набора параметров в зависимости от условий — другими словами, от топологии кластера (например, добавлен тот или иной сервис в кластер или нет). Во время получения метаданных об action (с помощью GET-запроса в API) рендерится файл в формате Jinja (шаблон Jinja2). При рендеринге шаблона формируется контекст, соответствующий inventory-файлу, за исключением изменений конфиг-групп, а также переменных и фактов, которые формирует Ansible во время выполнения playbook.

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

---
actions:
  - name: Restart and Reboot
    type: job
    script_type: ansible
    script: ansible/restart.yaml
    config_jinja: config_jinja/restart.j2

Файл restart.j2:

- reboot_servers:
  type: boolean
  default: false
  display_name: Reboot servers
{%  if cluster.state == 'created' %}
- configure_etc:
  type: boolean
  default: false
  display_name: Configure /etc/hosts
{% endif %}

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

"cluster": {
   "config": {
      "reliability_control": {
         "retries": 3153600,
         "delay": 10,
         "timeout": 31536000
       }
   },
   "id": 210,
   "name": "adh bu"
   "state": "installed",
   "multi_state": [],
   "before_upgrade": {},
   "version": "3.2.4_arenadata2_b1-for_autotest",
   "edition": "enterprise",
   "imports": None  # absent if no imports
},
"services":{
   "zookeeper":{
      "id" :193,
      "state":"installed",
      "multi_state":[],
      "before_upgrade":{"state":null},
      "config": {},
      "display_name": "Zookeeper",
      "version": "1.0",
      "maintenance_mode": False,
      "SERVER":{
         "component_id": 582,
         "state":"installed",
         "multi_state":[],
         "before_upgrade":{...},
         "config":{},
         "display_name": "Zookeeper Server",
         "maintenance_mode": false
      },
   },
},
"groups": {
   "CLUSTER": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
   "zookeeper": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
   "zookeeper.SERVER": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
},
"action": {
   "owner_group": "zookeeper",
   "name": "install"
}

config_template

Action может содержать опциональное свойство config_template. Это новый механизм работы с динамическими конфигурационными параметрами, обеспечивающий более строгие правила их обработки на этапе выполнения action и пришедший на смену устаревшему механизму config_jinja.

---
  actions:
    start:
      display_name: Start
      config_template:
        file:
          path: scripts_jinja/cluster/restart.j2
        engine:
          type: jinja2
      scripts_template:
        file:
          path: scripts_jinja/cluster/manage_install.j2
        engine:
          type: jinja2
      states:
        available:
          - installed

Формат описания шаблонов для свойств <wizard|scripts>_template применим и к свойству config_template.

display_name

Свойство display_name определяет короткое имя action, которое будет видно пользователю в веб‑интерфейсе ADCM.

hc_acl

Action может содержать опциональное свойство hc_acl. Это свойство задействуется при запуске action в веб-интерфейсе ADCM так, что перед стартом action у пользователя запрашивается новое распределение компонентов на хостах (host-component mapping).

actions:
  expand:
    type: job
    script_type: ansible
    script: ansible/site.yaml
    states:
      available: all
    hc_acl:
      -
        service: hadoop
        component: datanode
        action: add
      -
        service: hadoop
        component: server
        action: remove

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

  • service — название сервиса.

  • component — название компонента.

  • action — тип операции. Возможные значения: add, remove.

host_action

Action может содержать опциональное логическое свойство host_action, предназначенное для определения области применения action — на уровне отдельного хоста. Значение по умолчанию — false. Если свойство host_action принимает значение true, action отображается в выпадающем списке действий на странице Clusters → <Cluster name> → Hosts → <Host name> → Host-Components. В этом случае action выполняется для выбранного хоста, и автоматически создается таргет-группа, содержащая только данный хост.

Целесообразно объявлять action (host_action: true) только в контексте компонента, так как такие action позволяют управлять конкретным компонентом на конкретном хосте.

actions:
  install:
    type: job
    script_type: ansible
    script: action.yaml
    host_action: true

masking

masking — альтернативный способ описания доступности action как в веб-интерфейсе ADCM, так и в API. С помощью данного свойства можно определить набор основных (states) и расширенных (multi_state) состояний объекта.

Используйте masking, если хотите описать доступность action с помощью расширенных состояний, которые указываются в свойстве multi_state.

ВАЖНО
Свойство masking несовместимо со свойством states, которое описано ниже.
---
actions:
  install:
  display_name: "Install Monitor Server"
  type: job
  masking:
      # Action will be shown if both condition under state and multi_state are met.
      state:
          available:
              # If the state equal to any of this, then condition is true
              - "state_value1"
              - "state_value2"
          unavailable:
              # If you place unavailable, then no available should be there
              - "state_value1"
              - "state_value2"
      multi_state:
          available:
              # If we have any of this multistate, then condition is true
              - "multi_state_1"
              - "multi_state_2"
          unavailable:
              # If you place unavailable, then no available should be there
              - "multi_state_3"
              - "multi_state_4"
  on_fail:
      state: "new_sate_value"
      multi_state:
          set:
              - "multi_state3"
          unset:
              - "multi_state4"
  on_success:
      state: "new_sate_value"
      multi_state:
          set:
              - "multi_state3"
          unset:
              - "multi_state4"

Чтобы упростить описание правил, вы можете использовать скаляр any, который заменяет собой все возможные значения:

---
  masking:
  state:
      available: "any"
      unavailable: "any"
  multi_state:
      available: "any"
      unavailable: "any"

Если значение свойства masking отсутствует, то считается, что действие доступно для каждого значения свойств state или multi_state. Таким образом, следующие варианты эквивалентны:

---
  masking:
---
  masking:
      state:
---
  masking:
      state:
          available: "any"

Приведенные ниже варианты также считаются равнозначными:

---
  masking:
---
  masking:
      multi_state:
---
  masking:
      multi_state:
          available: "any"

name

Свойство name определяет внутреннее имя action, которое уникально для каждого прототипа.

states

Action может содержать опциональное свойство states, предназначенное для управления доступностью action и переходами состояний объекта в процессе его выполнения. Свойство задает перечень состояний, при которых действие может быть запущено, а также состояния объекта после успешного или неудачного завершения action.

Свойство states определяет следующие состояния:

  • available — список состояний объекта, для которых доступен action;

  • on_success — состояние, в которое объект переводится при успешном завершении action;

  • on_fail — состояние, в которое объект переводится при завершении action с ошибкой.

Состояния on_success и on_fail опциональны. При их отсутствии состояние объекта не будет изменено после успешного либо неудачного завершения action.

Также свойство states имеет два зарезервированных значения:

  • created — первичное состояние, в котором объекты находятся сразу после создания;

  • upgrading — состояние, в которое можно перевести кластер. В этом состоянии пользователю недоступны такие действия, как удаление хоста или сервиса из кластера.

type

Свойство type определяет состояние action. Возможные значения:

  • job — тип action, запускающего выполнение одного скрипта. Описывается следующими параметрами:

  • task — тип action, состоящего из последовательности job. Описывается следующими параметрами:

ПРИМЕЧАНИЕ
Свойство type считается устаревшим и не поддерживается начиная с версии контракта 2.0 (contract_version: 2).

ui_options

Блок ui_options позволяет настроить отображение и выполнение action в веб-интерфейсе ADCM. При наведении курсора на action в веб-интерфейсе появится всплывающее сообщение, указанное в поле disclaimer:

actions:
  install:
    type: job
    script_type: ansible
    script: ansible/site.yaml
    ui_options:
       disclaimer: "Enter your disclaimer"

venv

Обязательное свойство venv предназначено для указания версии Ansible, используемой при выполнении action.

ПРИМЕЧАНИЕ
Свойство venv считается устаревшим и не поддерживается начиная с версии контракта 2.0 (contract_version: 2).

Доступные значения:

  • default — запуск action в окружении Ansible 2.8 (при версии контракта 1.0);

  • 2.9 — запуск action в окружении Ansible 2.9;

  • 2.16 — запуск action в окружении Ansible 2.16 (начиная с версии ADCM 2.8.0).

ПРИМЕЧАНИЕ
Версия Ansible 2.8 считается устаревшей и поддерживается только для версии контракта 1.0 (contract_version: 1).

Изменение окружения по умолчанию для всех действий на объекте:

  ---
  - type: cluster # service component hostprovider host
    name: control
    version: 1
    contract_version: 2.0

    venv: "2.9"

wizard_template

Action может содержать опциональное свойство wizard_template, которое представляет собой шаблон процесса (flow), формируемого в результате его рендеринга.

В отличие от свойства config, wizard_template позволяет:

  • разделить конфигурирование action на несколько логических этапов в виде модальных окон;

  • передавать контекст рендеринга шаблона между этапами;

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

Свойство wizard_template является взаимоисключающим со следующими свойствами:

  • config, предназначенным для работы со статическими конфигурационными параметрами;

  • config_jinja, предназначенным для работы с динамическими конфигурационными параметрами;

  • hc_acl, предназначенным для работы с host-component mapping.

Заданное свойство отображается в web-интерфейсе ADCM в виде Wizard, который является этапом подготовки action до его запуска.

Процесс (flow) представляет собой последовательность из следующих элементов:

  • Этапы (stage) — контейнеры логически связанных шагов.

  • Шаги (step) — минимальные неделимые элементы процесса (process), выполняемого пользователем.

    ПРИМЕЧАНИЕ
    Процесс (process) возникает в результате нажатия пользователем на action в списке действий, доступных для работы с объектом.

Типы шагов:

  • Configuration — заполняемая пользователем конфигурация. Конфигурация динамически формируется во время рендеринга шаблона, указанного в свойстве config_template, при получении информации о шаге.

  • Operation — job, представляющая собой набор subjob, который запускается в результате выполнения шага. Набор subjob динамически формируется во время рендеринга шаблона, указанного в свойстве scripts_template, при выполнении конкретного шага. Пример описания шага типа operation приведен в файле manage_install.j2 (шаг check_kerberos этапа manage_kerberos_stage).

  • Mapping — правило распределения компонентов на хостах (host-component mapping). Шаблон правила и форма со значениями по умолчанию динамически формируются во время рендеринга шаблона, указанного в свойстве mapping_template, при получении информации о шаге.

    ВАЖНО
    В отличие от обычных action, при использовании Wizard автоматическое применение распределения компонентов на хостах к целевому кластеру не выполняется. В этом случае разработчику бандла необходимо самостоятельно сохранить распределение, заданное пользователем, вызвав hc_apply вне контекста процесса Wizard, то есть в рамках основной job соответствующего action.

Описание визуального представления Wizard в web-интерфейсе ADCM приведено в статье Wizard.

Шаги типа operation предоставляют следующие возможности:

  • валидация значений конфигурационных параметров action, введенных пользователем;

  • сохранение значений конфигурационных параметров action, введенных пользователем, в конфигурации целевого объекта (кластера, сервиса или компонента) c помощью функции config_apply.

Каждый этап включает в себя следующие параметры:

  • name — уникальное название этапа;

  • display_name — название этапа, которое отображается в веб-интерфейсе ADCM для пользователя;

  • steps — последовательность шагов.

При описании шага используются следующие атрибуты:

  • Общие атрибуты:

    • name — название шага, которое уникально для данного этапа.

    • display_name — название шага Wizard, которое предназначено для использования в качестве названия шага модального окна.

  • Атрибут для шага типа configuration: config_template — шаблон для работы с динамическими конфигурационными параметрами.

  • Атрибуты для шага типа operation:

    • ui_options — атрибуты, специфичные для веб-интерфейса ADCM, в частности, button_name — название кнопки.

    • scripts_template — шаблон для динамического формирования последовательности subjob.

  • Атрибут для шага типа mapping: hc_template — шаблон для формирования правила распределения компонентов на хостах. Шаблон может включать:

    • component и service — название компонента и сервиса соответствующего объекта.

    • operation — тип выполняемой операции. Возможные значения:

      • add — расширение набора хостов.

      • remove — сокращение набора хостов.

Формат описания шаблонов (свойство <wizard|config|scripts|hc>_template) включает в себя следующие параметры:

  • file — файл, который используется в качестве шаблона и содержит следующие атрибуты:

    • path — путь к файлу с расширением .j2 или .py.

    • entrypoint — название функции callable() без указания пакета или модуля, которую необходимо вызвать. Используется, если engine принимает значение python.

  • engine — движок для обработки файла. Возможные значения: jinja2, python.

На основе полученной информации об action (при наличии wizard_template) создается процесс (process).

  actions:
    install:
      display_name: "Install"
      type: task
      allow_to_terminate: true
      scripts_jinja: scripts_jinja/cluster/manage_install.j2
      wizard_template:
        file:
          path: wizard_jinja/manage_install.j2
        engine:
          type: jinja2
      states:
        available:
          - created
          - faulty_installed

Создание процесса, кроме всего прочего, включает в себя рендеринг файла, указанного в wizard_template, в результате чего формируется процесс (flow). При рендеринге шаблона формируется контекст, соответствующий inventory-файлу, за исключением изменений конфиг-групп, а также переменных и фактов, которые формирует Ansible во время выполнения playbook.

Файл wizard_jinja/manage_install.j2:

- name: manage_ssl_stage
  display_name: "Manage SSL"
  steps:
    - name: configure_ssl
      display_name: "Configure SSL"
      config_template:
        file:
          path: configs_jinja/manage_ssl.j2
        engine:
          type: jinja2
- name: manage_kerberos_stage
  display_name: "Manage Kerberos"
  stpes:
    - name: configure_kerberos
      display_name: "Kerberos configuration"
      config_template:
        file:
          path: configs_jinja/manage_kerberos.j2
        engine:
          type: jinja2
    - name: check_kerberos
      display_name: "Check configuration"
      ui_options:
        button_name: Check
      scripts_template:
        file:
          path: scripts_jinja/cluster/save_config.j2
        engine:
          type: jinja2
{% if services.hdfs is defined and services.hdfs.state == 'created' %}
- name: hdfs_stage
  display_name: "Manage HDFS"
  steps:
    - name: configure_hdfs
      display_name: "Configure HDFS"
      config_template:
        file:
          path: configs_jinja/manage_hdfs.j2
        engine:
          type: jinja2
    - name: mapping
      display_name: "Fill host-component mapping"
      hc_template:
        file:
          path:  hc_jinja/manage_hdfs_hc_step.j2
        engine:
          type: jinja2
    - name: validate
      display_name: "Validate host-component mapping"
      ui_options:
        button_name: Validate
      scripts_template:
        file:
          path: scripts_jinja/validate_mapping.j2
        engine:
          type: jinja2
{% endif %}
{% if services.hdfs is defined and services.hdfs.state == 'created' %}
- name: hbase_stage
  display_name: "Manage Hbase"
  steps:
    - name: validate
      display_name: "Validate host-component mapping"
      ui_options:
        button_name: Validate
      scripts_template:
        file:
          path: scripts_jinja/validate_mapping.j2
        engine:
          type: jinja2
{% endif %}
- name: save_stage
  display_name: "Save configuration"
  steps:
    - name: save_configuration
      display_name: "Check configuration"
      ui_options:
        button_name: Check
      scripts_template:
        file:
          path: scripts_python/cluster/check.py
          entrypoint: generate_scripts
        engine:
          type: python

Файл manage_ssl.j2:

- name: ssl_config
  display_name: "Enable SSL"
  type: group
{% if vars.cluster.config.ssl_config.enable_ssl %}
  activatable: true
{% else %}
  activatable: false
{% endif %}
  subs:
    - name: keystore_path
      display_name: "Keystore path"
      type: string
      default: "{{ cluster.config.ssl_default_config.keystore_path }}"
    - name: keystore_password
      display_name: "Keystore password"
      type: password

Файл manage_kerberos.j2:

- name: kerberos_config
  display_name: "Enable Kerberos"
  type: group
{% if vars.cluster.config.kerberos_config.enable_kerberos %}
  activatable: true
{% else %}
  activatable: false
{% endif %}
  subs:
    - name: keystore_password
      display_name: "Keystore password"
      type: password
      default: {{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config.keystore_password }}

Файл save_config.j2:

{% set ssl_key = "ssl_default_config/keystore_password" %}
- name: validate
  display_name: "Precheck"
  script_type: ansible
  script: some/playbook.yaml
  params:
    ansible_tags:
      - check
- name: state_2
  display_name: "State 2"
  script_type: internal
  script: config_apply
  params:
    changes:
      - object:
          type: cluster
        parameters:
{% if action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config.enable_ssl %}
          - key: "{{ ssl_key }}"
            value: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config }}"
{% endif %}
{% if action.process.stages.manage_kerberos_wizard.config.kerberos_config.enable_kerberos %}
          - key: "kerberos_default_config/keystore_password}"
            value: "{{ action.process.stages.manage_kerberos_stage.configure_kerberos.config.kerberos_config.keystore_password }}"
{% endif %}

Файл manage_hdfs_hc_step.j2:

{% raw %}
- service: hdfs
  component: namenode
  operation: add
- service: hdfs
  component: datanode
  operation: add
{% endraw %}

Файл manage_hdfs.j2:

- name: kerberos_config
  display_name: "DFS data dir"
  type: string
  default: {{ vars.services.hdfs.config.data_dir }}

Файл check.py:

def create_script_template(display_name, name, params, script, script_type):
    """Template for creating action dictionaries with consistent structure."""
    return {
        'display_name': display_name,
        'name': name,
        'params': params,
        'script': script,
        'script_type': script_type
    }

def generate_scripts(context: dict):
    cluster = context['cluster']
    action = context['action']
    script1 = create_script_template(
        display_name='Check',
        name='validate',
        params={'ansible_tags': ['check']},
        script='some/playbook.yaml',
        script_type='ansible'
    )

    script2_params = [{
        'object': {'type': 'cluster'},
        'parameters': [{
            'key':  'ssl_config',
            'value': action['process']['stages']['manage_ssl_stage']['configure_ssl']['config']['ssl_config']
        }]
    }]

    script2 = create_script_template(
        display_name='State 2',
        name='state_2',
        params=script2_params,
        script='config_apply',
        script_type='internal'
    )

    return [script1, script2]

  ### Return
  [{'display_name': 'Check',
  'name': 'validate',
  'params': {'ansible_tags': ['check']},
  'script': 'some/playbook.yaml',
  'script_type': 'ansible'},
   {'display_name': 'State 2',
  'name': 'state_2',
  'params': [{'object': {'type': 'cluster'},
              'parameters': [{'key': 'ssl_config', 'value': 'some_value'}]}],
  'script': 'config_apply',
  'script_type': 'internal'}]

Файл validate_mapping.j2:

- name: validate
  display_name: "Precheck"
  script_type: ansible
  script: some/playbook.yaml
  params:
    process:
      current_stage: {{ action.process.current.stage }}

При описании шаблона можно использовать переменную groups. Эта переменная содержит список имен хостов без их конфигураций. Ниже приведен пример переменных контекста рендеринга шаблона для шага save_configuration этапа save_stage.

ПРИМЕЧАНИЕ
  • При формировании контекста добавляются переменные из предыдущего шага, которые хранятся в словаре action.process.

  • Изменения, относящиеся к конкретному шагу, должны указываться в action.process.stages.<stage>.groups и использоваться только в рамках выполнения данного шага. Если в рамках процесса выполняются последовательные операции добавления и удаления одного и того же компонента на одном и том же хосте, такие операции не включаются в groups, поскольку они взаимно компенсируют друг друга. При этом соответствующие операции сохраняются в action.process.stages.<stage>.groups соответствующих шагов процесса.

"cluster": {
   "config": {
      "reliability_control": {
         "retries": 3153600,
         "delay": 10,
         "timeout": 31536000
       }
   },
   "id": 210,
   "name": "adh bu"
   "state": "installed",
   "multi_state": [],
   "before_upgrade": {},
   "version": "3.2.4_arenadata2_b1-for_autotest",
   "edition": "enterprise",
   "imports": None  # absent if no imports
},
"services":{
   "zookeeper":{
      "id" :193,
      "state":"installed",
      "multi_state":[],
      "before_upgrade":{"state":null},
      "config": {},
      "display_name": "Zookeeper",
      "version": "1.0",
      "maintenance_mode": False,
      "SERVER":{
         "component_id": 582,
         "state":"installed",
         "multi_state":[],
         "before_upgrade":{...},
         "config":{},
         "display_name": "Zookeeper Server",
         "maintenance_mode": false
      },
   },
},
"groups": {
   "CLUSTER": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
   "zookeeper": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
   "zookeeper.SERVER": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
   "hdfs.namenode.add": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
  "hdfs.datanode.add": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
},
"action": {
    "owner_group": "zookeeper",
    "name": "install",
    "process": {
        "current": {
            "step": "validate",
            "stage": "hbase_stage",
        },
        "stages": {
            "manage_ssl_stage": {
                "configure_ssl": {
                    "config": {
                        "ssl_config": {
                            "keystore_path": "/etc/security/ssl",
                            "keystore_password": "ANSIBLE_VAULT:...."
                        }
                    }
                }
            },
            "manage_kerberos_stage": {
                "configure_kerberos": {
                    "config": {
                        "kerberos_config": {
                            "keystore_password": "ANSIBLE_VAULT:...."
                        }
                    }
                }
            },
            "hdfs_stage": {
                "mapping": {
                    "groups": {
                        "hdfs.namenode.add": [
                            "ke-test-hadoop-25.ru-central1.internal",
                        ]
                        "hdfs.datanode.add": [
                            "ke-test-hadoop-25.ru-central1.internal",
                        ]
                    }
                }
            }
        }
    }
}

Параметры для action типа job

Ниже приведены обязательные параметры, которые должны быть определены для action типа job (type: job).

ПРИМЕЧАНИЕ
Свойство type не поддерживается начиная с версии контракта 2.0 (contract_version: 2).

params

Параметр params позволяет передать любой дополнительный параметр для вызова Ansible. Такие параметры будут использоваться в вызовах команды ansible-playbook.

Среди поддерживаемых параметров можно выделить ansible_tags. Параметр служит прямым эквивалентом аргумента --tags, который передается при запуске команды ansible‑playbook.

Вы также можете указать параметр jinja2_native. Данный параметр будет записан в файл ansible.cfg, что позволяет сохранить типы переменных во время операций с шаблонами Jinja2.

script

Параметр script принимает значение в зависимости от значения параметра script_type:

  • Если параметр script_type принимает значение ansible, то параметр script определяет путь к файлу скрипта. В приведенном выше примере действия install параметр script указывает путь к Ansible playbook, который находится в директории <bundle_root>/ansible/site.yaml. Вы можете использовать точку, чтобы указать путь к файлу скрипта. В этом случае поиск файла скрипта будет осуществляться в директории, которая содержит файл config.yaml:

    script: ./site.yaml
  • Если параметр script_type принимает значение internal, то параметр script может принимать значение одной из трех функций ADCM:

    • bundle_revert — эта функция возвращает состояние кластера, предшествующее моменту обновления. Состояние кластера включает его конфигурацию, набор всех сервисов, хостов и компонентов кластера, а также host-component map.

    • hc_apply — эта функция полезна, когда действие (action) включает hc_acl и возникает необходимость зафиксировать изменения host-component mapping независимо от результата завершения действия или после завершения определенного шага (subjob). Функция hc_apply фиксирует изменения host-component mapping в соответствии с полученными от пользователя данными. Используйте опциональный параметр params в случае необходимости фиксации частичных изменений. Другими словами, с помощью params вы можете указать правило аналогично hc_acl (имена сервиса и компонента, а также операцию add или remove), которое зафиксирует часть host-component mapping, ассоциированную с указанным правилом.

      - name: apply hc
        script_type: internal
        script: hc_apply
        params:
          rules:
            - service: redis
              component: server
              action: add
            - service: redis
              component: server
              action: remove
    • config_apply — эта функция полезна, когда действие (action) включает wizard_template и возникает необходимость сохранить изменения значений конфигурационных параметров, например в соответствии с полученными от пользователя данными. Правило фиксации значений конфигурационных параметров и объектов необходимо указать с помощью атрибута params, в котором описываются объект и в соответствии с типом объекта имена сервиса и компонента, а также множество пар ключ/значение.

      ПРИМЕЧАНИЕ
      Функция config_apply доступна начиная с версии 2.8.0.
      - name: save
        display_name: "Save configuration on target objects"
        script_type: internal
        script: config_apply
        params:
          changes:
            - object:
                type: cluster
              parameters:
                - key: "ssl_default_config/keystore_password"
                  value: "my_secrete_value"
            - object:
                type: service
                service_name: "hive"
              parameters:
                - key: "core-site_xml/keystore_password"
                  value: "my_secrete_value"
            - object:
                type: component
                service_name: "hive"
                component_name: "server"
              parameters:
                - key: "core-site_xml/keystore_password"
                  value: "my_value"
      - name: state_2
        display_name: "State 2"
        script_type: internal
        script: config_apply
        params:
          changes:
            - object:
                type: cluster
              parameters:
                - key: "{{ ssl_key }}"
                  value: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config }}"
            - object:
                type: service
                service_name: "{{ roles_generic_args.service_name }}"
              parameters:
                - key: "{{ ssl_key }}"
                  value: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config }}"
            - object:
                type: component
                service_name: "{{ roles_generic_args.service_name }}"
                component_name: "{{ roles_generic_args.component_name }}"
              parameters:
                - key: "{{ ssl_key }}"
                  value: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config }}"
    • bundle_switch — эта функция обновляет все прототипы до новых версий. Функция может использоваться только для действия upgrade и не может быть использована для обычных action.

script_type

Параметр script_type определяет тип скрипта. Возможные значения: ansible, internal.

Параметры для action типа task

Ниже приведены обязательные параметры, которые должны быть определены для action типа task (type: task).

ПРИМЕЧАНИЕ
Свойство type не поддерживается начиная с версии контракта 2.0 (contract_version: 2).

scripts

Последовательность выполняемых job определяется параметром scripts. Порядок выполнения job соответствует последовательности их перечисления в параметре scripts. Если один из скриптов завершается с ошибкой, то процесс выполнения job прерывается, а объект переводится в состояние, согласующееся со значением параметра on_fail.

actions:
  install:
    type: task
    scripts:
      -
          name: prepare
          display_name: Prepare to install
          script_type: ansible
          script: ansible/prepare.yaml
          on_fail: created
      -
          name: install
          display_name: Actual install
          script_type: ansible
          script: ansible/install.yaml
          on_fail: prepare
    states:
      available:
        - created
        - prepare
      on_success: installed

scripts_jinja

Action может содержать опциональный параметр scripts_jinja. Этот параметр указывает на файл в формате Jinja (поддерживается в версиях ADCM 2.xx).

ПРИМЕЧАНИЕ
Параметр scripts_jinja считается устаревшим и не поддерживается начиная с версии контракта 2.0 (contract_version: 2).

Параметр scripts_jinja предназначен для динамического формирования набора subjob на основе контекста в зависимости от условий — другими словами, от топологии кластера (например, добавлен тот или иной сервис в кластер или нет). После запуска action рендерится файл в формате Jinja (шаблон Jinja2) для формирования последовательности subjob. При рендеринге шаблона формируется контекст, соответствующий inventory-файлу, за исключением изменений конфиг-групп, а также переменных и фактов, которые формирует Ansible во время выполнения playbook (включая дополнительные детали action, в том числе, что было введено и выбрано пользователем при конфигурировании action).

Параметр scripts_jinja поддерживается только для action типа task и является взаимоисключающим с параметром scripts (статическим формированием subjob).

---
actions:
  - name: Add/remove components
    type: task
    scripts_jinja: scripts_jinja/manage_component_scripts.j2

Файл manage_component_scripts.j2:

{%- if (groups['zookeeper.SERVER.add'] | length) > 0 %}
- name: zookeeper
  display_name: "Zookeeper"
  script_type: ansible
  script: ansible/playbooks/cluster/zookeeper_install.yaml
  params:
    ansible_tags: repo_add, install, configure, configure_main_info, start, bootstrap
{%- endif %}
{%- if (groups['zookeeper.SERVER.remove'] | length) > 0 %}
- name: zookeeper
  display_name: "Zookeeper"
  script_type: ansible
  script: ansible/playbooks/cluster/zookeeper_remove.yaml
  params:
    ansible_tags: stop, remove
{%- endif %}
- name: zookeeper
  display_name: "Zookeeper"
  script_type: ansible
  script: ansible/playbooks/cluster/zookeeper_install.yaml
  params:
    ansible_tags: configure

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

"cluster": {
   "config": {
      "reliability_control": {
         "retries": 3153600,
         "delay": 10,
         "timeout": 31536000
       }
   },
   "id": 210,
   "name": "adh bu"
   "state": "installed",
   "multi_state": [],
   "before_upgrade": {},
   "version": "3.2.4_arenadata2_b1-for_autotest",
   "edition": "enterprise",
   "imports": None  # absent if no imports
},
"services":{
   "zookeeper":{
      "id" :193,
      "state":"installed",
      "multi_state":[],
      "before_upgrade":{"state":null},
      "config": {},
      "display_name": "Zookeeper",
      "version": "1.0",
      "maintenance_mode": False,
      "SERVER":{
         "component_id": 582,
         "state":"installed",
         "multi_state":[],
         "before_upgrade":{...},
         "config":{},
         "display_name": "Zookeeper Server",
         "maintenance_mode": false
      },
   },
},
"groups": {
   "CLUSTER": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
   "zookeeper": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
   "zookeeper.SERVER": [
      "ke-test-hadoop-25.ru-central1.internal",
   ]
},
"task":{
   "config": {},
   "verbose": false
},
"action": {
   "owner_group": "zookeeper",
   "name": "install"
}

Специальные action

Доступны четыре специальные action, которые могут быть запущены в веб-интерфейсе ADCM и на указанных конечных точках (endpoint):

  • adcm_turn_on_maintenance_mode

  • adcm_turn_off_maintenance_mode

  • adcm_host_turn_on_maintenance_mode

  • adcm_host_turn_off_maintenance_mode

Пример описания специального action:

  actions:
    adcm_turn_on_maintenance_mode

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

Название действия Тип прототипа Описание

adcm_turn_on_maintenance_mode

Сервис/компонент

Переводит объект в режим обслуживания с помощью соответствующего элемента веб-интерфейса

adcm_turn_off_maintenance_mode

Сервис/компонент

Выводит объект из режима обслуживания с помощью соответствующего элемента веб-интерфейса

adcm_host_turn_on_maintenance_mode

Кластер

Переводит хост кластера в режим обслуживания с помощью соответствующего элемента веб-интерфейса

adcm_host_turn_off_maintenance_mode

Кластер

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

adcm_delete_service

Сервис

Удаляет сервис с помощью соответствующего элемента веб-интерфейса

Специальные action, которые описаны в прототипе кластера (adcm_host_turn_on_maintenance_mode и adcm_host_turn_off_maintenance_mode), должны быть также объявлены для хоста (host_action: true).

ВАЖНО
Специальные action не поддерживаются для свойств config, hc_acl и ui_options.
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней