Actualités

[23/04/2014] Pour sa 3ème édition le CMSday prend une nouvelle envergure

Rendez-vous le Mardi 17 juin 2014 à Paris. Une surface d'exposition doublée, plus de 1 000 visiteurs attendus, 3 nouveaux co-organisateurs, le CMSday sera cette année, le rendez-vous phare de la gestion de contenu open source et des stratégies digitales.

[11/04/2014] Smile gagne un Jedox Award

Smile reçoit le trophée de Meilleur Partenaire Jedox de l'année.

[10/04/2014] Smile co-organisateur du Bargento 2014

Smile et NBS System s’associent pour l’organisation du Bargento qui se tiendra le 7 octobre prochain à Paris.

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

Déploiement d'un serveur avec Puppet sans PuppetMaster

Découvrez des astuces pour déployer un serveur avec Puppet sans PuppetMaster.

1. Contexte

Il est souvent fastidieux et aussi un peu rébarbatif d'avoir à déployer un nouveau serveur qu'on a déjà installé à maintes reprises, pour différents clients. Il est toujours possible de passer par un script qui réalise le déploiement d'une partie des composants à sa place, mais le jour ou les pré-requis diffèrent, ou que l'architecture demandée est différente, il faut nécessairement replonger dans le script pour l'adapter, le faire évoluer et cela devient difficile à maintenir à terme, notamment lorsqu'il faut ajouter ou supprimer des briques logiciels.

L'idéal est de passer par un gestionnaire de configuration tel que Puppet. Classiquement Puppet fonctionne en mode client/serveur ou un agent est déployé sur les machines que l'on souhaite gérer et qui récupère leur configuration hébergée sur un serveur central appelé Puppet Master. Dans le cas ou on souhaite déployer uniquement un ou deux serveurs pour lesquels on n'aura pas à maintenir la configuration une fois l'installation terminée, il n'est pas forcément judicieux de passer par l'installation d'un Puppet Master, d'autant plus si l'installation d'une machine supplémentaire pour assurer ce rôle n'est pas possible.

Je vais donc présenter ici comment il est possible de le faire avec Puppet en s'affranchissant de l'installation du Puppet Master.

L'idée est d'utiliser directement la configuration réalisée sur un Puppet Master en l'important sur le serveur pour lequel on souhaite réaliser le déploiement et ensuite d'utiliser la commande client de Puppet pour l'appliquer en spécifiant les modules qui doivent être mis en place sur le serveur. On conserve ainsi la puissance de Puppet, sa modularité et ses facilités de configuration pour réaliser le déploiement d'une machine.

L'exemple présenté ici est volontairement simplifié et pourrait être grandement amélioré, mais l'objectif de cet article est avant tout de présenter le principe et la méthode pour y parvenir plutôt que d'en faire un tutoriel complet.

2. Création de la configuration Puppet

La configuration Puppet qui sera mise en place ici doit nous permettre de déployer une infrastructure LAMP qui peut être composée d'un ou plusieurs serveurs pour gérer la scalabilité. Nous allons donc utiliser la modularité de puppet pour isoler la base et le serveur web en deux modules distincts et ainsi pouvoir choisir d'installer uniquement un serveur Apache, ou un serveur MySQL ou bien les deux en même temps.

A noter que la configuration présentée ici peut-être réalisée sur n'importe quelle machine sur laquelle sont installées les librairies Puppet et le client Puppet (package puppet-common sous Debian). L'agent Puppet et le Puppet master ne sont ici pas nécessaires.

Nous allons créer un répertoire "modules" qui contiendra les modules de configuration Puppet que nous allons mettre en place :

  • modules : répertoires contenant les modules
  • modules/base : module permettant de réaliser la configuration du système qui sera générique à toutes les installations (packages par défaut, configuration du client mail, service de temps, etc.)
  • modules/mysql : module de configuration du serveur MySQL
  • modules/apache : module de configuration du serveur Apache

A l’intérieur de chacun de ces trois modules, nous retrouvons l'arborescence classique d'un module puppet composé de :

  • manifests/init.pp : configuration puppet du module
  • templates/* : répertoire contenant les fichiers de templates à déployer sur le serveur
  • files/* : répertoire contenant les fichiers de configuration à déployer sur le serveur

Pour illustrer ce cas d'utilisation, voici le détail des fichiers de configuration Puppet de chacun des 3 modules créés :

  • modules/base/manifests/init.pp :
 class base
{
    # Package par défaut à installer sur le serveur
    $packages = ['less','tmux','strace','vim','sudo','mtr-tiny','lsof','diff','dstat','atop']
    package { $packages :
        ensure => present
    }
    # Fichier de configuration de vim de l'utilisateur root
    file { "/root/.vimrc" :
        ensure  => present,
        content => template('base/root.vimrc'),
        owner   => root,
        group   => root,
        mode    => 0644
    }
    # Il est ensuite possible d'inclure d'autres modules qu'on aurait préparé
    #include ntp
    #include ssh
    #include syslog
    #include postfix
}
  • modules/apache/manifests/init.pp:
 class apache
{
    # Installation des packages Apache et PHP5
    $packages = [ 'apache2', 'libapache2-mod-php5' ]
    package { $packages :
        ensure => present
    }
    # Définition de l'état du service Apache
    service { apache2 :
        ensure => running,
        enable => true
    }
    # Fichiers de configuration des services Apache2 et PHP5
    file { "/etc/apache2/apache2" :
        ensure  => present,
        content => template('apache/etc.apache2.apache2.conf'),
        owner   => root,
        group   => root,
        mode    => 0644 
    }
    file { "/etc/php5/apache2/php.ini" :
        ensure  => present,
        content => template('apache/etc.php5.apache2.php.ini'),
        owner   => root,
        group   => root,
        mode    => 0644
    }
}
  • modules/base/manifests/init.pp:
 class mysql
{
    # Installation du package MySQL
    package { mysql-server :
        ensure => present
    }
    # Définition de l'état du service MySQL
    service { mysql :
        ensure => running,
        enable => true
    }
    # Fichier de configuration du service MySQL
    file { "/etc/mysql/my.cnf" :
        ensure  => present,
        content => template('mysql/etc.mysql.my.cnf'),
        owner   => root,
        group   => root,
        mode    => 0644 
    }
}

3. Test de la configuration

Maintenant que les modules sont créés et que les fichiers templates sont disposés dans les répertoires templates de chacun des modules, il est possible avec la commande puppet apply et l'option --noop de tester le fonctionnement de la configuration sans l'appliquer. Par exemple pour installer le module base:

 root@puppet# puppet apply --modulepath=puppet-conf/modules/ -e "include base" --noop

Il est important de préciser le répertoire qui contient les modules à utiliser avec l'option --modulepath, sinon tenterait de les chercher dans /etc/puppet/modules.

De la même manière, nous pouvons procéder au test d'installation des trois modules base, apache et mysql en une seule fois :

 root@puppet# puppet apply --modulepath=puppet-conf/modules/ -e "include base,apache,mysql" --noop

Pour appliquer la configuration, il suffit de retirer l'option --noop.

4. Création d'un manifest

Pour simplifier le déploiement, il est possible de créer des fichiers manifests qui incluent l'ensemble des modules à déployer. Par exemple, pour réaliser l'installation d'un serveur LAMP, on pourrait créer le fichier manifest lamp.pp suivant :

include base
include apache
include mysql

On peut donc avoir plusieurs déclinaisons de ce fichier pour réaliser uniquement l'installation du serveur Apache (apache.pp) ou uniquement l'installation du serveur MySQL (mysql.pp).

La commande suivante permet de tester l'installation en utilisant le fichier manifest :

 root@puppet# puppet apply --modulepath=puppet-conf/modules/ pupet-conf/lamp.pp --noop

Il est possible d'enrichir ces fichiers manifests et d'ajouter des variables pour les options de configuration qui seront spécifiques à chacune des installations (compte utilisateur à créer, liste des serveurs NTP, type d'OS, configuration réseau, etc.).

Finalement, voici à quoi ressemble l'arborescence de notre configuration Puppet :

 puppet-conf 
├── apache.pp 
├── lamp.pp 
├── modules 
│   ├── apache 
│   │   ├── manifests 
│   │   │   └── init.pp 
│   │   └── templates 
│   │       ├── etc.apache2.apache2.conf 
│   │       └── etc.php5.apache2.php.ini 
│   ├── base 
│   │   ├── manifests 
│   │   │   └── init.pp 
│   │   └── templates 
│   │       └── root.vimrc 
│   └── mysql 
│       ├── manifests 
│       │   └── init.pp 
│       └── templates 
│           ├── etc.mysql.my.cnf 
│           └── root.my.cnf 
└── mysql.pp

5. Déploiement de la configuration sur le serveur cible

Il faut ensuite générer une archive complète de la configuration Puppet et la déposer sur le serveur cible, puis installer le package puppet-common contenant le client Puppet ainsi que les librairies ruby qui seront nécessaires pour déployer la configuration :

root@serveurcible# aptitude install puppet-common
root@serveurcible# tar xvzf puppet-conf.tar.gz -C /tmp
root@serveurcible# puppet apply --modulepath=/tmp/puppet-conf/modules/ /tmp/pupet-conf/lamp.pp
root@serveurcible# rm -rf /tmp/puppet-conf/
root@serveurcible# aptitude purge puppet-common

Voilà, le serveur est installé et pré-configuré avec la configuration Puppet que nous venons de réaliser !

Notez qu'une fois la configuration déployée, le client Puppet et sa configuration ne sont plus nécessaires et peuvent donc être supprimés, ce que font les 2 dernières lignes ci-dessus.

Il est donc assez facile – et pratique ! - de déployer une configuration sur un serveur sans Puppet Master surtout si l'on possède déjà des configurations et des modules bien configurés sous Puppet. Dans le cas contraire, il sera nécessaire de réaliser une première fois cette configuration sous Puppet, ce qui peut prendre un peu de temps au début, mais qui devrait permettre d'être rentabilisé rapidement.

Sébastien Giraud
picto

Commentaires

Soyez la premiere personne à ajouter un commentaire sur cet article.
Ecrire un nouveau commentaire