~~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 =====
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]
===== 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, ...)
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
===== 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
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"
===== 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
* **RedHat/Fedora** : yum install
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**
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 : classe - exemple 2 =====
* 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"]]
}
}
===== Puppet : noeud =====
* 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
}
===== Puppet : les templates =====
* permettent de génerer des fichiers textes très élaborés
.cgi">
SetEnv TRAC_ENV "/export/svn/trac/<%= name %>"
# You need something like this to authenticate users
.cgi/login">
AuthType Basic
AuthName "Trac"
AuthUserFile /etc/apache2/auth/svn
Require valid-user
===== 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**)
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
===== 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
# 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
===== 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 =====