Dernière mise à jour : 19/11/2022 à 16h25
Table des matières
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 :
Code BASH :
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 :
Code BASH :
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
Code BASH :
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:
Code BASH :
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 :
Code BASH :
ansible-config init --disabled > ansible.cfg
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 :
Code BASH :
ansible-config --viewQuelques 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 :
Code BASH :
[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
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 :
Code JSON :
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"
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.
Code BASH :
ansible-inventory -i inventory.yml --list
renverra l'inventaire avec -i le fichier d'inventaire. Voici la forme de restitution :
Code TEXT :
{
"_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.
Code TEXT :
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 :
Code TEXT :
@all: |--@debian: | |--srv1 | |--srv3 | |--srv4 | |--srv5 | |--srv6 |--@ubuntu: | |--srv10 | |--srv8 | |--srv9 |--@ungrouped:
L'option --vars ajouté à l'option --graph ajoute les variables.
Code TEXT :
@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 :
Code TEXT :
- 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 :
Code BASH :
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 :
Code BASH :
ansible -i 00_inventory.yml transmission -b -K --become-method=su -m apt -a "name=htop state=present"
Via un playbook :
Code TEXT :
- name: "Installation de htop"
hosts: transmission
become: yes
become_method: su
tasks:
- name: "Installation"
apt:
name: htop
state: present