ansible-role-infosvr

Rola Ansible służąca do automatyzacji wdrażania środowiska IBM InfoSphere Information Server w wersjach 11.5 i 11.7, obejmująca:

• warstwę repozytorium (bazy danych)
• warstwę domeny (usług)
• warstwę silnika
• warstwę zjednoczonego zarządzania ("Enterprise Search") (tylko w wersji 11.7)
• łatki / pakiety naprawcze

oraz następujące moduły edycji Enterprise, które można wyłączyć za pomocą opisanych poniżej zmiennych (np. jeśli nie masz prawa do ich używania lub nie chcesz ich instalować / konfigurować):

• Katalog zarządzania informacjami
• Analizator informacji
• Konsola operacji DataStage
• DataClick
• Zarządzanie zdarzeniami (integracja z Konsolą Wyjątków Jakości Danych)
• Konsola Wyjątków Jakości Danych
• QualityStage
• Dyrektor Usług Informacyjnych
• FastTrack
• Dashboard zarządzania informacjami (wymaga istniejącego środowiska Cognos)
• Maskowanie Optim w DataStage
• Włącznie z dodatkami dostępnymi tylko w wersji 11.7:
  • Nowy Katalog Zarządzania Informacjami (UI)
  • Dashboardy Governance Monitor
  • Enterprise Search (w tym Knowledge Graph)
  • Projektant przepływów DataStage
  • Klasyfikacja terminów uczenia maszynowego (v11.7+)

Obecnie wdrożenie obsługuje tylko DB2 jako zaplecze, chociaż działa zarówno w przypadku instalacji i konfiguracji bundlowanego DB2, jak i konfiguracji istniejącego DB2. Zainstalowana zostanie pełna konfiguracja WebSphere Application Server Network Deployment lub konfiguracja profilu WebSphere Liberty (szczegóły w zmiennych poniżej); obecnie rola nie jest w stanie skonfigurować istniejącej instalacji WebSphere.

Nowy w Ansible? Możesz skorzystać z tego proste wprowadzenie.

Wymagania

• Ansible v2.7
• dostęp do sieci jako 'root' na wszystkich serwerach
• dostęp administratora do maszyn klienckich Windows
• maszyny klienckie Windows skonfigurowane do uzyskania dostępu przez WinRM za pomocą Ansible (zobacz http://docs.ansible.com/ansible/latest/intro_windows.html)

Zmienne roli

Patrz defaults/main.yml w celu uzyskania dokumentacji inline, a przykład poniżej przedstawia główne zmienne, które są potrzebne. Plik z domyślnymi ustawieniami zawiera domyślne wartości, jakie znajdziesz dla podstawowej instalacji v11.7, dlatego musisz nadpisać tylko te zmienne, które chcesz zmienić (np. hasła dla użytkowników).

Minimalne zmienne, które mogą wymagać nadpisania, to:

• ibm_infosvr_media_dir: lokalizacja na hoście Ansible, gdzie już pobrano pliki instalacyjne (np. z Passport Advantage)
• ibm_infosvr_media_bin dict: nazwy plików binarnych do użycia do instalacji (domyślnie znajdują się tam najnowsze pliki v11.7; jeśli chcesz zainstalować v11.5, te muszą być zastąpione nazwami plików v11.5)
• ibm_infosvr_ug_storage: dodatkowe, surowe urządzenie pamięci masowej na warstwie Unified Governance do wykorzystania przez kubernetes (powinno być surowe: niezamontowane, nie w grupie lvm itp.)
• ibm_infosvr_features dict: definiująca funkcje, które chcesz mieć (True) lub nie chcesz (False)

Na koniec, różne zmienne dotyczące poświadczeń powinny być nadpisane, aby stworzyć wystarczająco bezpieczne środowisko. Wyszukiwanie _upwd_ ujawni wszystkie zmienne hasła w defaults/main.yml, które będziesz chciał nadpisać. (I nie krępuj się zastępować ich odniesieniami do innych zmiennych, które są dodatkowo zabezpieczone przez vault Ansible.)

Zależności

Konfiguracja Analizatora Informacji korzysta pośrednio z roli IBM.infosvr-metadata-asset-manager, używając dyrektywy import_role. Ta rola nie została wymieniona jako wyraźna zależność, aby uniknąć cyklicznych zależności, ale powinna być zainstalowana, jeśli planujesz skonfigurować Analizator Informacji.

Przykładowy Playbook

Poniższy przykładowy playbook wykona pełną instalację i konfigurację IBM InfoSphere Information Server, używając domyślnych parametrów z defaults/main.yml (oraz wszelkich nadpisanych wartości w np. group_vars/all.yml). Zauważ, że ponieważ cała instalacja jest przeprowadzana na wielu warstwach przez tę jedną rolę, powinieneś użyć any_errors_fatal, aby uniknąć częściowej instalacji / konfiguracji warstwy w przypadku, gdy wcześniejszy krok nie powiedzie się na innej warstwie.

---

- name: zainstaluj i skonfiguruj IBM InfoSphere Information Server
  hosts: all
  any_errors_fatal: true
  roles:
    - IBM.infosvr
  pre_tasks:
    - name: zaktualizuj wszystkie pakiety systemowe
      yum:
        state: latest
        name: '*'
        exclude: docker*,kubelet*,kubectl*,kubeadm*
      become: yes
      when: ('ibm_information_server_clients' not in group_names)

Zadania wstępne zapewniają, że wszystkie pakiety systemowe są aktualne przed rozpoczęciem instalacji.

Oczekiwana inwentarz

Oczekiwane grupy w inwentarzu są używane do rozróżnienia, gdzie różne komponenty są instalowane. Oczywiście, jeśli chcesz zainstalować wiele komponentów na jednym serwerze, możesz to zrobić, po prostu podając tę samą nazwę hosta w każdej grupie. W poniższym przykładzie na przykład warstwy repozytorium i domeny są umieszczone na 'serverA', podczas gdy warstwa silnika będzie zainstalowana osobno na 'serverB', a warstwa Unified Governance również zyskuje swój własny system 'serverC'.

[ibm_information_server_repo]
# Linux host, na którym powinna być zainstalowana warstwa repozytorium (baza danych) (DB2)
serverA.somewhere.com

[ibm_information_server_domain]
# Linux host, na którym powinna być zainstalowana warstwa domeny (usług) (WebSphere)
serverA.somewhere.com

[ibm_information_server_engine]
# Linux host, na którym powinna być zainstalowana warstwa silnika
serverB.somewhere.com

[ibm_information_server_clients]
# Windows host, na którym powinny być zainstalowane aplikacje klienckie i skonfigurowany serwer wymiany metadanych dla brokerów / mostów działających tylko w systemie Windows
client.somewhere.com

[ibm_information_server_ug]
# Linux host, na którym powinna być zainstalowana warstwa Unified Governance w wersji 11.7+ (kubernetes)
serverC.somewhere.com

[ibm_information_server_external_db]
# Linux host, który ma istniejącą bazę danych, w którą należy wdrożyć XMETA itp. -- jeśli nie podano hosta lub ta grupa jest całkowicie brakująca, zainstaluje się bundlowany DB2 na serwerze ibm_information_server_repo
serverD.somewhere.com

[ibm_cognos_report_server]
# Linux host, na którym istnieje wcześniejsza instalacja Cognos BI (dla Dashboardu zarządzania informacjami)
cognos.somewhere.com

[ibm_bpm]
# Linux host, na którym istnieje wcześniejsza instalacja BPM (obecnie nieużywane)
bpm.somewhere.com

Jak w każdym inwentarzu Ansible, należy zapewnić wystarczające szczegóły umożliwiające połączenie z serwerami (zobacz http://docs.ansible.com/ansible/latest/intro_inventory.html#list-of-behavioral-inventory-parameters).

Tagowanie

Instalowanie poprawek

Rola jest również przeznaczona do aktualizacji zainstalowanego środowiska za pomocą łatek i pakietów systemowych. Aby zastosować poprawki, po prostu wprowadź odpowiednie szczegóły do plików w vars/patches/[server|client]/<version>/<date>.yml. Na przykład poprawki dla servera v11.7.1.0 powinny trafić do vars/patches/server/11.7.1.0/<date>.yml, natomiast poprawki dla klienta v11.7.0.2 do vars/patches/client/11.7.0.2/<date>.yml, gdzie <date> to data wydania poprawki. Generalnie, są one aktualizowane w GitHubie w oparciu o dostępność głównych poprawek w Fix Central; jeśli chcesz zastosować tymczasową poprawkę lub inną, która nie znajduje się już na liście, po prostu postępuj zgodnie z poniższymi instrukcjami.

• Każda poprawka powinna być słownikiem o nazwie ibm_infosvr_patch_definition.
• Słownik powinien zawierać następujące klucze:
  • name: nazwa poprawki / pakietu naprawczego, jak podana w IBM Fix Central
  • srcFile: nazwa pliku poprawki / pakietu naprawczego, jak pobrano z IBM Fix Central
  • pkgFile: nazwa pliku .ispkg zawartego w srcFile
  • versionId: znaczek installerId, który zostanie dodany do Twojego Version.xml po zainstalowaniu poprawki / pakietu naprawczego
  • tiers: lista warstw, na których ta poprawka powinna być zastosowana (możliwe wartości to domain i engine) -- dla poprawek klienckich, zakłada się, że są one do zastosowania po stronie klienta, więc tiers nie jest potrzebne

Na przykład:

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

Aktualizacje JDK można również uwzględnić w vars/patches/jdk/[server|client]/<major>/latest.yml, gdzie <major> to główna wersja (11.5 lub 11.7). W obu przypadkach należy użyć jednego słownika o nazwie ibm_infosvr_jdk_definition, aby zdefiniować informacje o JDK.

W przypadku 11.5 potrzebne są następujące klucze:

• name: nazwa JDK, jak podano w IBM Fix Central
• infosvr_filename: nazwa pliku JDK, jak pobrano z IBM Fix Central
• infosvr_extract_path: ścieżka utworzona przez rozpakowanie pliku JDK
• versionInfo: ciąg wersji, który unikalnie identyfikuje tę wersję JDK (z java -version)
• was_filename: nazwa pakietu naprawczego WebSphere Application Server (WAS), który zawiera JDK v6
• was_offering: nazwa oferty w pakiecie naprawczym JDK (v6) dla WAS
• jdk7_filename: nazwa pakietu naprawczego WAS, który zawiera JDK v7
• jdk7_offering: nazwa oferty w pakiecie naprawczym JDK (v7) dla WAS
• was_versionInfo: ciąg wersji, który unikalnie identyfikuje tę wersję JDK (v6, z java -version)
• jdk7_versionInfo: ciąg wersji, który unikalnie identyfikuje tę wersję JDK (v7, z java -version)

Dla 11.7 potrzebne są następujące klucze:

• name: nazwa JDK, jak podano w IBM Fix Central
• infosvr_filename: nazwa pliku JDK, jak pobrano z IBM Fix Central
• infosvr_extract_path: ścieżka utworzona przez rozpakowanie pliku JDK
• was_filename: nazwa pakietu naprawczego WebSphere Application Server (WAS), który zawiera JDK
• was_offering: nazwa oferty w pakiecie naprawczym JDK dla WAS
• versionInfo: ciąg wersji, który unikalnie identyfikuje tę wersję (nie-WAS) JDK (z java -version)
• was_versionInfo: ciąg wersji, który unikalnie identyfikuje tę wersję JDK (WAS) (z java -version)

Te aktualizacje JDK nie są listą, lecz prostym słownikiem -- ponieważ każda aktualizacja nadpisze poprzednią, powinieneś zazwyczaj podać tylko najnowszą wersję JDK, którą chcesz zastosować.

Aby przeprowadzić aktualizację, użyj tagu update w następujący sposób:

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

To zastosuje wszelkie poprawki wymienione w plikach vars/patches... dla Twojej konkretnej wersji, które nie zostały już zastosowane. Poprawki są stosowane w uporządkowanej kolejności, na podstawie daty ich wydania (najstarsze jako pierwsze). Nie zaktualizuje to jednak żadnych pakietów systemowych dla systemu operacyjnego: jeśli chcesz to zrobić, upewnij się, że Twój szerszy playbook zajmuje się taką aktualizacją.

Operacje środowiskowe

Zapewniono wiele tagów, które ułatwiają operacje środowiska, szczególnie gdy obejmuje wiele hostów:

• status: sprawdzi, czy różne skonfigurowane komponenty działają (sprawdzając, czy usługa nasłuchuje na ich wyznaczonych portach).
• stop: łagodnie zamknie każdy komponent w odpowiedniej kolejności, na różnych hostach, bez zamykania samych hostów.
• start: uruchomi każdy komponent w odpowiedniej kolejności, na różnych hostach.
• restart: zapewnia prosty sposób na wykonanie stop, a następnie start.

Reużywalne zadania

Rola zawiera również następujące reużywalne zadania, przeznaczone do włączenia w inne role, które muszą korzystać z cech instalacji Information Server bez konieczności przechodzenia przez wszystkie kroki instalacji.

setup_vars.yml

Zmienne konfiguracyjne używane do wdrażania środowiska Information Server można później pobrać, korzystając z zestawu zadań setup_vars.yml, na przykład, włączając poniższy play w swoim playbooku:

---

- name: konfigurowanie zmiennych Information Server
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml

get_certificate.yml

Główny certyfikat SSL warstwy domeny środowiska Information Server można później pobrać, korzystając z zestawu zadań get_certificate.yml, na przykład, włączając poniższy play w swoim playbooku:

---

- name: konfigurowanie zmiennych 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

Zauważ, że ten zestaw zadań zależy również od wcześniejszego uruchomienia setup_vars.yml, dlatego warto je włączyć w tym samym play (jak w powyższym przykładzie). Główny certyfikat SSL warstwy domeny zostanie zapisany w cache/__ibm_infosvr_cert_root.crt w odniesieniu do ścieżki, w której playbook jest uruchamiany na maszynie kontrolnej.

Licencja

Apache 2.0

Informacje o autorze

Christopher Grote