ansible-role-infosvr-import-export

Rol de Ansible para automatizar la importación y exportación de contenido y estructuras dentro de IBM InfoSphere Information Server.

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

Requisitos

• Ansible v2.8+
• Acceso a la red que permita el uso del usuario dsadm en un entorno de IBM Information Server
• Nombres de grupos de inventario configurados de la misma manera que el rol IBM.infosvr
• (Y para mayor facilidad de uso, el rol IBM.infosvr instalado y configurado)
• jmespath instalado en tu máquina de control (este rol usa el módulo json_query, que depende de esta biblioteca)

El rol utiliza opcionalmente un escalado de privilegios a root para automatizar muy pocas tareas de configuración. Si tu entorno no permite este escalado de privilegios, asegúrate de que estos requisitos previos se cumplan manualmente en tu entorno y cambia la variable ibm_infosvr_impexp_priv_escalate en defaults/main.yml a False (esto omitirá cualquier intento de escalado de privilegios a root).

Si decides desactivar el escalado, asegúrate de que lo siguiente se realice en tu entorno objetivo antes de ejecutar el rol:

• Instalación de la biblioteca python-requests (por ejemplo, a través de yum)
• Instalación de la biblioteca python-lxml (por ejemplo, a través de yum)
• Instalación de curl (por ejemplo, a través de yum)
• El directorio {IS_HOME}/ASBServer/logs del nivel de dominio debe ser escribible por el usuario que ejecuta el rol (así como cada uno de los archivos .log en ese directorio)

(El escalado de privilegios a dsadm se usa principalmente para el manejo de metadatos operacionales y la extracción y carga de variables de proyectos de DataStage; si no necesitas usar esto, puede que no necesites escalado de privilegios en absoluto.)

Variables del Rol

Consulta defaults/main.yml para obtener documentación en línea y el ejemplo a continuación para las principales variables necesarias. Para cualquier aclaración sobre las variables y subestructuras esperadas para los diferentes tipos de objetos, consulta la documentación a continuación.

Por defecto, el rol hará verificación SSL de certificados autofirmados si los has recuperado usando la tarea get_certificate.yml de IBM.infosvr (ver ejemplo de playbook a continuación). Esto se controla mediante la variable ibm_infosvr_openigc_verify_selfsigned_ssl del rol: si deseas verificar solo certificados SSL firmados y de confianza, puedes establecer esta variable en False y cualquier certificado de dominio tier autofirmado ya no será confiable.

Ejemplo de Playbook

El rol incluye la capacidad de exportar e importar diferentes tipos de activos en Information Server. El rol puede ser importado en otro playbook proporcionando solo las variables de interés para limitar los activos a incluir en una importación o exportación (si las variables están vacías significará que el rol omitirá cualquier procesamiento de esos tipos de activos).

El primer nivel de variables proporcionadas al rol define las acciones amplias a tomar, y siempre se ejecutarán en este orden sin importar el orden en que se especifiquen:

1. gather - recuperar detalles del entorno (es decir, números de versión)
2. export - extraer activos de un entorno a archivos
3. merge - fusionar varios archivos de activos en un solo archivo
4. ingest - cargar activos en un entorno desde archivos (en Ansible, import es una variable reservada, por eso se usa ingest...)
5. progress - mover activos a través de un flujo de trabajo (no hará nada si el flujo de trabajo no está habilitado)
6. validate - validar que un entorno está en un estado esperado usando conteos de activos objetivos

Cualquier variable faltante simplemente omitirá ese conjunto de acciones.

Por ejemplo:

---

- name: configurar variables de 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: cargar y validar activos
  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

... comenzará recibiendo detalles del entorno en el que se está ejecutando el playbook.

Luego importará los metadatos comunes desde un archivo file2.isx (se espera que esté en un subdirectorio files/ relativo a tu playbook), renombrando cualquier nombre de host de MY_HOST a YOUR_HOST, y sobrescribiendo cualquier activo existente con las mismas identidades. A continuación, importará los activos de DataStage desde /some/directory/file1.isx al proyecto dstage1, sobrescribiendo cualquier activo existente con las mismas identidades.

Ten en cuenta que el orden en el que se definen las variables no importa: el rol se encargará de exportar e importar objetos en el orden adecuado para asegurar que se manejen las dependencias entre objetos (es decir, que los metadatos comunes y de negocio se carguen antes de las relaciones, etc.). Sin embargo, el orden de varios objetos definidos dentro de un tipo determinado puede importar, dependiendo de tus propias dependencias.

Finalmente, el playbook validará que la carga ha resultado en los activos esperados en el entorno objetivo: 5 trabajos de DataStage en el proyecto dstage1 y 10 tablas de bases de datos en alguna combinación de esquemas y bases de datos en el servidor YOUR_HOST.

(Dado que no se especifican las acciones progress ni export, no se ejecutarán.)

Estructuras de Acción (y objeto)

Lo siguiente describe todas las acciones y tipos de objetos que actualmente cubre este rol, y sus estructuras esperadas.

1. gather - recopilación de detalles del entorno
2. export / merge / ingest tipos de activos de metadatos (como con las acciones anteriores, el orden a continuación define el orden en que estos tipos de objetos serán extraídos y cargados -- independientemente del orden en que aparezcan dentro de una acción)
   1. customattrs - definiciones de atributos personalizados
   2. common - metadatos comunes (debe considerarse de bajo nivel, y donde sea posible evitarse utilizando una de las opciones específicas de tipo)
   3. logicalmodel - metadatos de modelo lógico
   4. physicalmodel - metadatos de modelo físico
   5. mdm - metadatos del modelo de gestión de datos maestros
   6. database - metadatos de base de datos
   7. datafile - metadatos de archivo de datos
   8. dataclass - metadatos de clase de datos
   9. datastage - activos de DataStage
   10. ds_vars - variables de proyecto de DataStage
   11. infoanalyzer - activos de Information Analyzer
   12. openigc - paquetes y activos de OpenIGC
   13. extendedsource - fuentes de datos extendidas
   14. extensionmap - documentos de mapeo de extensiones
   15. glossary - activos de glosario
   16. relationships - relaciones de metadatos
   17. omd - metadatos operacionales
3. progress - progreso del flujo de trabajo
4. validate - marco de validación

Para export, merge e ingest, mapeos se pueden aplicar para transformar metadatos entre entornos (por ejemplo, renombrar, cambiar contención, etc.), y la mayoría de los tipos de activos también pueden ser limitados mediante el uso de condiciones.

Ten en cuenta que generalmente puedes escribir estas estructuras de variables usando cualquier forma admitida por Ansible, por ejemplo, todas estas son equivalentes y dependen de tu preferencia personal:

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

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

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

Licencia

Apache 2.0

Información del Autor

Christopher Grote