Automatisation de l’administration systèmePlan

Problèmatique : trop de systèmes, trop de solutionsTypage des solutionsPuppet : gestion de configuration de systèmesCapistrano : déploiement d’applicationsUtilisation dans un service informatique

pierre.gambarotto@ .fr

Problématique : pourquoi plus de systèmes à gérer ?plus de services à gérerapplications web : transfert du coût de gestion du poste client au serveurcomplexité des infrastrucutres : environnements de prod, pré-prod, test, dev …généralisation du poste client

Les solutions triviales et leurs inconvénients :acheter des machines supplémentaires : coût en argent, mauvaise utilisation des ressourcesmatériellesinstaller les nouveaux services sur des systèmes existant : adhérence des applications, frein à lamise à jour : coût maintenance/sécurité, mauvaise utilisation des ressources humaines

Rationalisation des architecturesplus simple de gérer un système avec un nombre réduit de services (1 !)virtualisation des systèmes : meilleure utilisation des ressources matèriellescloud/hébergement : plus de ressources matérielle

Chaque système …

Les solutions techniques pour automatiser

classification en 3 couches

Installer le système de base2 grandes catégories :

machine réellemachine virtuelle : at home et cloud

Prérequis :accès à la machine physique ou accès authentifié au socle (ou compte pour le cloud)

Résultat :un système configuré, administrable par accès réseau

Gestion par prototype : installer un nouveau système à partir de la sauvegarde d’un ancien

ne gère pas les évolutions : dérive des configurationsla configuration est à faire à chaque fois manuellement

Configurer/mettre à jourscripter la configuration d’un système , une configuration = un script

Prérequissystème configuré, accessible par le réseauun compte administrateur sur le système

Résultatgérer plusieurs systèmes similaires avec la même configurationautomatiser certaines mises à jourrassembler dans un même endroit la description de tout le parcpassage de gestion de machine à gestion de parcautomatisation de l’intégration avec la supervision

Déploiement d’applications délégué à un tiersDéléguer une partie de la gestion d’un système à un tiers

Cas typique : application webserveur http, serveur BD : installation, configuration et mises à jour gérées par une personnedéploiements gérés par une autre personne

Prérequisserveur(s) installé(s) et configuré(s)séparation des comptes d’administrateur système et déploiement d’application

Résultatbonne entente des Administrateurs Systèmes et des Développeursgestion d’architecture de déploiement complexes

Études d’exemplesPuppet : gestion de configuration

Capistrano : déploiement d’applications

Puppet: gestion de configuration

architecture client/serveurconfiguration : décrite avecun DSLconfiguration :implémentation deressourcesressources : package, file,exec, service …

Puppet: DSL

DSL : une configuration est exprimée dans unlangage spécifique

Ressource : brique de basetype de la ressource : fixe les paramètres deconfigurationréaliser la ressource : donner une valeur auxparamètres

12345

file { "/etc/passwd": # nom unique donné à la ressource owner => root, # paramètre owner, valeur donnée : root group => root, mode => 644}

Type de ressourcesFile : gestion de fichier, le contenu d’unfichier peut être défini par un template. Leserveur puppetmasterd sert de serveur defichier.Exec : exécution de scriptPackage : installation de paquetageUser : définition d’utilisateurbien d’autres disponiblesextensible

Langage complet123456789

$ssh = $operatingsystem ? { # $operatingsystem : remonté par facter (redhat|fedora) => 'openssh-server', (debian|ubuntu) => 'ssh', default => 'openssh'}

package { $ssh: # $ssh est la variable définie ci-dessus ensure => installed,}

variables, conditionnelles, gestionde chaînes de caractères, tableauxde valeurs …sur le client, facter collecte desdonnées exposées sous forme devariables.

Gestion des dépendances entre les ressources123456789

10111213141516

file { '/etc/ssh/sshd_config': source => 'puppet:///modules/sshd/sshd_config', # on récupère le contenu du fichier sur le serveur owner => 'root', group => 'root', mode => '640', notify => Service['sshd'], # redémarage de sshd après changement de ce fichier require => Package[$ssh], # on force l'ordre de résolution, le paquetage avant le fichier de configuration}

service { 'sshd': ensure => running, enable => true, # actif au boot de la machine hasstatus => true, hasrestart => true,}

Puppet : organisation des descriptionspar défaut : les ressource sont réalisées sur tous lesclients puppet123456789

10111213141516

node 'machine.domaine.tld' { # restriction de la réalisation de # ressources à un système spécifique }

class NomClasse { # Définit un espace de nommage }include NomClasse # réalisation des ressources définies dans la classe

define mon_type($var1, $var2) { # définition d'une collection de ressources # utilisant var1 et var2 }mon_type { nom : # réalisation du type personnalisé mon_type var1 => valeur, var2 => valeur}

Configuration d’un produit completensemble de classes et de types de ressources personnalisésdéfinition d’une collection de ressourcesfichiers et template définissant le contenu des ressources File

Moduledistribution de la configuration d’un produit completpar exemple :

un serveur Apache et un site virtuelun serveur de base de données et une baseun serveur ldap maître et un serveur ldap esclave

KerberosServeur esclave :

123456789

1011121314

node 'krb-slave.enseeiht.fr' { include kerberos

$kerberos_realm="INP-TOULOUSE.FR" kerberos::server{$kerberos_realm: master => "krb-master.enseeiht.fr", password => "...", domains => ["enseeiht.fr", ".enseeiht.fr", "ensat.fr", ".ensat.fr", "ensiacet.fr", ".ensiacet.fr","inp-toulouse.fr", ".inp-toulouse.fr"], default_domain => "inp-toulouse.fr" } # extrait, manque conf des principaux kerberos}

KerberosServeur maître :

123456789

10111213

node 'krb-master.enseeiht.fr' { include kerberos

$kerberos_realm="INP-TOULOUSE.FR" kerberos::server{$kerberos_realm: password => "...", domains => ["enseeiht.fr", ".enseeiht.fr", "ensat.fr", ".ensat.fr", "ensiacet.fr", ".ensiacet.fr","inp-toulouse.fr", ".inp-toulouse.fr"], default_domain => "inp-toulouse.fr" } # extrait, manque conf des principaux kerberos}

Kerberos : export de ressource des esclaves vers lemaître

123456789

101112131415161718

class kerberos # extrait define server($realm="", $password, $domains="", $master=true, $default_domain="") { case $master { true: { # définition config pour le serveur maître } default:{ # slave server with master defined @@file{"/etc/krb5kdc/$realm_real/servers/$fqdn": tag => "kerberos_$realm_real", ensure => present, owner => root, group => root, mode => 640, } ... other stuff } }}

Gestion de parc@@file{ ... } : ressource définie sur unclient puppet, réalisée sur un autre clientpuppetles constituants définissant la ressource(ici de type File) sont stockés sur leserveur

Kerberos : réalisation de la ressource définie sur lesesclaves sur le maître :

123456789

101112131415161718

class kerberos # extrait define server($realm="", $password, $domains="", $master=true, $default_domain="") { case $master { true: { File <<| tag == "kerberos_$realm_real" |>>{ } # other stuff } default:{ # slave server with master defined } } }}

Gestion de parcréalisation de ressources exportées : File <<|... filtre ... |>> {}les informations stockées par un client puppetsur le serveur sont utilisées pour définir laconfiguration d’un autre client puppet

Sur le maître, un fichier portant le nom del’esclave est crée dans/etc/krb5kdc/$realm_real/servers.le script de propagation maître => esclavespeut maintenant utiliser cette information

Puppet : bilanPuppet permet de rédiger des procédures d’installation et de configuration complètes:

Avantagesla documentation de la procédure est la procédure elle mêmela mise à jour de la procédure permet la mise à jour de tous les serveurs sur lesquels elle estemployée.caractère open-source : la communauté redistribue des définitions complètes de modules.gestion centralisée : la configuration d’un client peut être définie à partir de celles d’autres clientspermet à un grand nombre de personnes de collaborer

Inconvénientscourbe d’apprentissage longuearchitecture structurante, complexe à mettre en oeuvre au niveau organisation

Études d’exemplesPuppet : gestion de configuration

Capistrano : déploiement d’applications

Capistrano

librairie rubypermet de décrire et d’exécuter des scripts surplusieurs machinesemploi typique : déployer une application websur des systèmes déjà configurésgestion de tâches interdépendantes (à laMakefile)surcouche SSH pour la gestion des connexionsgestion par transaction possible

Capistrano : syntaxefichier Capfile :

123456789

1011

role :db, 'postgres.domain.tld' # définition de serveurs avec leur rôle associérole :app, 'backend.domain.tld'role :web, 'frontend.domain.tld'set :user, "pierre" # définition de variable

desc "Description de la tâche" # définition d'une tâchetask :my_task, :roles =>:app,:web do # restriction de la tâche aux serveurs remplissant les rôles spécifiés run "echo #{user} fait des choses > /tmp/example"end

after("another_task, "my_task") # ordonnancement des tâches

Invocation : cap my_task

L’action de la tâche my_task est exécuté sur les serveurs :app(backend.domain.tld) et:web(frontend.domain.tld) avec le login pierre.

Capistrano : librairie de baseActions possibles dans une tâche capistrano :

exécution de commande sur un serveur distant : run, paralleltransfert de fichiers : local vers distant : put, uploadtransfert de fichiers : distant vers local : get, download

Capistrano est fourni par défaut avec des tâches adaptées aux conventions suivantes :

tout le code réside dans un SCM, type subversion ou gitles serveurs visés : SGBD, HTTP

1234567

cap deploy:setup # initialisation : création de répertoire

cap deploy:update # déploiement du code à partir de la dernière version du SCM

cap deploy:start, deploy:stop, deploy:restart # contrôle de l'exécution de l'application

cap deploy:revert # retour à la version précédente

Capistrano : bilanCapistrano permet d’automatiser le déploiement d’une application dans des environnementscomplexes (multi-serveurs).

Les plussimple : makefile+sshfait gagner beaucoup de tempsla configuration par défaut est utilisable sanscomprendre le produitcommunauté : tâches spécifiques pour certainsenvironnements/déploiements spécifiques

Les moinsapprentissage pour étendre les tâches par défauton peut gérer entièrement un serveur distant : ce n’est pas le but !

Récapitulatif des bénéfices de chaque type de solutionInstallation initiale du système

réduction du coût d’installation d’une machineutilisation optimisée des ressources matérielles1 système == 1 service : réduction du couplage, facilité d’adminitration/évolution

Configuration des systèmescentralisation des descriptions : modulariser, réutilisergestion de parc : automatiser l’inscription à la supervision

Délégation de déploiementséparation des rôles développeur/administrateurcommunication par spécification d’interface

Comment intégrer ces produits dans son servicePolitique d’un service informatique

nombre de personnescentralisationorganisation (hiérarchie)

Méthodologies : COMMUNIQUER !

approche de la base : faible nombre, peucentralisé, organisation lâche

approche descendante : organisation forte,centralisée, nombre importantla réalité est souvent entre les extrêmes …

Faire intervenir les solutions

collaboration développeur/sysadmin : produittype Capistranoapproche techniquenombreux retours d’expérience

approche institutionnelleapproche formelle : décrire pour mieux gérernécessite un engagement politiquecaractère structurant des produits type Puppet

Conclusion et perspectiveDépart

explosion du nombre de systèmes à gérerpléthore de solutions techniques

Arrivéedes cases où mettre les solutions2 exemplescomment insérer ces solutions dans son quotidien

Vos questions ?