Utilisation des plugins d'inventaire des Collections de contenu Ansible dans Ansible Tower

Les environnements informatiques deviennent de plus en plus complexes. Dans ces conditions, il est crucial pour un système d'automatisation informatique de disposer d'informations actualisées sur les nœuds présents dans le réseau et devant être traités. Dans la Red Hat Ansible Automation Platform, cette question est abordée grâce à ce que l'on appelle les inventaires (inventory) – des listes de nœuds gérés.

Dans sa forme la plus simple, un inventaire se présente sous la forme d'un fichier statique. C'est l'option idéale lorsque vous commencez à travailler avec Ansible, mais au fur et à mesure que l'automatisation s'accroît, cela devient insuffisant.

Et voici pourquoi :

1. Comment mettre à jour et maintenir à jour une liste complète des nœuds contrôlés lorsque quelque chose change constamment, lorsque les charges de travail – et donc les nœuds sur lesquels elles s'exécutent – apparaissent et disparaissent ?
2. Comment classer les composants de l'infrastructure informatique afin de sélectionner précisément les nœuds pour appliquer un type d'automatisation ou un autre ?

Les réponses à ces deux questions sont fournies par l'inventaire dynamique (dynamic inventory) – un script ou un plugin qui recherche les nœuds devant être automatisés en se référant à la source de vérité. De plus, l'inventaire dynamique classe automatiquement les nœuds par groupes, afin que vous puissiez sélectionner plus précisément les systèmes cibles pour l'exécution de l'automatisation Ansible.

Les plugins d'inventaire permettent à l'utilisateur d'Ansible d'accéder à des plateformes externes pour rechercher dynamiquement les nœuds cibles et d'utiliser ces plateformes comme source de vérité lors de la création de l'inventaire. La liste standard des sources dans Ansible comprend les plateformes cloud AWS EC2, Google GCP et Microsoft Azure, et il existe également de nombreux autres plugins d'inventaire pour Ansible.

Ansible Tower est livré avec une série de plugins d'inventaire, qui fonctionnent directement « hors de la boîte » et offrent, en plus des plateformes cloud mentionnées ci-dessus, une intégration avec VMware vCenter, Red Hat OpenStack Platform et Red Hat Satellite. Pour ces plugins, il suffit de fournir des identifiants pour se connecter à la plateforme cible, après quoi ils peuvent être utilisés comme source de données d'inventaire dans Ansible Tower.

En plus des plugins standards fournis avec Ansible Tower, il existe également d'autres plugins d'inventaire soutenus par la communauté Ansible. Avec le passage aux Red Hat Ansible Content Collections , ces plugins ont commencé à être inclus dans les collections correspondantes.

Dans ce post, nous allons examiner le fonctionnement du plugin d'inventaire pour ServiceNow, une plateforme populaire de gestion des services informatiques, où les clients conservent souvent des informations sur tous leurs appareils dans la CMDB. De plus, la CMDB peut contenir un contexte utile pour l'automatisation, comme des informations sur les propriétaires de serveurs, les niveaux de service (production/non-production), les mises à jour installées et les fenêtres de maintenance. Le plugin d'inventaire Ansible peut travailler avec la CMDB ServiceNow et fait partie de la collection. servicenow sur le portail galaxy.ansible.com.

Le dépôt Git

Pour utiliser le plugin d'inventaire de la collection dans Ansible Tower, il doit être défini comme source de projet. Dans Ansible Tower, un projet est une intégration avec un système de gestion de versions, comme un dépôt git, qui peut être utilisé pour synchroniser non seulement les playbooks d'automatisation, mais aussi les variables et les listes d'inventaire.

Notre dépôt est en réalité très simple :

├── collections
│   └── requirements.yml
└── servicenow.yml

Le fichier servicenow.yml contient les détails pour le plugin d'inventaire. Dans notre cas, nous spécifions simplement la table dans la CMDB ServiceNow que nous souhaitons utiliser. Nous définissons également les champs qui seront ajoutés en tant que variables de nœud, ainsi que certaines informations sur les groupes que nous souhaitons créer.

$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
  - key: sn_sys_class_name | lower
	prefix: ''
	separator: ''
  - key: sn_os | lower
	prefix: ''
	separator: ''

Notez qu'il n'est pas spécifié ici quelle instance de ServiceNow nous allons connecter, et aucun identifiant n'est fourni pour la connexion. Tout cela sera configuré plus tard dans Ansible Tower.

Le fichier collections/requirements.yml est nécessaire pour qu'Ansible Tower puisse télécharger la collection requise et obtenir ainsi le plugin d'inventaire nécessaire. Sinon, il faudrait installer et maintenir manuellement cette collection sur tous nos nœuds Ansible Tower.

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

Après avoir envoyé cette configuration au système de contrôle de version, il est possible de créer un projet dans Ansible Tower, faisant référence au dépôt correspondant. Dans l'exemple ci-dessous, Ansible Tower se connecte à notre dépôt sur GitHub. Notez l'URL SCM : elle permet de spécifier un compte pour se connecter à un dépôt privé, ainsi que de définir une branche, un tag ou un commit spécifique à extraire.

Créons des credentials pour ServiceNow

Comme déjà mentionné, la configuration dans notre dépôt ne contient pas de credentials pour se connecter à ServiceNow et ne précise pas l'instance de ServiceNow avec laquelle nous allons interagir. Par conséquent, pour définir ces données, nous allons créer des credentials dans Ansible Tower. Selon la documentation du plugin d'inventaire ServiceNow, il existe un certain nombre de variables d'environnement que nous utiliserons pour définir les paramètres de connexion, comme ceci :

= username
    	Le compte utilisateur ServiceNow, il doit avoir les droits pour lire cmdb_ci_server (par défaut), ou la table spécifiée par SN_TABLE

    	set_via:
      	env:
      	- name: SN_USERNAME

Dans ce cas, si la variable d'environnement SN_USERNAME est définie, le plugin d'inventaire l'utilisera comme compte pour se connecter à ServiceNow.

Nous devons également définir les variables SN_INSTANCE et SN_PASSWORD.

Cependant, dans Ansible Tower, il n'existe pas de credentials de ce type, où nous pourrions spécifier ces données pour ServiceNow. Cependant, Ansible Tower nous permet de définir des types de credentials personnalisés, vous pouvez en lire plus dans l'article "Ansible Tower Feature Spotlight: Custom Credentials".

Dans notre cas, la configuration d'entrée pour les credentials personnalisés pour ServiceNow est la suivante :

fields:
  - id: SN_USERNAME
	type: string
	label: Nom d'utilisateur
  - id: SN_PASSWORD
	type: string
	label: Mot de passe
	secret: true
  - id: SN_INSTANCE
	type: string
	label: Instance Snow
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

Ces credentials seront exposés comme des variables d'environnement avec le même nom. Cela est décrit dans la configuration de l'injecteur :

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

Donc, nous avons défini le type de credential dont nous avons besoin, il est maintenant possible d'ajouter le compte ServiceNow et de définir l'instance, le nom d'utilisateur et le mot de passe, comme ceci :

Créons un inventaire

Nous sommes donc prêts à créer un inventaire dans Ansible Tower. Appelons-le ServiceNow :

Après avoir créé un inventaire, nous pouvons y attacher une source de données. Ici, nous spécifions le projet que nous avons créé précédemment et entrons le chemin vers notre fichier d'inventaire YAML dans le dépôt du système de gestion de version, dans notre cas servicenow.yml à la racine du projet. De plus, il faut lier le compte ServiceNow.

Pour vérifier comment tout fonctionne, essayons de nous synchroniser avec la source de données en cliquant sur le bouton « Sync all ». Si tout est correctement configuré, les nœuds devraient être importés dans notre inventaire :

Notez que les groupes nécessaires ont également été créés.

Conclusion

Dans cet article, nous avons examiné comment utiliser les plugins d'inventaire d'Ansible Tower provenant de collections en prenant comme exemple le plugin ServiceNow. Nous avons également correctement spécifié les informations d'identification pour nous connecter à notre instance ServiceNow. La liaison du plugin d'inventaire provenant du projet fonctionne non seulement avec des plugins tiers ou personnalisés, mais elle peut également être appliquée pour modifier le fonctionnement de certains plugins d'inventaire standard. Grâce à cela, Ansible Automation Platform s'intègre facilement et sans couture avec des outils existants lors de l'automatisation des environnements informatiques devenant de plus en plus complexes.

Vous pouvez trouver des informations supplémentaires sur les sujets abordés dans cet article, ainsi que sur d'autres aspects de l'utilisation d'Ansible ici :

• Blog sur l'automatisation ServiceNow avec Ansible.
• Comment créer vos propres collections.
• Liste des collections Red Hat prises en charge sur le site Automation Hub (cloud.redhat.com).
• Livres électroniques sur Ansible Automation Platform.

*Red Hat ne garantit pas l'exactitude du code présenté ici. Tous les matériaux sont fournis sans support, sauf indication contraire clairement énoncée.

Source : habr.com