Abonnez-vous au flux

Nouvelle fonction : les inventaires construits

Dans un autre article de blog, nous avions présenté l'idée d'une méthode de gestion des inventaires plus intelligente reposant sur le plug-in « constructed » d'Ansible. La version 4.2 d'Ansible Automation Platform inclut désormais cette fonction entièrement prise en charge, que nous allons vous présenter ici. 

La fonction d'inventaire construit succède à la fonction d'inventaire intelligent existante, et  est désormais proposée comme option supplémentaire aux utilisateurs lors de la création d'un inventaire à l'aide du composant Automation Controller d'Ansible Automation Platform. À partir d'une sélection d'inventaires « normaux », cette commande effectue des opérations définies par l'utilisateur, filtre les données et produit un inventaire basé sur le contenu des inventaires d'entrée.

 

Un inventaire construit, qu'est-ce que c'est ?

Semblable à l'inventaire intelligent existant, cette fonction permet aussi aux utilisateurs d'exécuter des tâches sur des hôtes dans plusieurs inventaires. 

L'inventaire construit offre de nouvelles fonctionnalités, notamment la capacité intégrée de définir et d'utiliser à la fois des variables d'hôtes (hostvars) et de groupes (groupvars) :

  • L'inventaire construit contient des groupes qui jouent un rôle clé dans sa configuration.
  • La logique définie par l'utilisateur (pour ajouter des groupes, variables et hôtes sélectionnés) est exécutée par le contrôleur via ansible-inventory, et s'affiche dans l'interface utilisateur sous forme de mise à jour de l'inventaire.
  • La logique définie par l'utilisateur est au format jinja2, une syntaxe Ansible couramment utilisée.

L'un des principes fondamentaux de cette fonction est que la création d'un inventaire construit suit la même logique que l'écriture d'un playbook, contrairement à l'inventaire intelligent, pour lequel il faut réfléchir à l'inventaire tel que l'application le voit.

 

Inventaire construit dans l'interface utilisateur

Cliquez sur Add constructed inventory sous Inventories pour afficher le menu suivant :

image1

L'inventaire construit inclut trois options clés spécifiques.

  • Input inventories : option qui permet de sélectionner des inventaires existants dont le contenu (hôtes, groupes, etc.) alimentera l'inventaire construit.
  • Limit : option qui permet de définir une limite, transmise directement à ansible-inventory, et qui permet de filtrer les hôtes à l'aide de la syntaxe standard pour les modèles d'hôte Ansible.
  • Source vars : option qui regroupe les données en entrée du plug-in d'inventaire ansible.builtin.constructed.

REMARQUE : dans la liste Input Inventories, les inventaires d'entrée sont triés de sorte qu'en cas de conflit de noms d'hôte et de variables, les variables du dernier inventaire sont prioritaires. Les variables étant fusionnées, cette commande n'efface pas les variables d'un inventaire d'entrée précédent. S'il n'y a pas de conflit de noms d'hôtes, l'ordre des inventaires restera prioritaire.

Nous reviendrons sur ces points ci-dessous avec un exemple.

 

Inventaire construit de base

Vous devez indiquer au moins un inventaire d'entrée, les autres champs sont facultatifs. Dans certains cas, il peut être judicieux d'indiquer deux inventaires d'entrée ou plus et de ne pas remplir les champs « Limit » et « Source vars ». Vous pouvez ensuite exécuter des tâches qui agissent sur l'association du contenu de ces deux inventaires d'entrée. 

 

Cas d'utilisation d'un inventaire construit plus complexe

Pour comprendre l'utilité des options Limit et Source vars, qui permettent de tirer pleinement parti d'un inventaire construit, prenons un exemple concret.

 

Configuration de l'inventaire construit

Imaginons que nous avons deux inventaires issus du même fournisseur de cloud, mais qui couvrent plusieurs régions et qui ont donc différents ensembles d'hôtes. Ces inventaires sont gérés séparément, en raison de comptes, de fonctions et d'emplacements distincts. Dans cet exemple, nous utilisons des inventaires d'entrée simples qui correspondent chacun à une région, East/West.

Les inventaires sont issus de fichiers .ini basés sur Git, que nous alimentons selon une approche de configuration en tant que code avec des pratiques DevOps.

Commençons par configurer un nouveau projet et synchronisons-le afin de savoir d'où viennent les informations des inventaires. Dans l'interface utilisateur, sélectionnez Projects, puis cliquez sur Add :

Une fois créé et enregistré, le projet est automatiquement synchronisé :

Maintenant, créons les nouveaux inventaires qui vont faire référence aux informations des fichiers du projet. Sous Inventories, cliquez sur Create :

Cliquez à présent sur Sources, puis sur Add :

Renseignez le champ Name pour cette source, ici pour les hôtes de la région East, sélectionnez l'option Sourced from a Project pour Source et indiquez le projet qui vient d'être ajouté, ainsi que le fichier source east.ini approprié :

Après avoir enregistré, cliquez sur le bouton Sync pour extraire les informations :

Une fois la synchronisation terminée, consultez les résultats de la tâche dans l'onglet Output :

Dans cet exemple, vous verrez que 3 hôtes et 3 groupes ont été découverts et ajoutés automatiquement. Vous pouvez aussi voir ces informations dans l'interface utilisateur, sous Hosts.

À présent, la même procédure doit être appliquée pour la région West. Je vous invite à le faire vous-même en suivant l'exemple ci-dessus, en utilisant les informations du fichier west.ini comme source.

Pour ce scénario hypothétique, nous voulons exécuter des tâches sur certains des hôtes des régions East et West simultanément, en fonction de critères que nous allons définir.

Créons maintenant un nouvel inventaire construit dans l'interface utilisateur :

Ajoutez les deux inventaires cloud en entrée. Utilisez ensuite Source vars pour construire un nouveau groupe « target_group », puis utilisez l'option Limit pour filtrer ce groupe :

image2

Une fois la synchronisation terminée, vous pouvez consulter les résultats de la tâche dans l'onglet Output :

Nous avons maintenant 4 groupes avec 4 hôtes, auxquels nous pouvons accéder sous Hosts et Groups dans l'interface utilisateur pour confirmer le résultat. Intéressons-nous ici aux groupes :

Lorsque la mise à jour de l'inventaire construit s'est exécutée, les groupes « account_1234 », « account_4321 » et « accounts » ont été copiés à partir des inventaires d'entrée dans l'inventaire construit. 

Nous voyons également que l'inventaire construit inclut également le groupe « target_group » dont nous allons parler plus loin.

Si cet inventaire construit était utilisé par un modèle de tâche pour exécuter une tâche, tous les groupes définis pourraient être utilisés par la tâche.

À présent, si vous vérifiez Source vars dans le formulaire de l'inventaire construit, vous pouvez trouver la définition du nouveau groupe « target_group ».

     plugin: constructed
    strict: true
    groups:
        target_group: account_alias | default("") == "product_dev"

Le groupe « target_group » n'était pas présent dans les inventaires East et West d'origine. Il a été créé par le plug-in d'inventaire construit lors de la mise à jour. 

Dans ce cas, les hôtes sont ajoutés au groupe lorsque le modèle jinja2 « account_alias | default("") == "product_dev" » prend une valeur de vérité (1, « "1" », ou True) pour un hôte donné. 

Au cours de la mise à jour, ces modèles sont générés par Ansible pour chaque hôte des inventaires d'entrée afin d'effectuer ces évaluations. Pour les inventaires d'entrée plus volumineux, la mise à jour peut prendre plusieurs minutes. 

Les inventaires construits sont automatiquement mis à jour avant l'exécution d'une tâche de tout modèle qui les utilise, mais si ces mises à jour prennent trop de temps, vous pouvez réduire la fréquence des mises à jour avec l'option Update cache timeout dans les paramètres de l'inventaire construit de l'interface utilisateur. Définissez cette option sur une valeur > 1 pour mettre en cache les résultats de la mise à jour de l'inventaire construit pendant ce délai en secondes.

Le modèle jinja2 utilisé pour créer le groupe « target_group » comprendra un hôte si, lors de l'inspection de cet hôte, la variable hostvar du groupe « account_alias » existe et est la même que « product_dev ». 

Il est nécessaire d'utiliser la syntaxe par défaut (« | default ») dans le cas où la variable n'est pas définie pour certains hôtes. 

L'option « strict: true » indique que le référencement d'une variable non définie entraînera l'échec de la mise à jour de l'inventaire, ce qui explique l'utilité de la syntaxe « | default ». 

Nous vous conseillons d'utiliser « | default » et le paramètre « strict » pour lever toute ambiguïté liée à une variable non définie.

La construction de groupes peut être utile pour ajouter des groupes à la volée auxquels des playbooks feront référence. Il est en effet parfois pratique de synthétiser des groupes à partir de variables d'hôtes, car ils permettent d'effectuer des actions qu'il est impossible de faire avec ces variables. Il n'est par exemple pas possible de les utiliser dans des modèles d'hôte (ici, avec l'option Limit). 

Observez tous les hôtes créés pour notre inventaire construit :

Dans cet exemple, nous voyons que host3 dans l'inventaire east et host5 dans l'inventaire west ne sont pas inclus. Cette absence s'explique par le fait que dans les inventaires d'entrée, ils se trouvent dans un groupe différent (account_4321) et la valeur du groupe « account_alias » ne correspond pas à la valeur « product_dev » que nous avons spécifiée. Notez que même si le groupe pour account_4321 a été importé dans l'inventaire construit, aucun hôte de ce groupe ne correspondait à nos exigences, de sorte que le groupe importé est vide dans l'inventaire construit.

L'entrée Source vars peut inclure des variables d'hôte, en plus d'ajouter des groupes.

Le référentiel Github d'Alan contient un autre exemple qui peut vous être utile. Dans le fichier construct.yml, nous déterminons « l'état » d'un hôte et l'attribuons à différents groupes selon qu'il s'agit d'un arrêt ou d'une partie d'un environnement particulier (dev). La source de vérité de ce fichier .yml peut provenir d'autres systèmes extérieurs à Ansible Automation Platform et peut être utilisée pour exécuter des processus automatisés à la volée sur des sous-ensembles d'hôtes.

 

Conseils de débogage

Reprenons l'exemple précédent. Lors du développement de l'inventaire construit, supprimez la valeur « Limit » et remplacez « Source vars » par le contenu suivant.

image3

Cette opération exécute un modèle semblable à « account_alias | default(“”) » et l'enregistre dans une variable nommée « effective_account_alias ». Lorsque la valeur Limit est vide, tous les hôtes peuvent être récupérés dans les inventaires d'entrée. Nous pouvons ainsi examiner en détail les critères d'inclusion sur chaque hôte, comme montré ci-dessous pour « host3 ».

image4

Ici, nous voyons que la valeur évaluée hostvar « effective_account_alias » est « sustaining » et non « product_dev ». 

Le plug-in d'inventaire construit propose un certain nombre d'autres options qui peuvent être utiles et efficaces. Reportez-vous à la documentation du plug-in à l'adresse https://docs.ansible.com/ansible/latest/collections/ansible/builtin/constructed_inventory.html pour en savoir plus.

Vous trouverez d'autres exemples dans le guide de l'utilisateur à l'adresse https://docs.ansible.com/automation-controller/4.4/html/userguide/inventories.html#ug-inventories-constructed.

 

Résumé :

Nous espérons que vous avez compris comment utiliser la nouvelle fonction d'inventaire construit dans Ansible Automation Platform. 

Les concepts sous-jacents tels que le modèle d'hôte et le plug-in d'inventaire construit sont des concepts généraux d'Ansible. Les utilisateurs pourront donc ajouter des groupes, des variables ou inclure des hôtes en fonction de critères variés et complexes.

Cette fonction offre les avantages suivants :

  • Création dynamique de groupes à partir de plusieurs sources de vérité
  • Possibilité de filtrer, d'analyser et de limiter les hôtes de plusieurs inventaires, et de les utiliser pour exécuter des processus automatisés
  • Possibilité d'utiliser des variables d'hôtes prédéfinies lors du filtrage
  • Possibilité pour plusieurs équipes de posséder leur propre inventaire et les métadonnées associées à leurs hôtes, à utiliser de manière centralisée via Ansible Automation Platform

 


À propos de l'auteur

Backend engineer for Red Hat Ansible Automation Platform - automation controller
Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Parcourir par canal

automation icon

Automatisation

Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements

AI icon

Intelligence artificielle

Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement

open hybrid cloud icon

Cloud hybride ouvert

Découvrez comment créer un avenir flexible grâce au cloud hybride

security icon

Sécurité

Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies

edge icon

Edge computing

Actualité sur les plateformes qui simplifient les opérations en périphérie

Infrastructure icon

Infrastructure

Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde

application development icon

Applications

À l’intérieur de nos solutions aux défis d’application les plus difficiles

Original series icon

Programmes originaux

Histoires passionnantes de créateurs et de leaders de technologies d'entreprise