Миграция бандла на новую версию контракта

Аделя Звягинцева

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

Переход на более старшую версию требует последовательной миграции всех предыдущих версий.

С версии 1.0 на 2.0

Для миграции бандла с версии контракта 1.0 на 2.0 выполните следующие действия:

  1. Преобразуйте action типа job, так как начиная с версии контракта 2.0 action типа job не поддерживаются. Для этого:

    • Удалите свойство type.

    • Оформите выполнение скрипта с использованием параметра scripts, переместив в него параметры script и script_type.

    • Укажите атрибуты name и display_name в каждом элементе списка scripts.

    Пример action при contract_version: 1.0:

    ---
  actions:
    check:
      ....
      type: job
      script_type: ansible
      script: ansible/playbooks/cluster/check_mm.yaml
      ....

    Пример action при contract_version: 2.0:

    ---
  actions:
    check:
      ...
      scripts:
        - name: check
          display_name: Check
          script_type: ansible
          script: ansible/playbooks/cluster/check_mm.yaml

  2. Перенесите параметр params в соответствующий элемент списка scripts. Для contract_version: 1.0 параметр params, определенный на уровне action, наследовался и применялся к каждой подзадаче (subjob).

     
    Пример action при contract_version: 1.0:

    ---
  actions:
    check:
      display_name: Check
      type: task
      scripts:
        - name: check
          display_name: Check
          script_type: ansible
          script: ansible/playbooks/cluster/check_mm.yaml
      params:
        actions:
          - stop

    Пример action при contract_version: 2.0:

    ---
  actions:
    check:
      display_name: Check
      scripts:
        - name: check
          display_name: Check
          script_type: ansible
          script: ansible/playbooks/cluster/check_mm.yaml
          params:
            actions:
              - stop

  3. Удалите из секции actions свойства type и log_files, так как они не поддерживаются начиная с версии контракта 2.0.

     
    Пример action при contract_version: 1.0:

    ---
  actions:
    check:
      display_name: Check
      type: task
      log_files:
        - check
      scripts:
        - name: check
          display_name: Check
          script_type: ansible
          script: ansible/playbooks/cluster/check_mm.yaml

    Пример action при contract_version: 2.0:

    ---
  actions:
    check:
      display_name: Check
# legacy attributes to be deleted
#      type: task
#      log_files:
#        - check
      scripts:
        - name: check
          display_name: Check
          script_type: ansible
          script: ansible/playbooks/cluster/check_mm.yaml

  4. Замените параметры scripts_jinja и config_jinja на scripts_template и config_template, указав путь к файлу и тип движка для обработки файла, так как начиная с версии контракта 2.0 данные параметры не поддерживаются.

    ПРИМЕЧАНИЕ
    Обратите внимание, что параметры scripts_template и config_template используют более строгую валидацию по сравнению с устаревшими параметрами scripts_jinja и config_jinja. В связи с этим при переходе на новые параметры может потребоваться доработка шаблонов Jinja2.

     
    Пример action при contract_version: 1.0:

    ---
  actions:
    install:
      display_name: Install
      type: task
      config_jinja: config_jinja/cluster/config.j2
      scripts_jinja: scripts_jinja/cluster/manage_install.j2
      states:
        available:
          - created

    Пример action при contract_version: 2.0:

    ---
  actions:
    check:
      display_name: Check
      config_template:
        file:
          path: scripts_jinja/cluster/config.j2
        engine:
          type: jinja2
      scripts_template:
        file:
          path: scripts_jinja/cluster/manage_install.j2
        engine:
          type: jinja2
      states:
        available:
          - created

  5. Перенесите свойство venv на уровень объекта (например, сервиса), так как начиная с версии контракта 2.0 оно не поддерживается на уровне actions и upgrade.

    ПРИМЕЧАНИЕ
    Начиная с версии контракта 2.0 свойство venv является обязательным для объектов cluster и provider.

    Пример action при contract_version: 1.0:

    ---
- type: service
  name: hdfs
  actions:
    start:
      display_name: Start
      venv: 2.9
      ....
      states:
        available:
          - installed

    Пример action при contract_version: 2.0:

    ---
- type: service
  name: hdfs
  venv: 2.9
  actions:
    start:
      display_name: Start
      ....
      states:
        available:
          - installed

  6. Переведите action, использующие в качестве окружения Ansible 2.8 (default), на версию 2.16. Переход может потребовать доработок существующих Ansible playbook и ролей (role).

    ПРИМЕЧАНИЕ
    Начиная с версии контракта 2.0 свойство venv не поддерживает значения default и 2.8.
ВАЖНО

После внесения изменений:

  1. Проверьте корректность структуры бандла.

  2. Убедитесь, что конфигурация совместима с версией контракта 2.0.

  3. Загрузите обновленный бандл в ADCM и убедитесь, что он проходит валидацию.

С версии 2.0 на 2.1

Для миграции бандла с версии контракта 2.0 на 2.1 переведите action, использующие Ansible 2.9 в качестве окружения, на версию 2.16. Переход может потребовать доработки существующих Ansible playbook и ролей (role).

ПРИМЕЧАНИЕ
Начиная с версии контракта 2.1 свойство venv больше не поддерживает значение 2.9.
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней