ansible-role-infosvr-openigc

Ansible роль для автоматизации развертывания объектов OpenIGC в Каталоге информационного управления на IBM Information Server.

Новый в Ansible? Это простое введение может помочь.

Требования

• Ansible версии v2.6.x
• Следующие утилиты должны быть установлены на вашем контроллере:
  • zip
  • curl

Роль не использует повышения привилегий и выполняется в основном на самом контроллере (только отправляет сгенерированные файлы непосредственно к соответствующим API в среде).

Из-за использования роли расширенного шаблонирования Jinja для YAML-входов требуется версия Ansible с недавним дистрибутивом Jinja (версии v2.4 недостаточно, поэтому требуется v2.6.x). Хотя в версии v2.7 теперь есть возможность для модуля uri отправлять файлы, он не предоставляет возможности переопределить удостоверяющий центр -- поэтому, чтобы разрешить валидацию самоподписанных сертификатов, не меняя CA на самом контроллере, мы все еще полагаемся на curl на данный момент.

Переменные роли

Смотрите defaults/main.yml для встроенной документации, и пример ниже для основных необходимых переменных.

Эта роль будет пытаться автоматически повторно использовать переменные из роли IBM.infosvr, например, используя плейбук, который сначала импортирует IBM.infosvr, используя tasks_from=setup_vars.yml.

По умолчанию роль будет выполнять проверку SSL для самоподписанных сертификатов, если вы получили их с помощью задачи get_certificate.yml роли IBM.infosvr (см. пример плейбука ниже). Это контролируется переменной ibm_infosvr_openigc_verify_selfsigned_ssl роли: если вы хотите проверять только надлежащим образом подписанные и доверенные SSL сертификаты, вы можете установить эту переменную в False, и любой самоподписанный сертификат уровня домена больше не будет считаться доверенным.

Пример плейбука

Роль в первую очередь предназначена для импорта в другие плейбуки по мере необходимости для развертывания объектов OpenIGC -- как пакетов, так и экземпляров активов. (Таким образом, необходимость в Ansible v2.4.x и модуле import_role.)

---
- name: настройка переменных Information Server
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml
    - import_role: name=IBM.infosvr tasks_from=get_certificate.yml

- name: загрузка пакетов и активов OpenIGC
  hosts: ibm_information_server_engine
  roles:
    - IBM.infosvr-openigc
  vars:
    bundles:
      - /some/directory/<BundleId>
    assets_as_xml:
      - /some/directory/asset_instances-<BundleId>.xml
    assets_as_yaml:
      - /some/directory/assets.yml
    flows_as_xml:
      - /some/directory/lineage_flows-<BundleId>.xml
    flows_as_yaml:
      - /some/directory/lineage.yml

Структура действий (и объектов)

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

bundles

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

• <BundleId>: корневая директория, на которую вы указываете, должна иметь то же регистровое имя, что и сам пакет
  • asset_type_descriptor.xml: XML, который описывает пакет (т.е. все классы, их отношения / вложение и т.д.)
  • i18n: директория, содержащая метки
    • labels.properties: набор меток классов и атрибутов для перевода
  • icons: директория, содержащая два файла .gif для каждого класса, определенного пакетом:
    • <ClassId>-icon.gif: должен быть представлением класса размером 16x16 пикселей, также может быть файлом .png, но должен быть назван .gif
    • <ClassId>-bigIcon.gif: должен быть представлением класса размером 32x32 пикселя, также может быть файлом .png, но должен быть назван .gif

assets_as_xml

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

assets_as_yaml

Эта переменная предоставляется как более удобный / читаемый способ указать экземпляры активов, не изучая XML-формат, требуемый ранее в assets_as_xml.

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

---

bundleId: $<BundleId>
contains:
  - class: <ClassName>
    name: <name>
    contains:
      - class: <NestedClassName>
        name: <name>
        contains:
          ...

Подструктура contains может быть вложена столько раз, сколько необходимо, чтобы создать иерархию содержимого для ваших активов. Каждая подструктура должна иметь по меньшей мере определенные class и name.

Кроме того, можно указать любое количество дополнительных атрибутов, разрешенных определением вашего пакета и набором атрибутов по умолчанию для всех объектов (например, short_description, long_description). Любые атрибуты, определенные пакетом, должны быть предварены знаком $. Например:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: level1
    short_description: Ведущая директория
    $filesystem: UNIX
    contains:
      - class: Folder
        name: level2
        short_description: Следующий уровень в структуре каталога
        contains:
          - class: File
            name: MyFile.txt
            short_description: Файл, находящийся в /level1/level2/MyFile.txt
            $encoding: UTF-8

В этом примере пакет TestBundle определяет Folder и File, где Folder может иметь определенный атрибут filesystem, а File может иметь определенный атрибут encoding. Оба могут иметь short_description, так как все объекты в IGC имеют этот атрибут.

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

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: root
    $users_with_access:
      - user123
      - user456
      - user789

Наконец, существует сокращение names для конечных узлов иерархии вложенности, где необходимо указать только name каждого из них -- это позволяет избежать необходимости указывать один и тот же class снова и снова для каждого конечного узла:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: root
    contains:
      - class: File
        names:
          - MyFile.txt
          - YourFile.txt
          - OtherFile.txt

flows_as_xml

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

flows_as_yaml

Эта переменная предоставляется как более удобный / читаемый способ указать экземпляры активов, не изучая XML-формат, требуемый ранее в flows_as_xml.

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

---

assets:
  - class: <FullClassName>
    name: <name>
    contains:
      - class: <NestedFullClassName>
        name: <name>
        id: <уникальный идентификатор>
        contains:
          ...

flows:
  - name: <значимый комментарий>
    within: <id>
    contains:
      - name: <значимый комментарий>
        from:
          - <id>
          - ...
        to:
          - <id>
          - ...
      - ...

Подструктура contains для assets может быть вложена столько раз, сколько необходимо, чтобы создать иерархию содержимого для ваших активов. Каждая подструктура должна иметь как минимум определенные class и name (на самом деле любые другие атрибуты просто игнорируются, так как они не используются в XML линейного потока). Обратите внимание, что в этом случае вы должны указывать полностью квалифицированные имена классов, включая bundleId, например, $BundleId-ClassName. Это необходимо для того, чтобы вы могли сочетать как OpenIGC, так и родные активы в линейном потоке (и создавать линейные потоки, охватывающие несколько пакетов OpenIGC).

Для любых активов, которые вы планируете использовать в потоке, также включите явный атрибут id, чтобы указать, как вы будете на них ссылаться в переменной flows. Этот идентификатор должен быть уникальным в пределах YAML-файла и не должен содержать пробелов или других специальных символов (кроме . и _). Это необходимо дополнительно к name, так как id предоставляет плоскую, уникальную ссылку в пределах файла; name на самом деле является вложенным идентификатором, который будет зависеть от структуры содержащегося элемента, и поэтому сам по себе не уникален (только учитывая всю его структуру вложенности).

Каждый name в переменной flows используется как комментарий в сгенерированном XML, но на самом деле не появляется в IGC.

Рассмотрите следующий пример:

---

assets:
  - class: $TestBundle-Folder
    name: root
    contains:
      - class: $TestBundle-File
        name: MyFile.txt
        id: MyFile.txt
      - class: $TestBundle-File
        name: YourFile.txt
        id: YourFile.txt
      - class: $TestBundle-File
        name: OtherFile.txt
        id: OtherFile.txt
  - class: $TestBundle-Command
    name: copy
    id: copy

flows:
  - name: Копировать команду для дублирования файла
    within: copy
    contains:
      - name: Копировать из My в Your и Other
        from:
          - MyFile.txt
        to:
          - YourFile.txt
          - OtherFile.txt

В примере у нас есть TestBundle, который определяет новые объекты, представляющие Folder, File и Command. Раздел assets определяет только объекты, которые мы хотим описать в линейности, включая их иерархию содержания. Для каждого актива, который мы будем использовать в линейности, мы определили уникальный атрибут id.

В разделе flows мы создаем линейность: внешний within определяет процесс, ответственный за любое действие, изображенное в линейности, а contains внутри этого определяет конкретные входные и выходные данные действия.

Лицензия

Apache 2.0

Информация об авторе

Кристофер Гроте