ansible-role-infosvr

Ansible-Rolle zur Automatisierung der Bereitstellung einer IBM InfoSphere Information Server-Umgebung, sowohl der Versionen 11.5 als auch 11.7, einschließlich:

• der Repository (Datenbank) Schicht
• der Domain (Dienstleistungen) Schicht
• der Engine Schicht
• der Unified Governance ("Enterprise Search") Schicht (nur v11.7)
• Patches / Fixpacks

und den folgenden Modulen der Enterprise Edition, die über die unten beschriebenen Variablen deaktiviert werden können (zum Beispiel, wenn Sie nicht berechtigt sind, sie zu verwenden oder sie nicht installieren / konfigurieren möchten):

• Information Governance Catalog
• Information Analyzer
• DataStage Operations Console
• DataClick
• Event Management (Integration zur Data Quality Exception Console)
• Data Quality Exception Console
• QualityStage
• Information Services Director
• FastTrack
• Information Governance Dashboard (erfordert eine bereits vorhandene Cognos-Umgebung)
• Optim Maskierung innerhalb von DataStage
• Einschließlich dieser Extras, die nur in v11.7 verfügbar sind:
  • Neuer Information Governance Catalog (UI)
  • Governance Monitor Dashboards
  • Enterprise Search (einschließlich Knowledge Graph)
  • DataStage Flow Designer
  • Machine Learning Term Classification (v11.7+)

Derzeit unterstützt die Bereitstellung nur DB2 als Backend, funktioniert aber sowohl für die Installation und Konfiguration der enthaltenen DB2 als auch für die Konfiguration einer bereits vorhandenen DB2. Es wird entweder eine vollständige WebSphere Application Server Network Deployment-Konfiguration oder eine WebSphere Liberty Profile-Konfiguration installiert (siehe unten für weitere Details); derzeit kann die Rolle keine vorhandene WebSphere-Installation konfigurieren.

Neu bei Ansible? Diese einfache Einführung könnte hilfreich sein.

Anforderungen

• Ansible v2.7
• 'root'-fähiger Netzwerkzugang zu allen Servern
• Administratorzugang zu Windows-Clientmaschinen
• Windows-Clientmaschinen konfiguriert für WinRM-Zugriff durch Ansible (siehe http://docs.ansible.com/ansible/latest/intro_windows.html)

Rollenvariablen

Siehe defaults/main.yml für inline Dokumentation und das Beispiel unten für die wichtigsten benötigten Variablen. Die Standarddatei enthält bereits die Standardeinstellungen, die Sie für eine einfache v11.7-Installation finden würden, sodass Sie nur die Variablen überschreiben müssen, für die Sie die Standardeinstellungen nicht verwenden möchten (z. B. Passwörter für Benutzer).

Die minimalen Variablen, die wahrscheinlich überschrieben werden müssen, sind:

• ibm_infosvr_media_dir: der Speicherort auf Ihrem Ansible-Host, wo die Installationsbinärdateien bereits heruntergeladen wurden (z.B. von Passport Advantage)
• ibm_infosvr_media_bin dict: die Namen der Binärdateien, die für die Installation verwendet werden sollen (standardmäßig sind die neuesten verfügbaren v11.7-Dateien vorhanden; wenn Sie v11.5 installieren möchten, müssen diese durch die v11.5-Dateinamen ersetzt werden)
• ibm_infosvr_ug_storage: das zusätzliche, rohe Speichermedium auf der Unified Governance Schicht, das von Kubernetes verwendet werden soll (sollte roh sein: nicht gemountet, nicht in einer LVM-Gruppe, usw.)
• ibm_infosvr_features dict: definiert die Funktionen, die Sie möchten (True) vs. die, die Sie nicht wollen (False)

Schließlich sollten die verschiedenen Anmeldevariablen überschrieben werden, um eine ausreichend sichere Umgebung zu schaffen. Eine Suche nach _upwd_ zeigt alle Passwortvariablen in defaults/main.yml, die Sie überschreiben möchten. (Und Sie können dies gerne durch Verweise auf andere Variablen ersetzen, die ihrerseits durch ein Ansible Vault weiter gesichert sind.)

Abhängigkeiten

Die Konfiguration des Information Analyzers verwendet indirekt die Rolle IBM.infosvr-metadata-asset-manager, unter Verwendung der Direktive import_role. Diese Rolle ist nicht als explizite Abhängigkeit aufgeführt, um zirkuläre Abhängigkeiten zu vermeiden, sollte aber installiert sein, wenn Sie den Information Analyzer konfigurieren möchten.

Beispiel-Playbook

Das folgende Beispiel-Playbook wird eine vollständige Installation und Konfiguration von IBM InfoSphere Information Server mit den Standardparametern aus defaults/main.yml (und allen Überschreibungen, die Sie beispielsweise in group_vars/all.yml vorgenommen haben) durchführen. Beachten Sie, dass die gesamte Installation über mehrere Schichten durch diese eine Rolle erfolgt, weshalb Sie any_errors_fatal verwenden sollten, um eine partielle Installation / Konfiguration einer Schicht zu vermeiden, falls ein vorheriger Schritt auf einer anderen Schicht fehlschlägt.

---

- name: install and configure IBM InfoSphere Information Server
  hosts: all
  any_errors_fatal: true
  roles:
    - IBM.infosvr
  pre_tasks:
    - name: update all OS-level packages
      yum:
        state: latest
        name: '*'
        exclude: docker*,kubelet*,kubectl*,kubeadm*
      become: yes
      when: ('ibm_information_server_clients' not in group_names)

Die Voraufgaben stellen sicher, dass alle Betriebssystempakete auf dem neuesten Stand sind, bevor die Installation beginnt.

Erwarteter Inventar

Die folgenden Gruppen werden im Inventar erwartet, da sie verwendet werden, um zu unterscheiden, wo verschiedene Komponenten installiert sind. Natürlich kann, wenn Sie mehrere Komponenten auf einem einzigen Server installieren möchten, dies einfach geschehen, indem Sie denselben Hostnamen in jede Gruppe einfügen. Im folgenden Beispiel zum Beispiel sind das Repository und die Domain-Schichten beide auf 'serverA' platziert, während die Engine-Schicht separat auf 'serverB' installiert wird und die Unified Governance-Schicht ebenfalls ihr eigenes System 'serverC' hat.

[ibm_information_server_repo]
# Linux-Host, auf dem die Repository-Schicht (Datenbank) installiert werden soll (DB2)
serverA.eirgendwo.com

[ibm_information_server_domain]
# Linux-Host, auf dem die Domain (Dienstleistungen) Schicht installiert werden soll (WebSphere)
serverA.eirgendwo.com

[ibm_information_server_engine]
# Linux-Host, auf dem die Engine-Schicht installiert werden soll
serverB.eirgendwo.com

[ibm_information_server_clients]
# Windows-Host, auf dem die Client-Anwendungen installiert werden sollen, und ein Metadata Interchange Server für Windows-only Broker / Bridges konfiguriert ist
client.eirgendwo.com

[ibm_information_server_ug]
# Linux-Host, auf dem die v11.7+ Unified Governance-Schicht installiert werden soll (kubernetes)
serverC.eirgendwo.com

[ibm_information_server_external_db]
# Linux-Host, der eine vorhandene Datenbank hält, in die XMETA usw. bereitgestellt werden soll -- wenn kein Host bereitgestellt wird oder diese Gruppe fehlt, wird die enthaltene DB2 auf dem ibm_information_server_repo-Server installiert
serverD.eirgendwo.com

[ibm_cognos_report_server]
# Linux-Host, auf dem eine vorhandene Cognos BI-Installation vorhanden ist (für das Information Governance Dashboard)
cognos.eirgendwo.com

[ibm_bpm]
# Linux-Host, auf dem eine vorhandene BPM-Installation vorhanden ist (derzeit ungenutzt)
bpm.eirgendwo.com

Wie bei jedem Ansible-Inventar sollten ausreichende Details bereitgestellt werden, um die Konnektivität zu den Servern zu gewährleisten (siehe http://docs.ansible.com/ansible/latest/intro_inventory.html#list-of-behavioral-inventory-parameters).

Tags

Installation von Patches

Die Rolle soll auch in der Lage sein, eine installierte Umgebung mit Patches und Systempaketen auf dem neuesten Stand zu halten. Um Patches anzuwenden, geben Sie einfach die betreffenden Details in die Dateien unter vars/patches/[server|client]/<version>/<date>.yml. Zum Beispiel sollten Fehlerbehebungen für v11.7.1.0 serverseitig in vars/patches/server/11.7.1.0/<date>.yml und Fehlerbehebungen für v11.7.0.2 clientseitig in vars/patches/client/11.7.0.2/<date>.yml angegeben werden, wobei <date> das Datum angibt, an dem der Patch veröffentlicht wurde. In der Regel werden diese innerhalb von GitHub basierend auf der Verfügbarkeit von wichtigen Patches in Fix Central aktuell gehalten; falls Sie jedoch einen Zwischenpatch oder ähnliches anwenden möchten, das nicht bereits in der Liste ist, folgen Sie einfach den nachstehenden Anweisungen.

• Jeder Patch sollte ein Dictionary namens ibm_infosvr_patch_definition sein.
• Das Dictionary sollte die folgenden Schlüssel enthalten:
  • name: der Name des Patches / Fixpacks, wie auf IBM Fix Central aufgeführt
  • srcFile: der Name der Patch- / Fixpackdatei, wie sie von IBM Fix Central heruntergeladen wurde
  • pkgFile: der Name der .ispkg-Datei, die sich in der srcFile befindet
  • versionId: der installerId-Tag, der Ihrer Version.xml hinzugefügt wird, sobald der Patch / Fixpack installiert ist
  • tiers: eine Liste der Schichten, auf denen dieser Patch angewendet werden soll (mögliche Werte sind domain und engine) -- für die Client-Patches wird impliziert, dass es sich um den Client handelt, daher ist keine tiers-Option erforderlich

Beispiel:

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-Updates können auch unter vars/patches/jdk/[server|client]/<major>/latest.yml aufgenommen werden, wobei <major> die Hauptversionsnummer (11.5 oder 11.7) ist. In beiden Fällen sollte ein einfaches Dictionary namens ibm_infosvr_jdk_definition verwendet werden, um die JDK-Informationen zu definieren.

Für 11.5 sind die folgenden Schlüssel erforderlich:

• name: der Name des JDK, wie auf IBM Fix Central aufgeführt
• infosvr_filename: der Name der JDK-Datei, wie sie von IBM Fix Central heruntergeladen wurde
• infosvr_extract_path: der Pfad, der durch das Entpacken der JDK-Datei erstellt wird
• versionInfo: der Versionsstring, der diese Version des JDK eindeutig identifiziert (von java -version)
• was_filename: der Name des WebSphere Application Server (WAS) Fixpacks, das das v6 JDK enthält
• was_offering: der Name des Angebots innerhalb des WAS JDK (v6) Fixpacks
• jdk7_filename: der Name des WAS Fixpacks, das das v7 JDK enthält
• jdk7_offering: der Name des Angebots innerhalb des WAS JDK (v7) Fixpacks
• was_versionInfo: der Versionsstring, der diese Version des JDK (v6, von java -version) eindeutig identifiziert
• jdk7_versionInfo: der Versionsstring, der diese Version des JDK (v7, von java -version) eindeutig identifiziert

Für 11.7 sind die folgenden Schlüssel erforderlich:

• name: der Name des JDK, wie auf IBM Fix Central aufgeführt
• infosvr_filename: der Name der JDK-Datei, wie sie von IBM Fix Central heruntergeladen wurde
• infosvr_extract_path: der Pfad, der durch das Entpacken der JDK-Datei erstellt wird
• was_filename: der Name des WebSphere Application Server (WAS) Fixpacks, das das JDK enthält
• was_offering: der Name des Angebots innerhalb des WAS JDK Fixpacks
• versionInfo: der Versionsstring, der diese Version des (nicht-WAS) JDK eindeutig identifiziert (von java -version)
• was_versionInfo: der Versionsstring, der diese Version des (WAS) JDK eindeutig identifiziert (von java -version)

Diese JDK-Updates sind keine Liste, sondern ein einfaches Dictionary -- da jedes Update das vorherige Update überschreibt, sollten Sie nur die neueste Version des JDK angeben, die Sie anwenden möchten.

Um ein Update durchzuführen, verwenden Sie das Tag update wie folgt:

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

Dies wird alle in den vars/patches...-Dateien für Ihre bestimmte Version aufgeführten Patches anwenden, die noch nicht angewendet wurden. Die Patches werden in aufsteigender Reihenfolge basierend auf dem Datum angewendet, an dem sie veröffentlicht wurden (älteste zuerst). Es wird jedoch nicht erfolgen, um systemweite Pakete des Betriebssystems zu aktualisieren: wenn dies gewünscht ist, stellen Sie sicher, dass Ihr umfassenderes Playbook eine solche Aktualisierung vornimmt.

Betriebsumgebungen

Eine Reihe von Tags wurde bereitgestellt, um die Operationen der Umgebung zu erleichtern, insbesondere wenn sie sich über mehrere Hosts erstreckt:

• status: überprüft, ob die verschiedenen konfigurierten Komponenten aktiv sind (indem geprüft wird, ob ein Dienst auf ihren vorgesehenen Ports lauscht).
• stop: fährt jede Komponente in der richtigen Reihenfolge auf den verschiedenen Hosts sanft herunter, ohne die zugrunde liegenden Hosts selbst herunterzufahren.
• start: startet jede Komponente in der richtigen Reihenfolge auf den verschiedenen Hosts.
• restart: bietet eine einfache Möglichkeit, ein stop gefolgt von einem start auszuführen.

Wiederverwendbare Aufgaben

Die Rolle umfasst auch die folgenden wiederverwendbaren Aufgaben, die dazu gedacht sind, in anderen Rollen verwendet zu werden, die die Eigenschaften der Information Server-Installation nutzen müssen, ohne unbedingt alle Installationsschritte selbst durchzuführen.

setup_vars.yml

Die Konfigurationsvariablen, die beim Bereitstellen einer Information Server-Umgebung verwendet werden, können später mit Hilfe der setup_vars.yml-Aufgabensätze abgerufen werden, beispielsweise durch Einfügen des folgenden Plays in Ihr Playbook:

---

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

get_certificate.yml

Das Root-SSL-Zertifikat der Domain-Schicht einer Information Server-Umgebung kann später mit Hilfe der get_certificate.yml-Aufgabensätze abgerufen werden, beispielsweise durch Einfügen des folgenden Plays in Ihr Playbook:

---

- name: setup Information Server vars
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml
    - import_role: name=IBM.infosvr tasks_from=get_certificate.yml

Beachten Sie, dass dieser Aufgabenstapel davon abhängt, dass setup_vars.yml bereits ausgeführt wurde; es kann daher sinnvoll sein, sie im selben Play zu integrieren (wie im obigen Beispiel). Das SSL-Zertifikat der Domain-Schicht wird in cache/__ibm_infosvr_cert_root.crt relativ zu dem Pfad gespeichert, an dem das Playbook auf dem Steuergerät ausgeführt wird.

Lizenz

Apache 2.0

Autoreninformation

Christopher Grote