Introduction À Ansible - L'outil Du Sysadmin Paresseux Mais Pragmatique - Sam & Max

05/08/2019 Introduction à Ansible: l’outil du sysadmin paresseux mais pragmatique – Sam & Max
Sam
&
Max
 Introduction
à
Ansible:
l’outil
du
sysadmin
 32
paresseux
mais
pragmatique
This entry was posted in Administration System on 06/12/2013 by VonTenia
Ceci est un post invité de VonTenia posté sous licence creative common 3.0 unported.
Je profite du fait que Sam & Max me donnent la parole pour vous parler d’Ansible, un programme très puissant et
relativement simple dont je me sers depuis récemment (beaucoup trop tardivement à mon goût), mais qui a radicalement
changé ma façon de gérer mes déploiements d’appli sur serveur.
Avant-propos : Ce guide s’adresse avant tout à ceux et celles ayant le minimum d’aisance avec les systèmes linux. Je pense
qu’il est nécessaire de savoir marcher avant d’apprendre à courir, l’automatisation de configuration est une bonne chose
(vous allez voir que vous ne pourrez plus vous en passer), mais si vous n’avez aucune idée de comment éditer un fichier de
configuration, ou comment redémarrer un service, vous risqueriez bien d’être pris au dépourvu… Mieux vaut alors pour vous
commencer par apprendre les bases de l’administration système puis revenir une fois à l’aise avec le concept.
Pourquoi
utiliser
un
“Configuration
Management
Tool”
Vous vous dites : mon boulot c’est de coder, l’administration système c’est sympa 5 minutes mais ça me gonfle… Et
pourtant, au final votre application sera accédée via vos serveurs, et selon leur fragilité, la satisfaction de vos clients pourrait
en pâtir (ce malgré votre excellent code parfaitement testé).
En tant que dev, il serait risible pour vous de ne pas versionner votre code ou ne pas le tester. Pourtant c’est ce que vous
faites avec vos systèmes en n’utilisant pas de CfM. Et personne n’est à l’abri des aléas de la vie, par exemple:
vous êtes hébergé dans le cloud et votre voisin d’hyperviseur s’avère maintenir un site Tor de trafic d’organes et de
prostitution animalière (tout ça pour blanchir des bitcoins)… Vous apprécierez moyennement le downtime lorsque le FBI
saisira le serveur que vous partagiez avec cet indélicat voisin.
Votre sysadmin ultra compètent pourrait se trouver dans l’incapacité d’exercer à la suite d’une banale auto-asphyxie
érotique qui aurait mal tournée. Et bien évidemment il n’a rien documenté avant, le saligaud…
Bref, le genre de risque qu’on apprend à identifier quand on passe sa certif ITIL…
Les
alternatives
aux
CfM
Je vous vois venir, me disant que vous ne m’avez pas attendu pour envisager les situations précédentes. Vous avez déjà un
plan de secours, à savoir :
Des
scripts
: Si vous êtes déjà un peu plus malin que la moyenne, vous vous êtes aperçu que pour déployer une
nouvelle machine, vous tapez toujours les mêmes commandes : installer vos packages, les configurer, démarrer les
services. Vous aurez donc votre collection de scripts shell ou fabric pour vous aider à la tâche.
Inconvénient : il faut être très organisé, gérer les différents fichiers de config peut prendre du temps lorsqu’il faut les
modifier pour chaque serveur. Il est aussi parfois dangereux de relancer le script plusieurs fois sur la même machine,
cela peut avoir des conséquences pour le moins hasardeuses.
Une
image
disque
: Une fois votre serveur configuré et parfaitement fonctionnel, vous avez pris soin d’en prendre une
image disque. Le saint Graal de la prod, contenant la vérité absolue. En cas de crash vous serez opérationnel en un rien
de temps.

sametmax.com/introduction-a-ansible-loutil-du-sysadmin-paresseux-mais-pragmatique/ 1/14
Inconvénient : Les besoins de votre application vont évoluer avec le temps, les fichiers de configuration auront
Sam
&
Max
probablement changé aussi. A chaque changement vous devez refaire votre image… Ça devient assez lourd à la
longue, et c’est facile d’oublier de le faire jusqu’au jour où “the shit hit the fan”.
Rien
(ou
presque)
: Si vous êtes comme moi, d’un naturel optimiste, vous n’avez quasiment pas de solution de
secours (à part des backups). Le jour ou votre serveur crash, vous essayez de fixer le problème, et au pire vous en re-
configurez un nouveau, ce qui vous prends entre 2 heures et 2 jours, en fonction de la dernière fois où vous avez eu à le
faire (je n’ai jamais prétendu être un sysadmin très compètent…). Sans aller jusqu’au crash irrécupérable, le simple fait
de vouloir changer d’hébergeur peut vous faire perdre un temps précieux. Vous perdez donc en flexibilité.
Inutile de vous dire que si vous faites parti de cette catégorie, je vous invite d’autant plus à continuer de lire.
Ansible
à
votre
secours
Ansible est un outil open-source de gestion de configuration écrit en python (aussi dispo en version commerciale avec une
interface graphique et un service de déploiement). La configuration se fait via des fichiers appelés “Playbooks”. Citons parmi
les avantages :
Un système déclaratif : syntaxe YAML facilement lisible, ce qui rend l’apprentissage très rapide (plus qu’avec Chef à
mon goût, où l’on s’empêtre très vite dans des problèmes de dépendance, et en plus je ne suis pas très fluent en ruby).
Templating des fichiers de configuration : qui permet d’avoir des fichiers dynamiquement générés en fonction de ce que
vous voulez, tel que le rôle du serveur, ou bien dépendant d’un autre serveur. En plus le langage de template par défaut
est Jinja2, ça plaira aux amateurs de Django.
Quasiment rien à installer. A part Ansible sur votre machine hôte, tout ce dont vous avez besoin c’est d’un accès root
via SSH sur vos serveurs cibles.
Ansible ne sert pas qu’à déployer votre infrastructure, il peut aussi servir à tester et s’assurer que tous les services qui sont
censés fonctionner soient bien tous actifs, et que tous les fichiers de configurations sont bien à jour. Autant vous dire que
plus vous avez de machines, plus ça devient intéressant.
Je sens que j’écris beaucoup et que j’ai déjà perdu la moitié des lecteurs. Aussi je vous invite à suivre ce petit tutoriel que j’ai
préparé rien que pour vous parce que vous êtes quand même sympa.
Tutoriel
:
Déployer
une
app
django
Nous allons essayer de déployer l’application Django–an-app-at-a-time sur un système Debian wheezy en utilisant Ansible.
1.
Préparer
la
machine
cible
Pour les besoins du test, créer un serveur tout neuf sous Debian Wheezy :
Soit en utilisant Virtualbox (dans ce cas utilisez Debian netinstall). N’installez que le système de base et le serveur SSH.
Seul impératif: un accès ssh via root sur la machine.
Si vous avez les moyens, vous pouvez aussi vous créer temporairement une machine cloud sur OVH ou digital ocean,
ça pourrait être plus rapide.
2.
Installer
Ansible
Sur votre machine hôte (que j’assume être sous Ubuntu pour simplifier):
Installez Ansible, via pip (de façon globale sans passer par virtualenv) :
$ sudo pip install ansible
Générez clefs privée/publique si vous n’en avez pas déjà :

$ ssh-keygen
Copiez la clef publique sur le serveur cible (qui sera désigné par 192.168.1.1 dans ce tutoriel, mais bien entendu remplacez
par l’adresse de votre serveur cible).
$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.1
Créez le fichier /etc/ansible/hosts qui contiendra la liste des serveurs à gérer, et placez-y l’adresse de votre serveur:
$ sudo vim /etc/ansible/hosts
192.168.1.1
Testez que le serveur soit bien accessible:

$ ansible all -m ping -u root
devrait retourner: 
192.168.1.1 | success >> {
"changed": false,
Sam
&
Max
"ping": "pong"
}
Bravo, Ansible est installé et peut communiquer avec votre serveur cible. En avant pour la magie !
3.
Récupérer
le
Playbook
de
démo
et
l’exécuter
Clonez mon repo github concocté avec amour et exécutez le playbook:
$ git clone https://github.com/Remiz/playbook-demo.git

$ cd playbook-demo/
$ ansible-playbook site.yml
Maintenant, plus qu’à attendre…
3.
Admirer
le
résultat
Visitez le site hébergé à l’adresse de votre serveur (dans mon exemple http://192.168.1.1)
Votre réaction la plus normale devrait être la suivante :
Je vous invite maintenant à ouvrir le playbook site.yml et essayer de comprendre. Durant ce court laps de temps, nous
avons:
Créé un utilisateur “myproject”

Ajouté cet utilisateur aux sudoers
Ajouté votre clef privée locale
Mis a jour la date du serveur
Installé/activé le serveur NTP
Sécurisé le serveur en installant fail2ban et en configurant le firewall iptables (laissant ouvert les ports 22, 80, 443 et 
4949 pour le monitoring sous munin)
Installé quelques outils systèmes bien utiles tel que git ou htop
Sam
&
Max
Installé/configuré Nginx, Supervisor, Pip, virtualenv
Cloné le repo Django–an-app-at-a-time
Créé un virtualenv avec django/gunicorn
Configuré gunicorn pour être lancé via supervisor
et finalement deployé les fichiers statiques…
Pas mal en 5 minutes, non ? Maintenant si vous ne me croyez pas, je vous invite à vous connecter sur votre serveur
$ ssh myproject@192.168.1.1
et tester les commandes suivantes :
$ date
$ sudo iptables -L
$ ps -ef | grep fail2ban
$ ps -ef | grep gunicorn
Notez que je n’ai pas utilisé runserver de Django, tout est proprement déployé sur une stack gunicorn/supervisor/virtualenv,
bref je me suis pas foutu de votre gueule. Le Playbook est à vous, c’est cadeau. J’espère qu’il vous servira comme base pour
vos futurs déploiements, et si jamais vous vous rendez compte que vous gagnez un temps fou à l’utiliser, n’hésitez pas à me
payer une pinte si vous êtes de passage au Canada.
Une autre expérience intéressante consiste à relancer l’exécution du playbook :
$ ansible-playbook site.yml
Tout devrait aller beaucoup plus vite, et à la place de “changed” après chaque instruction, vous devriez lire “ok”. Ce qui veut
dire qu’un playbook est plus intelligent qu’un bête script, et ne se contente pas d’exécuter des instructions, Ansible va
garantir quel tel service soit bien actif et qu’il utilise bien le dernier fichier de conf. Ce qui en fait l’outil parfait pour tester vos
systèmes automatiquement.
La
syntaxe
Playbook
Le but de ce tutoriel n’est que de vous présenter Ansible, aussi je ne rentrerai pas trop dans les détails et je vous inviterai à
vous rendre sur le site officiel pour une documentation plus complète.
Un playbook est avant tout composé de tâches :
- name: Texte qui décris votre tâche

module: option=value
Une tâche va donc appeler un module Ansible, dont la fonction peut être de copier un fichier, démarrer un service, clôner un
repository… Il y en a vraiment beaucoup. Chaque module reçoit des paramètres tels que : un fichier de configuration source
(sur votre machine hôte), un path de destination, un package apt à installer… Référez vous à la doc pour savoir quels
paramètres sont acceptés.
Exemples :
- name: Démarrer fail2ban

service: name=fail2ban state=started enabled=true
va s’assurer que le service appelé fail2ban soit bien démarré (le démarrer si ce n’est pas le cas), mais aussi s’assurer qu’il
soit bien présent au démarrage du système. Quand je vous disait que la syntaxe est très simple (même plus simple qu’avec
des scripts shell).
Autre exemple:
- name: Configurer Nginx

template: src=templates/nginx.conf.j2
dest=/etc/nginx/sites-enabled/{{ user }}.conf
notify: restart nginx
se traduit par : récupérer le template de conf dans le répertoire local templates/ (le parser avec les bonnes valeurs), et placer
le résultat dans le répertoire de conf de Nginx (en utilisant le nom d’utilisateur comme nom du fichier). Enfin redémarrer nginx
via un handler (uniquement si le contenu du fichier de conf a changé). 
Conclusion
(et
aller
plus
loin)
Sam
&
Max
Je vous conseille de lire la documentation officielle, elle est plutôt bien faite, dites-vous que je ne connaissais pas du tout cet
outil il y a deux semaines et je m’en sert désormais régulièrement (et je suis du genre slow-learner). Renseignez vous
particulièrement sur les rôles que vous pouvez donner à vos serveurs, ce qui vous permet de diviser vos playbooks (frontend,
cluster DB, worker celery…), et ce qui encourage aussi la réutilisation (par exemple j’ai toujours un rôle “common” qui inclus
tout ce qui est nécessaire à l’ensemble de mes serveurs : utilisateur admin, sécurité, timezone…). Comme on n’apprend
jamais aussi bien que par l’exemple, n’hésitez pas à vous inspirer des exemples issus de la doc (l’outil évolue vite et certains
ne sont plus entièrement valides, mais c’est toujours bon à prendre).
Si vous voulez pousser l’automatisation jusqu’à l’extrême, il est aussi possible de configurer Ansible sur vos serveurs pour se
connecter à un repo git, récupérer les playbooks et fichiers de conf appropriés et s’auto-configurer…
Voila, mon rôle s’arrête ici et libre à vous d’en apprendre plus. Au final j’espère avoir tenu ma promesse d’éclairer vos esprit
sur les miracles de l’automatisation.
Partager:
Tweet Share 23  Email  More
 32
thoughts
on
“Introduction
à
Ansible:
l’outil
du
sysadmin
paresseux
mais
pragmatique”
mototo Log in to Reply
06/12/2013 at 12:03
Merci ! Tu viens de m’epargner quelques mois de codage, vu que c’est exactement ce que je
commencais a preparer pour ma plateforme.
La documentation sur leur site est super claire et AWX semble gratuit jusqu’a 10 machines. Au dela j’attendrais d’etre
sorti de l’hopital psychiatrique.
Alors, encore un ++ pour Mossieur Von Tenia !
cyp Log in to Reply

06/12/2013 at 12:16
Merci pour le post.
Ça faisait quelques temps que je me disais que ça serait bien d’avoir sous la main ce genre d’outil
pour faire les déploiements isolés sans avoir à se farcir Chef ou Puppet.
Je vais tester rapidement mais ça devrait bien me plaire.
François Log in to Reply

06/12/2013 at 12:26
Merci !

J’ai envisagé un temps les scripts fabric mais le ratio gain/invest ne me semblait pas suffisant car trop “bas niveau”. Là,
Sam
&
Max
je suis réellement convaincu.
Pierre Log in to Reply

06/12/2013 at 14:04
Pour compléter, il y a également un très bon article sur Ansible dans Linux Pratique du mois de….
mars-juin (enfin dans ces eaux là).
J’ai personnellement pas mal galéré avec Fabric alors qu’Ansible a été beaucoup plus rapide à mettre en place. En tout
cas, c’est un vrai régal de pouvoir déployer un nouveau site sur le serveur, conf git, mysql, nginx, supervisor et
virtualenv comprises, en une seule commande.
Je conseille donc vivement son utilisation si vous vous situez dans la catégorie “N’aime pas les tâches répétitives”
VonTenia Post author

Log in to Reply
06/12/2013 at 14:42
Merci pour vos commentaires, ca fait plaisir de voir que le temps passé à ecrire ce pavé servira
aux autres.
Une note cependant pour ceux qui deciderait de faire un git pull depuis leur propre repo via Ansible : si votre tache reste
bloquee, c’est qu’il vous faut rajouter le serveur git aux known hosts : http://www.tomaz.me/2013/10/14/solution-for-
ansible-git-module-getting-stuck-on-clone.html
sd76 Log in to Reply

06/12/2013 at 14:43
Dans la même ligné (toujours en python <3 ) il y a slat: http://www.saltstack.com/community/
Je préfère surtout pour l'usage de 0mq là ou ansible s'appuie sur SSH.
Et puis je le trouve plus simple. Après les goûts et les odeurs…
cyp Log in to Reply

06/12/2013 at 14:48
Voilà premier test rapide, ça n’a pas trop mal marché mais j’ai déjà bloqué sur un première
limitation/problème.
Le coupable http://www.ansible.cn/docs/modules.html#apt-repository
D’abord depuis une distribution sur laquelle python-apt n’est pas dispo… bon pourquoi pas, le système n’est pas trop
inter distribution. Pas trop grave, ça ne sera pas très compliqué d’avoir une machine Debian/Ubuntu et une
Redhat/CentOS sous la main si nécessaire.
Ensuite deuxième essai depuis une VM Debian 7 avec python-apt et python-pycurl présent et je me retrouve avec la
même erreur (“Could not import python modules: pycurl…”) pas le temps de chercher le pourquoi du comment
maintenant mais il y a certains module qui semble un peux plus expérimental que les autres.

Log in to Reply
06/12/2013 at 15:01
@cyp: si c’etait sous pip je te dirais un probleme de dependance… un autre package a installer
avant. Mais la j’avoue que je ne sais pas trop, je vais tester sur ma VM. Le plus souvent, c’est
interessant de le faire manuellement pour voir si ca bloque, et ensuite le mettre dans ansible. 
Perso je fais des clones de ma VM sous virtualbox (juste apres avoir installe debian), comme ca je peux relancer mes
Sam
&
Max
playbook depuis zero.
cyp Log in to Reply

06/12/2013 at 15:10
@VonTenia corrigé, en fait j’avai mal compris “python-apt” et “python-pycurl” doivent être installé
mais sur la machine de destination (app&remment “python-apt” l’est par défaut sur Debian
manque pycurl).
Donc au final ça fonctionne et ça reste inter-distribution par contre il faut penser a ajouter une tache pour installer
“python-pycurl” avant d’utiliser le module “apt-repository” si on en a besoin.

Log in to Reply
06/12/2013 at 15:17
Pour une solution portable inter-distrib je pense que Chef est plus adapte. Perso je change
rarement de distrib et j’ai tendance a tout faire sous debian pour eviter de me prendre la tete.
Apres je peux comprendre que les business needs font qu’on puisse se retrouver avec des environnements multiples…
Durant la conception de mes premiers playbooks j’ai aussi rencontre des problemes avec certains modules (beaucoup
d’erreurs de debutants aussi), mais au final rien d’insurmontable et je pense que le temps investis sur cet outil sera
rapidement recupere dans le futur.
Eliot Log in to Reply

06/12/2013 at 15:37
Merci pour cet article, je n’ai rien d’autre à dire que “ça tue !”.
guatar Log in to Reply

06/12/2013 at 17:07
Merci pour ce post instructif !
mat Log in to Reply

06/12/2013 at 17:26
Merci beaucoup pour l’article :)
Par contre, quelle est la différence entre Ansible et Fabric ?

Je n’en ai testé aucun des deux, mais de ce que j’ai compris, il peuvent en gros faire la même chose non ?
Syl Log in to Reply

06/12/2013 at 22:35
Chez moi, ça bloque au moment de cloner le dépôt github:
TASK: [Git clone/pull Django--an-app-at-a-time] *******************************

fatal: [192.168.1.69] => Incorrect sudo password

Je suis le seul à coincer ici?

Sam
&
Max
(mac mavericks >> vm virtualbox sous ubuntu server 12.04)
A part ça, ben c’est vraiment d’la bombe cet outil! Merci pour le tuto!
VonTenia Log in to Reply

06/12/2013 at 22:55
@Mat : Rapidement resume, ansible sert a la configuration generale de serveur niveau Packages,
Services, Configurations. Fabric est ideal pour faire du deploiement genre executer une serie de
commande (collectstatic, redemarrer gunicorn…). Perso j’utilise les deux de facon complementaire.
@Syl : Merci de tester le tuto, j’avoue n’avoir essaye que sous ubuntu et virtualbox. Tu peux essayer de remplacer le :
remote_user {{ user }}
par :
sudo: yes
sudo_user: {{ user}}
Baronsed Log in to Reply

07/12/2013 at 00:01
L’un des intérêts majeurs d’un Cfm est donc de reproduire une configuration indépendamment de
la distribution (avec adaptation à l’architecture des répertoires et à la version) , j’ai bien compris ?
À propos des scripts :

“dangereux de relancer le script plusieurs fois sur la même machine, cela peut avoir des conséquences pour le moins
hasardeuses”
Je me permets de linker ce petit guide pour écrire des scripts dits “robustes”, orienté atomicité et évitement d’états
indéterminés pour le système :
http://www.davidpashley.com/articles/writing-robust-shell-scripts/
Laurent Log in to Reply

07/12/2013 at 08:56
Merci pour l’article, il est très intéressant.
Perso, j’utilise souvent Fabric qui correspond bien à mon besoin, et c’est cool de voir ce que la
concurrence propose :)
Pour les personnes trouvant Fabric trop bas de niveau, je leur conseille fortement de lui ajouter Fabtools. Fabtools
apporte plein d’outils de haut niveau comblant les lacunes de Fabric.
Là où Fabric peut se résumer (vite fait) à envoyer des commandes via ssh vers un serveur. Fabtools permet de gérer les
services, installer des virtualenv, créer des configurations Nginx, gérer les tâches CRON … et encore plein d’autres
choses. Je vous invite à parcourir la doc.
zazabe Log in to Reply

07/12/2013 at 10:59
Cool, ca va me servir pour définir notre solution de déploiement. Pour l’instant on partait sur
puppet, mais ca me semble plus fait pour gérer des grosses infra…
En tout cas, merci !

Sam
&
Max Syl
Log in to Reply
07/12/2013 at 11:57
@VonTenia: Merci! Ca va plus loin maintenant! Maintenant, ça bloque sur:
TASK: [Setup supervisor config (to manage gunicorn)] **************************

failed: [192.168.1.69] => {"failed": true}
msg: Destination /etc/supervisor/conf.d not writable
FATAL: all hosts have already failed -- aborting
J’ai pourtant bien ajouté la directive “sudo_user”…
JEEK Log in to Reply

07/12/2013 at 13:28
Ça, c’est un article qui roxxxe du poney… Merci VonTenia ! ;-)
VonTenia Log in to Reply

09/12/2013 at 01:04
Responses en vracs et en retard dsl (j’avais pas internet ce weekend…):
@Baronseed: Je ne dirais pas que l’interet principaux des CfM reside dans la portabilite (le
playbook que j’ai donne en exemple ne fonctionnera probablement pas sous Centos par exemple…). Pour moi l’interet
principal c’est de rapidement pouvoir configurer un systeme et eviter la repetition de commandes en specifiant des
roles. La syntaxe playbook est quand meme relativement simple a cote de l’ecriture complete de scripts shell, et je suis
de ceux qui pensent que moins on ecrit de code a la main, moins y a de bug :).
@Laurent: Je suis persuade qu’on peut tout a faire faire la meme chose avec Fabric et Fabtool (merci je vais me
renseigner sur cet outil d’ailleur). Chacun choisira la solution la plus adaptee, peut etre Ansible est trop lourd pour un
projet tournant sur serveur unique et Fabric fera perdre moins de temps… Mais ce que j’aime bien dans Ansible c’est la
possibilite de reutiliser des playbooks (un peu comme les recettes dans Chef), et les appliquer sur d’autres projets (on
peut sans doute faire ca dans Fabric, mais c’est peut etre un peu moins compartimente donc moins facilement
reutilisable).
@Syl: “sudo_user: myuser” veut dire : executer cette commande via sudo utilisateur myuser. Il faut etre root pour ecrire
dans /etc/, donc il ne faut pas utiliser sudo_user pour cette action (lorsqu’on ne precise pas d’utilisateur pour une action
on revient a l’utilisateur par defaut, dans notre cas root). Peut etre que ta distrib n’a pas le repertoire
/etc/supervisor/conf.d/ cree automatiquement apres son installation via apt…
Syl Log in to Reply

09/12/2013 at 08:04
@VonTenia: Le répertoire “/etc/supervisor/conf.d/” est bien là.
La machine cible est un UbuntuServer, donc pas de compte root actif par défaut.
Logiquement, rien ne pourrait m’empêcher d’écrire dans etc via sudo.
Je vais refaire quelques tests ce soir…
Hub 
11/12/2013 at 14:46
Il me tardait de voir un post sur Ansible sur Sam&Max! Log in to Reply

Sam
&
Max Bravo pour l’explication.
Etant AdminSys d’un petit parc de machines Linux, j’ai découvert Ansible il y a peu de temps et je
ne pourrais plus m’en passer.
Ansible gère maintenant l’ensemble des services de mes machines utilisateurs (ntp, ssh, comptes utilisateurs, droits
sudos, cups, partages NFS, logiciels installés, etc).
Avec un cron qui me lance la commande tous les jours, je suis sûr d’avoir un parc de machines utilisateurs homogènes.
Rajouter des exceptions pour des machines et/ou des OS différents est vraiment trivial.
L’avantage par rapport à puppet est qu’il ne nécessite aucun démon tournant sur les machines (mode pull pour Ansible
alors que puppet fonctionne en mode push) ce qui permet de l’utiliser après une install toute fraiche.
L’avantage à fabtools est qu’il n’est pas nécessaire d’écrire du code “Python” mais juste des directives YAML et de
gérer des templates avec Jinja2 ce qui permet d’écrires des rôles très rapidement.
Bref, c’est vraiment un programme bien foutu qui ne cesse d’évoluer.
(Non, je n’ai pas de part dans la société ;) )
gentilmaispastrop Log in to Reply

12/12/2013 at 15:45
Ce genre d’outil comme les frameworks de tests…j’ai aussi vite fait à la main que de me taper leur
tonne de doc imbitable…Mes déploiements, avec ssh-id-copy, le module sh et path, j’arrive à
m’en sortir…On vit dans un monde d’usines à gaz…Je sais les pros me diront que je suis pas corporate et que j’aurais
pas ma certif ITIL ni mon ISO 1222 de mescouilles ;), les certifs je m’en tamponne, je travaille pas en costard mais en
short ;)
dramaticalementcorrect Log in to Reply

12/12/2013 at 15:47
“tout ce dont vous avez besoin c’est d’un accès root via SSH sur vos serveurs cibles.”
Et soudain c’est le drame…
rageux Log in to Reply

12/12/2013 at 15:52
Bon les enfants, avant de passer votre certification ITIL, essayez déjà le Besherelle, ce sera déjà un
bon début ;)
Un bon programmeur c’est avant tout une personne qui comprend le sens des mots et les respecte, un peu comme il
respecte la grammaire de son langage préféré. La bonne résolution d’un problème commence souvent par sa bonne
compréhension.
groug Log in to Reply

14/12/2013 at 19:11
Merci pour l’article, très intéressant.
Je me suis mis à fabtools récemment, donc je ne suis pas sûr d’avoir un intérêt à changer, mais
l’article, et la templatisation des fichiers de conf avec jinja2 donnent envie de tester !

Sam
&
Max Sam
Log in to Reply
14/12/2013 at 19:15
C’est vrai que fabtools manque d’un outil de template par défaut.
tcbv Log in to Reply

29/01/2014 at 13:47
et pour ceux pour veulent voir plus “large” en terme de périmètre OS, il existe OpenSVC , qui fait
de la gestion de service, de la gestion de config, de l’inventaire (os/hardware/stockage), de
l’automatisation de bascule en PRI/PRA, du reporting, de la conformité, …
Adrien Log in to Reply

09/10/2014 at 09:02
Attention, il faut quand même python > 2.5 sur la machine cible. Ou alors 2.4, et installer python-
simplejson.
Je dis ça parce que j’ai eu à faire un playbook de bootstrap, afin de gérer un parc d’environ 500 machines sous Suse
10. Python 2.4. Vieux.
Mais ça ne devrait pas arriver à beaucoup de monde :)
Zer00CooL Log in to Reply

06/01/2018 at 13:10
Ansible vs Ansible pour les nuls
Bonjour à tous, j’aurais besoin de vos conseils pour avancer avec Ansible.
Je tente de suivre le tutoriel officiel de DemocracyOS pour installer la version OnPremises ou il est question de Ansible.
Je me retrouve bloqué, je ne sais pas comment renseigner 3 ou 4 fichiers de configuration.
Merci de votre aide pour utiliser Ansible, Docker, et, déployer DemocracyOS
J’en suis arrivé la : https://www.visionduweb.eu/wiki/index.php?

title=Installer_DemocracyOS#Reprendre_sur_la_Machine_Virtuelle
Sam Log in to Reply

07/01/2018 at 13:54
Va sur indexerror.net
✒ Leave
a
comment
You must be logged in to post a comment.
Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.

Post
navigation
Sam
&
Max
← En Python 3, le type bytes est un array d’entiers Petite astuce d’unpacking en Python →
Mais où je suis tombé(e) là ?
Télécharger cette page en PDF
Souscrire
à
nos
conneries
Entrez votre adresse mail et vous recevrez une notification à chaque nouvel article.
Join 1,477 other subscribers
Email Address
J'adhère, bon dieu !
 TagCloud
0bin angularjs asyncio autobahn bash bitcoin blog cache comprehension-lists crossbar css cul dict django don encoding git http import
ipython iterable javascript jquery linux meta mysql nginx nsfw pep8 pip poo python python 3 redis ruby shell sublime text
ubuntu unicode unit tests unpacking virtualenv wamp web yield
Envoyez
des
sioux
On adooooore les bitcoins :
19zAHPPuce4BAhsdy9KaFwVLurEJXMhMAn
 Nos
projets
› Multiboards – l’actu geek fr en une page
› 0bin – le pastebin chiffré
› All that counts – compteur pour jeux
› Django quicky – quick views for Django
› VizHash.js – Hash visuels
› Code des articles du blog
 Meta
› Log in
› Entries RSS
› Comments RSS
› WordPress.org
 Hors
du
blog
› Page de contact
› @sam_et_max sur twitter
› Nos tweets en RSS
› Fork me, I’m famous (github)

Tous les textes de ce blog, sauf signalement contraire, sont sous licence creative common 3.0 unported.

Sam
&
Max Toi
aussi,
trouve
un
article
obsolète
sur
notre
blog
› June 2019 (1)
› February 2019 (1)
› January 2019 (3)
› December 2018 (1)
› September 2018 (2)
› August 2018 (1)
› July 2018 (3)
› June 2018 (4)
› May 2018 (2)
› March 2018 (2)
› November 2017 (5)
› October 2017 (2)
› July 2017 (5)
› June 2017 (3)
› May 2017 (3)
› April 2017 (2)
› March 2017 (3)
› January 2017 (5)
› October 2016 (2)
› August 2016 (2)
› March 2016 (8)
› January 2016 (16)
› October 2015 (2)
› August 2015 (10)
› July 2015 (18)
› June 2015 (13)
› May 2015 (12)
› April 2015 (13)
› March 2015 (8)
› January 2015 (21)
› October 2014 (18)
› August 2014 (5)
› July 2014 (11)
› June 2014 (25)
› May 2014 (14)
› April 2014 (10)
› March 2014 (23)

› January 2014 (17)
Sam
&
Max › December 2013 (27)
› October 2013 (27)
› August 2013 (31)
› July 2013 (32)
› June 2013 (24)
› May 2013 (30)
› April 2013 (31)
› March 2013 (33)
› January 2013 (34)
› October 2012 (35)
› August 2012 (37)
› July 2012 (33)
› June 2012 (24)
› May 2012 (31)
› April 2012 (20)
› March 2012 (10)

· © 2019 Sam & Max · Designed by Themes & Co ·
Back to top


Introduction À Ansible - L'outil Du Sysadmin Paresseux Mais Pragmatique - Sam & Max

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introduction À Ansible - L'outil Du Sysadmin Paresseux Mais Pragmatique - Sam & Max

Transféré par

Droits d'auteur :

Formats disponibles

05/08/2019 Introduction à Ansible: l’outil du sysadmin paresseux mais pragmatique – Sam & Max

This entry was posted in Administration System on 06/12/2013 by VonTenia

Générez clefs privée/publique si vous n’en avez pas déjà :

Testez que le serveur soit bien accessible:

$ git clone https://github.com/Remiz/playbook-demo.git

Maintenant, plus qu’à attendre…

Votre réaction la plus normale devrait être la suivante :

Créé un utilisateur “myproject”

et tester les commandes suivantes :

Une autre expérience intéressante consiste à relancer l’exécution du playbook :

Un playbook est avant tout composé de tâches :

- name: Texte qui décris votre tâche

- name: Démarrer fail2ban

- name: Configurer Nginx

Tweet Share 23  Email  More

cyp Log in to Reply

François Log in to Reply

Pierre Log in to Reply

VonTenia Post author

sd76 Log in to Reply

cyp Log in to Reply

VonTenia Post author

cyp Log in to Reply

VonTenia Post author

Eliot Log in to Reply

guatar Log in to Reply

mat Log in to Reply

Par contre, quelle est la diﬀérence entre Ansible et Fabric ?

Syl Log in to Reply

TASK: [Git clone/pull Django--an-app-at-a-time] *******************************

Je suis le seul à coincer ici?

VonTenia Log in to Reply

Baronsed Log in to Reply

À propos des scripts :

Laurent Log in to Reply

zazabe Log in to Reply

En tout cas, merci !

TASK: [Setup supervisor config (to manage gunicorn)] **************************

FATAL: all hosts have already failed -- aborting

J’ai pourtant bien ajouté la directive “sudo_user”…

JEEK Log in to Reply

VonTenia Log in to Reply

Syl Log in to Reply

Logiquement, rien ne pourrait m’empêcher d’écrire dans etc via sudo.

Je vais refaire quelques tests ce soir…

Il me tardait de voir un post sur Ansible sur Sam&Max! Log in to Reply

Bref, c’est vraiment un programme bien foutu qui ne cesse d’évoluer.

(Non, je n’ai pas de part dans la société ;) )

gentilmaispastrop Log in to Reply

dramaticalementcorrect Log in to Reply

Et soudain c’est le drame…

rageux Log in to Reply

groug Log in to Reply

tcbv Log in to Reply

Adrien Log in to Reply

Zer00CooL Log in to Reply

Je me retrouve bloqué, je ne sais pas comment renseigner 3 ou 4 ﬁchiers de conﬁguration.

J’en suis arrivé la : https://www.visionduweb.eu/wiki/index.php?

Sam Log in to Reply

Join 1,477 other subscribers

J'adhère, bon dieu !

Vous aimerez peut-être aussi