Aller au contenu

Ansible

ansible

Ici, je vais noter ce que j'apprend sur Ansible et ce qui me semble pertinent. Peut-être que si cet article devient trop long, il sera plus tard divisé en plusieurs...

Installation

Selon le site d'Ansible, il existe plusieurs méthodes :

  • les binaires
  • les dépôts (apt, dnf...)
  • pip

J'ai commencé par installé via apt mais l'installation ne m'a pas créé de dossier /etc/ansible. J'ai donc essayé via la commande pip mais le résultat est identique.

Configuration de ssh

Utilisation de la clé privée

Il est nécessaire de pouvoir accéder en ssh à ses serveurs que l'on veut pouvoir gérer via ansible. Il faut pour cela utiliser la méthode de clé privée/publique. Rien de compliqué, plein de sites en parlent...

Quelques rappels de commandes.

Pour générer les clés :

ssh-keygen -t ecdsa -b 521

Cette commande permet de générer une clé de type ecdsa avec la longueur maximale. La page de manuel de ssh-keygen donne des infos sur les différentes types et les longueurs de clé que l'on peut générer en fonction de la méthode choisie.

Il est possible de générer une clé sans phrase de passe mais ce n'est pas le plus sécurisé...

Pour copier la clé sur le serveur distant :

ssh-copy-id user@ip-serveur-distant -p port-serveur-ssh

Utilisation des noms d'hôte

Afin de simplifier les choses, il est conseiller de bien configurer ssh pour que la connexion soit simplifiée. Pour cela, créer ou éditer le fichier ~/.ssh/config

Host rpi3
    HostName 192.168.1.51
    Port 7985
    User pi

L'ajout de ce type de bloc dans le fichier permet de spécifier pour un nom d'hôte : l'adresse ip ou le hostname configuré en dns, le port si on n'utilise pas le port 22, le nom d'utilisateur.

Dans le cas contraire, il sera nécessaire de configurer ces paramètres dans ansible via l'inventory.

Ansible en mode "CLI"

On peut utiliser "manuellement" en ligne de commande.

Par exemple:

ansible transmission -m ping -i hosts.yaml --key-file /home/remi/.ssh/key_asus_fedora
  • -i permet de spécifier le fichier d'inventaire à utiliser, de base il utilise le fichier /etc/ansible/hosts (où le fichier défini dans ansible.cfg, voir paragraphe dédié)
  • -m permet d'appeler un module, ici le module ping
  • transmission est l'hôte sur lequel on exécute la commande, défini dans le fichier d'inventaire
    • --key-file permet de spécifier la clé privée à utiliser (cf. les notions après)
  • -u permet de préciser l'utilisateur distant
  • -b permet de passer les commandes avec une élévation de privilèges (par défaut avec sudo. Pour modifier, on peut utiliser le paramètre --become-method=su pour utiliser su plutôt que sudo)
  • -k permet de demander le mot de passe de l'utilisateur (si on n'utilise pas la clé privée)
  • -K permet de demander le mot de passe lié à l'élévation de privilège
  • -C permet de tester la commande sans faire les actions
  • -D permet de retourner les modifications effectuées

Quelques notions à avoir en tête

Lorsqu'on exécute ansible, la connexion se fait avec l'utilisateur courant donc si la clé privée sur le serveur distant est celle de remi, lancer une commande ansible avec root ne fonctionne pas... Il faut alors spécifier manuellement la clé (avec l'option --key-file de la commande ansible

ansible.cfg

Localisation du fichier

ansible.cfg est le fichier de configuration d'ansible.

Si celui-ci n'est pas présent dans /etc/Ansible/, il est possible de le générer via la commande :

ansible-config init --disabled > ansible.cfg

Note

Cette commande n'est valable que depuis ansible 2.12. Pour les versions antérieures, on peut aller chercher des exemples de fichier ansible.cfg sur le github du projet. Par exemple pour la version 2.10 : Github de la version 2.10

Ce fichier gérera tout Ansible mais il est aussi possible de faire des fichiers plus spécifiques dans le dossier home (.Ansible/ansible.cfg) qui ne s'appliquera qu'à un utilisateur donné ou dans le dossier d'un playbook pour qu'il ne s'applique qu'à ce playbook.

On peut dans ce fichier modifier la localisation du fichier hosts mais ce n'est pas conseillé (voir ci-après)

Pour voir le fichier de configuration pris en compte, on peut utiliser la commande suivante :

ansible-config --view

Quelques paramètres intéressants

Voici quelques paramètres intéressants à modifier dans ansible.cfg :

S'affranchir de la validation du fingerprint lors de la première connexion : 

[defaults]
host-key-checking = false

L'inventory

Les inventory vont permettre de lister les serveurs cibles d'Ansible. On peut y spécifier notamment :

  • Les hôtes (par IP ou pas hostname)
  • Les ports ssh des hôtes
  • Les idées avec lesquels se connecter aux hôtes

Question

A vérifier : les users et port doivent-ils être défini dans les inventory ou la config ssh suffit-elle

Le fichier inventory sera au format YAML, plus pratique (.yml ou .yaml).

Exemple d'un fichier d'inventory :

all:
  hosts:                      # en dessous, les serveurs directement rattachés à all
    srv1:                     # exemple d'un serveur appelé par son hostname
  children:                   # en dessous, des groupes enfants du groupe all
    debian:                   # exemple d'un groupe nommé debian
       hosts:                 # en dessous la liste des machines du groupe debian
          srv1:               # une machine nommée serv1
          srv[3-6]:           # les machines nommées serv3, serv4, serv5 et serv6
       vars:                  # en dessous les variables qui s'appliquent au groupe debian
          var1: "debian"      # une variable nommée var1 qui vaut "debian"
    ubuntu:                   # un groupe nommé Ubuntu
       hosts:
          srv8:
             vars:            # en dessous des variables qui ne s'appliquent qu'à la machine srv8
                var1: "Ubuntu"
          srv9:
          srv10:
       vars:                  # en dessous des variables qui s'appliquent à l'ensemble du groupe "Ubuntu"
          var1: "linux"

Warning

On met ici comme exemple la possibilité de définir des variables dans l'inventory mais ce n'est pas le meilleur endroit où le faire. Il est préférable d'utiliser des dossiers group_vars et host_vars pour cela. On peut ensuite soit créer des fichier avec le nom des groupes soit des dossiers avec le nom des groupes puis un fichier avec les variables à l'intérieur du fichier Un fichier par groupe avec les variables à l'intérieur : 

 00_inventory.yml
📁 group_vars
├──  debian.yml
└──  ubuntu.yml
📁 host_vars
└──  srv8.yml

La commande "ansible-inventory"

Cette commande permet d'afficher de différentes manières l'inventory.

ansible-inventory -i inventory.yml --list

renverra l'inventaire avec -i le fichier d'inventaire. Voici la forme de restitution :

{
    "_meta": {
        "hostvars": {
            "srv1": {
                "var1": "debian"
            },
            "srv10": {
                "var1": "linux"
            },
            "srv3": {
                "var1": "debian"
            },
            "srv4": {
                "var1": "debian"
            },
            "srv5": {
                "var1": "debian"
            },
            "srv6": {
                "var1": "debian"
            },
            "srv8": {
                "var1": "Ubuntu"
            },
            "srv9": {
                "var1": "linux"
            }
        }
    },

L'option --yaml permet d'afficher en format yml. Cela revient à afficher le fichier inventory.yml en y ajoutant les variables des group_vars et host_vars.

all:
  children:
    debian:
      hosts:
        srv1:
          var1: debian
        srv3:
          var1: debian
        srv4:
          var1: debian
        srv5:
          var1: debian
        srv6:
          var1: debian
    ubuntu:
      hosts:
        srv10:
          var1: linux
        srv8:
          var1: Ubuntu
        srv9:
          var1: linux
    ungrouped: {}

L'option --graph à la place de --list change le format de restitution :

@all:
  |--@debian:
  |  |--srv1
  |  |--srv3
  |  |--srv4
  |  |--srv5
  |  |--srv6
  |--@ubuntu:
  |  |--srv10
  |  |--srv8
  |  |--srv9
  |--@ungrouped:

L'option --vars ajouté à l'option --graph ajoute les variables.

@all:
  |--@debian:
  |  |--srv1
  |  |  |--{var1 = debian}
  |  |--srv3
  |  |  |--{var1 = debian}
  |  |--srv4
  |  |  |--{var1 = debian}
  |  |--srv5
  |  |  |--{var1 = debian}
  |  |--srv6
  |  |  |--{var1 = debian}
  |  |--{var1 = debian}
  |--@ubuntu:
  |  |--srv10
  |  |  |--{var1 = linux}
  |  |--srv8
  |  |  |--{var1 = Ubuntu}
  |  |--srv9
  |  |  |--{var1 = linux}
  |  |--{var1 = linux}
  |--@ungrouped:

Le playbook

Création d'un playbook

Le playbook s'écrit au format yaml. Il peut se mettre à la racine du dossier ansible ou dans un sous-dossier. Il permet de faire le lien entre l'inventory et les tâches à réaliser.

Pour y mettre directement des tasks, on peut l'écrire de cette façon :

- name: "Mise à jour serveurs Debian"
  hosts: serveurs 
  become: yes
  become_method: su
  tasks:
    - name: "Update cache"
      apt:
        update_cache: yes
    - name: "Full-upgrade"
      apt:
        upgrade: full
    - name: "Autoremove & purge"
      apt:
        autoremove: yes
        purge: yes
    - name: "Vérification de la nécessité d'un reboot"
      register: reboot_required_file
      stat:
        path: /var/run/reboot-required
    - name: "Reboot si besoin"
      reboot:
        msg: "Reboot via Ansible"
        connect_timeout: 10
        reboot_timeout: 300
        test_command: uptime
      when:  reboot_required_file.stat.exists

Utilisation du playbook

Pour lancer un playbook, on utilise la commande ansible-playbook. Par exemple :

ansible-playbook -i ../00_inventory.yml -K -C upgrade.yml

upgrade.yml est le chemin vers le playbook.

Quelques modules

Lorsqu'on lance un module (avec -m), on lui passe les paramètres avec l'option (-a puis entre " " les paramètres). Voir ci-dessous quelques exemples.

apt

Le module apt permet de gérer les paquets. Les principaux paramètres sont :

  • name : le nom du paquet
  • state : le statut (present, absent, latest,...)

En CLI :

ansible -i 00_inventory.yml transmission -b -K --become-method=su -m apt -a "name=htop state=present"

Via un playbook :

- name: "Installation de htop"
  hosts: transmission  
  become: yes  
  become_method: su  
  tasks:
    - name: "Installation"
      apt:                     
        name: htop
        state: present