Ansible

Ensemble des recettes de déploiement Ansible pour les serveurs du Crans.

Ces politiques de déployement nécessite Ansible 2.7 ou plus récent. Le paquet dans Debian Buster est suffisamment à jour, sinon vous pouvez l'obtenir de la façon suivante :

pip3 install --user ansible

Exécution d'un playbook

Pour appliquer le playbook base.yml :

ansible-playbook --ask-vault-pass base.yml

Il est souhaitable de faire un test avant avec --check si on a des doutes !

FAQ

Ansible 101

Si vous n'avez jamais touché à Ansible avant, voilà une rapide introduction.

Inventory : c'est le fichier hosts d'inventaire. Il contient la définition de chaque machine et le regroupement.

Quand on regroupe avec un :children en réalité on groupe des groupes.

Chaque machine est annoncée avec son DNS. Il faut pouvoir SSH sur cette machine avec ce DNS, car c'est ce qu'Ansible fera.

Playbook : c'est une politique de déploiement. Il contient les associations des rôles avec les machines.

L'idée au Crans est de regrouper par thême. Exemple, le playbook monitoring.yml va contenir toutes les définitions machines-rôles qui touchent au monitoring. Cela permet de déployer manuellement tout le monitoring sans toucher au reste.

Rôle : un playbook donne des rôles à des machines. Ces rôles sont tous dans le dossier roles/. Un rôle installe un service précis sur un service.

Il est préférable d'être atomique sur les rôles plutôt d'en coder un énorme qui sera difficilement maintenable.

Exemples de rôle : activer les backports pour ma version de Debian, installer NodeJS, déployer un serveur prometheus, déployer une node prometheus…

Tâche : un rôle est composé de tâche. Une tâche effectue une et une seule action. Elle est associée à un module Ansible.

Exemples de tâche : installer un paquet avec le module apt, ajouter une ligne dans un fichier avec le module lineinfile, copier une template avec le module template…

Une tâche peut avoir des paramètres supplémentaires pour la réessayer quand elle plante, récupérer son résultat dans une varible, mettre une boucle dessus, mettre des conditions…

N'oubliez pas d'aller lire l'excellent documentation de RedHat sur tous les modules d'Ansible !

Mettre sa clé SSH sur une machine

ssh-copy-id -i ~/.ssh/id_rsa_crans.pub zamok.crans.org

Ignorer la fingerprint ECDSA du serveur (dangereux !)

Il faut changer la variable d'environnement suivante : ANSIBLE_HOST_KEY_CHECKING=0.

Configurer la connexion au bastion

Envoyer son agent SSH peut être dangereux (source).

On va utiliser plutôt ProxyJump. Dans la configuration SSH :

# Use a key to log on all Crans servers
# and use a bastion
Host 10.231.136.* *.adm.crans.org
    IdentityFile ~/.ssh/id_rsa_crans
    ProxyJump passerelle.crans.org

Il faut savoir que depuis Ansible 2.5, des connexions persistantes sont créées vers les serveurs puis détruites à la fin de l'exécution.

Gestion des groupes de machines

Dans BCFG2 on avait des groupes selon la version de Debian. Avec Ansible on peut utiliser en condition ansible_distribution_release == 'stretch' par exemple. Donc il n'y a plus trop d'intêret de séparer selon la version de Debian les machines.

Sinon pour les autres groupes, vous allez retrouver une configuration similaire à BCFG2 avec par exemple les groupes crans-vm, crans… Pour en savoir plus je vous invite à lire le fichier hosts.

Pour les fonctions (proxy-server, dhcp-dynamique…) il a été choisi de ne pas faire de groupe particulier mais plutôt de sélectionner les machines pertinentes directement dans les playbooks.

Lister tout ce que sait Ansible sur un hôte

Lors du lancement d'Ansible, il collecte un ensemble de faits sur les serveurs qui peuvent ensuite être utilisés dans des variables. Pour lister tous les faits qu'Ansible collecte nativement d'un serveur on peut exécuter le module setup manuellement.

ansible -i hosts zamok.crans.org -m setup --ask-vault-pass