ansible-role-infosvr

Rôle Ansible pour automatiser le déploiement d'un environnement IBM InfoSphere Information Server, versions 11.5 et 11.7, incluant :

• le niveau de répertoire (base de données)
• le niveau de domaine (services)
• le niveau moteur
• le niveau de gouvernance unifiée ("Recherche d'Entreprise") (uniquement v11.7)
• les correctifs / packs de correctifs

et les modules suivants de l'édition Entreprise, qui peuvent être désactivés via les variables décrites ci-dessous (par exemple, si vous n'êtes pas autorisé à les utiliser ou si vous ne souhaitez pas les installer/configurer) :

• Catalogue de gouvernance de l'information
• Analyseur d'information
• Console d'opérations DataStage
• DataClick
• Gestion des événements (intégration à la console des exceptions de qualité des données)
• Console des exceptions de qualité des données
• QualityStage
• Directeur des services d'information
• FastTrack
• Tableau de bord de gouvernance de l'information (nécessite un environnement Cognos préexistant)
• Masquage optimisé dans DataStage
• Extras disponibles uniquement dans v11.7 :
  • Nouveau Catalogue de gouvernance de l'information (interface utilisateur)
  • Tableaux de bord de Surveillance de la gouvernance
  • Recherche d'entreprise (y compris le Graph de connaissance)
  • Concepteur de flux DataStage
  • Classification de termes d'apprentissage automatique (v11.7+)

Actuellement, le déploiement est uniquement conçu pour DB2 comme back-end, mais fonctionne à la fois pour installer et configurer le DB2 inclus ainsi que pour configurer un DB2 préexistant. Une configuration complète de WebSphere Application Server Network Deployment ou une configuration de WebSphere Liberty Profile sera installée (voir les variables ci-dessous pour plus de détails) ; actuellement, le rôle ne peut pas configurer une installation WebSphere préexistante.

Nouveau dans Ansible ? Cette introduction simple pourrait vous aider.

Exigences

• Ansible v2.7
• Accès réseau avec élévation de privilèges 'root' sur tous les serveurs
• Accès administrateur aux machines clientes Windows
• Machines clientes Windows configurées pour un accès WinRM par Ansible (voir http://docs.ansible.com/ansible/latest/intro_windows.html)

Variables de rôle

Voir defaults/main.yml pour la documentation en ligne, et l'exemple ci-dessous pour les principales variables nécessaires. Le fichier des valeurs par défaut contient les paramètres par défaut que vous trouveriez pour une installation standard de v11.7, donc vous devez seulement remplacer les variables pour lesquelles vous ne souhaitez pas utiliser les valeurs par défaut (c'est-à-dire, les mots de passe pour les utilisateurs).

Les variables minimales qui doivent probablement être remplacées sont les suivantes :

• ibm_infosvr_media_dir : l'emplacement sur votre hôte Ansible où les fichiers d'installation ont déjà été téléchargés (par exemple, à partir de Passport Advantage)
• ibm_infosvr_media_bin dict : les noms des fichiers binaires à utiliser pour l'installation (par défaut, les derniers fichiers v11.7 sont disponibles ; si vous souhaitez installer v11.5, ceux-ci doivent être remplacés par les noms de fichiers v11.5)
• ibm_infosvr_ug_storage : le dispositif de stockage brut supplémentaire sur le niveau de gouvernance unifiée à utiliser par Kubernetes (doit être brut : non monté, non dans un groupe lvm, etc)
• ibm_infosvr_features dict : définir les fonctionnalités que vous souhaitez (Vrai) par rapport à celles que vous ne souhaitez pas (Faux)

Enfin, les différentes variables d'identification doivent être remplacées pour créer un environnement suffisamment sécurisé. En recherchant _upwd_, vous découvrirez toutes les variables de mot de passe dans le defaults/main.yml que vous voudrez remplacer. (Et n'hésitez pas à remplacer cela par des références à d'autres variables qui sont elles-mêmes davantage sécurisées via un coffre Ansible.)

Dépendances

La configuration de l'Analyseur d'information utilise indirectement le rôle IBM.infosvr-metadata-asset-manager avec la directive import_role. Ce rôle n'a pas été listé comme une dépendance explicite pour éviter les dépendances circulaires, mais il devrait être installé si vous prévoyez de configurer l'Analyseur d'information.

Exemple de Playbook

Le playbook d'exemple suivant effectuera une installation et une configuration complètes de IBM InfoSphere Information Server en utilisant les paramètres par défaut de defaults/main.yml (et tous les remplacements que vous avez ajoutés par exemple dans group_vars/all.yml). Notez que comme l'ensemble de l'installation se fait à travers plusieurs niveaux par ce rôle unique, vous devriez utiliser any_errors_fatal pour éviter une installation/configuration partielle d'un niveau en cas d'échec d'une étape antérieure sur un autre niveau.

---

- name: installer et configurer IBM InfoSphere Information Server
  hosts: all
  any_errors_fatal: true
  roles:
    - IBM.infosvr
  pre_tasks:
    - name: mettre à jour tous les paquets au niveau OS
      yum:
        state: latest
        name: '*'
        exclude: docker*,kubelet*,kubectl*,kubeadm*
      become: yes
      when: ('ibm_information_server_clients' not in group_names)

Les pré-tâches garantissent que tous les paquets au niveau OS sont à jour avant de commencer l'installation.

Inventaire attendu

Les groupes suivants sont attendus dans l'inventaire, car ils sont utilisés pour distinguer où divers composants sont installés. Bien sûr, si vous souhaitez installer plusieurs composants sur un seul serveur, cela peut être fait simplement en fournissant le même nom d'hôte sous chaque groupe. Dans l'exemple ci-dessous, par exemple, les niveaux de répertoire et de domaine sont tous deux placés sur 'serverA', tandis que le niveau moteur sera installé séparément sur 'serverB' et le niveau de gouvernance unifiée a également son propre système 'serverC'.

[ibm_information_server_repo]
# Hôte Linux où le niveau de répertoire (base de données) devrait être installé (DB2)
serverA.somewhere.com

[ibm_information_server_domain]
# Hôte Linux où le niveau de domaine (services) devrait être installé (WebSphere)
serverA.somewhere.com

[ibm_information_server_engine]
# Hôte Linux où le niveau moteur devrait être installé
serverB.somewhere.com

[ibm_information_server_clients]
# Hôte Windows où les applications clientes devraient être installées, et un serveur d'échange de métadonnées configuré pour des courtiers/ponts uniquement Windows
client.somewhere.com

[ibm_information_server_ug]
# Hôte Linux où le niveau de gouvernance unifiée v11.7+ devrait être installé (kubernetes)
serverC.somewhere.com

[ibm_information_server_external_db]
# Hôte Linux qui possède une base de données préexistante dans laquelle déployer XMETA, etc. -- si aucun hôte n'est fourni, ou si ce groupe est totalement manquant, le DB2 inclus sera installé sur le serveur ibm_information_server_repo
serverD.somewhere.com

[ibm_cognos_report_server]
# Hôte Linux où une installation Cognos BI préexistante existe (pour le tableau de bord de gouvernance de l'information)
cognos.somewhere.com

[ibm_bpm]
# Hôte Linux où une installation BPM préexistante existe (actuellement non utilisée)
bpm.somewhere.com

Comme pour tout inventaire Ansible, des détails suffisants doivent être fournis pour garantir la connectivité aux serveurs (voir http://docs.ansible.com/ansible/latest/intro_inventory.html#list-of-behavioral-inventory-parameters).

Étiquettes

Installer des correctifs

Le rôle est également conçu pour maintenir un environnement installé à jour avec des correctifs et des paquets système. Pour appliquer des correctifs, il suffit d'entrer les détails pertinents dans les fichiers sous vars/patches/[server|client]/<version>/<date>.yml. Par exemple, les corrections pour le serveur v11.7.1.0 devraient aller dans vars/patches/server/11.7.1.0/<date>.yml, tandis que les corrections pour le client v11.7.0.2 vont dans vars/patches/client/11.7.0.2/<date>.yml, où <date> est la date à laquelle le correctif a été publié. En général, ceux-ci sont maintenus à jour sur GitHub en fonction de la disponibilité des principaux correctifs dans Fix Central ; mais si vous souhaitez appliquer un correctif intérimaire ou autre qui n'est pas déjà dans la liste, suivez simplement les instructions ci-dessous.

• Chaque correctif doit être un dictionnaire nommé ibm_infosvr_patch_definition.
• Le dictionnaire doit contenir les clés suivantes :
  • name : le nom du correctif / pack de correctifs, tel que répertorié sur IBM Fix Central
  • srcFile : le nom du fichier de correctif / pack de correctifs, tel que téléchargé depuis IBM Fix Central
  • pkgFile : le nom du fichier .ispkg contenu dans le srcFile
  • versionId : le tag installerId qui est ajouté à votre Version.xml une fois le correctif / pack de correctifs installé
  • tiers : une liste des niveaux sur lesquels ce correctif doit être appliqué (les valeurs possibles sont domain et engine) -- pour les correctifs clients, cela est implicite comme étant client, donc aucune tiers n'est nécessaire

Par exemple :

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

Les mises à jour de JDK peuvent également être incluses sous vars/patches/jdk/[server|client]/<major>/latest.yml, où <major> est le numéro de version principale (11.5 ou 11.7). Dans les deux cas, un seul dictionnaire nommé ibm_infosvr_jdk_definition doit être utilisé pour définir les informations JDK.

Pour 11.5, les clés suivantes sont nécessaires :

• name : le nom du JDK, tel que répertorié sur IBM Fix Central
• infosvr_filename : le nom du fichier JDK, tel que téléchargé depuis IBM Fix Central
• infosvr_extract_path : le chemin créé en extraire le fichier JDK
• versionInfo : la chaîne de version qui identifie de manière unique cette version du JDK (à partir de java -version)
• was_filename : le nom du pack de correctifs WebSphere Application Server (WAS) qui contient le JDK v6
• was_offering : le nom de l'offre dans le pack de correctifs WAS JDK (v6)
• jdk7_filename : le nom du pack de correctifs WAS qui contient le JDK v7
• jdk7_offering : le nom de l'offre dans le pack de correctifs WAS JDK (v7)
• was_versionInfo : la chaîne de version qui identifie de manière unique cette version du JDK (v6, à partir de java -version)
• jdk7_versionInfo : la chaîne de version qui identifie de manière unique cette version du JDK (v7, à partir de java -version)

Pour 11.7, les clés suivantes sont nécessaires :

• name : le nom du JDK, tel que répertorié sur IBM Fix Central
• infosvr_filename : le nom du fichier JDK, tel que téléchargé depuis IBM Fix Central
• infosvr_extract_path : le chemin créé en extraire le fichier JDK
• was_filename : le nom du pack de correctifs WebSphere Application Server (WAS) qui contient le JDK
• was_offering : le nom de l'offre dans le pack de correctifs WAS JDK
• versionInfo : la chaîne de version qui identifie de manière unique cette version du JDK (non-WAS, à partir de java -version)
• was_versionInfo : la chaîne de version qui identifie de manière unique cette version du JDK (WAS, à partir de java -version)

Ces mises à jour JDK ne sont pas une liste, mais un simple dictionnaire -- car chaque mise à jour écrasera la mise à jour précédente, vous n'aurez besoin de lister que la dernière version du JDK que vous souhaitez appliquer.

Pour effectuer une mise à jour, utilisez l'étiquette update comme suit :

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

Cela appliquera tous les correctifs listés dans les fichiers vars/patches... pour votre version particulière qui n'ont pas déjà été appliqués. Les correctifs sont appliqués dans l'ordre croissant, en fonction de la date de leur publication (les plus anciens d'abord). Cela ne mettra pas à jour les paquets au niveau système pour le système d'exploitation : si c'est souhaité, assurez-vous que votre playbook plus large s'occupe de cette mise à jour.

Opérations d'environnement

Un certain nombre d'étiquettes ont été fournies pour faciliter les opérations de l'environnement, en particulier lorsqu'il s'étend sur plusieurs hôtes :

• status : vérifiera que les différents composants configurés fonctionnent (en vérifiant qu'un service écoute sur leurs ports désignés).
• stop : arrêtera proprement chaque composant, dans l'ordre approprié, à travers les différents hôtes ; sans éteindre les hôtes sous-jacents.
• start : démarrera chaque composant, dans l'ordre approprié, à travers les différents hôtes.
• restart : fournit un moyen simple d'exécuter un stop suivi immédiatement d'un start.

Tâches réutilisables

Le rôle inclut également les tâches réutilisables suivantes, destinées à être incluses dans d'autres rôles qui ont besoin d'utiliser les caractéristiques de l'installation d'Information Server sans nécessairement passer par toutes les étapes d'installation elles-mêmes.

setup_vars.yml

Les variables de configuration utilisées pour déployer un environnement Information Server peuvent être récupérées plus tard en utilisant l'ensemble de tâches setup_vars.yml, par exemple en incluant le play suivant dans votre playbook :

---

- name: configurer les vars d'Information Server
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml

get_certificate.yml

Le certificat SSL racine du niveau de domaine d'un environnement Information Server peut être récupéré plus tard en utilisant l'ensemble de tâches get_certificate.yml, par exemple en incluant le play suivant dans votre playbook :

---

- name: configurer les vars d'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

Notez que cet ensemble de tâches dépend également de l'exécution préalable de setup_vars.yml, il peut donc être judicieux de les inclure dans le même play (comme dans l'exemple ci-dessus). Le certificat SSL du niveau de domaine sera stocké dans cache/__ibm_infosvr_cert_root.crt par rapport au chemin où le playbook s'exécute sur la machine de contrôle.

Licence

Apache 2.0

Informations sur l'auteur

Christopher Grote