SUSE Manager 4.2 est disponible depuis peu et apporte son lot de nouveautés.
L'une des nouvelles fonctionnalités encore en Tech Preview est la capacité d'intégrer et de gérer un noeud Ansible.

Intégration Ansible

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.

Architecture de communication

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.

SUSE Manager s'interface avec le Salt Master via son API. Le Master Salt transmet les ordres de SUSE Manager à ses minions.

Ansible ?

Salt étant lui-même un outil de gestion de configuration, les fonctionnalités apportées par ce dernier sont également disponible dans SUSE Manager.

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.

• Les communications Salt passent par un agent dédié, un Salt Minion.
  
• Ansible utilise SSH, et s'authentifie sur les serveurs avec une clé SSH.
  

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

Ansible X 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 :

• Ansible dispose de son propre inventaire, on ne peut donc pas déclencher un playbook Ansible sur une liste de minion Salt..
  Il n'est donc pas possible de faire quelque chose de ce genre :

salt -G 'role:whatever' ansible.playbooks myplaybook

• Ansible sert donc ici simplement de proxy d'exécution pour l'exécution de playbook.

  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.

Ansible X Salt X SUSE Manager

L'objectif de l'intégration Ansible est de permettre à SUSE Manager de piloter un "Ansible Control Node".

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 planifier l'exécution un playbook à une heure spécifique, ou en l'intégrant à une Action Chain de SUSE Manager.

• 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.
  

Wishlist

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.

Comment ça marche ?

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.