Tutoriel Ansible rapide

Ligne de commande ad hoc ansible

La ligne de commande ansible permet d’utiliser un seul module Ansible sans écrire de playbook. Utile pour des commandes ponctuelles, c’est aussi une très bonne façon de vérifier qu’Ansible peut fonctionner sur un serveur donné et de tester différents arguments CLI qui fonctionneront à la fois avec les commandes ansible et ansible-playbook.

Utilisez la ligne de commande ansible avec le module ping pour vérifier qu’Ansible peut fonctionner sur un serveur cible :

ansible --module-name ping --inventory 1.2.3.4, all

Arguments :

• --module-name ping : demander à la ligne de commande Ansible d’exécuter le module Ansible ping,
• --inventory 1.2.3.4, : demander à la ligne de commande Ansible de ne pas utiliser de fichier d’inventaire mais une seule IP,
• all : demander à la ligne de commande Ansible d’exécuter le module sur tous les hôtes de l’inventaire.

Voir plus dans la documentation des commandes ad hoc Ansible

Ligne de commande ansible-playbook

Un playbook est une structure de données YAML qui contient au moins un play. Un play définit le contexte dans lequel vous pouvez orchestrer un groupe de tâches au moyen d’appels de modules paramétrés.

- hosts: all
  tasks:
  - ping:

Vous pouvez l’exécuter avec :

ansible-playbook -i 1.2.3.4, play.yaml

Voir l’introduction aux playbooks Ansible pour plus de détails.

Modules

Ansible fournit une liste de modules extrêmement riche que vous pouvez utiliser. Référez-vous à la documentation Ansible pour la liste complète des modules.

Exemple de script YAML de base, ou playbook, utilisant les modules Ansible file et shell :

- hosts: all
  tasks:
  - file:
      path: /etc/old_file
      state: absent
  - shell: /some/command some cmd args

Équivalent CLI de la première tâche :

ansible --module-name file --args 'path=/etc/old_file state=absent' -i 1.2.3.4, all

Dans l’exemple d’argument freeform avec le module Ansible shell, les arguments doivent être passés depuis la clé args de la tâche :

ansible --module-name shell --args '/some/command some cmd args' -i 1.2.3.4, all

Authentification

Ansible fonctionne au-dessus de différents protocoles, SSH étant le favori pour piloter des serveurs Linux. Vous pouvez le configurer à la volée en CLI avec :

• --user : nom d’utilisateur SSH à utiliser pour se connecter au serveur
• --become : demander à Ansible de devenir root avec sudo
• --extra-vars : déclarer des variables d’exécution supplémentaires
• --extra-vars 'ansible_ssh_pass=...' : mot de passe SSH de connexion
• --extra-vars 'ansible_sudo_pass=...' : mot de passe à utiliser pour sudo sur le serveur
• --ask-sudo-pass : identique au précédent mais interactif
• --extra-vars 'ansible_ssh_common_args=-oStrictHostKeyChecking=no' : demander à Ansible de travailler sans vérifier la clé d’hôte du serveur SSH

Supposons donc que nous voulons exécuter une commande shell avec sudo après nous être connectés sur 1.2.3.4 comme localadm avec un mot de passe, de façon non interactive. Nous pouvons utiliser quelque chose comme :

ansible --module-name shell --args '/some/command some cmd args' --user localadm --become --extra-vars 'ansible_ssh_pass=SomePassword*' --extra-vars 'ansible_sudo_pass=SomePassword*' --extra-vars 'ansible_ssh_common_args="-oStrictHostKeyChecking=no' -i 1.2.3.4, all

Ou :

ansible -m shell -a '/some/command some cmd args' --user localadm --become -e 'ansible_ssh_pass=SomePassword*' -e 'ansible_sudo_pass=SomePassword*' -e 'ansible_ssh_common_args="-oStrictHostKeyChecking=no' -i 1.2.3.4, all

Variables et templating

Ansible utilise Jinja2 pour le templating :

- hosts: all
  vars:
    your_var: /some/command some cmd args
  tasks:
  - file:
      path: /etc/old_file
      state: absent
  # note that we quote the string value here so that Jinja2 doesn't try to
  # intercept the curly braces {}
  - shell: "{{ your_var }}"

Lire davantage sur l’utilisation des variables avec Ansible et le templating avec Ansible

Chiffrement AES256 des variables avec ansible-vault

Vous pouvez aussi chiffrer des variables.

Sauf si vous travaillez sur un serveur de test avec un mot de passe par défaut, vous voulez probablement avoir vos mots de passe secrets chiffrés sur disque plutôt qu’écrits dans un playbook ou dans l’historique shell.

Créez un fichier de variables secrètes avec chiffrement par mot de passe AES256 :

ansible-vault create secrets.yaml

La commande ci-dessus ouvre un éditeur après vous avoir demandé un mot de passe. Écrivez vos secrets en syntaxe YAML ainsi :

ansible_ssh_pass: Aoeuidhtns*
ansible_sudo_pass: '{{ ansible_ssh_pass }}'

Comme vous pouvez le voir, nous utilisons la syntaxe de templates Jinja pour l’expansion de paramètres, afin de réutiliser une variable par exemple. Elle est rendue au moment de l’exécution d’Ansible et prend en charge l’ensemble des fonctionnalités Jinja. Voir la documentation des filtres de playbooks pour plus de détails.

Quoi qu’il en soit, le contenu sera écrit sur disque après chiffrement AES256 par la commande ansible-vault, et ressemblera à peu près à ceci dans secrets.yaml :

$ANSIBLE_VAULT;1.1;AES256
30626463636663623531376137373635616539396435613432353434313233653466666234613764
65653435306633376266323932663363663766356333393438343035353436356566396363326536
61326530303736656536636132663064303432336366623166303166653835303332623738373765
3834

Ce qui signifie que vous devrez utiliser ansible-vault edit et les autres commandes ansible-vault pour travailler avec le contenu déchiffré.

Maintenant, écrivez un playbook play.yaml en clair qui inclut votre fichier secrets.yaml ainsi, de façon équivalente à la ligne de commande ci-dessus :

- hosts: localhost
  user: localadm
  become: true
  vars:
    ansible_ssh_common_args: '-oStrictHostKeyChecking=no'
  vars_files:
  - secrets.yaml
  tasks:
  - shell: /some/command some cmd args

Cependant, Ansible aura besoin du mot de passe pour déchiffrer les variables vaultées, que vous pouvez passer avec :

• --ask-vault-password pour une demande de mot de passe interactive
• --vault-id /path/to/password pour stocker le mot de passe dans un fichier

Voir plus dans la documentation Ansible Vault

Rôles

Un rôle Ansible est un groupe de tâches.

Créez-en un avec ansible-galaxy role init test_role.

Éditez le fichier créé test_role/tasks/main.yml avec le contenu suivant :

- shell: 'date > {{ path_variable }}'
- file:
    path: '{{ path_variable }}'
    state: absent

Ensuite, incluez le test_role dans un playbook avec la liste roles :

- hosts: all
  roles:
  - role: test_role
    path_variable: /example_path
  - role: test_role
    path_variable: /other_path_example

Ce playbook exécutera les tâches du rôle deux fois avec des valeurs différentes pour path_variable.

Autre syntaxe que vous pourriez aussi voir, avec un mot-clé intermédiaire vars:, qui produit le même effet que sans lui :

- role: test_role
  vars:
    path_variable: /example_path

Voir la documentation des rôles Ansible pour plus de détails.

Ressources Ansible

• Guide de démarrage Ansible
• Chat temps réel Ansible, vraiment excellent pour Ansible et les autres questions systèmes/réseau, le meilleur chat technique du monde depuis plus d’une décennie !!
• Construire un inventaire avec Ansible, nécessaire si vous voulez automatiser des clusters.
• Ansible Galaxy, indexeur pour les commandes d’installation ansible-galaxy.