ansible-role-infosvr-openigc

Rôle Ansible pour automatiser le déploiement des objets OpenIGC pour le Catalogue de Gouvernance de l'Information, au sein du Serveur d'Information IBM.

Vous débutez avec Ansible ? Cette introduction simple peut vous aider.

Exigences

• Ansible v2.6.x
• Les utilitaires suivants préinstallés sur votre machine de contrôle :
  • zip
  • curl

Le rôle n'utilise aucune élévation de privilège et s'exécute principalement sur la machine de contrôle elle-même (il envoie uniquement des fichiers générés directement contre les API pertinentes de l'environnement).

En raison de l'utilisation par ce rôle d'un modèle Jinja avancé pour les entrées basées sur YAML, une version d'Ansible avec une distribution Jinja récente est requise (v2.4 n'est pas adéquate, ce qui justifie l'exigence de v2.6.x). Bien que v2.7 inclue maintenant la capacité pour le module uri de soumettre des fichiers, il ne permet toujours pas de remplacer l'autorité de certification -- donc pour valider des certificats auto-signés, sans modifier l'AC de la machine de contrôle elle-même, nous restons pour le moment dépendants de curl.

Variables du rôle

Voir defaults/main.yml pour la documentation en ligne, et l'exemple ci-dessous pour les principales variables nécessaires.

Ce rôle tentera de réutiliser automatiquement les variables du rôle IBM.infosvr, par exemple en utilisant un playbook qui importe d'abord IBM.infosvr via tasks_from=setup_vars.yml.

Par défaut, le rôle effectuera la vérification SSL des certificats auto-signés si vous les avez obtenus en utilisant la tâche get_certificate.yml du rôle IBM.infosvr (voir l'exemple de playbook ci-dessous). Cela est contrôlé par la variable ibm_infosvr_openigc_verify_selfsigned_ssl du rôle : si vous souhaitez uniquement vérifier des certificats SSL correctement signés et approuvés, vous pouvez définir cette variable sur False et tout certificat de domaine auto-signé ne sera plus approuvé.

Exemple de Playbook

Le rôle est principalement destiné à être importé dans d'autres playbooks selon les besoins pour le déploiement d'objets OpenIGC -- à la fois des bundles et des instances d'actifs. (D'où la nécessité d'Ansible v2.4.x et du module import_role.)

---
- name: configurer les variables du Serveur d'Information
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml
    - import_role: name=IBM.infosvr tasks_from=get_certificate.yml

- name: charger les bundles et actifs OpenIGC
  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

Structures d'actions (et objets)

La section suivante décrit toutes les actions et types d'objets actuellement couverts par ce rôle, ainsi que leurs structures attendues. Peu importe l'ordre dans lequel les variables sont listées dans le playbook, elles seront chargées dans l'ordre où elles sont listées ci-dessous.

bundles

La liste des répertoires fournis par cette variable doit être sous forme de bundle, contenant spécifiquement la structure suivante :

• <BundleId> : le répertoire racine doit avoir le même nom sensible à la casse que le bundle lui-même.
  • asset_type_descriptor.xml : le XML qui décrit le bundle (c'est-à-dire toutes les classes, leurs relations, etc.)
  • i18n : un répertoire contenant des étiquettes.
    • labels.properties : l'ensemble des étiquettes de classe et d'attribut traduisibles.
  • icons : un répertoire contenant deux fichiers .gif par classe définie par le bundle :
    • <ClassId>-icon.gif : doit être une représentation de la classe de 16x16 pixels, et peut aussi être un fichier .png, mais doit être nommé .gif quoi qu'il en soit.
    • <ClassId>-bigIcon.gif : doit être une représentation de la classe de 32x32 pixels, et peut aussi être un fichier .png, mais doit être nommé .gif quoi qu'il en soit.

assets_as_xml

La liste des fichiers XML fournis par cette variable doit être des fichiers d'instance d'actifs XML totalement fonctionnels, déjà générés (par exemple, par la variable ci-dessous) ou créés manuellement.

assets_as_yaml

Cette variable est fournie comme une manière plus pratique / lisible de spécifier des instances d'actifs que d'apprendre le format XML requis par assets_as_xml.

La liste des fichiers YAML fournis par cette variable est utilisée pour générer des XML d'instance d'actifs valides qui sont ensuite chargés automatiquement. La structure de chaque fichier YAML doit être la suivante :

---

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

La sous-structure contains peut être imbriquée autant de fois que nécessaire pour créer la hiérarchie de contenu requise pour vos actifs. Chaque sous-structure doit avoir au minimum class et name définis.

De plus, un nombre quelconque d'attributs supplémentaires peut également être spécifié, comme le permet votre définition de bundle et l'ensemble d'attributs par défaut pour tous les objets (par exemple, short_description, long_description). Les attributs définis par le bundle doivent simplement être préfixés par $. Par exemple :

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: level1
    short_description: Le répertoire de niveau supérieur
    $filesystem: UNIX
    contains:
      - class: Folder
        name: level2
        short_description: Le niveau suivant dans la structure de répertoires
        contains:
          - class: File
            name: MyFile.txt
            short_description: Un fichier situé dans /level1/level2/MyFile.txt
            $encoding: UTF-8

Dans cet exemple, le bundle TestBundle définit des Folders et des Files, où les Folders peuvent avoir un attribut filesystem défini et les Files peuvent avoir un encoding défini. Tous deux peuvent avoir des short_descriptions car tous les objets dans l'IGC ont cet attribut.

Pour les attributs qui permettent plusieurs valeurs, il suffit de définir la valeur de l'attribut comme une liste YAML. Dans cet exemple, l'attribut users_with_access spécifique au bundle permet plusieurs valeurs, donc nous spécifions chaque valeur comme partie d'une liste YAML pour cet attribut :

---

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

Enfin, le raccourci names existe pour les nœuds de feuilles d'une hiérarchie de containment où vous n'avez qu'à spécifier le name de chacun -- cela évite de devoir spécifier la même class encore et encore pour chaque nœud de feuille :

---

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

flows_as_xml

La liste des fichiers XML fournis par cette variable doit être des fichiers XML de flux de lignée totalement fonctionnels, déjà générés (par exemple, par la variable ci-dessous) ou créés manuellement.

flows_as_yaml

Cette variable est fournie comme une manière plus pratique / lisible de spécifier des instances de flux que d'apprendre le format XML requis par flows_as_xml ci-dessus.

La liste des fichiers YAML fournis par cette variable est utilisée pour générer des XML de flux de lignée valides qui sont ensuite chargés automatiquement. La structure de chaque fichier YAML doit être la suivante :

---

assets:
  - class: <FullClassName>
    name: <name>
    contains:
      - class: <NestedFullClassName>
        name: <name>
        id: <unique identifier>
        contains:
          ...

flows:
  - name: <comment significatif>
    within: <id>
    contains:
      - name: <comment significatif>
        from:
          - <id>
          - ...
        to:
          - <id>
          - ...
      - ...

La sous-structure contains pour assets peut être imbriquée autant de fois que nécessaire pour créer la hiérarchie de contenu requise pour vos actifs. Chaque sous-structure doit avoir au minimum les attributs class et name définis (en fait, tous les autres attributs sont simplement ignorés car non utilisés par le XML de flux de lignée). Notez que dans ce cas, vous devez spécifier des noms de classe entièrement qualifiés, y compris le bundleId, par exemple, $BundleId-ClassName. Cela permet de combiner les actifs OpenIGC et natifs dans un flux de lignée (et de créer des flux de lignée s'étendant sur plusieurs bundles OpenIGC).

Pour tous les actifs que vous prévoyez d'utiliser dans un flux, incluez également un attribut id explicite pour spécifier comment vous allez vous y référer dans la variable flows. Cet identifiant doit être unique dans le fichier YAML et ne doit pas contenir d'espaces ni d'autres caractères spéciaux (autre que . et _). Cela est nécessaire en plus du name car l'id fournit une référence unique et plate dans le fichier ; le name est en réalité un identifiant imbriqué qui dépend de la structure de containment dans laquelle il apparaît, et donc n'est pas unique en soi (uniquement lorsque l'on prend en considération l'ensemble de sa structure de containment).

Chaque name dans la variable flows est utilisé comme commentaire dans le XML généré, mais n'apparaît pas réellement dans l'IGC.

Considérez l'exemple suivant :

---

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: Commande de copie pour dupliquer un fichier
    within: copy
    contains:
      - name: Copier de My à Your et Other
        from:
          - MyFile.txt
        to:
          - YourFile.txt
          - OtherFile.txt

Dans cet exemple, nous avons un TestBundle qui définit de nouveaux objets représentant des Folders, Files et Commands. La section assets définit uniquement les objets que nous voulons décrire dans la lignée, y compris leur hiérarchie de containment. Pour chaque actif que nous utiliserons dans la lignée, nous avons défini un attribut id unique.

Dans la section flows, nous créons ensuite la lignée : la déclaration extérieure within définit le processus responsable de l'action représentée dans la lignée, et la section contains à l'intérieur de cela précise les entrées et sorties spécifiques de l'action.

Licence

Apache 2.0

Informations sur l'auteur

Christopher Grote