ansible-role-infosvr-import-export

Rôle Ansible pour automatiser l'import et l'export de contenu et de structures au sein d'IBM InfoSphere Information Server.

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

Exigences

• Ansible v2.8+
• Accès réseau capable de dsadm à un environnement IBM Information Server
• Noms de groupes d'inventaire configurés comme le rôle IBM.infosvr
• (Et pour une utilisation plus facile, le rôle IBM.infosvr installé et configuré)
• jmespath installé sur votre machine de contrôle (ce rôle utilise le module json_query, qui dépend de cette bibliothèque)

Le rôle utilise facultativement l'escalade de privilèges pour automatiser très peu de tâches de configuration. Si votre environnement ne permet pas cette escalade de privilèges, veuillez vous assurer que ces pré-requis sont déjà remplis manuellement dans votre environnement et changez la variable ibm_infosvr_impexp_priv_escalate dans defaults/main.yml à False (cela ignorera toute tentative d'escalade de privilèges à root).

Si vous définissez l'escalade à false, assurez-vous que ce qui suit est fait dans votre environnement cible avant d'exécuter le rôle :

• Installation de la bibliothèque python-requests (par exemple via yum)
• Installation de la bibliothèque python-lxml (par exemple via yum)
• Installation de curl (par exemple via yum)
• Le répertoire {IS_HOME}/ASBServer/logs du niveau domaine doit être accessible en écriture par l'utilisateur exécutant le rôle (ainsi que chacun des fichiers .log dans ce répertoire)

(L'escalade de privilèges à dsadm est utilisée principalement pour la gestion des métadonnées opérationnelles et l'extraction et le chargement des variables de projet DataStage ; si vous n'avez pas besoin de les utiliser, vous n'aurez peut-être pas besoin d'escalade de privilèges.)

Variables du rôle

Consultez defaults/main.yml pour la documentation en ligne, et l'exemple ci-dessous pour les principales variables nécessaires. Pour toute clarification sur l'action attendue ainsi que sur les variables et sous-structures pour les différents types d'objets, référez-vous à la documentation ci-dessous.

Par défaut, le rôle effectuera la vérification SSL des certificats auto-signés si vous les avez récupérés à l'aide de la tâche get_certificate.yml d'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 de confiance, vous pouvez définir cette variable sur False, et tout certificat de niveau domaine auto-signé ne sera plus considéré comme fiable.

Exemple de playbook

Le rôle inclut la capacité d'exporter et d'importer un certain nombre de types d'actifs différents dans Information Server. Le rôle peut être importé dans un autre playbook en fournissant uniquement les variables d'intérêt afin de restreindre les actifs à inclure dans un import ou un export (des variables vides signifieront que le rôle ignorera tout traitement de ces types d'actifs).

Le premier niveau de variables fournies au rôle définit les grandes actions à réaliser, et s'exécutera toujours dans cet ordre, indépendamment de l'ordre dans lequel elles sont spécifiées :

1. gather - récupérer les détails sur l'environnement (c'est-à-dire les numéros de version)
2. export - extraire des actifs d'un environnement vers des fichiers
3. merge - fusionner plusieurs fichiers d'actifs en un seul fichier
4. ingest - charger des actifs dans un environnement à partir de fichiers (import est une variable réservée dans Ansible, d'où ingest...)
5. progress - faire avancer les actifs à travers un flux de travail (ne fera rien si le flux de travail n'est pas activé)
6. validate - valider que l'environnement est dans un état attendu en utilisant des comptes d'actifs objectifs

Toute variable manquante ignorera simplement cet ensemble d'actions.

Par exemple :

---

- name: configurer les variables d'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

- name: charger et valider des actifs
  hosts: all
  roles:
    - IBM.infosvr-import-export
  vars:
    isx_mappings:
      - { type: "HostSystem", attr: "name", from: "MY_HOST", to: "YOUR_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: "YOUR_HOST" }
          is: 10

... démarrera par la collecte des détails de l'environnement dans lequel le playbook est exécuté.

Il importera ensuite les métadonnées communes à partir d'un fichier file2.isx (attendu dans un sous-répertoire files/ relatif à votre playbook), renommant tous les noms d'hôtes de MY_HOST à YOUR_HOST, et écrasant les actifs existants avec les mêmes identités. Il importera ensuite les actifs DataStage de /some/directory/file1.isx dans le projet dstage1, écrasant tout actif existant avec les mêmes identités.

Notez que l'ordre dans lequel les variables sont définies n'a pas d'importance : le rôle s'occupera d'exporter et d'importer des objets dans l'ordre approprié pour garantir que les dépendances entre objets sont gérées (c'est-à-dire que les métadonnées communes et commerciales sont chargées avant les relations, etc.). Cependant, l'ordre des objets multiples définis au sein d'un type donné peut avoir de l'importance, selon vos propres dépendances.

Enfin, le playbook validera que le chargement a abouti aux actifs attendus dans l'environnement cible : 5 travaux DataStage dans le projet dstage1 et 10 tables de base de données dans une certaine combinaison de schémas et de bases de données sur le serveur YOUR_HOST.

(Comme aucune action progress ou export n'est spécifiée, elles ne seront pas exécutées.)

Structures d'actions (et d'objets)

Ce qui suit décrit toutes les actions et types d'objets actuellement couverts par ce rôle, ainsi que leurs structures attendues.

1. gather - collecte de détails sur l'environnement
2. export / merge / ingest types d'actifs de métadonnées (comme pour les actions ci-dessus, l'ordre ci-dessous définit l'ordre dans lequel ces types d'objets seront extraits et chargés - indépendamment de l'ordre dans lequel ils apparaissent au sein d'une action)
   1. customattrs - définitions d'attributs personnalisés
   2. common - métadonnées communes (considéré comme de bas niveau et, si possible, à éviter en utilisant l'une des options spécifiques au type)
   3. logicalmodel - métadonnées du modèle logique
   4. physicalmodel - métadonnées du modèle physique
   5. mdm - métadonnées du modèle de gestion des données maîtresses
   6. database - métadonnées de base de données
   7. datafile - métadonnées de fichier de données
   8. dataclass - métadonnées de classe de données
   9. datastage - actifs DataStage
   10. ds_vars - variables de projet DataStage
   11. infoanalyzer - actifs de l'Analyseur d'informations
   12. openigc - bundles et actifs OpenIGC
   13. extendedsource - sources de données étendues
   14. extensionmap - documents de mappage d'extension
   15. glossary - actifs de glossaire
   16. relationships - relations des métadonnées
   17. omd - métadonnées opérationnelles
3. progress - faire avancer le flux de travail
4. validate - cadre de validation

Pour export, merge et ingest, des mappages peuvent être appliqués pour transformer les métadonnées entre les environnements (par exemple, renommer, changer d'appartenance, etc.), et la plupart des types d'actifs peuvent également être limités par l'utilisation de conditions.

Notez que vous pouvez généralement écrire ces structures de variable en utilisant n'importe quelle forme supportée par Ansible, par exemple, toutes ces formats sont équivalents et laissent simplement place à votre préférence personnelle :

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

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

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

Licence

Apache 2.0

Informations sur l'auteur

Christopher Grote