ibm.infosvr-import-export

ansible-role-infosvr-import-export

Ansible роль для автоматизации импорта и экспорта контента и структур в IBM InfoSphere Information Server.

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

Требования

Ansible версии 2.8 и выше
Доступ к сети с правами dsadm в среду IBM Information Server
Имена групп инвентаря настроены так же, как в роли IBM.infosvr
(Для удобства использования, роль IBM.infosvr должна быть установлена и настроена)
Установлен jmespath на вашей управляющей машине (эта роль использует модуль json_query, который зависит от данной библиотеки)

Роль opcionalno использует повышенные привилегии для выполнения нескольких задач настройки. Если ваша среда не позволяет повысить привилегии, убедитесь, что эти предварительные требования уже выполнены вручную, и измените переменную ibm_infosvr_impexp_priv_escalate в файле defaults/main.yml на False (это пропустит все попытки повышения привилегий до root).

Если вы установили повышение привилегий на false, убедитесь, что следующее выполнено в вашей целевой среде перед запуском роли:

Установлена библиотека python-requests (например, через yum)
Установлена библиотека python-lxml (например, через yum)
Установлен curl (например, через yum)
Каталог {IS_HOME}/ASBServer/logs доменной линии должен быть доступен для записи пользователю, выполняющему роль (также как и каждый из файлов .log в этом каталоге)

(Повышение привилегий до dsadm используется в основном для обработки оперативной метаданных и извлечения и загрузки переменных проектов DataStage; если вам не нужны эти функции, вам может не понадобиться повышение привилегий.)

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

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

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

Пример Playbook

Роль включает возможность как экспортировать, так и импортировать ряд различных типов активов в Information Server. Роль можно импортировать в другой playbook, предоставив только интересующие переменные, чтобы ограничить активы, которые будут включены в экспорт или импорт (пустые переменные означают, что роль пропустит обработку этих типов активов).

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

gather - получить данные о среде (например, номера версий)
export - извлечь активы из среды в файлы
merge - объединить несколько файлов активов в один файл
ingest - загрузить активы в среду из файлов (import — это зарезервированная переменная в Ansible, поэтому используется ingest...)
progress - перемещать активы через рабочий процесс (ничего не произойдет, если рабочий процесс не включен)
validate - проверить, что среда находится в ожидаемом состоянии, используя объективные подсчеты активов

Любые отсутствующие переменные просто пропустят этот набор действий.

Например:

---

- 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: загрузка и валидация активов
  hosts: all
  roles:
    - IBM.infosvr-import-export
  vars:
    isx_mappings:
      - { type: "HostSystem", attr: "name", from: "MY_HOST", to "YOUR_HOST" }
    gather: True
    ingest:
      datastage:
        - from: /some/directory/file1.isx
          into_project: dstage1
          with_options:
            overwrite: True
      common:
        - from: file2.isx
          with_options:
            transformed_by: "{{ isx_mappings }}"
            overwrite: True
    validate:
      that:
        - number_of: dsjob
          meeting_all_conditions:
            - { property: "transformation_project.name", operator: "=", value: "dstage1" }
          is: 5
        - number_of: database_table
          meeting_all_conditions:
            - { property: "database_schema.database.host.name", operator: "=", value: "YOUR_HOST" }
          is: 10

... начнет с получения данных о среде, с которой работает playbook.

Затем он импортирует общие метаданные из файла file2.isx (ожидается наличие подкаталога files/ относительно вашего playbook), переименовывая любые имена хостов с MY_HOST на YOUR_HOST, и перезаписывая любые существующие активы с теми же идентификаторами. Затем он импортирует активы DataStage из /some/directory/file1.isx в проект dstage1, перезаписывая любые существующие активы с теми же идентификаторами.

Обратите внимание, что порядок определения переменных не имеет значения: роль позаботится о правильном порядке экспорта и импорта объектов, чтобы гарантировать, что зависимости между объектами учитываются (например, что общие и бизнес-метаданные загружаются до зависимостей и т. д.). Однако порядок нескольких объектов, определенных внутри данного типа, может иметь значение, в зависимости от ваших собственных зависимостей.

Наконец, playbook валидирует, что загрузка привела к ожидаемым активам в целевой среде: 5 задач DataStage в проекте dstage1 и 10 таблиц баз данных в некоторых комбинациях схем и баз данных на сервере YOUR_HOST.

(Поскольку ни действия progress, ни export не указаны, они не будут выполнены.)

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

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

gather - сбор данных о среде
export / merge / ingest метаданные типов активов (как и с вышеупомянутыми действиями, порядок ниже определяет порядок, в котором эти типы объектов будут извлекаться и загружаться — независимо от порядка их появления в действии)
1. customattrs - определения пользовательских атрибутов
2. common - общие метаданные (считаются базовым уровнем, и по возможности избегайте их использования, используя один из специализированных вариантов)
3. logicalmodel - метаданные логической модели
4. physicalmodel - метаданные физической модели
5. mdm - метаданные управления основными данными
6. database - метаданные базы данных
7. datafile - метаданные файлов данных
8. dataclass - метаданные класса данных
9. datastage - активы DataStage
10. ds_vars - переменные проектов DataStage
11. infoanalyzer - активы Анализатора информации
12. openigc - пакеты и активы OpenIGC
13. extendedsource - расширенные источники данных
14. extensionmap - документы сопоставления расширений
15. glossary - активы глоссария
16. relationships - метаданные отношений
17. omd - оперативные метаданные
progress - продвижение рабочего процесса
validate - рамки валидации

Для export, merge и ingest, можно применять сопоставления для преобразования метаданных между средами (например, переименование, изменение укрытия и т. д.), а также большинство типов активов могут быть ограничены с помощью условий.

Обратите внимание, что вы можете писать эти структуры переменных в любом формате, поддерживаемом Ansible, например, все они эквивалентны и зависят только от вашего личного предпочтения:

var_name: [ { a: "", b: "", c: "" }, { d: "", e: "", f: "" } ]

var_name:
  - { a: "", b: "", c: "" }
  - { d: "", e: "", f: "" }

var_name:
  - a: ""
    b: ""
    c: ""
  - d: ""
    e: ""
    f: ""