ansible-role-infosvr

Rol de Ansible para automatizar la implementación de un entorno de IBM InfoSphere Information Server, tanto en las versiones 11.5 como 11.7, incluyendo:

• la capa de repositorio (base de datos)
• la capa de dominio (servicios)
• la capa de motor
• la capa de gobernanza unificada ("Búsqueda Empresarial") (solo en v11.7)
• parches / paquetes de corrección

Y los siguientes módulos de la Edición Empresarial, que se pueden desactivar a través de las variables descritas a continuación (por ejemplo, si no tiene derecho a usarlos o no desea instalarlos/configurarlos):

• Catálogo de Gobernanza de la Información
• Analizador de Información
• Consola de Operaciones de DataStage
• DataClick
• Gestión de Eventos (integración con la Consola de Excepción de Calidad de Datos)
• Consola de Excepción de Calidad de Datos
• QualityStage
• Director de Servicios de Información
• FastTrack
• Tablero de Gobernanza de la Información (requiere un entorno Cognos preexistente)
• Enmascaramiento Optimizado dentro de DataStage
• Incluyendo estos extras disponibles solo en v11.7:
  • Nuevo Catálogo de Gobernanza de la Información (UI)
  • Tableros de Monitoreo de Gobernanza
  • Búsqueda Empresarial (incluyendo Gráfico de Conocimiento)
  • Diseñador de Flujos de DataStage
  • Clasificación de Términos de Aprendizaje Automático (v11.7+)

Actualmente, la implementación solo es compatible con DB2 como backend, aunque funciona tanto para la instalación como para la configuración de DB2 empaquetado, así como para la configuración de un DB2 preexistente. Se instalará ya sea una configuración completa de WebSphere Application Server Network Deployment o una configuración de WebSphere Liberty Profile (ver variables a continuación para más detalles); actualmente, el rol no puede configurar una instalación preexistente de WebSphere.

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

Requisitos

• Ansible v2.7
• Acceso a la red 'root' en todos los servidores
• Acceso de administrador a las máquinas cliente de Windows
• Máquinas cliente de Windows configuradas para acceso WinRM por Ansible (ver http://docs.ansible.com/ansible/latest/intro_windows.html)

Variables del Rol

Consulte defaults/main.yml para documentación en línea, y el ejemplo a continuación para las principales variables necesarias. El archivo de valores predeterminados contiene la configuración predeterminada que encontraría para una instalación básica de v11.7, por lo que solo necesita sobrescribir aquellas variables para las que no desea usar el valor predeterminado (es decir, contraseñas para usuarios).

Las variables mínimas que probablemente necesiten ser sobrescritas son las siguientes:

• ibm_infosvr_media_dir: la ubicación en su host de Ansible donde ya se han descargado los binarios de instalación (por ejemplo, desde Passport Advantage)
• ibm_infosvr_media_bin diccionario: los nombres de los binarios a usar para la instalación (por defecto, los archivos más recientes de v11.7 están allí; si desea instalar v11.5, estos deben reemplazarse por los nombres de archivo de v11.5)
• ibm_infosvr_ug_storage: el dispositivo de almacenamiento adicional y en bruto en la capa de Gobernanza Unificada que será utilizado por Kubernetes (debe ser en bruto: sin montar, no en un grupo LVM, etc.)
• ibm_infosvr_features diccionario: definiendo las características que desea (True) frente a las que no desea (False)

Finalmente, varias variables de credenciales deben ser sobrescritas para crear un entorno suficientemente seguro. Buscar _upwd_ revelará todas las variables de contraseña en defaults/main.yml que querrá sobrescribir. (Y siéntase libre de reemplazar esto con referencias a otras variables que estén a su vez más seguras a través de un vault de Ansible.)

Dependencias

La configuración del Analizador de Información utiliza el rol IBM.infosvr-metadata-asset-manager de manera indirecta, usando la directiva import_role. Este rol no se ha listado como una dependencia explícita para evitar dependencias circulares, pero debe instalarse si planea configurar el Analizador de Información.

Ejemplo de Playbook

El siguiente ejemplo de playbook realizará una instalación y configuración completa de IBM InfoSphere Information Server usando los parámetros predeterminados de defaults/main.yml (y cualquier anulación que haya colocado en, por ejemplo, group_vars/all.yml). Tenga en cuenta que, dado que toda la instalación se realiza a través de múltiples capas por este único rol, debe usar any_errors_fatal para evitar la instalación/configuración parcial de una capa en caso de que un paso anterior falle en otra capa.

---

- name: instalar y configurar IBM InfoSphere Information Server
  hosts: all
  any_errors_fatal: true
  roles:
    - IBM.infosvr
  pre_tasks:
    - name: actualizar todos los paquetes del sistema operativo
      yum:
        state: latest
        name: '*'
        exclude: docker*,kubelet*,kubectl*,kubeadm*
      become: yes
      when: ('ibm_information_server_clients' not in group_names)

Las tareas previas aseguran que todos los paquetes del sistema operativo estén actualizados antes de comenzar la instalación.

Inventario Esperado

Se esperan los siguientes grupos en el inventario, ya que se utilizan para distinguir dónde se instalan los diferentes componentes. Por supuesto, si desea instalar múltiples componentes en un solo servidor, esto se puede hacer simplemente proporcionando el mismo nombre de host bajo cada grupo. En el ejemplo a continuación, por ejemplo, las capas de repositorio y dominio están ambas ubicadas en 'serverA', mientras que la capa de motor se instalará por separado en 'serverB' y la capa de Gobernanza Unificada también se le asigna su propio sistema 'serverC'.

[ibm_information_server_repo]
# Host de Linux donde debe instalarse la capa de repositorio (base de datos) (DB2)
serverA.somewhere.com

[ibm_information_server_domain]
# Host de Linux donde debe instalarse la capa de dominio (servicios) (WebSphere)
serverA.somewhere.com

[ibm_information_server_engine]
# Host de Linux donde debe instalarse la capa de motor
serverB.somewhere.com

[ibm_information_server_clients]
# Host de Windows donde deben instalarse las aplicaciones cliente y configurarse un servidor de Intercambio de Metadatos para brokers / puentes solo para Windows
client.somewhere.com

[ibm_information_server_ug]
# Host de Linux donde debe instalarse la capa de Gobernanza Unificada v11.7+ (kubernetes)
serverC.somewhere.com

[ibm_information_server_external_db]
# Host de Linux que contiene una base de datos preexistente en la que implementar XMETA, etc. -- si no se proporciona un host, o este grupo falta por completo, se instalará el DB2 empaquetado en el servidor ibm_information_server_repo
serverD.somewhere.com

[ibm_cognos_report_server]
# Host de Linux donde existe una instalación preexistente de Cognos BI (para el Tablero de Gobernanza de la Información)
cognos.somewhere.com

[ibm_bpm]
# Host de Linux donde existe una instalación preexistente de BPM (actualmente no utilizada)
bpm.somewhere.com

Al igual que con cualquier inventario de Ansible, se deben proporcionar suficientes detalles para garantizar que sea posible la conectividad a los servidores (ver http://docs.ansible.com/ansible/latest/intro_inventory.html#list-of-behavioral-inventory-parameters).

Etiquetas

Instalando parches

El rol también está destinado a mantener un entorno instalado actualizado con parches y paquetes del sistema. Para aplicar parches, simplemente ingrese los detalles relevantes en los archivos bajo vars/patches/[server|client]/<version>/<date>.yml. Por ejemplo, las correcciones para el servidor v11.7.1.0 deben ir en vars/patches/server/11.7.1.0/<date>.yml, mientras que las correcciones para el cliente v11.7.0.2 deben ir en vars/patches/client/11.7.0.2/<date>.yml, donde <date> es la fecha en que se lanzó el parche. Generalmente, estos se mantienen actualizados en GitHub según la disponibilidad de parches importantes en Fix Central; pero si desea aplicar una corrección interina u otra que no esté ya en la lista, simplemente siga las instrucciones a continuación.

• Cada parche debe ser un diccionario denominado ibm_infosvr_patch_definition.
• El diccionario debe contener las siguientes claves:
  • name: el nombre del parche / paquete de corrección, como se indica en IBM Fix Central
  • srcFile: el nombre del archivo de parche / paquete de corrección, como se descargó de IBM Fix Central
  • pkgFile: el nombre del archivo .ispkg contenido dentro de srcFile
  • versionId: la etiqueta installerId que se agrega a su Version.xml una vez que se instala el parche / paquete de corrección
  • tiers: una lista de las capas en las que debe aplicarse este parche (los valores posibles son domain y engine) -- para los parches del cliente, se supone que es cliente, por lo que no se necesita tiers

Por ejemplo:

ibm_infosvr_patch_definition:
  name: is11700_ServicePack2_ug_services_engine_linux64
  srcFile: servicepack_11.7_SP2_linux64_11700.tar.gz
  pkgFile: servicepack_11.7_SP2_linux64_11700.ispkg
  versionId: servicepack_SP2_IS117_11700
  tiers:
    - domain
    - engine

Las actualizaciones de JDK también se pueden incluir bajo vars/patches/jdk/[server|client]/<major>/latest.yml, donde <major> es la versión principal (11.5 o 11.7). En ambos casos, se debe utilizar un diccionario único denominado ibm_infosvr_jdk_definition para definir la información de JDK.

Para 11.5, se necesitan las siguientes claves:

• name: el nombre del JDK, como se indica en IBM Fix Central
• infosvr_filename: el nombre del archivo JDK, como se descargó de IBM Fix Central
• infosvr_extract_path: la ruta creada al extraer el archivo JDK
• versionInfo: la cadena de versión que identifica de manera única esta versión del JDK (de java -version)
• was_filename: el nombre del paquete de corrección de WebSphere Application Server (WAS) que contiene el JDK v6
• was_offering: el nombre de la oferta dentro del paquete de corrección JDK (v6) de WAS
• jdk7_filename: el nombre del paquete de corrección de WAS que contiene el JDK v7
• jdk7_offering: el nombre de la oferta dentro del paquete de corrección JDK (v7) de WAS
• was_versionInfo: la cadena de versión que identifica de manera única esta versión del JDK (v6, de java -version)
• jdk7_versionInfo: la cadena de versión que identifica de manera única esta versión del JDK (v7, de java -version)

Para 11.7, se necesitan las siguientes claves:

• name: el nombre del JDK, como se indica en IBM Fix Central
• infosvr_filename: el nombre del archivo JDK, como se descargó de IBM Fix Central
• infosvr_extract_path: la ruta creada al extraer el archivo JDK
• was_filename: el nombre del paquete de corrección de WebSphere Application Server (WAS) que contiene el JDK
• was_offering: el nombre de la oferta dentro del paquete de corrección JDK de WAS
• versionInfo: la cadena de versión que identifica de manera única esta versión del JDK (no WAS) (de java -version)
• was_versionInfo: la cadena de versión que identifica de manera única esta versión del JDK (WAS) (de java -version)

Estas actualizaciones de JDK no son una lista, sino un simple diccionario, porque cada actualización sobreescribirá la actualización anterior. Solo deberá enumerar la última versión del JDK que desea aplicar.

Para realizar una actualización, use la etiqueta update de la siguiente manera:

ansible-playbook [-i hosts] [site.yml] --tags=update

Esto aplicará cualquier parche listado en los archivos vars/patches... para su lanzamiento particular que no se haya aplicado ya. Los parches se aplican en orden clasificado, según la fecha en que fueron lanzados (de más antiguo a más reciente). Sin embargo, no actualizará ningún paquete a nivel de sistema operativo: si desea esto, asegúrese de que su playbook más amplio se encargue de tal actualización.

Operaciones del entorno

Se han proporcionado varias etiquetas para facilitar las operaciones del entorno, especialmente cuando abarca múltiples hosts:

• status: verificará que los diversos componentes que se han configurado estén en funcionamiento (comprobando que un servicio esté escuchando en sus puertos designados).
• stop: apagará de manera ordenada cada componente, en el orden apropiado, a través de los diversos hosts; sin apagar los hosts subyacentes.
• start: iniciará cada componente, en el orden apropiado, a través de los diversos hosts.
• restart: proporciona una forma sencilla de ejecutar un stop seguido inmediatamente por un start.

Tareas reutilizables

El rol también incluye las siguientes tareas reutilizables, destinadas a ser incluidas en otros roles que necesiten utilizar las características de la instalación de Information Server sin necesariamente pasar por todos los pasos de instalación ellos mismos.

setup_vars.yml

Las variables de configuración utilizadas en la implementación de un entorno de Information Server pueden recuperarse más tarde utilizando el conjunto de tareas setup_vars.yml, por ejemplo, incluyendo el siguiente play en su playbook:

---

- name: configurar vars de Information Server
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml

get_certificate.yml

El certificado SSL raíz de la capa de dominio de un entorno de Information Server se puede recuperar más tarde utilizando el conjunto de tareas get_certificate.yml, por ejemplo, incluyendo el siguiente play en su playbook:

---

- name: configurar vars 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

Tenga en cuenta que este conjunto de tareas depende de que setup_vars.yml ya se haya ejecutado, por lo que puede ser útil incluirlas en el mismo play (como en el ejemplo anterior). El certificado SSL de la capa de dominio se almacenará en cache/__ibm_infosvr_cert_root.crt en relación con la ruta donde se está ejecutando el playbook en la máquina de control.

Licencia

Apache 2.0

Información del Autor

Christopher Grote