Cours 1 - Présentation

Présentation d’Ansible

Ansible

Ansible est un gestionnaire de configuration et un outil de déploiement et d’orchestration très populaire et central dans le monde de l'infrastructure as code (IaC).

Il fait donc également partie de façon centrale du mouvement DevOps car il s’apparente à un véritable couteau suisse de l’automatisation des infrastructures.

Histoire

Ansible a été créé en 2012 (plus récent que ses concurrents Puppet et Chef) autour d’une recherche de simplicité et du principe de configuration agentless.

Très orienté linux/opensource et versatile il obtient rapidement un franc succès et s’avère être un couteau suisse très adapté à l’automatisation DevOps et Cloud dans des environnements hétérogènes.

Red Hat rachète Ansible en 2015 et développe un certain nombre de produits autour (Ansible Tower, Ansible container avec Openshift).

Architecture : simplicité et portabilité avec ssh et python

Ansible est agentless c’est à dire qu’il ne nécessite aucun service/daemon spécifique sur les machines à configurer.

La simplicité d’Ansible provient également du fait qu’il s’appuie sur des technologies linux omniprésentes et devenues universelles.

  • ssh : connexion et authentification classique avec les comptes présents sur les machines.
  • python : multiplateforme, un classique sous linux, adapté à l’admin sys et à tous les usages.

De fait Ansible fonctionne efficacement sur toutes les distributions linux, debian, centos, ubuntu en particulier (et maintenant également sur Windows).

Ansible pour la configuration

Ansible est semi-déclaratif c’est à dire qu’il s’exécute séquentiellement mais idéalement de façon idempotente.

Il permet d’avoir un état descriptif de la configuration:

  • qui soit auditable
  • qui peut évoluer progressivement
  • qui permet d'éviter que celle-ci ne dérive vers un état inconnu

Ansible pour le déploiement et l’orchestration

Peut être utilisé pour des opérations ponctuelles comme le déploiement:

  • vérifier les dépendances et l’état requis d’un système
  • récupérer la nouvelle version d’un code source
  • effectuer une migration de base de données (si outil de migration)
  • tests opérationnels (vérifier qu’un service répond)

Ansible à différentes échelles

Les cas d’usages d’Ansible vont de …:

  • petit:

    • … un petit playbook (~script) fournit avec le code d’un logiciel pour déployer en mode test.
    • … la configuration d’une machine de travail personnelle.
    • etc.

  • moyen:

    • … faire un lab avec quelques machines.
    • … déployer une application avec du code, une runtime (php/jav etc) et une base de données à migrer.
    • etc.

  • grand:

    • … gestion de plusieurs DC avec des produits multiples.
    • … gestion multi-équipes et logging de toutes les opérations grâce à Ansible Tower.
    • etc.

Ansible et Docker

Ansible est très complémentaire à docker:

  • Il permet de provisionner des machines avec docker ou kubernetes installé pour ensuite déployer des conteneurs.
  • Il permet une orchestration simple des conteneur avec le module docker_container.

Plus récemment avec l’arrivé d'Ansible container il est possible de construire et déployer des conteneurs docker avec du code ansible. Cette solution fait partie de la stack Red Hat Openshift. Concrêtement le langage ansible remplace (avantageusement ?) le langage Dockerfile pour la construction des images Docker.

Partie 1, Installation, configuration et commandes ad hoc.

Pour l’installation plusieurs options sont possibles:

  • Avec le gestionnaire de paquet de la distribution ou homebrew sur OSX:
    • version généralement plus ancienne (2.4 ou 2.6)
    • facile à mettre à jour avec le reste du système
    • Pour installer une version récente on il existe des dépots spécifique à ajouter: exemple sur ubuntu: sudo apt-add-repository --yes --update ppa:ansible/ansible
  • Avec pip le gestionnaire de paquet du langage python: sudo pip3 install
    • installe la dernière version stable (2.8 actuellement)
    • commande d’upgrade spécifique sudo pip3 install ansible --upgrade
    • possibilité d’installer facilement une version de développement pour tester de nouvelles fonctionnalité ou anticiper les migrations.

Pour voir l’ensemble des fichier installé par un paquet pip3 :

pip3 show -f ansible | less

Pour tester la connexion aux serveurs on utilise la commande ad hoc suivante. ansible all -m ping

Les inventaires statiques

Il s’agit d’une liste de machines sur lesquelles vont s’exécuter les modules Ansible. Les machines de cette liste sont:

  • Classées par groupe et sous groupes pour être désignables collectivement (exp executer telle opération sur)
  • La méthode connexion est précisée soit globalement soit pour chaque machine.
  • Des variables peuvent être définies pour chaque machine ou groupe pour contrôler dynamiquement par la suite la configuration ansible.

Exemple :

[all:vars]
ansible_ssh_user=elie
ansible_python_interpreter=/usr/bin/python3

[awx_nodes]
awxnode1 node_state=started ansible_host=10.164.210.101 container_image=centos_ansible_20190901

[dbservers]
pgnode1 node_state=started ansible_host=10.164.210.111 container_image=centos_ansible_20190901
pgnode2 node_state=started ansible_host=10.164.210.112 container_image=centos_ansible_20190901

[appservers]
appnode1 node_state=started ansible_host=10.164.210.121 container_image=centos_ansible_20190901
appnode2 node_state=started ansible_host=10.164.210.122 container_image=centos_ansible_20190901

Les inventaires peuvent également être au format YAML (plus lisible mais pas toujours intuitif) ou JSON (pour les machines).

Configuration

Ansible se configure classiquement au niveau global dans le dossier /etc/ansible/ dans lequel on retrouve en autre l’inventaire par défaut et des paramètre de configuration.

Ansible est très fortement configurable pour s’adapter à des environnement contraints. Liste des paramètre de configuration:

Alternativement on peut configurer ansible par projet avec un fichier ansible.cfg présent à la racine. Toute commande ansible lancée à la racine du projet récupère automatiquement cette configuration.

La commande ansible

  • version minimale : ansible <groupe_machine> -m <module> -a <arguments_module>

  • ansible all -m ping: Permet de tester si les hotes sont joignables et ansible utilisable (SSH et python sont présents et configurés).

  • version plus complète : ansible <groupe_machine> --inventory <fichier_inventaire> --become -m <module> -a <arguments_module>

Les modules Ansible

Ansible fonctionne grâce à des modules python téléversés sur sur l’hôte à configurer puis exécutés. Ces modules sont conçus pour être cohérents et versatiles et rendre les tâches courantes d’administration plus simples.

Il en existe pour un peu toute les tâches raisonnablement courantes : un slogan Ansible “Batteries included” ! Plus de 1300 modules sont intégrés par défaut.

  • ping: un module de test Ansible (pas seulement réseau comme la commande ping)

  • yum/apt: pour gérer les paquets sur les distributions basées respectivement sur Red Hat ou Debian.

... -m yum -a "name=openssh-server state=present"

  • systemd (ou plus générique service): gérer les services/daemons d’un système.

... -m systemd -a "name=openssh-server state=started"

  • user: créer des utilisateurs et gérer leurs options/permission/groupes

  • file: pour créer, supprimer, modifier, changer les permission de fichiers, dossier et liens.

  • shell: pour exécuter des commandes unix grace à un shell

Option et documentation des modules

La documentation des modules Ansible se trouve à l’adresse https://docs.ansible.com/ansible/latest/modules/file_module.html

Chaque module propose de nombreux arguments pour personnaliser son comportement:

exemple: le module file permet de gérer de nombreuses opérations avec un seul module en variant les arguments.

Il est également à noter que la plupart des arguments sont facultatifs.

  • cela permet de garder les appel de modules très succints pour les tâches par défaut
  • il est également possible de rendre des paramètres par défaut explicites pour augmenter la clarté du code.

Exemple et bonne pratique: toujours préciser state: present même si cette valeur est presque toujours le défaut implicite.

Commençons le TP1