Afficher/cacher Sommaire
URL: https://linuxfr.org/users/skhaen/journaux/deploiement-et-automatisation-avec-ansible-partie-1 Title: Déploiement et automatisation avec Ansible - partie 1 Authors: skhaen Date: 2017-01-07T23:11:51+01:00 License: CC by-sa Tags: ansible, automatisation et déploiement Score: 50
Au programme de cette année : l’automatisation ! Il existe plusieurs outils connus pour ça, vous en avez sans aucun doute entendu parler si vous êtes adminsys : Puppet, Chef, Salt et le petit dernier : Ansible.
Ansible a la réputation d’être le plus “accessible” avec une courbe d’apprentissage assez basse. Il peut être pertinent de l’utiliser à partir d’un seul serveur pour faciliter des déploiements selon les besoins (configuration des outils basique, serveur web, BDD…).
Au contraire des trois autres, il n’utilise pas d’agents (agentless), c’est à dire que rien n’a besoin de tourner côté serveur pour le faire fonctionner, ce qui le rend de facto plus facile à mettre en place. Il requiert seulement un accès SSH et python sur les serveur.
Toujours concernant Ansible (bien entendu), on parle souvent d’idempotence, ce qui signifie qu’une opération a le même effet qu’on l’applique une ou plusieurs fois.
Les recettes utilisent du YAML et Jinja2 pour les templates. L’utilisation de YAML permet d’avoir des recettes normalement facile à lire et à comprendre. À noter aussi que grâce au (ou à cause du) YAML, l’indentation est primordiale et source de bug si elle n’est pas respecté comme on le verra plus tard.
Au programme aujourd’hui :
- installation d’Ansible (v2.2.0.0)
- tests de connexions aux serveurs
- installation de quelques paquets
- debug et tests
Installation
Si vous avez besoin d’autre chose, ça devrait être dans la documentation.
sur Debian
Vous pouvez l’installer directement via les dépôts, mais ce sont évidemment des versions anciennes (cf. packages.debian.org), pour avoir une version plus récente, ajouter la ligne suivante à /etc/apt/sources.list.d/ansible.list
:
deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main
Puis il suffira de lancer les commandes suivantes :
sudo apt-get update
sudo apt-get install ansible
sur Ubuntu
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible
Il suffit ensuite d’aller dans /etc/ansible/
pour la suite :
cd /etc/ansible/
nous avons normalement 2 fichiers et un dossier :
- ansible.cfg : la configuration d’ansible, celle par défaut nous convient parfaitement bien pour le moment, mais ça peut valoir le coup d’y jeter un coup d’oeil pour voir ce que l’on peut faire.
- hosts : c’est dans ce fichier que nous allons indiquer nos serveurs, étape obligatoire pour la suite.
- roles : ce dossier nous servira surtout par la suite quand on commencera à avoir plusieurs rôles à nos playbooks.
Inventory / hosts
Dans /etc/ansible/
, donc, éditons notre fichier hosts
. Nous pouvons y déclarer nos serveurs individuellement ou par groupe, par exemple :
serveur1.exemple.org
serveur2.exemple.org
preprod.elysee.org
8.253.9.125
[web]
skhn-web-nginx-01
skhn-web-nginx-02
[seedbox]
skhn-seedbox-01
Voici ma configuration actuelle, à noter que j’ai modifié mon /etc/hosts
et mon .ssh/config
pour que ça pointe vers les bons serveurs avec les bonnes clés SSH :
[scaleway]
skhn-001
skhn-002
[seedbox]
sb
Par la suite, je pourrai ainsi lancer des tâches sur tous les serveurs avec l’option générique all
ou par groupe selon vos besoins (web, bdd, wordpress, etc…). Si vous vous posez la question, le premier groupe s’appelle scaleway car j’ai pris 2 serveurs chez eux pour tester Ansible ^^).
ping
- Avant toute chose, est ce que l’on arrive bien à joindre les serveurs :
ansible -m ping all --one-line
Ce qui me donne :
skhn-002 | SUCCESS => {"changed": false, "ping": "pong"}
skhn-001 | SUCCESS => {"changed": false, "ping": "pong"}
sb | SUCCESS => {"changed": false, "ping": "pong"}
test SSH
Mais est ce que l’on arrive à se connecter au groupe scaleway
? On va en profiter pour récupérer quelques infos :
ansible scaleway -m setup --tree /tmp/facts_servers/
La sortie de cette commande sera recopiée pour chaque serveur dans /tmp/facts_servers/
, vous devriez avoir toutes les informations que vous souhaitez avoir sur vos serveurs ;-)
et mon uptime ?
ansible all -m command -u root --args "uptime" --one-line
résultat :
sb | SUCCESS | rc=0 | (stdout) 17:33:14 up 410 days, 21:59, 1 user, load average: 0.21, 0.16, 0.14
skhn-001 | SUCCESS | rc=0 | (stdout) 16:33:14 up 1 day, 2:05, 1 user, load average: 0.00, 0.00, 0.00
skhn-002 | SUCCESS | rc=0 | (stdout) 16:33:14 up 1 day, 2:05, 1 user, load average: 0.00, 0.00, 0.00
Installation d’une liste de paquets
J’aime bien avoir certains paquets installé sur tout mes serveurs, Ansible me permet de l’automatiser facilement. On commence par éditer notre nouveau fichier /etc/ansible/roles/skhn_common.yml
pour y mettre le bloc suivant :
---
- hosts: all
remote_user: root
tasks:
- name: install common packages for all servers
apt:
update_cache=yes
state=latest
name=
with_items:
- curl
- htop
- ncdu
- pwgen
- strace
- sudo
- tar
- unzip
- vim
- wget
- whois
- screen
Après l’avoir enregistré, il suffira de lancer la commande suivante pour installer cette liste de paquets sur tout les serveurs :
ansible-playbook -i hosts /etc/ansible/roles/skhn_common.yml
Et c’était donc notre premier rôle, yay \o/
Vous avez peut être remarqué 2/3 trucs :
- un rôle commence toujours par
---
, hosts: all
est ici directement dans le fichier et non dans la commande,- on nomme ensuite nos tâches (
tasks
) avecname
, ça permet de s’y retrouver plus facilement et d’avoir un libellé humainement compréhensible à lire pendant le déroulement du rôle (on sait donc plus facilement où on en est et ce qui est en train de se passer). update_cache=yes
permet de faire unapt-get update
- j’ai choisi de mettre
state=latest
et nonstate=present
, j’ai envie que ce genre de paquet soit à jour sans que j’ai besoin de m’en occuper.
Debug
Le plus gros problème que j’ai eu pour le moment concerne l’indentation qui est vicieuse et la syntaxe YAML.
L’indentation
Si vous voulez vous éviter des prises de têtes qui vous font perdre quelques heures facilement, faites des indentations de DEUX espaces ! Pourquoi ? Parce que :
- ça, c’est VALIDE (DEUX espaces) :
---
- hosts: all
remote_user: root
tasks:
- name: install common packages for all servers
apt:
update_cache=yes
state=latest
name=
with_items:
- curl
- htop
- ça, c’est INVALIDE (QUATRE espaces) :
---
- hosts: all
remote_user: root
tasks:
- name: install common packages for all servers
apt:
update_cache=yes
state=latest
name=
with_items:
- curl
- htop
- et ça, c’est VALIDE (QUATRE espaces) :
---
- hosts: all
remote_user: root
tasks:
- name: install common packages for all servers
apt:
update_cache=yes
state=latest
name=
with_items:
- curl
- htop
VOUS LA VOYEZ LA DIFFÉRENCE ? C’EST CE #### D’ESPACEMENT ET D’ALIGNEMENT AVEC LE RESTE DE hosts: all
! Bon, une fois qu’on le sait, pourquoi pas, mais à cause de ça j’ai perdu plus d’une heure hier après-midi, merci le message ERROR! Syntax Error while loading YAML.
absolument pas parlant…
La syntaxe YAML
Si vous avez un doute sur ce que vous avez fait, ou si vos collègues sont des adeptes de la fameuse méthode “gruiiiiiik et je me casse en vacances sans vérifier si ça marche en prod”, l’utilisation de yamllint est recommandée (ça, et le non moins fameux coup-de-clavier-dans-la-gueule). Idéal en pré-commit (yamllint, pas le clavier).
Ansible propose aussi un check : --syntax-check
, que l’on peut utiliser de cette manière là :
ansible-playbook --syntax-check example-playbook.yml
ansible-playbook --syntax-check roles/*
Oh, et évidemment, je vous conseille beaucoup de lire les best practices.