Noeud de contrôle (Control Node) vs Noeuds gérés (Managed Nodes)
Distinguez clairement le rôle du noeud de contrôle (Control Node), la machine qui exécute Ansible, et des noeuds gérés (Managed Nodes), les systèmes cibles de l'automatisation. Une distinction clé pour bien démarrer avec Ansible.
Le noeud de contrôle : le chef d'orchestre de l'automatisation
Au sein de l'architecture Ansible, le noeud de contrôle (Control Node) occupe une position centrale et unique. C'est la machine sur laquelle Ansible est installé et depuis laquelle toutes les opérations d'automatisation sont initiées et gérées. Considérez-le comme le cerveau ou le poste de commande de votre infrastructure Ansible. Il héberge vos playbooks, vos inventaires, vos rôles et toute autre configuration nécessaire à Ansible.
Pour qu'une machine puisse agir en tant que noeud de contrôle Ansible, elle doit répondre à certains prérequis. Le plus important est la présence d'une installation fonctionnelle d'Ansible. Généralement, les systèmes d'exploitation de type Unix, tels que Linux (distributions comme Ubuntu, CentOS, RHEL, Debian) ou macOS, sont privilégiés comme noeuds de contrôle. Il est également possible d'utiliser Windows comme noeud de contrôle via le Sous-système Windows pour Linux (WSL), qui fournit un environnement Linux compatible.
Depuis le noeud de contrôle, vous exécutez les commandes `ansible` (pour les commandes Ad-Hoc) et `ansible-playbook` (pour exécuter les playbooks). C'est également depuis cette machine qu'Ansible établit des connexions, typiquement via SSH, vers les noeuds gérés pour y effectuer les tâches définies. Il est important de noter qu'Ansible n'a pas besoin d'être installé sur les noeuds gérés, ce qui est un avantage de son architecture sans agent.
Le noeud de contrôle doit disposer de Python (version 2.7 ou, de préférence, 3.5 et supérieures) car Ansible est écrit en Python. Il doit également avoir un accès réseau aux noeuds gérés et les informations d'authentification nécessaires (généralement des clés SSH) pour s'y connecter. Dans une configuration typique, un seul noeud de contrôle peut gérer des centaines, voire des milliers de noeuds distants. Pour des raisons de haute disponibilité ou de répartition de charge, des configurations plus avancées avec plusieurs noeuds de contrôle (souvent derrière un équilibreur de charge et utilisant des outils comme Ansible Tower/AWX) peuvent être mises en place, mais le concept de base reste le même : une source centrale pour l'automatisation.
Les noeuds gérés : les cibles de vos actions d'automatisation
Les noeuds gérés (Managed Nodes), parfois appelés "hôtes" (hosts) dans la terminologie Ansible, sont les systèmes, serveurs, équipements réseau ou tout autre dispositif que vous souhaitez configurer, administrer et automatiser à l'aide d'Ansible. Ce sont les destinataires des instructions envoyées depuis le noeud de contrôle. Ansible peut interagir avec une grande variété de systèmes, allant des serveurs Linux et Windows aux équipements réseau (commutateurs, routeurs), en passant par les plateformes cloud et les conteneurs.
Contrairement au noeud de contrôle, les noeuds gérés n'ont pas besoin d'avoir Ansible installé. C'est l'un des principes fondamentaux de l'architecture "agentless" d'Ansible. Cependant, ils doivent remplir quelques conditions pour être gérables. La principale est de disposer d'un interpréteur Python. Pour la plupart des modules Ansible, Python 2 (version 2.6 ou ultérieure) ou Python 3 (version 3.5 ou ultérieure) est requis sur le noeud géré. Ansible transfère temporairement les modules (qui sont des scripts Python) sur le noeud géré, les exécute, puis récupère les résultats.
En plus de Python, le noeud géré doit être accessible via un protocole de communication supporté. Pour les systèmes Linux/Unix, il s'agit quasi exclusivement de SSH. Le serveur SSH doit être actif et configuré pour permettre les connexions depuis le noeud de contrôle, idéalement via une authentification par clé publique pour éviter les saisies de mot de passe. Pour les systèmes Windows, le protocole utilisé est WinRM (Windows Remote Management). Le service WinRM doit être activé et configuré sur les hôtes Windows pour qu'Ansible puisse les gérer.
La liste des noeuds gérés est définie dans le fichier d'inventaire Ansible. Ce fichier indique à Ansible quelles machines il peut contacter et comment s'y connecter. Il est possible d'avoir un grand nombre de noeuds gérés, organisés en groupes pour faciliter leur administration. Chaque noeud géré peut avoir des variables spécifiques qui influencent la manière dont les playbooks sont appliqués. La flexibilité d'Ansible lui permet de gérer des environnements hétérogènes comprenant différents types de systèmes d'exploitation et de dispositifs au sein d'un même inventaire.