gestion_de_configuration [SIO Wiki]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
~~SLIDESHOW~~
====== Gestion de configuration ======



**03/11/2020**


**Ph. Sevre**

===== Plan =====

  - Avant-propos d'après Larry Wall
  - Etat des lieux
  - La virtualisation
  - Les infrastructures
  - L'installation automatique
  - cfengine
  - puppet
  - ansible
  - Conclusion

===== Les 3 vertus de l'administrateur système =====
D'après** Larry Wall**, éminent créateur du **langage Perl**, les 3 vertus cardinales du développeur et/ou de l'administrateur système sont :
  * **la fainéantise**
  * **l'impatience**
  * **l'orgueil**

===== la fainéantise =====
  * consiste à faire les choses avec le **minimum d'efforts**
  * faire/utiliser des outils permettant de limiter les efforts ultérieurs
  * rédiger de la documentation de façon à ce que les utilisateurs n'aient plus rien à vous demander (enfin presque ...)


===== l'impatience =====
  * **court, c'est encore trop long !!**
  * **en faire le moins possible, c'est toujours attendre ...** 
  * il faut concevoir et utiliser des **outils efficaces** ...  

===== l'orgueil =====
  * faire des choses dont on n'aura pas à rougir
  * il est nettement plus confortable de pouvoir se dire que quand ça plante, je n'y suis pour **RIEN** !   
  * même si c'est moi qui devrai rattraper les erreurs des autres ...
  * en d'autres termes, prévoir le pire ...


===== Etat des lieux 2020 =====
  * montée en puissance de la virtualisation
  * montée en puissance du cloud (OpenStack, Docker) 
    * plus de serveurs
    * plus de services demandés


===== La virtualisation =====

  * **pourquoi ?**
    * **consolidation** : permet de regrouper plusieurs serveurs sur une seule machine physique
    * **isolation physique** : permet (presque) de s'abstraire des caractéristiques physiques  de la machine.
    * **maintenance plus simple** : moins de machines physiques à réparer/maintenir
    * **anciens systèmes d'exploitation** : permet de continuer à faire fonctionner une très ancienne application avec un système d'exploitation ancien (Windows 2000) sur une machine récente
    * **tests** : il est très rapide et simple de mettre en oeuvre une maquette
    * **économies d'énergie** : évident
    

===== Virtualisation : les solutions - 1 =====

  * **VMWARE** : la plus mature des solutions   
    * solutions poste de travail : Vmware Player, Vmware Workstation
    * solutions serveurs et datacenter (VMWare ESX/ESXI, VSphere, VMware infrastucture
    * depuis le gratuit jusqu'au très cher 
  * **Xen** : fonctionne en environnement Linux - excellentes performances  - utilisé par AWS
  * **KVM** : Kernel Virtual Machine - le standard en environnement Linux
  * **VirtualBox** : Oracle - plutot utilisé sur le poste de travail
  * **Microsoft** : HyperV

===== Virtualisation : les solutions - 2 =====

  * les **conteneurs** :    
     * permettent une très haute densité de machines virtuelles
     * performances proches du mode natif (~3% de déperdition)
     * déploiement très simple avec des templates (< 2 minutes)
     * OS guest identiques à celui du host
    * **LXC** : récent et très utilisé - a servi de base pour Docker 
    * **OpenVz** : efficace mais en perte de vitesse
    * **Linux Virtual Server**
    * **Docker** : en fort développement

===== Virtualisation : mise en oeuvre au Castel =====

  * **2006/2005** : Xen - rapide et stable - machines virtuelles Windows pas utilisables en production  
  * **2007/2006** : Vmware Server 1.0.2 sur Linux Ubuntu - 
    * 3 machines physiques
    * entre 15 et 20 machines virtuelles 
    * pas de problèmes particuliers en production 
    * //snapshots// croisés à chaud 2 fois par jour
  * **actuellement** : OpenVz avec Proxmox sur un cluster de 3 machines physiques (25 machines virtuelles)  
    * Vmware ESXI - 12 machines virtuelles (8 Windows)

===== Virtualisation : bilan =====
  * la virtualisation : très efficace, très pratique (**trop ?**)
  * résultat : les machines virtuelles se multiplient  et **prolifèrent** (pour les tests, les évaluations, ...)
  * bilan => pratiquement 1 machine virtuelle par service
  * au Lycée Le Castel : 
    * environ 25 machines virtuelles Linux en production
    * 6 machines virtuelles Windows





===== Virtualisation : le stockage  =====
  * le **stockage** constitue bien sûr un enjeu important (gros volumes à prévoir pour stocker les partition systèmes)
   * stockage **local** : utilisation de LVM (//Logical Volume Manager//) pour gérer de nombreuse partitions
   * stockage **distant** : plusieurs pistes 
     * **SAN Fiber Channel** : 4 Mb/s mais très cher et très complexe
     * **SAN ISCSI** : moins cher mais moins performant
     * **SAN AOE** : solution d'entrée de gamme pour les petites installations 
     * **NAS - Filer NFS/SMB** : moins recommandé pour les performances et les problèmes de verrouillage 

   * quelle que soit la solution choisie, les volumes mis en oeuvre impliquent un **réseau rapide** (Gigabit +) 


===== Problématique =====
  * des machines physiques ou virtuelles de plus en plus nombreuses ,
  * des **distribution différentes** (Debian, Ubuntu, Redhat, Fedora, Centos, Suse,...) dans des **versions différentes** (7.0, 6.0, 14.04, FC12, ...) avec des **modes de fonctionnement différents** (paquetages, gestion des services)
  * quels outils utiliser pour maintenir en état de fonctionnement ces systèmes différents ?


===== Problématique =====
  * l’efficacité passe d'abord par une infrastructure adaptée

===== Les infrastructures =====

  * la qualité et la robustesse d'une infrastructure passe par un certains nombre de point importants
    * le **serveur de temps**
    * le **serveur de noms DNS**
    * le **serveur DHCP**
    * un **serveur de log** centralisé
    * un **serveur gold** pour la centralisation des configurations 



===== Le serveur de noms : DNS =====
  * il joue un rôle indispensable en **traduisant les noms de machines** en **adresses IP** : en effet, les services réseau ne connaissent que des adresses IP
    * exemple : **pipo.lecastel.lan** <=> 172.16.0.7  
  * il est bien sûr indispensable pour l'accès à l'internet
  * grâce aux mécanisme d'alias, il permet de donner un **synonyme** à une **machine**
  * on pourra donner un nom indépendant (**web**, **www**, **ftp**, **proxy**, **intra**, **syslog**, ...) de la machine à un **service** ou à un **usage** 


===== Le serveur de noms : DNS - suite =====

  * le serveur **wiki** du lycée est hebergé sur la machine **lisa**
  * le jour où, pour une raison quelconque, le serveur wiki doit migrer sur une autre machine, les utilisateurs ne se rendent compte de rien : il suffit de changer l'alias DNS
  * il est également important de mettre en place un  **serveur DNS secondaire** (esclave) pour assurer la tolérance de panne 

===== Le serveur DHCP =====
  * **DHCP** : **Dynamic Host Configuration Protocol**
  * avec TCP/IP, chaque machine connectée au réseau doit disposer impérativement :
    * d'une **adresse IP unique** (sinon attention aux problèmes !!)
    * d'un **masque de sous-réseau** ad-hoc
    * d'un certain nombre de **paramètres TCP/IP** (adresse de passerelle, adresse serveur DNS, nom de domaine DNS, ...)
  
   
===== Le serveur DHCP - suite =====
  * le **serveur DHCP** affecte **automatiquement** à chaque machine une **adresse** et des **paramètres adaptés**, le tout **sans intervention** humaine 
  * au lycée le Castel, les paramètres TCP/IP sont au nombre de **8** et varient selon le réseau ... 
  * l'absence de serveur DHCP impliquerait que l'administrateur passe sur chacun des postes pour spécifier les paramètres.
  * les machines sont environ **400**
  
  * => le serveur DHCP est **indispensable** 


===== Le serveur de logs centralisé =====
  * **log** : fichier journal produit par le système 
  * affiche les différents messages générés par le système depuis les simples avertissement jusqu'aux erreurs les plus graves
  * indipensable pour établir des **diagnostics**
  * chaque serveur stocke ses propres logs, mais il est très simple de **centraliser** les logs sur une seule machine pour avoir une vision synthétique
  * des outils comme **logcheck** ou **swatch** peuvent prévenir en cas d'apparition d'évenement atypique

===== Un extrait de fichier log =====

<code>
Nov 18 16:11:43 pitou smbd_vscan-clamav[9456]: [2008/11/18 16:09:37, 0] smbd/service.c:make_connection(1102)
Nov 18 16:11:43 pitou smbd_vscan-clamav[9456]:   pccdi-00 (172.16.110.191) couldn't find service rentree2005
Nov 18 16:11:44 marge dhcpd: DHCPREQUEST for 172.16.110.157 from 00:1c:c4:66:de:e9 (PT245-11) via 172.16.110.254
Nov 18 16:11:44 marge dhcpd: DHCPACK on 172.16.110.157 to 00:1c:c4:66:de:e9 (PT245-11) via 172.16.110.254
Nov 18 16:11:52 marge dhcpd: ip length 312 disagrees with bytes received 392.
Nov 18 16:11:52 marge dhcpd: accepting packet with data after udp payload.
Nov 18 16:11:52 marge dhcpd: DHCPDISCOVER from 00:1e:c1:06:78:60 via eth0: network 172.16.0.2/32: no free leases
Nov 18 16:11:54 marge postfix/smtpd[22391]: connect from zenoss.lecastel.lan[172.16.0.9]
</code>


===== La gestion  des versions =====
  * les fichiers de configuration 
    * **nombreux** (souvent une dizaine ou plus par serveur)
    * souvent relativement **complexes**
    * **diffèrent** selon les versions et les distributions de Linux
    * sont **répartis** sur l'ensemble des machines
  * un **système de gestion de version** permet 
    * de **centraliser** les éléments de configuration
    * d'assurer le **suivi** et l'**évolution** des versions :
      * par qui ?
      * pourquoi ?
      * quand ?
    * permet les **retours arrière** et les **branchements**
  

===== La gestion  des versions : exemples =====
  * quelques exemples 

  * mise à jour du dépot :

  git commit -a -c "Chgt DNS"

  * affichage de l'historique

  git show log




===== La gestion  des versions : les logiciels =====
  * **cvs** (Concurrent Versions System) : l'ancêtre - montre ses limites
  * **subversion** (svn) : très utilisé actuellement
  * **git** : développé par Linus Torwalds et utilisé pour le développement du noyau Linux
  * la plupart offrent en plus des outils web en plus de la ligne de commande

===== le serveur Gold =====
  * serveur de fichier **stockant** les **documents** et **paramètres de référence**
  * paramètres **tirés** par les clients (mode //pull//) et non poussés par le serveur
  * pas une ressource critique : le réseau peut fonctionner sans lui.
  * offre les protocoles adaptés :
    * **NFS** : Network File System
    * **HTTP/WebDav**
    * **rsync**
  *  serveur **SSH** et **puppetmaster**
  * héberge un dépot **svn** ou **git** des fichiers de configuration
    

===== L'installation d'une machine Linux =====
  * long et fastidieux
  * mettre le CD-ROM 
  * répondre aux questions (nom de machine, langue, clavier, partitionnement, adresse réseau, paramètres proxy, paquetages à installer, ...)
  * téléchargement éventuel de paquetages et mises à jour
  * après le premier redémarrage, installer et configurer les logiciels
  * plus simple et plus rapide pour les machines virtuelles : on installe à partir de l'image ISO du CDROM stockée sur disque

===== les outils d'installation automatisés =====
  * le processus d'installation de serveur doit être quasi industriel
  * procédures quasi automatiques avec le minimum d'interventions humaines (mode unatended)
  * doit s'adapter aux machines
    * machines physiques //classiques//
    * machines virtuelles


===== Installation de machines physiques =====
  * réalisables en démarrant depuis une CDROM ou une clé USB
  * depuis le réseau avec PXE/DHCP
  * mode image utilisable mais peu souple
  * quelques logiciels 
    * **FAI** : Fully Automated Installation (Debian/Ubuntu)
    * **Cobbler** (Redhat), foreman (theforeman.org)

===== Cobbler =====
  * développé par **RedHat**
  * utilisable pour les machines **physiques** et les machines **virtuelles**
  * gère automatiquement PXE DHCP et NFS 
  * interface **Web** et interface ligne de commande
  * gestion encore imparfaite des Debian/Ubuntu

===== vmbuilder =====
  * développé par **Cannonical**
  * fonctionne avec Ubuntu 
  * permet de créer automatiquement des machines virtuelles (kvm, vmware, ...)
<code>
sudo vmbuilder kvm ubuntu --arch i386 --ip 192.168.0.100 
--part vmbuilder.partition 
--user user --name user --pass = default --tmpfs - 
--firstboot boot.sh --firstlogin login.sh 
--mirror http://mirroraddress:9999/ubuntu --suite intrepid --flavour virtual 
--addpkg apache2 --addpkg apache2-mpm-prefork 
--addpkg apache2-utils --addpkg apache2.2-common 
</code>
  * installation en moins de 5 minutes sans intervention humaine



===== les outils de configuration automatisés =====
  * une fois le système de base installé, installation des paquetages ad-hoc et configuration
  * la solution classique : **bash/ssh** + clés publique
<code bash>
for server in "pim pam poum" 
do
 ssh $server "aptitude update && aptitude upgrade -y" 
done
</code>
  * la solution plus évoluée : **dsh** Dancer Shell + clés publique
<code bash>
dsh -g lesserveurs "aptitude update && aptitude upgrade -y"
</code>

===== Configuration automatique : problématique =====
Le paysage vu d'un peu plus près est loin d'être idyllique, selon les distributions, les outils diffèrent :
  * **Debian/Ubuntu** : apt-get install <paquetage>
  * **RedHat/Fedora** : yum install <paquetage>

Les noms de paquetages également :
  * **apache2** pour Debian/Ubuntu, **httpd** pour Redhat/Fedora

Comme les répertoires de base :
  * **/etc/apache2** pour Debian/Ubuntu, **/etc/httpd** pour Redhat/Fedora








===== Les outils =====
  * ils permettent de spécifer les paquetages à installer, le format du partitionnement, les options de configuration ...
    * RedHat **kickstart**
    * Debian **preseed** : 
    * Solaris **Jumpstart**
  

===== les devops =====
  * **DevOps** = **Dev**lopment + **Ops** pour (//operations// : exploitation)
  * Patrick Desbois - 2009 - Gand
  * à l'origine, admins systems adeptes des méthodes //agiles//
  * résoudre le pb de la confrontation de l'équipe de développement et de l'équipe d'exploitation => collaboration entre les deux équipes
  * principes utilisé entre autres par Nokia, Google, American Express, Linkedin 2, Amazon3 et bien d'autres
  * **infrastructure as code**
  * principes : 
    * collaboration entre **dvlpt** et **syst/exploit**.
    * fluidification des processus
    * livraison dasn les temps
  * cf http://fr.slideshare.net/fabrice.bernhard/le-miracle-devops-symfony-live-paris-2014

===== les devops - suite =====
  * automatisation /industrialiasation
    * de l'installation, de la configuration
    * des tests
 
===== mode pull et mode push =====
  * mode **Pull** 
    * le client tire sa configuration d'un serveur distant et exécute les actions spécifiques à un modèle (puppet)

  * mode **Push**
    * une machine envoie successivement sur les clients la description des tâches à faire et les exécute

===== Configuration automatique : bilan provisoire =====

  * il peut être intéressant de trouver des outils permettant de faire abstraction (autant que possible) de la distribution utilisée : c'est le rôle des outils de gestion de configuration
  * quelques noms
    * **cfengine**
    * **puppet**
    * **chef**
    * **ansible**

===== les outils de configuration : cfengine =====
  * 1993 - Mark Burgess - University College - Oslo 
  * le premier logiciel de ce genre
  * écrit en langage C
  * utilise un système de classes et d'héritage
  * très mûr
  * fonctionne sur la plupart des Unix et Windows
  * évolution limitée depuis quelques années
  * passablement complexe et syntaxe parfois obscure

===== Puppet =====
  * **Puppet** est un outil de gestion de **configuration système**
  * conçu comme une version moderne de **cfengine**
  * **Puppet** fonctionne sur les systèmes de type **Unix**
  * rédigé en langage **Ruby** par **Luke Kanies** - http://puppetlabs.com
  * logiciel **Open-source**
  * fonctionnement **Client-serveur**
  * langage déclaratif

===== Puppet - Architecture =====
  * stocke de façon centralisée l'ensemble des configurations des machines
  * permet de définir des modèles (templates) avec de l'héritage et des exceptions pour simplifier le trvail
  * utilise HTTPS et des certificats
  * fonctionne sur toutes les architecture Linux (Debian/Ubuntu, Redhat, Suse) et Unix (Solaris, BSD, MacOS/X, ...) et même Windows depuis quelque temps

===== Mode de fonctionnement =====
  * le serveur **puppetmaster** contient la configuration commune ainsi que celle des noeuds (**nodes**)
  * vérifie la configuration d'un client toutes les 30 minutes par défaut

{{Puppet_Star.png}}



===== Puppet : le langage déclaratif =====
Puppet permet de décrire :
  * **classes** (permet de définir les confs de chaque service)
  * **héritage** (permet de regrouper les confs communes)
  * **types d’objets particuliers** (définis par puppet, ou par des modules ruby utilisateur)
  * **fonctions utilisateur**
  * **abonnement d’instances** à d’autres instances (ex, un service est abonné à son fichier de conf, la modif de l’un entraînera le redémarrage de l’autre)

===== Puppet : classe =====

  * un exemple de classe : **resolv.pp**
<code ruby>
class resolv {
 file { "/etc/resolv.conf":
   owner => root,
   group => root,
   mode => 644,
   source => [ "puppet://puppet/files/$hostname/resolv.conf",
                "puppet://puppet/files/etc/resolv.conf"]
 }
}
</code>
  * cette classe décrit le contenu du fichier **resolv.conf** utilisé  par la configuration réseau de chaque machine
  * elle décrit également les possesseurs, groupes et droits 
  * on remarque qu'à défaut de l'existence d'un **resolv.conf** specifique, on utilisera un **resolv.conf** générique

===== Puppet : classe - exemple 2 =====
  * Puppet est utilisé pour décrire une classe NTP (serveur de temps).
<code ruby>
class ntp {
 # On installe le paquetage si besoin
 package { ntp:
   ensure => installed,
  }
 # Le fichier de configuration
 file { "/etc/ntp.conf":
   source  => "puppet://puppet/files/etc/ntp.conf",
   # On declenche ce controle "file" apres l'install du package
   require => Package[ntp]
 }
 # On declare aussi le service ntp qui sera démarré et contrôlé
 service { ntp:
   ensure    => running,
   # Si le package ou le fichier de conf sont modifiés, on redémarre le service.
   subscribe => [Package[ntp], File["/etc/ntp.conf"]]
 }
}
</code>

===== Puppet : noeud =====  
  * fichier **node.pp** : definition des noeuds (machines)
<code ruby>
node generic-etch { #debian Etch generique
  include sudo, snmp-etch, ntp, timezone, etch-default-install, apt-etch, resolv
}
node webserver inherits generic-etch {
  include apache, php5
}
node mailserver inherits generic-etch {
  include postfix
}
node "ld.heberge.info" inherits webserver {
  $hostkind="alternc";
}
node "webpublic.heberge.info" inherits webserver, mailserver {
  include webpublic_resolv
}
</code>


===== Puppet : les templates =====

  * permettent de génerer  des fichiers textes très élaborés

<code>
<Location "/cgi-bin/<%= name %>.cgi">
    SetEnv TRAC_ENV "/export/svn/trac/<%= name %>"
</Location> 

# You need something like this to authenticate users
<Location "/cgi-bin/<%= name %>.cgi/login">
    AuthType Basic 
    AuthName "Trac" 
    AuthUserFile /etc/apache2/auth/svn
    Require valid-user
</Location>

</code>

===== Puppet : le serveur de fichiers =====
  * **puppet** dispose de son propre serveur de fichiers 
  * il n'est pas nécessaire d'installer un serveur spécifique (FTP, HTTP, SMB/CIFS, NFS ou autre) pour que les clients puissent récupérer les fichiers de configuration depuis le serveur
  * Puppet assure une sécurité de base : clauses **allow** et **deny**

===== Facter =====
  * librairie implantée sur le client 
  * renvoie des informations sur les caractéristiques de ce dernier
  * exemple (extrait d'information renvoyées par **Facter**)
 <code>
  architecture => i386
  domain => lecastel.lan
  fqdn => kid.lecastel.lan
  hostname => kid
  ipaddress => 172.16.0.34
  kernel => Linux
  kernelrelease => 2.6.27-7-generic
  lsbdistcodename => intrepid
  lsbdistdescription => Ubuntu 8.10
  macaddress => 00:15:f2:1f:92:5e
</code>




===== Puppet : l'utilisation au lycée Le Castel =====
  * **phase d'exploration** : 13 machines (70% virtuelles) sont gérées avec Puppet
  * serveurs Debian 60%, Ubuntu 30% + Fedora Core
  * environ une dizaine de classes définies
    * **resolv** : pour le fichier /etc/resolv.conf
    * **apache** : paquetage Apache + service 
    * **ssh** : paquetage ssh + service
    * **mc** : paquetage Midnight Commander
    * **source list** : serveur cache pour les paquetages (Debian Etch et Ubuntu Hardy)
    * **dhcp** : paquetage + service + configuration serveur DHCP
    * **bind** : paquetage + service + configuration serveur DNS maître
    * **wpad** : configuration automatique des navigateurs

===== Puppet : les limites =====
Puppet **n'est pas** :
  * un **outil d'installation** : Puppet s'applique à une machine en état de fonctionner (cf . FAI, Systeme Imager, Cobbler, ...)
  * un **outil de monitoring/supervision** (Nagios, ..) : mais Puppet peut générer la configuration nécessaire à un fonctionnement avec un outil de supervision 

===== Bilan =====
  * M. Renfro, auteur d'un document dont je me suis largement inspiré indique qu'avec 
    * **DHCP/PXE** , 
    * le **preseeding**
    * puis **Puppet**,
  * il installe **Linux Debian** sur un serveur **Dell PE1435** en **moins de 10 minutes** avec **une seule frappe clavier** (F12 pour démarrer en PXE)
  * à la fin de l'installation, les paquetage sont mis en place, les tâches de post-installation sont effectuées par Puppet et le serveur **accepte une connexion ssh sans mot de passe** grâce à une clé publique installée.

===== Qui utilise Puppet ? =====
  * de plus en plus de monde 
  * **Google** pour son parc de Mac (6000 machines)
  * l'**Université de Stanford**
  * **Université de Georgie** (EU) : 500 machines
  * **Alfresco**
  * globalement, beaucoup d'organisations utilisant le Cloud (//openstack// + //puppet// : 400 m resultats).
=====  Puppet : quelques liens =====
  * installation sur Debian Wheezy : http://nyxi.eu/blog/2013/10/22/puppetmaster-on-debian-wheezy/
  * autre installation : http://blog.nicolargo.com/2012/09/puppet-installation-et-premiere-configuration.html
  * sur Debian Administration (Ancien)
    * https://www.debian-administration.org/article/526/1/2_An_introduction_to_using_Puppet
    * https://www.debian-administration.org/article/528/2/2_An_introduction_to_using_Puppet
===== Puppet - Bilan =====
  * outil puissant qui permet de simplifier énormément la configuration des systèmes
  * une **communauté très active** avec des règles/recettes de plus en plus riches et efficaces
  * env. 10 M de résultats Google
  * fonctionne avec Windows

 
===== Puppet - les limites =====
  * nécessité d'un client ruby très gourmand en mémoire sur chaque machine - lancement possible par crontab
  * mode **pull**  (tiré par le client) **non déterministe** : on ne sait pas quand se déclenchent les actions
  * gestion de certificats pénible
  * forte charge induite sur le serveur

===== Une autre approche: Ansible =====
  * un logiciel de déploiement/configuration à distance
  * créé par M. De Hann ( Redhat : Cobbler et Func)
  * écrit en python
  * utilise seulement **SSH** 
  * pas besoin de serveur : un simple station de travail suffit
  * mode **push** mais également en mode **pull**
  * le client ne nécessite que python 2.4+
  * extensible en n'importe quel langage


===== Ansible - les bases =====
Quelques liens :

  * cf http://slideshare.net
  * http://fr.slideshare.net/johnthethird/ansible-presentation-24942953
  * http://fr.slideshare.net/pas256/code-mash
  * http://fr.slideshare.net/bcoca/ansible-config-mgmt
===== Ansible - les playbooks =====
  * fichier texte au format **yaml** décrivant les actions à effectuer
exemple : installation d'**apache2** + **php5** sur une Linux Debian
<code yaml>
# playbook.yml
---
- hosts: all
  tasks:
    - name: 1. install Apache
      apt: name=apache2 state=present

    - name: 2. install PHP module for Apache
      apt: name=libapache2-mod-php5 state=present

    - name: 3. start Apache
      service: name=apache2 state=running enabled=yes

    - name: 4. install Hello World PHP script
      copy: src=index.php dest=/var/www/index.php mode=0664
</code>
===== Ansible - le bilan =====
  * projet très actif 
  * mise en oeuvre simple
  * de nombreux playbooks comme base de travail en particulier sur **github**


===== Ansible - quelques liens =====
  * http://ansible.com 
  * **devops** + **ansible** : https://devopsu.com/ avec une newsletter
  * une petite demo : 
    * http://sametmax.com/introduction-a-ansible-loutil-du-sysadmin-paresseux-mais-pragmatique/
  * http://kovda.blogspot.fr/2013/09/ansible-lorchestration-facile.html
  * http://kovda.blogspot.fr/2013/09/ansible-lorchestration-facile-22.html




===== Bilan global =====
  * **Puppet** 
    * lent, nombreux OS, nombreuses librairies - qualités diverses, interf. web payante, installation lourde, très mûr
  * **chef** 
      * concu comme le successeur de puppet, plus rapide, interf. web gratuite, 
  * **ansible**
    * arch. très simple, rapide, pas d'agent, Unix/Linux seulement, apprentissage facile, pas aussi mûr mais en développement très rapide

cf http://kangaroot.net/easy-server-configuration-management

===== Merci de votre attention =====