ansible-role-infosvr

Роль Ansible для автоматизации развертывания окружения IBM InfoSphere Information Server, версий 11.5 и 11.7, включая:

• уровень репозитория (база данных)
• уровень домена (услуги)
• уровень движка
• уровень единого управления ("Корпоративный поиск") (только v11.7)
• патчи / фиксированные пакеты

и следующие модули Enterprise Edition, которые могут быть отключены с помощью описанных ниже переменных (например, если у вас нет прав на их использование или вы не хотите их устанавливать / настраивать):

• Каталог управления информацией
• Анализатор информации
• Консоль операций DataStage
• DataClick
• Управление событиями (интеграция с Консолю исключений качества данных)
• Консоль исключений качества данных
• QualityStage
• Директор информационных услуг
• FastTrack
• Панель управления управления информацией (требует существующую среду Cognos)
• Оптимизация маскирования в DataStage
• Включая эти дополнительные элементы, доступные только в v11.7:
  • Новый каталог управления информацией (интерфейс)
  • Панели мониторинга управления
  • Корпоративный поиск (включая Граф знаний)
  • Дизайнер потоков DataStage
  • Классификация терминов машинного обучения (v11.7+)

В настоящее время развертывание поддерживает только DB2 в качестве задней части, хотя работает как для установки и настройки пакета DB2, так и для конфигурации существующей DB2. Будет установлена полная конфигурация WebSphere Application Server Network Deployment или конфигурация WebSphere Liberty Profile (подробнее см. переменные ниже); в данный момент роль не может настраивать существующую установку WebSphere.

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

Требования

• Ansible v2.7
• Доступ к сети с правами 'root' на всех серверах
• Доступ администратора к Windows-клиентам
• Windows-клиенты настроены для доступа WinRM через Ansible (см. http://docs.ansible.com/ansible/latest/intro_windows.html)

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

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

Минимальные переменные, которые, вероятно, нужно переопределить, следующие:

• ibm_infosvr_media_dir: место на вашем хосте Ansible, куда уже загружены установочные бинарные файлы (например, из Passport Advantage)
• ibm_infosvr_media_bin dict: названия бинарных файлов, которые нужно использовать для установки (по умолчанию там находятся последние доступные файлы v11.7; если вы хотите установить v11.5, их нужно заменить на имена файлов v11.5)
• ibm_infosvr_ug_storage: дополнительное, необработанное устройство хранения на уровне единого управления, которое будет использоваться Kubernetes (должно быть необработанным: не смонтированным, не в группе lvm и т.д.)
• ibm_infosvr_features dict: определяет функции, которые вы хотите (True) или не хотите (False)

Наконец, различные переменные учетных данных должны быть переопределены, чтобы создать достаточно безопасную среду. Поиск _upwd_ откроет все переменные паролей в defaults/main.yml, которые вы захотите переопределить. (И не стесняйтесь заменять это на ссылки на другие переменные, которые также защищены через Ansible vault.)

Зависимости

Конфигурация Анализатора информации использует роль IBM.infosvr-metadata-asset-manager косвенно, используя директиву import_role. Эта роль не была указана как явная зависимость, чтобы избежать циклических зависимостей, но ее следует установить, если вы планируете настраивать Анализатор информации.

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

Следующий пример плейбука выполнит полную установку и настройку IBM InfoSphere Information Server с использованием параметров по умолчанию из defaults/main.yml (и любых переопределений, которые вы разместили, например, в group_vars/all.yml). Обратите внимание, что поскольку вся установка выполняется через несколько уровней с помощью этой одной роли, вам следует использовать any_errors_fatal, чтобы избежать частичной установки / настройки уровня в случае, если ранний шаг завершился неудачно на другом уровне.

---

- name: установить и настроить IBM InfoSphere Information Server
  hosts: all
  any_errors_fatal: true
  roles:
    - IBM.infosvr
  pre_tasks:
    - name: обновить все пакеты ОС
      yum:
        state: latest
        name: '*'
        exclude: docker*,kubelet*,kubectl*,kubeadm*
      become: yes
      when: ('ibm_information_server_clients' not in group_names)

Предварительные задачи гарантируют, что все пакеты ОС обновлены перед началом установки.

Ожидаемая инвентаризация

Ожидаются следующие группы в инвентаре, поскольку они используются для различения местоположения различных компонентов. Конечно, если вы хотите установить несколько компонентов на одном сервере, это можно сделать, просто указав одно и то же имя хоста в каждой группе. В примере ниже, например, репозиторий и уровень домена размещаются на 'serverA', тогда как уровень движка будет установлен отдельно на 'serverB', а уровень единого управления также получит свою собственную систему 'serverC'.

[ibm_information_server_repo]
# Linux хост, где должен быть установлен уровень репозитория (база данных) (DB2)
serverA.somewhere.com

[ibm_information_server_domain]
# Linux хост, где должен быть установлен уровень домена (услуги) (WebSphere)
serverA.somewhere.com

[ibm_information_server_engine]
# Linux хост, где должен быть установлен уровень движка
serverB.somewhere.com

[ibm_information_server_clients]
# Windows хост, где должны быть установлены клиентские приложения и настроен сервер обмена метаданными для брокеров / мостов только Windows
client.somewhere.com

[ibm_information_server_ug]
# Linux хост, где должен быть установлен уровень единого управления v11.7+ (kubernetes)
serverC.somewhere.com

[ibm_information_server_external_db]
# Linux хост, который удерживает существующую базу данных, в которую нужно развернуть XMETA и т.д. -- если хост не предоставлен или эта группа отсутствует, будет установлен встроенный DB2 на сервере ibm_information_server_repo
serverD.somewhere.com

[ibm_cognos_report_server]
# Linux хост, где существует существующая установка Cognos BI (для панели управления управления информацией)
cognos.somewhere.com

[ibm_bpm]
# Linux хост, где существует существующая установка BPM (в данный момент не используется)
bpm.somewhere.com

Как и в любом инвентаре Ansible, должны быть предоставлены достаточные детали, чтобы обеспечить возможность подключения к серверам (см. http://docs.ansible.com/ansible/latest/intro_inventory.html#list-of-behavioral-inventory-parameters).

Теги

Установка патчей

Роль также предназначена для того, чтобы поддерживать установленную среду в актуальном состоянии с патчами и системными пакетами. Чтобы применить патчи, просто внесите соответствующие данные в файлы в vars/patches/[server|client]/<version>/<date>.yml. Например, исправления для серверной стороны v11.7.1.0 следует помещать в vars/patches/server/11.7.1.0/<date>.yml, тогда как исправления для клиентской стороны v11.7.0.2 помещаются в vars/patches/client/11.7.0.2/<date>.yml, где <date> — это дата, когда патч был выпущен. Обычно эти данные обновляются в GitHub в зависимости от доступности основных патчей в Fix Central; но если вы хотите применить временный фикс или другой, который уже не входит в список, просто следуйте нижеследующим инструкциям.

• Каждый патч должен быть словарем с именем ibm_infosvr_patch_definition.
• Словарь должен содержать следующие ключи:
  • name: название патча / фиксированного пакета, как указано на IBM Fix Central
  • srcFile: имя файла патча / фиксированного пакета, как загруженного с IBM Fix Central
  • pkgFile: имя .ispkg файла, содержащегося в srcFile
  • versionId: тег installerId, который добавляется к вашему Version.xml, после установки патча / фиксированного пакета
  • tiers: список уровней, на которые этот патч должен быть применен (возможные значения — domain и engine) — для клиентских патчей это подразумевается как клиент, поэтому tiers не требуется

Например:

ibm_infosvr_patch_definition:
  name: is11700_ServicePack2_ug_services_engine_linux64
  srcFile: servicepack_11.7_SP2_linux64_11700.tar.gz
  pkgFile: servicepack_11.7_SP2_linux64_11700.ispkg
  versionId: servicepack_SP2_IS117_11700
  tiers:
    - domain
    - engine

Обновления JDK также могут быть включены в vars/patches/jdk/[server|client]/<major>/latest.yml, где <major> — это версия основного выпуска (11.5 или 11.7). В обоих случаях должен использоваться один словарь с именем ibm_infosvr_jdk_definition для определения информации о JDK.

Для 11.5 нужны следующие ключи:

• name: название JDK, как указано на IBM Fix Central
• infosvr_filename: имя файла JDK, как загруженного с IBM Fix Central
• infosvr_extract_path: путь, созданный при распаковке файла JDK
• versionInfo: строка версии, которая уникально определяет эту версию JDK (из java -version)
• was_filename: имя фиксированного пакета WebSphere Application Server (WAS), который содержит JDK версии 6
• was_offering: имя предложения в фиксированном пакете JDK (WAS версии 6)
• jdk7_filename: имя фиксированного пакета WAS, который содержит JDK версии 7
• jdk7_offering: имя предложения в фиксированном пакете JDK (WAS версии 7)
• was_versionInfo: строка версии, которая уникально определяет эту версию JDK (версии 6, из java -version)
• jdk7_versionInfo: строка версии, которая уникально определяет эту версию JDK (версии 7, из java -version)

Для 11.7 нужны следующие ключи:

• name: название JDK, как указано на IBM Fix Central
• infosvr_filename: имя файла JDK, как загруженного с IBM Fix Central
• infosvr_extract_path: путь, созданный при распаковке файла JDK
• was_filename: имя фиксированного пакета WebSphere Application Server (WAS), который содержит JDK
• was_offering: имя предложения в фиксированном пакете JDK (WAS)
• versionInfo: строка версии, которая уникально определяет эту версию (не-WAS) JDK (из java -version)
• was_versionInfo: строка версии, которая уникально определяет эту версию JDK (WAS) (из java -version)

Эти обновления JDK не являются списком, а простым словарем, так как каждое обновление перезапишет предыдущее обновление; вам следует указывать только последнюю версию JDK, которую вы хотите применить.

Чтобы запустить обновление, используйте тег update следующим образом:

ansible-playbook [-i hosts] [site.yml] --tags=update

Это применит любые патчи, указанные в файлах vars/patches... для вашего конкретного релиза, которые еще не были применены. Патчи применяются в отсортированном порядке по дате их выпуска (сначала самые ранние). Однако это не обновит пакеты на уровне системы для операционной системы: если вы хотите этого, убедитесь, что ваш более широкий плейбук позаботится об этом обновлении.

Операции с окружением

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

• status: проверит, что различные компоненты, которые были настроены, работают (проверяя, что служба прослушивает их назначенные порты).
• stop: аккуратно завершит работу каждого компонента в соответствующем порядке на разных хостах; не выключая сами хосты.
• start: запустит каждый компонент в соответствующем порядке на разных хостах.
• restart: предоставляет простой способ выполнить stop, сразу за которым следует start.

Повторно используемые задачи

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

setup_vars.yml

Конфигурационные переменные, используемые для развертывания окружения Information Server, могут быть позже получены, используя набор задач setup_vars.yml, например, включив следующий плей в ваш плейбук:

---

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

get_certificate.yml

Корневой SSL-сертификат уровня домена окружения Information Server можно получить позже, используя набор задач get_certificate.yml, например, включив следующий плей в ваш плейбук:

---

- 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

Обратите внимание, что этот набор задач также зависит от выполнения setup_vars.yml, поэтому, возможно, стоит включить их в один и тот же плей (как в приведенном выше примере). SSL-сертификат уровня домена будет сохранен в cache/__ibm_infosvr_cert_root.crt относительно пути, где выполняется плейбук на управляющей машине.

Лицензия

Apache 2.0

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

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