Gestion de configuration

03/11/2020

Ph. Sevre

1. Avant-propos d'après Larry Wall
2. Etat des lieux
3. La virtualisation
4. Les infrastructures
5. L'installation automatique
6. cfengine
7. puppet
8. ansible
9. Conclusion

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

• 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 …)

• court, c'est encore trop long !!
• en faire le moins possible, c'est toujours attendre …
• il faut concevoir et utiliser des outils efficaces …

• 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 …

• montée en puissance de la virtualisation
• montée en puissance du cloud (OpenStack, Docker)
  • plus de serveurs
  • plus de services demandés

• 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

• 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

• 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

• 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)

• 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

• 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 +)

• 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 ?

• l’efficacité passe d'abord par une infrastructure adaptée

• 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

• 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 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

• 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 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

• 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

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]

• 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

• quelques exemples

• mise à jour du dépot :

git commit -a -c "Chgt DNS"

• affichage de l'historique

git show log

• 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

• 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

• 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

• 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

• 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)

• 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

• développé par Cannonical
• fonctionne avec Ubuntu
• permet de créer automatiquement des machines virtuelles (kvm, vmware, …)

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 

• installation en moins de 5 minutes sans intervention humaine

• une fois le système de base installé, installation des paquetages ad-hoc et configuration
• la solution classique : bash/ssh + clés publique

for server in "pim pam poum" 
do
 ssh $server "aptitude update && aptitude upgrade -y" 
done

• la solution plus évoluée : dsh Dancer Shell + clés publique

dsh -g lesserveurs "aptitude update && aptitude upgrade -y"

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

• ils permettent de spécifer les paquetages à installer, le format du partitionnement, les options de configuration …
  • RedHat kickstart
  • Debian preseed :
  • Solaris Jumpstart

• DevOps = Devlopment + 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

• automatisation /industrialiasation
  • de l'installation, de la configuration
  • des tests

• 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

• 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

• 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 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

• 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

• 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 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)

• un exemple de classe : resolv.pp

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"]
 }
}

• 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 est utilisé pour décrire une classe NTP (serveur de temps).

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"]]
 }
}

• fichier node.pp : definition des noeuds (machines)

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
}

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

<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>

• 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

• librairie implantée sur le client
• renvoie des informations sur les caractéristiques de ce dernier
• exemple (extrait d'information renvoyées par Facter)

  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

• 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 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

• 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.

• 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).

• 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

• 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

• 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

• 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

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

• fichier texte au format yaml décrivant les actions à effectuer

exemple : installation d'apache2 + php5 sur une Linux Debian

# 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

• projet très actif
• mise en oeuvre simple
• de nombreux playbooks comme base de travail en particulier sur github

• 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

• 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