01 Jan 0001, 00:00

Introduction

Ansible est exécuté sur un poste local (typiquement un pc de bureau), et va servir à gérer un ou plusieurs postes distants (typiquement des serveurs).

Ceci ne nécessite pas de démon sur les serveurs à gérer ; la connexion se fait via ssh.

Installation

bullseye : sudo apt install ansible Dans bookworm, séparation entre ansible-core (binaires) et ansible (?). Le paquet ansible dépend de ansible-core.
Numéros de version différents : ansible 6 et ansible-core 2.13 en novembre 2022.

Pattern

https://docs.ansible.com/ansible/latest/inventory_guide/intro_patterns.html

À chaque appel, ansible se connecte à un hote (ou groupe d’hotes). On appelle ces cibles le “pattern”. Un pattern peut être un hote, une addresse IP, un groupe, un ensemble de groupe, ou un FQDN.

Par défaut, le seul pattern accessible est l’hote implicite localhost ou 127.0.0.1 (et PAS 127.0.1.1). Ce pattern n’est pas inclus lors d’un appel au groupe “all”.

Pour pouvoir être utilisé, chaque pattern DOIT être entré dans un inventaire (même les IP/FQDN).

On peut utiliser des wildcard, regex et autres pour définir un pattern.

Inventaire

https://linux.goffinet.org/ansible/comprendre-inventaire-ansible/

Constitué d’hôtes, de groupes d’hôtes, et de variables associées.
2 groupes spéciaux : all (tous les éléments) et ungrouped (tous les éléments n’ayant aucun autre groupe que all)

Les éléments d’un inventaire sont les éléments sur lesquels vont être effectués les modules ansible.

Nomenclature parent/enfant ?

On peut imbriquer des groupes.

On peut définir un inventaire au moment de l’appel de la commande (1 ou plusieurs hotes) :
ansible -i '127.0.0.1,'
Il faut préciser la virgule, même si 1 seul hôte, sinon il cherche un fichier nommé 127.0.0.1 dans le répertoire courant.

Modules

Les modules ansibles sont des scripts pré-écrits, réutilisables, qui servent généralement à remplir une fonction précise. On peut créer ses propres modules (?)

La syntaxe pour appeler un module est :
-m module_name -a module_args

Voici quelques modules inclus dans l’installation d’ansible :

command : c’est le module par défaut. Va exécuter, via ssh, la commande sur l’hôte. Par exemple ansible localhost -a "whoami"
Ne passe pas par un shell ; exécute directement la commande. En conséquence, un certain nombre de fonctionnalités nbe sont pas disponibles, par exemple les redirecteurs (> etc), l’expansion de variables, l’environnement utilisateur etc.
https://serverfault.com/questions/958952/ansible-task-write-to-local-log-file
shell

Différences entre les modules command et shell

ping : essaye de se connecter en ssh au pattern, et vérifie que python est accessible ; retourne "ping": "pong" en cas de succès ; Retourne "changed": false en tous les cas.
En cas d’échec, "unreachable": true (ou autre ?)

Syntaxe

ansible pattern -i inventory -m module

Playbook

Ensemble/organisation de commandes ad-hoc ? Playbook est à commande ansible ce qu’un script est à une commande bash ?

Config

ansible-config list pour lister tous les éléments de configuration

/etc/ansible/ansible.cfg ~/ansible.cfg (override la précédente)

HOTES

ansible peut être utilisé sur un client local, et se connecter à un “hote”. Les hotes doivent être définis. L’hote “localhost” existe par défaut.

ansible –list-hosts localhost

dans inventory -> playground, sous sandbox, on spécifie l’hostanme/ip du serveur, et le user utilisé)

roles https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html

Brouillons d'un g33k