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:
-
Action, которые являются частью операции обновления (см. Обновление кластера ADPG до новой версии), не могут быть запущены для группы хостов.
-
Не поддерживается одновременное использование этого свойства и свойства host_action.
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 (иконка
) прерывается выполнение 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 %}
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"
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, запускающего выполнение одного скрипта. Описывается следующими параметрами:-
ПРИМЕЧАНИЕAction типа
jobсчитается устаревшим и не поддерживается начиная с версии контракта2.0(contract_version: 2).
-
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 }}
Параметры для 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.
-
Параметры для 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
Специальные 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.
|