ansible-role-infosvr-metadata-asset-manager

Rôle Ansible pour automatiser le déploiement de métadonnées en utilisant les courtiers et les ponts d’IBM Metadata Asset Manager.

Nouveau sur Ansible ? Cette introduction simple pourrait vous aider.

Exigences

• Ansible v2.4.x
• Accès réseau avec des privilèges 'dsadm' à un environnement IBM Information Server
• Noms des groupes d'inventaire configurés de la même manière que le rôle IBM.infosvr

Variables du rôle

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

Chaque courtier et chaque pont a son propre ensemble unique de paramètres. Ceux-ci sont documentés en détail dans chaque fichier YAML sous vars/, et les exigences minimales pour tous les courtiers et ponts sont documentées dans vars/simple_examples.yml. Au fil du temps, l'objectif est que tous les courtiers et ponts fonctionnent, mais la liste s'élargira progressivement — attendez-vous à ce que seuls ceux inclus dans vars/ pour une version donnée de ce rôle soient opérationnels.

Exemple de Playbook

Le rôle est principalement destiné à être importé dans d'autres playbooks selon les besoins pour le déploiement de métadonnées — par l'intermédiaire de l'un des courtiers et ponts pris en charge dans l'environnement Information Server. (D'où la nécessité d'Ansible v2.4.x et du module import_role.)

L'exemple suivant effectuera :

1. Ajouter les pilotes DB2 inclus avec Information Server à la configuration JDBC.
2. Créer une connexion de données appelée AutoJDBC (si elle n'existe pas déjà) pour se connecter à une base de données DB2 appelée MYDB sur myhost.somewhere.com. (nécessite Information Server v11.7+)
3. Créer un espace d'importation et exécuter l'importation des métadonnées de tout fichier trouvé dans /data/loadable sur le système de fichiers du moteur Information Server (et enregistrer le nom d’hôte sur lequel ils sont trouvés sous 'IS-SERVER.IBM.COM').
4. Pour le schéma DB2INST1 de MYDB sur la connexion AutoJDBC, importer automatiquement toute métadonnée (c'est-à-dire pour les tables, colonnes), puis exécuter une analyse des colonnes sur celles-ci, détecter automatiquement les attributions de termes, effectuer une analyse de la qualité des données, et une fois terminé, publier les résultats dans le Catalogue de Gouvernance des Informations. (nécessite Information Server v11.7+)

Notez que l'ordre dans lequel les variables sont définies n’a pas d’importance — le rôle s'occupe automatiquement de les exécuter dans l'ordre approprié afin que les objets dépendants soient traités en premier (par exemple, la configuration JDBC est terminée avant d'essayer de faire une connexion de données ou un espace d'importation).

- import_role: name=IBM.infosvr-metadata-asset-manager
  vars:
    import_areas:
      - name: Simple_LocalFileConnector_ImportArea
        type: LocalFileConnector
        description: "Un échantillon simple (en remplissant uniquement les champs requis) pour un espace d'importation LocalFileConnector"
        metadata_interchange_server: myhost.domain.com
        dcn:
          name: LOCALFS
        assets_to_import:
          - "folder[/data/loadable]"
        hostname: "IS-SERVER.IBM.COM"
    jdbc_entries:
      classpaths:
        - /opt/IBM/InformationServer/ASBNode/lib/java/db2jcc.jar
      classnames:
        - com.ibm.db2.jcc.DB2Driver
    data_connections:
      - name: AutoJDBC
        type: JDBCConnector
        description: Connexion de données pour découvrir automatiquement une source JDBC
        url: jdbc:db2://myhost.somewhere.com:50000/MYDB
        username: db2inst1
        password: "{{ a_password_from_eg_vault }}"
    discover_sources:
      - dcn: AutoJDBC
        project: UGDefaultWorkspace
        target_host: myhost.somewhere.com
        steps:
          - import
          - columnAnalysis
          - termAssignment
          - dataQualityAnalysis
          - publish
        parameters:
          rootAssets: schema[MYDB|DB2INST1]
          Asset_description_already_exists: Replace_existing_description

Variables possibles

import_areas

Utilisez cette variable pour fournir une liste (tableau) de structures complexes, chacune définissant un espace d'importation pour Metadata Asset Manager. Si l'espace d'importation n'existe pas encore, il sera créé puis chargé ; si un espace d'importation du même nom existe déjà, ses métadonnées seront réimportées (l'espace d'importation ne sera pas remplacé).

Des structures d'exemple, entièrement documentées, peuvent être trouvées sous vars/documented_*.yml. Des structures simples peuvent être trouvées sous vars/simple_examples.yml.

data_connections

Disponible uniquement pour v11.7+, cette variable peut être utilisée pour définir uniquement des connexions de données plutôt qu'un espace d'importation complet. Ceci est utile si, par exemple, vous souhaitez utiliser la capacité de découverte automatique disponible à partir de v11.7+ (c'est-à-dire en tirant parti de la capacité du cadre Open Discovery à canaliser la collecte de métadonnées, suivie d'une analyse automatique des colonnes, etc.).

odbc_entries

Utilisez cette variable pour définir toute entrée ODBC qui devrait être ajoutée au fichier {DSHOME}/.odbc.ini. Cela est nécessaire pour assurer la connectivité appropriée via ODBC, par exemple, par les connexions ODBC dans DataStage et IMAM.

En général, les clés requises dans chacun de ces objets sont :

• name: le nom (unique) de l'entrée ODBC
• description: une description de l'entrée ODBC (ne doit pas utiliser le caractère = nulle part)
• type: le type de l'entrée ODBC, l'une des valeurs db2, dbase, informix, oracle, oraclewire, sqlserver, sqlservernative, sybase, sybaseiq, salesforce, text, teradata, openedge, mysql, postgres, greenplum, hive, impala
• database: le nom de la base de données (pour les entrées RDBMS)
• host: le nom d'hôte ou l'adresse IP du système hébergeant la source de données
• port: le numéro de port (pour les entrées RDBMS) — généralement, ceci sera également par défaut le port par défaut pour le type de base de données en question

Étant donné que chaque pilote ODBC pour différentes plates-formes prend en charge une variété d'options spécifiques à la plate-forme, celles-ci peuvent également être (facultativement) spécifiées. Voir les modèles dans templates/odbc/*.j2 pour les options qui peuvent être fournies en plus ; celles qui ne sont pas obligatoires (énumérées ci-dessus) seront automatiquement définies sur leurs valeurs par défaut dans la configuration ODBC si vous ne spécifiez pas d'autres valeurs pour elles.

Enfin, si vous connaissez des propriétés supplémentaires que vous souhaitez ajouter à une entrée particulière, qui n'ont pas de valeurs par défaut (c'est-à-dire qui ne sont pas déjà énumérées dans le modèle mentionné ci-dessus), ajoutez-les à une entrée extras sous forme de paires clé-valeur.

Exemples :

odbc_entries:
  - name: IADB on DB2
    description: Connexion à IADB sur DB2
    type: db2
    database: IADB
    host: infosvr.vagrant.ibm.com
  - name: Test database on Oracle
    description: Connexion à un ensemble de données test sur Oracle
    type: oracle
    database: TESTDB
    host: infosvr.vagrant.ibm.com
    SID: TESTDB
    extras:
      - QueryTimeout: -1
      - ColumnSizeAsCharacter: 1
      - ColumnsAsChar: 1

jdbc_entries

Utilisez cette variable pour définir toutes les classes JDBC qui doivent être incluses dans le fichier {DSHOME}/isjdbc.config. Cela est nécessaire pour garantir une connectivité appropriée via JDBC, par exemple, par les connexions JDBC dans DataStage et IMAM.

Deux sous-clés sont nécessaires :

• classpaths: définit les emplacements de toutes les classes Java qui doivent être ajoutées au CLASSPATH, c'est-à-dire qui fournissent des pilotes JDBC
• classnames: définit les noms des classes Java qui fournissent les pilotes JDBC dans les classpaths ci-dessus

Le rôle s'assurera que tous les classpaths ou classnames qui ne sont pas déjà inclus dans le fichier de configuration sont ajoutés et laissera ceux qui y sont déjà présents.

Exemples :

jdbc_entries:
  classpaths:
    - "{{ ibm_infosvr_metadata_asset_mgr_install_location }}/ASBNode/lib/java/db2jcc.jar"
  classnames:
    - com.ibm.db2.jcc.DB2Driver

osh_schemas

Utilisez cette variable pour définir tout fichier DDL (contenant des instructions CREATE TABLE) qui doit être utilisé pour générer des fichiers de schéma OSH pour des fichiers de données qui captureraient le même contenu que les tables de la base de données.

Tous les paramètres sont requis, sauf pour le paramètre tables — s'il n'est pas spécifié, un schéma OSH sera généré pour chaque instruction CREATE TABLE trouvée dans le DDL spécifié.

Cela créera ce qui suit :

• un fichier de données (vide) sous le répertoire dest spécifié pour chaque instruction CREATE TABLE dans le DDL spécifié (limité par les tables définies dans le paramètre facultatif tables), en utilisant l'extension de fichier spécifiée comme extension de fichier
• un fichier de schéma OSH sous le même répertoire dest spécifié pour chaque fichier de données vide créé, en ajoutant .osh comme extension de fichier supplémentaire

Exemples :

osh_schemas:
  - ddl: /some/location/MYDB.sql
    structure: "file_format: 'delimited', header: 'false'"
    recordfmt: "delim='|', final_delim=end, null_field='', charset=UTF-8"
    dest: /some/target/directory
    fileext: csv
    tables:
      - TABLE1
      - TABLE2

L'exemple ci-dessus va créer :

• /some/target/directory/TABLE1.csv
• /some/target/directory/TABLE1.csv.osh
• /some/target/directory/TABLE2.csv
• /some/target/directory/TABLE2.csv.osh

discover_sources

Utilisez cette variable pour définir toutes les sources de données qui doivent être découvertes automatiquement en utilisant le cadre Open Discovery en v11.7+.

Les sous-clés suivantes sont nécessaires pour chaque entrée :

• dcn: spécifie le nom de la connexion de données à utiliser pour la découverte
• project: spécifie le nom du projet Information Analyzer dans lequel effectuer la découverte
• target_host: spécifie le nom d'hôte qui doit être utilisé pour la source à découvrir

Le reste des sous-clés est facultatif :

• parameters: fournit un ensemble de sous-clés définissant un comportement ou des restrictions supplémentaires à appliquer à la découverte, par exemple :
  • rootAssets: définit le sous-ensemble d'actifs pour lesquels exécuter la découverte (sans quoi tous les actifs sur la cible seront découverts — par exemple, tous les fichiers dans tous les répertoires, toutes les tables à travers tous les schémas)
  • Asset_description_already_exists: définit comment gérer la situation où un actif technique particulier avec la même identité existe déjà
  • d'autres paramètres sont également possibles selon le type de source — voir le centre de connaissance Information Server pour plus de détails
• steps: indique quelles étapes du processus de découverte doivent être appliquées, et peut inclure :
  • import: découvre et ingère les métadonnées techniques pour la source dans le Catalogue de Gouvernance des Informations
  • columnAnalysis: exécute l'analyse des colonnes sur la source, déterminant les formats, les fréquences de distribution des valeurs et détectant les classes de données (dépend de l'importation effectuée)
  • termAssignment: tente de détecter automatiquement les termes commerciaux à attribuer aux métadonnées techniques sur la base de leurs classes de données détectées, des noms de colonnes et des relations antérieures dont le système a appris (si configuré) (dépend de l'analyse des colonnes effectuée), y compris l'application de toute règle d'automatisation qui attribue automatiquement des règles de données basées sur les termes attribués
  • dataQualityAnalysis: passe par un ensemble de vérifications de qualité standard, par exemple, à la recherche de valeurs aberrantes, et des règles de données qui ont été automatiquement assignées
  • publish: publie les résultats de toutes les autres étapes dans le Catalogue de Gouvernance des Informations

Notez qu'hormis la dernière étape de publish, tout le travail a été conservé dans un état non publié dans le projet / espace de travail de l'Information Analyzer. Une fois publié, toutes les diverses analyses sont visibles par quiconque dans le Catalogue de Gouvernance des Informations. Vous souhaiterez donc peut-être omettre cette dernière étape publish afin de forcer une révision (et une décision manuelle de publication) au sein de l'Information Analyzer. (Par défaut, si les étapes ne sont pas spécifiées, la découverte inclura toutes les étapes sauf l'étape publish.)

Soyez également conscient que le format schema[DBNAME|SCHEMA] de rootAssets, lorsqu'il est appliqué aux connexions JDBC, peut nécessiter des valeurs spéciales pour la partie DBNAME (par exemple, pour DB2, puisque la base de données est inhérente à l'URL fournie dans la connexion de données, vous fournissez toujours db2 comme DBNAME ici, plutôt que le nom réel de la base de données).

Exemples :

discover_sources:
  - dcn: AutoJDBC
    project: UGDefaultWorkspace
    target_host: myhost.somewhere.com
    steps:
      - import
      - columnAnalysis
      - termAssignment
      - dataQualityAnalysis
      - publish
    parameters:
      rootAssets: schema[MYDB|DB2INST1]
      Asset_description_already_exists: Replace_existing_description

Licence

Apache 2.0

Informations sur l'auteur

Christopher Grote