ansible-rolle-infosvr-openigc

Ansible-Rolle zur Automatisierung der Bereitstellung von OpenIGC-Objekten für das Information Governance Catalog innerhalb des IBM Information Server.

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

Anforderungen

• Ansible v2.6.x
• Die folgenden Tools sollten vorab auf Ihrem Steuerrechner installiert sein:
  • zip
  • curl

Die Rolle verwendet keine privilegierte Eskalation und führt die meisten Aktionen direkt auf dem Steuerrechner aus (nur die generierten Dateien werden direkt gegen die relevanten APIs in der Umgebung gepusht).

Aufgrund der Verwendung von fortgeschrittenem Jinja-Templating für die YAML-basierten Eingaben ist eine Version von Ansible mit einer aktuellen Jinja-Distribution erforderlich (v2.4 ist nicht ausreichend, daher die Anforderung von v2.6.x). Während v2.7 jetzt die Möglichkeit bietet, dass das uri-Modul Dateien überträgt, gibt es keine Möglichkeit, die Zertifizierungsstelle zu überschreiben - daher verlassen wir uns weiterhin auf curl, um die Validierung selbstsignierter Zertifikate zu ermöglichen, ohne die CA des Steuerrechners selbst ändern zu müssen.

Rollenvariablen

Siehe defaults/main.yml für Inline-Dokumentation und das folgende Beispiel für die wichtigsten benötigten Variablen.

Diese Rolle versucht automatisch, Variablen aus der Rolle IBM.infosvr wiederzuverwenden, indem sie ein Playbook verwendet, das zunächst IBM.infosvr mit tasks_from=setup_vars.yml importiert.

Standardmäßig überprüft die Rolle die SSL-Zertifikate selbstsignierter Zertifikate, wenn Sie diese mit der get_certificate.yml-Aufgabe 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 ordnungsgemäß signierte und vertrauenswürdige SSL-Zertifikate überprüfen möchten, können Sie diese Variable auf False setzen, und jedes selbstsignierte Domain-Zertifikat wird nicht mehr als vertrauenswürdig angesehen.

Beispiel-Playbook

Die Rolle ist hauptsächlich dafür gedacht, bei Bedarf in andere Playbooks für die Bereitstellung von OpenIGC-Objekten importiert zu werden - sowohl Bündel als auch Asset-Instanzen. (Das ist der Grund für die Notwendigkeit von Ansible v2.4.x und dem import_role-Modul.)

---
- 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: OpenIGC-Bündel und -Assets laden
  hosts: ibm_information_server_engine
  roles:
    - IBM.infosvr-openigc
  vars:
    bundles:
      - /some/directory/<BundleId>
    assets_as_xml:
      - /some/directory/asset_instances-<BundleId>.xml
    assets_as_yaml:
      - /some/directory/assets.yml
    flows_as_xml:
      - /some/directory/lineage_flows-<BundleId>.xml
    flows_as_yaml:
      - /some/directory/lineage.yml

Aktionen (und Objekt) Strukturen

Das Folgende beschreibt alle Aktionen und Objekttypen, die derzeit von dieser Rolle abgedeckt werden, sowie deren erwartete Strukturen. Unabhängig von der Reihenfolge, in der die Variablen im Playbook aufgeführt sind, werden sie in der Reihenfolge geladen, die unten aufgeführt ist.

bundles

Die über diese Variable bereitgestellte Liste von Verzeichnissen sollte in Bündelform vorliegen und speziell die folgende Struktur enthalten:

• <BundleId>: Das Wurzelverzeichnis, auf das Sie zeigen, sollte denselben groß- und kleingeschriebenen Namen wie das Bündel selbst haben.
  • asset_type_descriptor.xml: Die XML, die das Bündel beschreibt (d.h. alle Klassen, ihre Beziehungen / enthaltenen Elemente usw.)
  • i18n: Ein Verzeichnis mit Labels.
    • labels.properties: Die übersetzbaren Klassen- und Attributlabels.
  • icons: Ein Verzeichnis mit zwei .gif-Dateien pro Klasse, die durch das Bündel definiert sind:
    • <ClassId>-icon.gif: Soll eine 16x16 Pixel große Darstellung der Klasse sein und könnte auch eine .png-Datei sein, sollte aber trotzdem .gif genannt werden.
    • <ClassId>-bigIcon.gif: Soll eine 32x32 Pixel große Darstellung der Klasse sein und könnte auch eine .png-Datei sein, sollte aber trotzdem .gif genannt werden.

assets_as_xml

Die über diese Variable bereitgestellte Liste von XML-Dateien sollte vollständig funktionierende Asset-Instanz-XML-Dateien sein, die entweder bereits generiert (z.B. durch die unten stehende Variable) oder manuell erstellt wurden.

assets_as_yaml

Diese Variable wird als bequemere / lesbarere Möglichkeit bereitgestellt, Asset-Instanzen zu spezifizieren als das Erlernen des XML-Formats, das für assets_as_xml erforderlich ist.

Die über diese Variable bereitgestellte Liste von YAML-Dateien wird verwendet, um gültige Asset-Instanz-XMLs zu generieren, die dann automatisch geladen werden. Die Struktur jeder YAML-Datei sollte wie folgt aussehen:

---

bundleId: $<BundleId>
contains:
  - class: <ClassName>
    name: <name>
    contains:
      - class: <NestedClassName>
        name: <name>
        contains:
          ...

Die contains-Unterstruktur kann so oft geschachtelt werden, wie nötig, um die Hierarchie zu schaffen, die Sie für Ihre Assets benötigen. Jede Unterstruktur muss mindestens die class und name definiert haben.

Darüber hinaus können eine beliebige Anzahl weiterer Attribute angegeben werden, die durch Ihre Bündeldefinition und das Standardset von Attributen für alle Objekte erlaubt sind (z.B. short_description, long_description). Alle bündeldefinierten Attribute müssen einfach mit $ vorangestellt werden. Zum Beispiel:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: level1
    short_description: Verzeichnis auf oberster Ebene
    $filesystem: UNIX
    contains:
      - class: Folder
        name: level2
        short_description: Das nächste Level in der Verzeichnisstruktur
        contains:
          - class: File
            name: MyFile.txt
            short_description: Eine Datei, die sich in /level1/level2/MyFile.txt befindet
            $encoding: UTF-8

In diesem Beispiel definiert das Bündel TestBundle Folders und Files, wobei Folders ein filesystem-Attribut definiert haben können und Files ein encoding. Beide können short_descriptions haben, da alle Objekte in IGC dieses Attribut haben.

Für Attribute, die mehrere Werte zulassen, definieren Sie den Wert einfach als YAML-Liste. In diesem Beispiel erlaubt das Attribut users_with_access, das spezifisch für das Bündel ist, mehrere Werte, sodass wir jeden Wert als Teil einer YAML-Liste für dieses Attribut angeben:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: root
    $users_with_access:
      - user123
      - user456
      - user789

Schließlich gibt es die names-Abkürzung für Blattknoten einer Hierarchie, bei der Sie einfach den name jedes einzelnen angeben müssen – das vermeidet die Notwendigkeit, für jeden Blattknoten immer wieder die gleiche class anzugeben:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: root
    contains:
      - class: File
        names:
          - MyFile.txt
          - YourFile.txt
          - OtherFile.txt

flows_as_xml

Die über diese Variable bereitgestellte Liste von XML-Dateien sollte vollständig funktionierende Fluss-XML-Dateien sein, die entweder bereits generiert (z.B. durch die unten stehende Variable) oder manuell erstellt wurden.

flows_as_yaml

Diese Variable wird als bequemere / lesbarere Möglichkeit bereitgestellt, Flüsse zu spezifizieren als das Erlernen des XML-Formats, das für flows_as_xml erforderlich ist.

Die über diese Variable bereitgestellte Liste von YAML-Dateien wird verwendet, um gültige Fluss-XMLs zu generieren, die dann automatisch geladen werden. Die Struktur jeder YAML-Datei sollte wie folgt aussehen:

---

assets:
  - class: <FullClassName>
    name: <name>
    contains:
      - class: <NestedFullClassName>
        name: <name>
        id: <eindeutige Kennung>
        contains:
          ...

flows:
  - name: <bedeutsamer Kommentar>
    within: <id>
    contains:
      - name: <bedeutsamer Kommentar>
        from:
          - <id>
          - ...
        to:
          - <id>
          - ...
      - ...

Die contains-Unterstruktur für assets kann so oft geschachtelt werden, wie nötig, um die Hierarchie zu schaffen, die Sie für Ihre Assets benötigen. Jede Unterstruktur muss mindestens die class und name definiert haben (in der Tat werden alle anderen Attribute einfach ignoriert, da sie nicht im Fluss-XML verwendet werden). Beachten Sie, dass Sie in diesem Fall die vollqualifizierten Klassennamen angeben sollten, einschließlich des bundleId, z.B. $BundleId-ClassName. Dies soll sicherstellen, dass Sie sowohl OpenIGC- als auch native Assets in einem Fluss kombinieren können (und Flüsse erstellen, die sich über mehrere OpenIGC-Bündel erstrecken).

Für alle Assets, die Sie als Teil eines Flusses verwenden möchten, fügen Sie außerdem ein explizites id-Attribut hinzu, um anzugeben, wie Sie sie innerhalb der flows-Variable und eindeutig innerhalb der YAML-Datei ansprechen werden. Dieses Identifikator sollte innerhalb der YAML-Datei einzigartig sein und keine Leerzeichen oder andere Sonderzeichen (außer . und _) enthalten. Dies ist zusätzlich zum name erforderlich, da die id einen flachen, eindeutigen Bezug innerhalb der Datei bietet; der name ist in Wirklichkeit ein geschachtelter Identifikator, der von der Hierarchie abhängt, in der er erscheint und daher für sich allein nicht einmalig ist (nur wenn man die gesamte Hierarchie berücksichtigt).

Jeder name in der flows-Variable wird als Kommentar im generierten XML verwendet, erscheint jedoch in IGC selbst nicht.

Betrachten Sie folgendes Beispiel:

---

assets:
  - class: $TestBundle-Folder
    name: root
    contains:
      - class: $TestBundle-File
        name: MyFile.txt
        id: MyFile.txt
      - class: $TestBundle-File
        name: YourFile.txt
        id: YourFile.txt
      - class: $TestBundle-File
        name: OtherFile.txt
        id: OtherFile.txt
  - class: $TestBundle-Command
    name: copy
    id: copy

flows:
  - name: Befehl zur Duplikation einer Datei
    within: copy
    contains:
      - name: Kopiere von My nach Your und Other
        from:
          - MyFile.txt
        to:
          - YourFile.txt
          - OtherFile.txt

In diesem Beispiel haben wir ein TestBundle, das neue Objekte definiert, die Folders, Files und Commands darstellen. Der Abschnitt assets definiert nur die Objekte, die wir in der Linie beschreiben möchten, einschließlich ihrer Hierarchie. Für jedes Asset, das wir in der Linie verwenden wollen, haben wir ein eindeutiges id-Attribut definiert.

Im Abschnitt flows erstellen wir dann die Linie: Der äußere within definiert den Prozess, der für die dargestellte Aktion verantwortlich ist, und das contains innerhalb davon spezifiziert die spezifischen Eingaben und Ausgaben der Aktion.

Lizenz

Apache 2.0

Autorinformation

Christopher Grote