ansible-role-infosvr-metadata-asset-manager

Rol de Ansible para automatizar el despliegue de metadatos utilizando los brokers y puentes de IBM Metadata Asset Manager.

¿Nuevo en Ansible? Esta introducción sencilla puede ayudarte.

Requisitos

• Ansible v2.4.x
• Acceso a la red con permisos 'dsadm' a un entorno de IBM Information Server
• Nombres de grupos de inventario configurados igual que el rol IBM.infosvr

Variables del rol

Consulta defaults/main.yml para documentación en línea y el ejemplo a continuación para las principales variables necesarias.

Cada broker y puente tiene su propio conjunto único de parámetros. Estos se documentan con más detalle en cada uno de los archivos YAML en vars/, y los requisitos mínimos para todos los brokers y puentes están documentados en vars/simple_examples.yml. Con el tiempo, la intención es hacer funcionar todos los brokers y puentes, pero la lista crecerá gradualmente; espera que solo los incluidos en vars/ para una versión determinada de este rol estén funcionando.

Ejemplo de Playbook

El rol está destinado principalmente a ser importado en otros playbooks según sea necesario para el despliegue de metadatos, a través de cualquiera de los brokers y puentes compatibles en el entorno de Information Server. (De ahí la necesidad de Ansible v2.4.x y el módulo import_role).

El siguiente ejemplo hará lo siguiente:

1. Agregar los drivers de DB2 incluidos con el Information Server a la configuración JDBC.
2. Crear una conexión de datos llamada AutoJDBC (si no existe ya) para conectarse a una base de datos DB2 llamada MYDB en myhost.somewhere.com. (requiere Information Server v11.7+)
3. Crear un área de importación y ejecutar la importación de metadatos de cualquier archivo encontrado en /data/loadable en el sistema de archivos de la capa del motor de Information Server (y registrar el nombre de host en el que se encuentran como 'IS-SERVER.IBM.COM').
4. Para el esquema DB2INST1 de MYDB en la conexión AutoJDBC, importar automáticamente cualquier metadato (es decir, para tablas, columnas), luego ejecutar análisis de columnas, detectar automáticamente asignaciones de términos, ejecutar análisis de calidad de datos y, una vez finalizado, publicar cualquier resultado en el Catálogo de Gobernanza de la Información. (requiere Information Server v11.7+)

Ten en cuenta que el orden en que se definen las variables no importa; el rol se encarga automáticamente de ejecutarlas en el orden apropiado para que los objetos dependientes se ejecuten primero (por ejemplo, la configuración JDBC se completa antes de intentar realizar cualquier conectividad a través de conexiones de datos o áreas de importación).

- import_role: name=IBM.infosvr-metadata-asset-manager
  vars:
    import_areas:
      - name: Simple_LocalFileConnector_ImportArea
        type: LocalFileConnector
        description: "Un ejemplo sencillo (configurando solo los campos requeridos) para un área de importación 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: Conexión de datos para descubrir automáticamente una fuente 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

Posibles variables

import_areas

Usa esta variable para proporcionar una lista (array) de estructuras complejas, cada una de las cuales define un área de importación para Metadata Asset Manager. Si el área de importación aún no existe, se creará y luego se cargará; si ya existe un área de importación con el mismo nombre, su metadata será reimportada (el área de importación no será reemplazada).

Las estructuras de ejemplo, completamente documentadas, se pueden encontrar en vars/documented_*.yml. Las estructuras simples se pueden encontrar en vars/simple_examples.yml.

data_connections

Disponible solo para v11.7+, esta variable se puede usar para definir solo conexiones de datos, en lugar de un área de importación completa. Esto es útil si, por ejemplo, deseas utilizar la capacidad de descubrimiento automático disponible desde v11.7+ (es decir, aprovechando la capacidad del Open Discovery Framework para canalizar la recolección de metadatos, seguido de análisis de columnas automatizadas, etc.).

odbc_entries

Usa esta variable para definir cualquier entrada ODBC que deba añadirse al archivo {DSHOME}/.odbc.ini. Esto es necesario para garantizar una conectividad adecuada a través de ODBC, por ejemplo, a través de las conexiones ODBC en DataStage e IMAM.

Generalmente, las claves requeridas dentro de cada uno de estos objetos son:

• name: el nombre (único) de la entrada ODBC
• description: una descripción de la entrada ODBC (no debe usar el carácter = en ninguna parte)
• type: el tipo de entrada ODBC, uno de db2, dbase, informix, oracle, oraclewire, sqlserver, sqlservernative, sybase, sybaseiq, salesforce, text, teradata, openedge, mysql, postgres, greenplum, hive, impala
• database: el nombre de la base de datos (para entradas RDBMS)
• host: el nombre de host o dirección IP del sistema que aloja la fuente de datos
• port: el número de puerto (para entradas RDBMS); generalmente, esto también se establecerá en el puerto predeterminado para el tipo de base de datos en particular.

Dado que cada controlador ODBC para diferentes plataformas admite una variedad de opciones específicas de la plataforma, también se pueden especificar estas (opcionalmente). Consulta las plantillas en templates/odbc/*.j2 para las opciones que se pueden proporcionar adicionalmente; cualquier opción que no sea obligatoria (enumerada arriba) se establecerá automáticamente en sus valores predeterminados en la configuración ODBC si no especificas otros valores.

Finalmente, si conoces propiedades adicionales que deseas agregar a una entrada particular, que no tienen valores predeterminados (es decir, que no están ya listadas en la plantilla mencionada anteriormente), añádelas a una entrada extras como pares clave-valor.

Ejemplos:

odbc_entries:
  - name: IADB en DB2
    description: Conexión a IADB en DB2
    type: db2
    database: IADB
    host: infosvr.vagrant.ibm.com
  - name: Base de datos de prueba en Oracle
    description: Conexión a un conjunto de datos de prueba en Oracle
    type: oracle
    database: TESTDB
    host: infosvr.vagrant.ibm.com
    SID: TESTDB
    extras:
      - QueryTimeout: -1
      - ColumnSizeAsCharacter: 1
      - ColumnsAsChar: 1

jdbc_entries

Usa esta variable para definir cualquier clase JDBC que deba incluirse en el archivo {DSHOME}/isjdbc.config. Esto es necesario para garantizar una conectividad adecuada a través de JDBC, por ejemplo, mediante las conexiones JDBC en DataStage e IMAM.

Se requieren dos sub-claves:

• classpaths: define las ubicaciones de cualquier clase de Java que se deba añadir al CLASSPATH, es decir, que proporciona drivers JDBC
• classnames: define los nombres de las clases de Java que proporcionan los drivers JDBC dentro de los classpaths mencionados anteriormente

El rol se asegurará de que cualquier classpath o classname no ya incluido en el archivo de configuración se añada a él y dejará los que ya estén presentes.

Ejemplos:

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

osh_schemas

Usa esta variable para definir cualquier archivo DDL (que contenga sentencias CREATE TABLE) que se utilizará para generar archivos de esquema OSH para archivos de datos que capturarían el mismo contenido que las tablas de la base de datos.

Todos los parámetros son obligatorios, excepto el parámetro tables; si no se especifica, se generará un esquema OSH para cada sentencia CREATE TABLE encontrada en el DDL especificado.

Esto creará lo siguiente:

• un archivo de datos (en blanco) en el directorio especificado para cada sentencia CREATE TABLE en el DDL especificado (limitado por las tablas definidas en el parámetro opcional tables), utilizando el fileext especificado como la extensión de archivo
• un archivo de esquema OSH bajo el mismo directorio especificado para cada uno de los archivos de datos en blanco creados, añadiendo .osh como una extensión de archivo adicional

Ejemplos:

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

El ejemplo anterior creará:

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

discover_sources

Usa esta variable para definir cualquier fuente de datos que deba ser descubierta automáticamente utilizando el Open Discovery Framework en v11.7+

Las siguientes sub-claves son requeridas para cada entrada:

• dcn: especifica el nombre de la conexión de datos para usar en el descubrimiento
• project: especifica el nombre del proyecto de Information Analyzer en el que realizar el descubrimiento
• target_host: especifica el nombre de host que se usará para la fuente que se está descubriendo

El resto de las sub-claves son opcionales:

• parameters: proporciona un conjunto de sub-claves que definen comportamientos o restricciones adicionales a aplicar al descubrimiento, por ejemplo:
  • rootAssets: define el subconjunto de activos para los cuales ejecutar el descubrimiento (sin esto, se descubrirán todos los activos en el target, es decir, todos los archivos en todos los directorios, todas las tablas en todos los esquemas)
  • Asset_description_already_exists: define cómo manejar la situación donde ya existe un activo técnico particular con la misma identidad
  • otros parámetros también son posibles dependiendo del tipo de fuente; consulta el Centro de Conocimiento de Information Server para obtener más detalles
• steps: indica qué pasos del proceso de descubrimiento deben aplicarse, y puede incluir:
  • import: descubre e ingesta los metadatos técnicos para la fuente en el Catálogo de Gobernanza de la Información
  • columnAnalysis: ejecuta análisis de columnas contra la fuente, determinando formatos, distribuciones de frecuencia de valores y detectando clases de datos (dependiente del import realizado)
  • termAssignment: intenta detectar automáticamente términos comerciales para asignar a los metadatos técnicos basándose en sus clases de datos detectadas, nombres de columnas y relaciones anteriores de las que el sistema ha aprendido (si está configurado) (dependiente del columnAnalysis realizado), incluyendo la aplicación de cualquier Regla de Automatización que asigne automáticamente reglas de datos basadas en los términos asignados
  • dataQualityAnalysis: realiza un conjunto de controles de calidad estándar, por ejemplo, buscando valores atípicos, y cualquier regla de datos que se haya asignado automáticamente
  • publish: publica los resultados de todos los otros pasos en el Catálogo de Gobernanza de la Información

Ten en cuenta que hasta el último paso publish, todo el trabajo se ha mantenido en un estado no publicado en el proyecto / espacio de trabajo de Information Analyzer. Una vez publicado, todos los análisis son visibles para cualquier persona en el Catálogo de Gobernanza de la Información. Por lo tanto, puede que desees omitir este último paso publish para forzar una revisión (y decisión manual de publicar) dentro de Information Analyzer. (Por defecto, si no se especifican los pasos, el descubrimiento incluirá todos los pasos excepto el paso publish).

También ten en cuenta que el formato schema[DBNAME|SCHEMA] de rootAssets, cuando se aplica a conexiones JDBC, puede requerir valores especiales para la parte DBNAME (por ejemplo, para DB2, dado que la base de datos está inherente en la URL proporcionada como parte de la conexión de datos, siempre debes proporcionar db2 como el DBNAME aquí, en lugar del nombre real de la base de datos).

Ejemplos:

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

Licencia

Apache 2.0

Información sobre el autor

Christopher Grote