Cuisinez vos serveurs comme un Chef – Première partie

La majorité des projets actuels utilisent un framework, que ce soit Symfony2, RoR ou encore Django… Leurs avantages sont indéniables :

  • La rapidité des développements ;
  • La qualité du socle applicatif ;
  • La cohérence par l’utilisation de normes et de bonnes pratiques ;
  • La maintenabilité du projet est améliorée (bien que ce dernier point reste théorique).

Mais qu’en est-il de l’infrastructure serveur ? Nombreux sont ceux qui parlent de Chef, de Puppet ou encore d’autres frameworks de scripts, mais qui les emploie vraiment ? À ma connaissance, très peu de projets utilisent réellement ce type de logiciel en production (si vous le faites déjà, merci de laisser un commentaire). 

Je ne vais pas refaire un énième article au sujet de l’utilité ou de la comparaison de ces outils, et vous invite plutôt à consulter un article détaillé sur le blog d’Octo.

Si ces outils sont si peu utilisés, c’est surtout en raison de leur méconnaissance – non pas des avantages qu’ils procurent, mais surtout de leur mode d’utilisation. C’est pourquoi ce billet est le premier d’une série d’articles qui va présenter différents aspects de ces outils, depuis l’installation de Chef en environnement local jusqu’à son utilisation en production dans le cadre d’un projet Symfony2. Pourquoi Chef, et pas Puppet ? Ils sont tous les deux assez similaires, j’avoue avoir été plus à l’aise avec Chef, et enfin ce retour d’expérience m’a conforté dans mon choix.

Objectif

Logo de l'outil Chef La première chose à faire, lorsqu’on souhaite écrire des scripts avec Chef (ou avec d’autres frameworks de déploiement scriptés), consiste à bien définir la cible. Quelle sera l’architecture de production ? Quel sera le système d’exploitation utilisé ? Quelles applications devront être installées ? Quelles sont les évolutions futures possibles de cette architecture et de ces applications ? En premier exemple, nous allons considérer une cible classique pour un projet de moyenne envergure :

  • 1 serveur Web en front ;
  • 1 serveur de tâches ;
  • 1 serveur de données

Et ces différents logiciels :

  • Serveur Web délivré avec Apache 2 et PHP ;
  • Serveur de tâche géré avec crontab et PHP ;
  • Serveur de données avec MySQL

La mise en place de Chef s’apparente à la préparation d’un ensemble de scripts qui permettront de configurer automatiquement l’application Symfony2 sur ces différents serveurs de production. Évidemment, il faut que ces scripts soient également exécutables sur les environnements de développement et de recette, afin de garantir une configuration inter-environnements homogène, et s’offrir ainsi des conditions de test pertinentes avant l’exécution réelle, en production, des scripts Chef.

Localhost

Pour rappel, le fonctionnement de Chef (ou même de puppet) est le suivant : un serveur Chef partage les scripts de déploiement avec ses différents noeuds, et ces derniers les exécutent.

En plus d’être assez compliquée pour le novice, la mise en place complète de cette chaîne de déploiement est par ailleurs inutile dans les environnements locaux, où le seul besoin est l’exécution des scripts Chef. Chef Solo, regroupant le serveur Chef et le client au sein d’un même logiciel, permet l’abstraction de cette communication Chef-client, tout en gardant les mêmes fonctionnalités.

Cependant, installer Chef Solo directement sur un environnement local est une pratique risquée que nous déconseillons, dans la mesure où cela présente le risque de créer des conflits avec les applications déjà installées (ou leur configuration) et ne permet pas d’identifier facilement les dépendances réelles du projet : il vaut mieux utiliser un système nu, ce qui mettra en évidence l’oubli de telle ou telle dépendance de fonctionnement du projet. 

Cette problématique peut aisément être contournée par l’utilisation d’une machine virtuelle installée avec Vagrant, un outil Open-Source permettant de gérer des machines virtuelles. Vagrant permet, via son fichier de configuration, un provisionnement aisé des scripts Chef. Enfin, il existe une liste de machines virtuelles pré-configurées avec Chef-Solo (ou Puppet), ce qui permet un déploiement rapide de VMs.

Logo de Vagrant

La documentation officielle de Vagrant est vraiment de qualité, elle vous guidera pas à pas dans son installation. Vagrant possède par ailleurs une gestion de plugins qui rajoutent des fonctionnalités pour plus de confort :

  • vagrant-vbguest : un plugin permettant l’installation des guests additions correspondant à la version de VirtualBox ;
  • vagrant-hostmaster : ce plugin permet l’ajout facile d’entrées DNS locales dans le fichier /etc/hosts au lancement de la machine virtuelle, et leur suppression à son arrêt.

Ces deux plugins s’installent facilement via les commandes suivantes :

vagrant gem install vagrant-vbguest
vagrant gem install vagrant-hostmaster

Installation d’une box

Une fois Vagrant installé, nous avons besoin d’une « box ». Pour les besoins de cette suite d’articles, je vous recommande fortement soit une box basée sur Debian (Debian, Ubuntu), soit une basée sur Redhat (Rhel, Centos, Scientific, …). Les scripts présentés fonctionneront sur ces deux types de systèmes, ce qui permettra de voir les points critiques à vérifier lorsque l’on crée des scripts qui doivent fonctionner sur plusieurs OS.

Pour l’installation d’une box, placez-vous dans le répertoire où vous voulez l’installer, et jouez les commandes suivantes (Exemple pour Ubuntu Lucid version 64bits) :

cd /where/you/want
vagrant box add lucid64 http://files.vagrantup.com/lucid64.box
vagrant init lucid64
vagrant up

Knife Solo

Hey look, I'am a cook Knife est un outil en ligne de commande fourni avec Chef qui permet de communiquer des ordres au serveur maître. Knife-Solo est une extension de cet outil, qui lui ajoute des commandes afin de mieux gérer la création et la gestion de scripts Chef.

Knife-Solo s’installe via rubygems avec la commande suivante :

gem install knife-solo 

Si vous êtes sous Windows avec cygwin (shame on you), il vous faudra les paquets suivants avant de procéder à cette installation :

  • g++
  • make
  • ruby

Si vous avez bien tout suivi, vou êtes maintenant prêt à écrire et tester de premières recettes Chef. Pour cela, je vous donne rendez-vous dans un prochain article !

blog comments powered by Disqus