Depuis quelques années maintenant, SUSE Manager intègre un master Salt dans son architecture. On est donc en droit de demander le rôle que joue cette intégration à Ansible.
Avant de rentrer le détail, commençons donc par décrire les méthodes utilisée par SUSE Manager pour communiquer avec les différents composants qui le constitue.
SUSE Manager est un outil en mesure de piloter plusieurs milliers de machines. Pour arriver à ce résultat, SUSE a intégré Salt dans sa solution et l'utilise comme média de communication.
Pour rappel, Salt est un outil de gestion de configuration disposant de sa propre architecture, avec un serveur maître, le Salt Master, et des agents à déployer sur les serveurs, appelé Minions.
Dans une architecture SUSE Manager, le serveur principal est un Salt Master et chaque serveur est un minion. Toute opération sur un serveur est déclenchée au travers de state Salt et de module d'exécution.
Salt couvre les mêmes fonctionnalités qu'Ansible (et plus encore), mais dans certains environnement, de nombreux playbooks peuvent déjà avoir été développé en interne.
Bien heureusement, Ansible et Salt peuvent parfaitement fonctionner en parallèle, sans aucun conflit.
Le module ansiblegate permet même à Salt de s'interfacer avec Ansible, il est ainsi possible de demander à un minion de lancer des playbooks Ansible.
Note : Le module ansiblegate fait partie des contributions de SUSE au code de Salt
Sur le principe, on peut effectivement utiliser Salt, notamment ses capacités d'orchestrations, pour déclencher des playbooks.
L'intégration a cependant ses limites :
salt -G 'role:whatever' ansible.playbooks myplaybook
L'ensemble est donc utile dans certaines circonstances, mais on peut probablement mieux faire.
Note : Le sujet ansiblegate est un sujet à lui tout seul, et sera peut-être abordé plus en détail dans un autre post.
L'objectif de l'intégration Ansible est de permettre à SUSE
Une machine est donc enregistrée dans SUSE Manager, avec un salt-minion.
On lui donne ensuite le rôle de Ansible Control Node en activant l'option dans les add-ons.
Un highstate se charge alors d'installer les pré-requis nécessaires au rôle.
Une fois le rôle déployé, un onglet Ansible fait son apparition et il est alors possible d'accéder à une interface où l'on précisera l'emplacement des playbooks et les fichiers d'inventaires à utiliser.
Il est ensuite possible de visualiser le contenu de l'inventaire et de lister les différents playbooks. On peut également exéute l'un des playbooks en sélectionnant le fichier d'inventaire à la volée.
Le Salt Master envoie ensuite le job au noeud Ansible, qui exécute le playbook avec le fichier d'inventaire passé en paramètre.
Suse nous donne accès à la Tech Preview dans cette nouvelle version.
Pour le moment, il est possible de :
De définir à la volée le fichier d'inventaire à utiliser pour l'exécution du playbook
Les prochaines features annoncées sont par SUSE sont :
L'ajout et l'édition de playbook Ansible dans SUSE Manager
La création de template de job pour permettre de passer des paramètres aux playbooks Ansible.
L'exécution conditionnelle.
L'intégration Ansible en est encore à ses débuts et il sera intéressant d'observer ses futures évolutions.
L'un des points d'améliorations qui serait, à notre sens, critique, concerne les fichiers d'inventaires.
L'inventaire Ansible est un fichier listant les différents serveurs par FQDN ou adresse IP, regroupé dans différentes sections.
[webserver]
webserver1.domain.fr
webserver2.domain.fr
[dbserver]
dbserver1.domain.fr
dbserver2.domain.fr
Ces sections sont parfois réutilisés dans les playbooks, ce qui permet un déploiement multi-serveur pour une application donnée. Il n'est donc pas toujours évident de le remplacer.
Cependant, SUSE Manager dispose de son propre inventaire de serveur, maintenu en temps réel. Il ne serait donc pas absurde d'imaginer réutiliser l'inventaire SUSE Manager pour le déploiement de playbooks.
Avec un peu de travail, il serait même envisageable de remplacer les sections du fichier d'inventaire par des System Groups SUSE Manager.
Pour les curieux, SUSE Manager ajoute un state ansible au hightstate
salt 'ansiblectrlnode' state.show_top
sles15sp2-10-10-0-174:
----------
base:
- util.noop
- channels
- certs
- packages
- custom
- custom_groups
- custom_org
- formulas
- services.salt-minion
- services.docker
- services.kiwi-image-server
- ansible
Le state en lui-même est assez basique, il se contente de déployer ansible
salt 'ansiblectrlnode' state.show_sls ansible --output=yaml
sles15sp2-10-10-0-174:
mgr_ansible_installed:
__env__: base
__sls__: ansible
pkg:
- pkgs:
- ansible
- installed
- order: 10000
Remarque : 16/07/21 - Il s'agit encore du début de la Tech Preview, le code est susceptible d'évoluer.
Le code d'ansiblegate a été modifié pour intégrer deux fonctions, ansible.targets et ansible.discover_playbooks permettant l'analyse du fichier d'inventaire et la découverte des playbooks dans un répertoire.
#Source: /usr/share/susemanager/py27-compat/salt/modules/ansiblegate.py
def discover_playbooks(path=None,
locations=None,
playbook_extension=None,
hosts_filename=None,
syntax_check=False):
def targets(**kwargs):
Suse Manager 4.2 ouvre de nouvelles portes sur l'intégration de la solution Ansible autour d'une seule et unique console. Un atout !
N'hésitez pas à venir assister à notre prochain webinaire le 27 Juillet ou le 9 Septembre prochains. Inscription sur notre page évènements.