Les environnements informatiques deviennent de plus en plus complexes. Dans ces conditions, il est essentiel que le système d'automatisation informatique dispose d'informations à jour sur les nœuds présents dans le réseau et soumis au traitement. Dans Red Hat Ansible Automation Platform, ce problème est résolu via ce que l'on appelle l'inventaire () – listes de nœuds gérés.
Dans sa forme la plus simple, l'inventaire est un fichier statique. C'est idéal lorsque vous commencez à travailler avec Ansible, mais à mesure que l'automatisation augmente, cela devient insuffisant.
Et voici pourquoi:
- Comment mettre à jour et maintenir une liste complète des nœuds surveillés lorsque les choses changent constamment, lorsque les charges de travail (et par conséquent les nœuds sur lesquels ils s'exécutent) vont et viennent ?
- Comment classer les composants de l'infrastructure informatique afin de sélectionner spécifiquement les nœuds pour appliquer une automatisation particulière ?
L'inventaire dynamique apporte des réponses à ces deux questions () – un script ou un plugin qui recherche les nœuds à automatiser, en faisant référence à la source de vérité. De plus, l'inventaire dynamique classe automatiquement les nœuds en groupes afin que vous puissiez sélectionner plus précisément les systèmes cibles pour effectuer une automatisation Ansible spécifique.
donnez à l'utilisateur Ansible la possibilité d'accéder à des plates-formes externes pour rechercher dynamiquement des nœuds cibles et utiliser ces plates-formes comme source de vérité lors de la création d'un 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 un certain nombre de , qui fonctionnent immédiatement et, en plus des plates-formes cloud répertoriées ci-dessus, offrent une intégration avec VMware vCenter, Red Hat OpenStack Platform et Red Hat Satellite. Pour ces plugins, il vous suffit de fournir des informations d'identification pour vous connecter à la plate-forme cible, après quoi ils peuvent être utilisés comme source de données d'inventaire dans Ansible Tower.
En plus des plugins standard inclus avec Ansible Tower, il existe d'autres plugins d'inventaire pris en charge par la communauté Ansible. Avec le passage à ces plugins ont commencé à être inclus dans les collections correspondantes.
Dans cet article, nous prendrons un exemple de travail avec le plugin d'inventaire pour ServiceNow, une plate-forme de gestion de services informatiques populaire dans laquelle les clients stockent 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 fonctionner avec ServiceNow CMDB et fait partie de la collection sur le portail .
Dépôt Git
Pour utiliser un plugin d'inventaire d'une collection dans Ansible Tower, il doit être défini comme source du projet. Dans Ansible Tower, un projet est une intégration avec une sorte de système de contrôle de version, comme un référentiel git, qui peut être utilisé pour synchroniser non seulement les playbooks d'automatisation, mais également les variables et les listes d'inventaire.
Notre référentiel est en fait très simple :
├── collections
│ └── requirements.yml
└── servicenow.yml
Le fichier servicenow.yml contient des détails sur l'inventaire des plugins. Dans notre cas, nous spécifions simplement la table de 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: ''
Veuillez noter que cela ne spécifie pas l'instance ServiceNow à laquelle nous nous connecterons de quelque manière que ce soit, ni aucune information d'identification pour la connexion. Nous configurerons tout cela plus tard dans Ansible Tower.
nécessaire pour qu'Ansible Tower puisse télécharger la collection requise et ainsi obtenir le plugin d'inventaire requis. Sinon, nous devrons installer et maintenir manuellement cette collection sur tous nos nœuds Ansible Tower.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Une fois que nous avons poussé cette configuration vers le contrôle de version, nous pouvons créer un projet dans Ansible Tower qui référence le référentiel correspondant. L'exemple ci-dessous relie Ansible Tower à notre référentiel github. Faites attention à l'URL du SCM : elle vous permet d'enregistrer un compte pour vous connecter à un référentiel privé, ainsi que de spécifier une branche, une balise ou un commit spécifique à extraire.
Création d'informations d'identification pour ServiceNow
Comme mentionné, la configuration de notre référentiel ne contient pas d'informations d'identification pour se connecter à ServiceNow et ne spécifie pas l'instance ServiceNow avec laquelle nous communiquerons. Par conséquent, pour définir ces données, nous créerons des informations d'identification dans Ansible Tower. Selon , il existe un certain nombre de variables d'environnement avec lesquelles nous définirons les paramètres de connexion, par exemple, comme ceci :
= username
The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by 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, il n'existe aucune information d'identification de ce type dans Ansible Tower où vous pourriez spécifier ces données pour ServiceNow. Mais Ansible Tower nous permet de définir , vous pouvez en savoir plus à ce sujet dans l'article .
Dans notre cas, la configuration d'entrée des informations d'identification personnalisées pour ServiceNow ressemble à ceci :
fields:
- id: SN_USERNAME
type: string
label: Username
- id: SN_PASSWORD
type: string
label: Password
secret: true
- id: SN_INSTANCE
type: string
label: Snow Instance
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Ces informations d'identification seront exposées en tant que variables d'environnement portant le même nom. Ceci est décrit dans la configuration de l'injecteur :
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Nous avons donc défini le type d'identifiant dont nous avons besoin, nous pouvons maintenant ajouter un compte ServiceNow et définir l'instance, le nom d'utilisateur et le mot de passe, comme ceci :
Nous créons un inventaire
Nous sommes donc maintenant tous prêts à créer un inventaire dans Ansible Tower. Appelons-le ServiceNow :
Après avoir créé l'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 d'accès à notre fichier d'inventaire YAML dans le référentiel de contrôle de source, dans notre cas, il s'agit de servicenow.yml à la racine du projet. De plus, vous devez lier votre compte ServiceNow.
Pour vérifier comment tout fonctionne, essayons de nous synchroniser avec la source de données en cliquant sur le bouton « Tout synchroniser ». Si tout est configuré correctement, alors les nœuds doivent être importés dans notre inventaire :
Veuillez noter que les groupes dont nous avons besoin ont également été créés.
Conclusion
Dans cet article, nous avons examiné comment utiliser les plugins d'inventaire des collections dans Ansible Tower en utilisant le plugin ServiceNow comme exemple. Nous avons également enregistré en toute sécurité les informations d'identification pour nous connecter à notre instance ServiceNow. Lier un plugin d'inventaire à partir d'un projet fonctionne non seulement avec des plugins tiers ou personnalisés, mais peut également être utilisé pour modifier le fonctionnement de certains inventaires standards. Cela rend Ansible Automation Platform facile et transparent à intégrer aux outils existants lors de l’automatisation d’environnements informatiques de plus en plus complexes.
Vous pouvez trouver plus d’informations sur les sujets abordés dans cet article, ainsi que sur d’autres aspects de l’utilisation d’Ansible, ici :
- Bloguer par .
- .
- Liste des collections prises en charge par Red Hat sur le site Web Automation Hub ().
- .
*Red Hat ne garantit pas que le code contenu dans ce document est correct. Tous les documents sont fournis sans approbation, sauf indication contraire expresse.
Source: habr.com