ansible-role-infosvr-import-export

Ansible-Rolle zur Automatisierung des Imports und Exports von Inhalten und Strukturen innerhalb des IBM InfoSphere Information Server.

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

Anforderungen

• Ansible v2.8+
• dsadm-fähiger Netzwerkzugang zu einer IBM Information Server-Umgebung
• Die Gruppennamen im Inventar sollten wie bei der IBM.infosvr-Rolle eingerichtet sein
• (Zur vereinfachten Nutzung sollte die IBM.infosvr-Rolle installiert und konfiguriert sein)
• jmespath sollte auf Ihrer Steuerungsmaschine installiert sein (diese Rolle nutzt das json_query-Modul, welches von dieser Bibliothek abhängig ist)

Die Rolle verwendet optional eine Erhöhung der Berechtigungen auf root, um sehr wenige Einrichtungsschritte zu automatisieren. Wenn Ihre Umgebung diese Erhöhung der Berechtigungen nicht zulässt, stellen Sie bitte sicher, dass diese Voraussetzungen bereits manuell in Ihrer Umgebung erfüllt sind und ändern Sie die Variable ibm_infosvr_impexp_priv_escalate in der Datei defaults/main.yml auf False (dies überspringt Versuche zur Erhöhung der Berechtigungen auf root).

Wenn Sie die Erhöhung der Berechtigungen auf false setzen, stellen Sie bitte sicher, dass Folgendes in Ihrer Zielumgebung erledigt ist, bevor Sie die Rolle ausführen:

• Installation der python-requests-Bibliothek (z. B. über yum)
• Installation der python-lxml-Bibliothek (z. B. über yum)
• Installation von curl (z. B. über yum)
• Das Verzeichnis {IS_HOME}/ASBServer/logs der Domain-Schicht muss schreibbar sein für den Benutzer, der die Rolle ausführt (sowie für jede der .log-Dateien in diesem Verzeichnis)

(Die Erhöhung der Berechtigungen auf dsadm wird hauptsächlich für den Umgang mit operativen Metadaten und das Extrahieren und Laden von DataStage-Projektvariablen verwendet; wenn Sie dies nicht benötigen, ist möglicherweise keine Erhöhung der Berechtigungen erforderlich.)

Rollenvariablen

Siehe defaults/main.yml für Inline-Dokumentation und das folgende Beispiel für die wichtigsten benötigten Variablen. Für Klarstellungen zu den erwarteten Aktionsvariablen und Unterstrukturen für die verschiedenen Objekttypen, siehe die Dokumentation unten.

Standardmäßig führt die Rolle eine SSL-Überprüfung selbstsignierter Zertifikate durch, wenn Sie diese mit der Aufgabe get_certificate.yml von IBM.infosvr abgerufen haben (siehe Beispiel-Playbook unten). Dies wird durch die Variable ibm_infosvr_openigc_verify_selfsigned_ssl der Rolle gesteuert: Wenn Sie nur gegen richtig signierte und vertrauenswürdige SSL-Zertifikate überprüfen möchten, können Sie diese Variable auf False setzen und jedes selbstsignierte Zertifikat der Domain-Schicht wird nicht mehr vertraut.

Beispiel-Playbook

Die Rolle bietet die Möglichkeit, eine Vielzahl von verschiedenen Asset-Typen im Information Server sowohl zu exportieren als auch zu importieren. Die Rolle kann in ein anderes Playbook importiert werden, wobei nur die interessierenden Variablen bereitgestellt werden, um die einzuschließenden Assets entweder beim Import oder Export einzuschränken (leere Variablen bedeuten, dass die Rolle die Verarbeitung dieser Asset-Typen überspringt).

Die erste Ebene der Variablen, die der Rolle bereitgestellt wird, definiert die allgemeinen Aktionen, die durchgeführt werden sollen, und wird immer in dieser Reihenfolge ausgeführt, unabhängig von der Reihenfolge, in der sie angegeben sind:

1. gather - Details zur Umgebung abrufen (z. B. Versionsnummern)
2. export - Assets aus einer Umgebung in Datei(en) extrahieren
3. merge - Mehrere Asset-Dateien in eine einzige Datei zusammenführen
4. ingest - Assets aus Datei(en) in eine Umgebung laden (import ist eine reservierte Variable in Ansible, daher ingest...)
5. progress - Assets durch einen Workflow bewegen (wird nichts tun, wenn der Workflow nicht aktiviert ist)
6. validate - Überprüfen, ob sich die Umgebung in einem erwarteten Zustand befindet, unter Verwendung objektiver Asset-Zahlen

Fehlende Variablen überspringen einfach dieses Aktionsensemble.

Zum Beispiel:

---

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

- name: Assets laden und validieren
  hosts: all
  roles:
    - IBM.infosvr-import-export
  vars:
    isx_mappings:
      - { type: "HostSystem", attr: "name", from: "MEIN_HOST", to "DEIN_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: "DEIN_HOST" }
          is: 10

... wird zunächst Details zur Umgebung von der Umgebung abfragen, in der das Playbook ausgeführt wird.

Es wird dann die gemeinsame Metadaten aus der Datei file2.isx importieren (erwartet wird ein Unterverzeichnis files/ relativ zu Ihrem Playbook), wobei alle Hostnamen von MEIN_HOST auf DEIN_HOST umbenannt werden und alle vorhandenen Assets mit denselben Identitäten überschrieben werden. Danach werden die DataStage-Assets aus /some/directory/file1.isx in das Projekt dstage1 importiert, wobei alle vorhandenen Assets mit denselben Identitäten überschrieben werden.

Bitte beachten Sie, dass die Reihenfolge, in der die Variablen definiert sind, keine Rolle spielt: Die Rolle kümmert sich um den Export und Import der Objekte in der richtigen Reihenfolge, um sicherzustellen, dass Abhängigkeiten zwischen den Objekten beachtet werden (d. h. dass gemeinsame und geschäftliche Metadaten vor Beziehungen geladen werden, usw.). Allerdings kann die Reihenfolge mehrerer Objekte innerhalb eines bestimmten Typs wichtig sein, abhängig von Ihren eigenen Abhängigkeiten.

Schließlich wird das Playbook validieren, dass der Ladevorgang zu den erwarteten Assets in der Zielumgebung geführt hat: 5 DataStage-Jobs im Projekt dstage1 und 10 Datenbanktabellen in einer Kombination von Schemata und Datenbanken auf dem DEIN_HOST-Server.

(Da weder die progress noch die export-Aktionen angegeben sind, werden sie nicht ausgeführt.)

Aktions- (und Objekts-)Strukturen

Die folgenden Beschreibungen betreffen alle Aktionen und Objekttypen, die derzeit von dieser Rolle abgedeckt sind, sowie ihre erwarteten Strukturen.

1. gather - Umgebungsdetails sammeln
2. export / merge / ingest Metadaten-Asset-Typen (wie bei den oben genannten Aktionen, definiert die untenstehende Reihenfolge, in der diese Objekttypen extrahiert und geladen werden -- unabhängig von der Reihenfolge, in der sie innerhalb einer Aktion erscheinen)
   1. customattrs - benutzerdefinierte Attributdefinitionen
   2. common - gemeinsame Metadaten (sollte als niedrigstufig betrachtet und wo möglich vermieden werden, indem eine der typenspezifischen Optionen verwendet wird)
   3. logicalmodel - logische Modell-Metadaten
   4. physicalmodel - physische Modell-Metadaten
   5. mdm - Metadaten des Master Data Management-Modells
   6. database - Datenbank-Metadaten
   7. datafile - Datenbank-Datei-Metadaten
   8. dataclass - Datenklassifizierungs-Metadaten
   9. datastage - DataStage-Assets
   10. ds_vars - DataStage-Projektvariablen
   11. infoanalyzer - Information Analyzer-Assets
   12. openigc - OpenIGC-Pakete und -Assets
   13. extendedsource - erweiterte Datenquellen
   14. extensionmap - Dokumente zur Erweiterungskartierung
   15. glossary - Glossar-Assets
   16. relationships - Metadatenbeziehungen
   17. omd - operationale Metadaten
3. progress - Workflow vorantreiben
4. validate - Validierungsframework

Für die export, merge und ingest können Mapping angewendet werden, um Metadaten zwischen Umgebungen zu transformieren (z. B. Umbenennung, Änderung der Einbettung usw.), und die meisten Asset-Typen können auch durch die Verwendung von Bedingungen eingeschränkt werden.

Beachten Sie, dass Sie diese Variablenstrukturen im Allgemeinen in jeder von Ansible unterstützten Form schreiben können, z. B. sind alle diese gleichwertig und einfach nur von Ihrer persönlichen Vorliebe abhängig:

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

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

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

Lizenz

Apache 2.0

Autorinformation

Christopher Grote