ansible-role-infosvr-openigc

Rol de Ansible para automatizar la implementación de objetos OpenIGC para el Catálogo de Gobernanza de la Información, dentro de IBM Information Server.

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

Requisitos

• Ansible v2.6.x
• Las siguientes utilidades preinstaladas en su máquina de control:
  • zip
  • curl

El rol no utiliza ninguna escalación de privilegios y se ejecuta principalmente en la máquina de control (solo empujando archivos generados directamente contra las API relevantes en el entorno).

Debido al uso de plantillas Jinja avanzadas para las entradas basadas en YAML, se requiere una versión de Ansible con una distribución reciente de Jinja (v2.4 no es adecuada, por lo que se requiere v2.6.x). Aunque v2.7 ahora incluye la capacidad para que el módulo uri envíe archivos, no proporciona ninguna capacidad para anular la autoridad de certificación; por lo tanto, para permitir la validación de certificados autofirmados, sin necesidad de modificar la CA de la máquina de control, seguimos dependiendo de curl por el momento.

Variables del Rol

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

Este rol intentará reutilizar automáticamente variables del rol IBM.infosvr, por ejemplo, utilizando un playbook que primero importe IBM.infosvr usando tasks_from=setup_vars.yml.

Por defecto, el rol verificará SSL de certificados autofirmados si los ha recuperado utilizando la tarea get_certificate.yml de IBM.infosvr (consulte el ejemplo de playbook a continuación). Esto está controlado por la variable ibm_infosvr_openigc_verify_selfsigned_ssl del rol: si desea verificar solo certificados SSL firmados y de confianza, puede establecer esta variable en False y cualquier certificado de dominio de nivel autofirmado ya no será de confianza.

Ejemplo de Playbook

El rol está destinado principalmente a ser importado en otros playbooks según sea necesario para la implementación de objetos OpenIGC, tanto de paquetes como de instancias de activos. (Por lo tanto, la necesidad de Ansible v2.4.x y el módulo import_role.)

---
- name: configurar variables del Servidor de Información
  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 paquetes y activos de 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

Estructuras de acción (y objeto)

Lo siguiente describe todas las acciones y tipos de objetos cubiertos actualmente por este rol, y sus estructuras esperadas. Independientemente del orden en que se enumeren las variables en el playbook, se cargarán en el orden en que se enumeran a continuación.

bundles

La lista de directorios proporcionada a través de esta variable debe estar en forma de paquete, específicamente conteniendo la siguiente estructura:

• <BundleId>: el directorio raíz al que apunta debe tener el mismo nombre sensible a mayúsculas que el propio paquete
  • asset_type_descriptor.xml: el XML que describe el paquete (es decir, todas las clases, sus relaciones / contención, etc.)
  • i18n: un directorio que contiene etiquetas
    • labels.properties: el conjunto traducible de etiquetas de clase y atributos
  • icons: un directorio que contiene dos archivos .gif por clase definida por el paquete:
    • <ClassId>-icon.gif: debe ser una representación de 16x16 píxeles de la clase, y también podría ser un archivo .png, pero debe tener una extensión .gif independientemente
    • <ClassId>-bigIcon.gif: debe ser una representación de 32x32 píxeles de la clase, y también podría ser un archivo .png, pero debe tener una extensión .gif independientemente

assets_as_xml

La lista de archivos XML proporcionada a través de esta variable debe ser archivos XML de instancia de activo completamente funcionales, ya sea previamente generados (por ejemplo, por la variable a continuación) o creados manualmente.

assets_as_yaml

Esta variable se proporciona como una forma más conveniente y legible de especificar instancias de activos que aprender el formato XML requerido por assets_as_xml anterior.

La lista de archivos YAML proporcionada a través de esta variable se utiliza para generar XMLs de instancia de activo válidos que luego se cargan automáticamente. La estructura de cada archivo YAML debe ser la siguiente:

---

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

La subestructura contains se puede anidar tantas veces como sea necesario para crear la jerarquía de contención que requiera para sus activos. Cada subestructura debe tener, como mínimo, class y name definidos.

Además, se pueden especificar cualquier número de atributos adicionales según lo permitido por la definición de su paquete y el conjunto de atributos predeterminado para todos los objetos (por ejemplo, short_description, long_description). Simplemente, los atributos definidos en el paquete deben estar precedidos por el símbolo $. Por ejemplo:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: level1
    short_description: El directorio de nivel superior
    $filesystem: UNIX
    contains:
      - class: Folder
        name: level2
        short_description: El siguiente nivel en la estructura del directorio
        contains:
          - class: File
            name: MyFile.txt
            short_description: Un archivo que se encuentra dentro de /level1/level2/MyFile.txt
            $encoding: UTF-8

En este ejemplo, el paquete TestBundle define Folders y Files, donde los Folders pueden tener un atributo filesystem definido y los Files pueden tener un encoding definido. Ambos pueden tener short_descriptions porque todos los objetos en IGC tienen este atributo.

Para atributos que permiten múltiples valores, simplemente debe definir el valor para el atributo como una lista YAML. En este ejemplo, el atributo users_with_access específico del paquete permite múltiples valores, por lo que especificamos cada valor como parte de una lista YAML para ese atributo:

---

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

Finalmente, existe un atajo names para nodos hoja de una jerarquía de contención donde solo necesita especificar el name de cada uno, lo que evita la necesidad de especificar la misma class una y otra vez para cada nodo hoja:

---

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

flows_as_xml

La lista de archivos XML proporcionada a través de esta variable debe ser archivos XML de flujo de linaje completamente funcionales, ya sea previamente generados (por ejemplo, por la variable a continuación) o creados manualmente.

flows_as_yaml

Esta variable se proporciona como una forma más conveniente y legible de especificar instancias de activos que aprender el formato XML requerido por flows_as_xml anterior.

La lista de archivos YAML proporcionada a través de esta variable se utiliza para generar XMLs de flujo de linaje válidos que luego se cargan automáticamente. La estructura de cada archivo YAML debe ser la siguiente:

---

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

flows:
  - name: <comentario significativo>
    within: <id>
    contains:
      - name: <comentario significativo>
        from:
          - <id>
          - ...
        to:
          - <id>
          - ...
      - ...

La subestructura contains para assets se puede anidar tantas veces como sea necesario para crear la jerarquía de contención que requiera para sus activos. Cada subestructura debe tener, como mínimo, class y name definidos (de hecho, cualquier otro atributo se ignora ya que no se utiliza en el XML de flujo de linaje). Tenga en cuenta que en este caso debe especificar nombres de clase completamente calificados, incluyendo el bundleId, por ejemplo, $BundleId-ClassName. Esto es para asegurar que pueda combinar activos tanto de OpenIGC como nativos en un flujo de linaje (y crear flujos de linaje que atraviesen múltiples paquetes de OpenIGC).

Para cualquier activo que planee utilizar como parte de un flujo, también incluya un atributo id explícito para especificar cómo se referirá a ellos dentro de la variable flows. Este identificador debe ser único dentro del archivo YAML y no debe contener espacios ni otros caracteres especiales (aparte de . y _). Esto es necesario además del name porque el id proporciona una referencia plana y única dentro del archivo; el name es, en la realidad, un identificador anidado que dependerá de la estructura de contención en la que aparece y, por lo tanto, no es único por sí solo (solo al considerar toda su estructura de contención).

Cada name en la variable flows se utiliza como un comentario en el XML generado, pero no aparece realmente en IGC.

Considere el siguiente ejemplo:

---

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: Comando de copia para duplicar un archivo
    within: copy
    contains:
      - name: Copiar de My a Your y Other
        from:
          - MyFile.txt
        to:
          - YourFile.txt
          - OtherFile.txt

En este ejemplo, tenemos un TestBundle que define nuevos objetos que representan Folders, Files y Commands. La sección assets define solo los objetos que queremos describir en linaje, incluyendo su jerarquía de contención. Para cada activo que utilizaremos en linaje, hemos definido un atributo id único.

En la sección flows, luego creamos el linaje: el within externo define el proceso responsable de cualquier acción que se esté representando en linaje, y el contains dentro de eso especifica las entradas y salidas específicas de la acción.

Licencia

Apache 2.0

Información del Autor

Christopher Grote