Capistrano est un produit open source qui permet d’associer des machines à des rôles (exemple : role :web, « frontal1 », « frontal2 ») et d’exécuter une tâche donnée en parallèle sur toutes les machines d’un ou plusieurs rôles. Il permet également de capitaliser les connaissances sur les différentes tâches de l’infrastructure et les rend reproductibles et centralisées, donc fiables. Il se connecte en SSH et donc assure un niveau de sécurité minimum.

Version IPhone
Version IPod

Puppet et Capistrano sont 2 outils ayant pour but de capitaliser les connaissances sur le fonctionnement d’une infrastructure et de l’automatiser de façon à l’homogénéiser et la fiabiliser.

Chacun des outils à son propre rôle et utiliser les 2 est une très bonne solution, Puppet étant attaché au maintient d’une configuration iso à tout moment entre chaque machine d’un même type et Capistrano permettant d’exécuter des tâches plus ou moins complexes en parallèle sur des groupes de machines assignées à des rôles.

Il est également possible en poussant le fonctionnement un peu plus loin, dans un environnement virtualisé par exemple, d’avoir un script qui démarre des machines, installe le client Puppet sur celles-ci, référence les nouvelles machines et accepte les certificats au niveau du Puppet Master, puis redémarre le client, avant de lancer une tâche Capistrano qui déploie la dernière version de l’application à partir de SVN sur les serveurs ne possédant pas encore l’application. En un clic, il est possible de multiplier le nombre de ses frontaux pour absorber un pic de charge par exemple.

Le mot clé est : « automatisation ! »

Frédéric FAURE

La clé est d’organiser le projet de façon modulaire en évaluant correctement les différentes briques fonctionnelles et techniques du projet à mettre en place.

Nous prendrons dans notre exemple le cas d’un projet développé sous Eclipse et dont le serveur d’application cible est Tomcat. Tout autre technologie est bien sûr envisageable.

Le découpage des sources
Tout d’abord il conviendra d’effectuer un découpage fonctionnel des différents modules ou accès de l’application. Nous pouvons prendre le cas d’un projet proposant un Back Office et un Front Office. Chaque module fonctionnel sera déclaré comme un projet à part entière et consommera des fonctionnalités, méthodes et outils communs présents dans un autre projet contenant le framework maison ou tronc commun. Outre une maintenabilité accrue pour l’ensemble du projet par la suite, cela permet de séparer clairement les éléments nécessaires à la compilation et exécution de chaque modules qui pourront s’exécuter sur des environnements/serveurs distincts. En effet, sur un site commerçant par exemple, le Back Office nécessitera probablement une infrastructure minimale afin de remplir les produits qui seront accessibles au grand public sur le Front Office qui pourra nécessiter une infrastructure plus poussée afin de supporter la charge, avec un système de réplication de données master-slave par exemple. Il faut donc que chaque module soit indépendant afin de pouvoir être déployés séparément sur des infrastructures distinctes.

L’intérêt d’avoir un projet à part pour le tronc commun permet en plus d’effectuer des montées de versions rapides pour peu que les méthodes et interfaces dudit framework maison aient été convenablement définies et ne bougent pas ou bien que la rétrocompatibilité soit assurée de manière générale. Cela permet d’avoir une version ISO du framework entre les différents projets (pas au sens Eclipse du terme mais au sens « business ») de la société et que chacun puisse profiter des dernières corrections et évolutions du framework maison.

Concernant les framework du marché, la séparation n’est pas aussi simple puisque, plus qu’un ensemble de méthodes et d’outils, ils proposent des modèles de développement, et donc qu’en général, les sources sont intégrées directement dans leur modèle, comme dans Struts pour ne citer que lui. Il n’est donc pas nécessaire de vouloir extraire dans des projets séparés tous les framework, car cela ne serait pas forcément bénéfique.

Le cas des outils éditeurs
Reste en suite le cas des outils éditeurs, par exemple, qui bien souvent se retrouvent modifiés directement dans leur code source (quand les sources sont disponibles) rendant ainsi toute montée de version insurmontable. Le but de le mettre dans un projet à part est le même que pour le framework, c’est-à-dire de pouvoir profiter des évolutions/corrections du produit proposées par l’éditeur en gardant la possibilité de changer simplement de version. Cette simplicité est accrue avec les qualité des interfaces que doit proposer le tronc commun pour accéder au produit. En effet, lors d’une montée de version, si quelques méthodes de l’outil ont changé, il suffira de mettre jour l’interface du tronc commun correspondante sans avoir à modifier un seul élément du Front ou du Back office.

Si il s’avère que des modifications sont nécessaires afin d’apporter quelques spécificités au produit, il faudra le faire dans un projet à part, en conservant la même logique arborescente que le produit lui-même. Les modifications seront fusionnées avec la version originale de l’outil lors de la phase de génération de la cible via le moteur d’automatisation des tâches.

Le contenu
Certains développements ont pour but de présenter du contenu. On peut prendre le cas d’un projet se basant sur un outil éditeur de type CMS (Content Management Systems ou Système de Gestion de Contenu). Du contenu sera nécessaire lors de la phase de développement. Cependant, le contenu doit se trouver impérativement dans un projet à part :

- pour identifier aisément les ressources « statiques » du site et les « dynamiques » correspondant au contenu,

- pour éviter lors des livraisons dans l’environnement de PROD d’embarquer des éléments de type contenu et d’écraser les modifications effectuées via le Back Office par les responsables du contenu (je suis sûr que si vous avez déjà travaillé sur un projet de CMS vous avez déjà vu ça… Hein !),

- pour ne pas mettre 3 heures à rapatrier votre projet de SVN/CVS (gestionnaire de sources) alors que vous ne vouliez récupérer que les fichiers sources du développement et que vous vous retrouvez avec 1Go de contenu en prime !

La compilation et l’exécution
La compilation des sources est assurées grâce aux dépendances que l’on peut appliquer entre projets. Il n’est donc pas nécessaire de tout mettre dans le même projet pour que cela compile ! ;ob Il faut cependant faire attention aux dépendances cycliques : bien que le compilateur refusera par défaut, il est toujours possible de désactiver certaines barrières, … Il est indispensable de ne pas en avoir car au-delà du fait que l’exécution ne sera pas possible sur l’environnement cible (rien que ça) à moins de tout poser au même endroit, cela signifie qu’il y a un problème de conception. Il n’y a pas de dépendance cyclique des projets si ils suivent une logique de couches correcte.

Concernant l’exécution, elle sera permise grâce à une tâche ANT qui va récupérer les compilés et ressources de chaque projet afin de les mettre à disposition dans un répertoire cible :

- répertoire du plugin Eclipse-Tomcat pour l’exécution en mode « débug »,

- version livrable sous forme de « war » pour plateformes d’INT, de PROD, …

- …

ANT est un scripteur de tâches permettant un ensemble complet de fonctionnalités (compilation, génération de Javadoc, archivage (zip, war, …), extraction CVS/SVN, …). Issu d’un projet Open source de la fondation Apache, il permet l’automatisation et donc la fiabilisation lors de la reproduction d’opérations répétitives tout au long du cycle de développement. Il sera alors possible de créer un ensemble de tâches ANT qu’il suffira d’exécuter : « Livraison DEV », « Livraison PRE-PROD », « Livraison PROD », …

ANT est capable également de se connecter à SVN et de générer les livrables à partir d’une version par exemple, une version des sources devant normalement être générée avant chaque livraison.

Si il est nécessaire d’avoir à disposition un ensemble de données d’initialisation du CMS pour le développement, un projet spécifique de contenu doit être créé et intégré via ANT lors de la génération du « build » dans la target « Livraison DEV ».

Illustration

Structuration-Organisation Projet

Conclusion
L’organisation d’un projet au niveau des sources est indispensable car c’est ce qui va vous permettre d’assurer une maintenabilité et une évolutivité de vos développements, vis-à-vis également des éventuelles montées de version des composants communs ou éditeurs sous-tendant votre projet.

De plus un moteur d’automatisation des tâches de développement est indispensable quelque soit la taille du projet afin de permettre une reproductibilité des tâches, d’assurer une capitalisation des connaissances via ces scripts et également de soutenir l’organisation projet des équipes en permettant, par exemple, à n’importe qui d’effectuer une livraison, et ce rapidement.

L’investissement au niveau de la conception est une économie au niveau du projet dans sa globalité.

Frédéric FAURE

Différence avec une infrastructure standard
Tout d’abord il est normal de se poser la question. La réponse devrait être : « aucune ! ». Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergé « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile et dynamique au niveau de ces EC2 oblige à mettre en place des mécanismes qui devraient être standards afin :

• de tirer profit des possibilités, du dynamisme, de la solution,

• de prendre en compte plus sérieusement, du fait de la volatilité de l’outil, les plans de reprise sur incident et identifier les données importantes afin d’assurer leur durabilité.

Le monitoring
Le monitoring est le premier élément à mettre en place. Dans une architecture scalable, il est indispensable d’avoir à disposition des métriques afin de savoir justement quand scaler. C’est le rôle de cet élément. Il permet de plus d’identifier les points d’engorgement de l’infrastructure, analyser l’évolution du trafic sur votre site et en déduire les comportement des utilisateurs et dans le cadre d’un monitoring actif, permet également de déclencher des alertes qui servent de base aux astreintes.

Il n’y a pas d’outil miracle pour le monitoring et un certain nombre existent sur le marché avec leurs avantages et inconvénients. Nous pouvons citer Nagios, Cacti, Zabbix, Munin, … Nous avons choisi Cacti pour notre infrastructure du fait de la qualité des courbes qu’il propose. Il est vrai que le packaging de cet outil manque, à mon avis, de rigueur et que les métriques manquent, sur certains templates, de précision, cependant la qualité des courbes, basées sur RRDtool, et leur diversité permet d’effectuer un suivi complet de notre infrastructure et de comprendre les impacts de l’évolution des composants de ladite infrastructure ou bien des applications supportées au fur et à mesure des livraisons des différentes releases.

Nous avons installé également la « plugin architecture » de Cacti qui nous permet d’installer, comme son nom l’indique, des plugin sur l’outil et notamment « Thold », nous permettant de déclencher des trigger sur l’atteinte d‘une valeur sur une courbe ou bien sur une variation afin d’effectuer du monitoring actif. Bien entendu, cela est le prélude à une gestion des astreintes et à chaque alerte remontée doit correspondre un mode opératoire de reprise sur l’incident mis en lumière via Cacti.

Le monitoring est positionné sur une machine EC2 pour des raisons évidentes de coût (le coût des échanges sur l’IP interne est nul) et de sécurité (inutile d’ouvrir plein de ports et donc autant de failles à l’extérieur).

Cacti - Apache Statistics - Thread scoreboard

La gestion de configuration centralisée
La notion de scalabilité rendue accessible par l’infrastructure des services Amazon, nous oblige à utiliser un outil de gestion centralisé de la configuration. L’utilité est multiple :

• instancier rapidement une machine correspondant à un type prédéfini : serveur SQL, serveur de cache, serveur Web, …

• assurer l’homogénéité de la configuration des instances d’un même type,

• capitaliser un savoir faire.

Nous utilisons Puppet dans notre infrastructure. Nous avons installé le Puppet Master sur le serveur de monitoring. Le Puppet Master contient les descripteurs des installations et configurations à apporter à une nouvelle machine afin de la préparer suivant le type de machine (nœud) auquel on l’a associé. Régulièrement, le client pull le master afin de vérifier que sa configuration est à jour. Il est également possible de faire du push sur les clients à partir du master pour déclencher une mise à jour urgente.

Il est ainsi très simple de monter une nouvelle instance d’un type donné et d’être sûr que, d’une machine à une autre, la configuration est complètement iso, configuration qui est centralisée sur notre machine de monitoring et dispatchée sur les instances de notre infrastructure. Il est à noter que le descripteur du Puppet Master fonctionne sur un système de nodes et donc un type de machine peut faire référence à plusieurs nodes et on obtient une configuration très modulaire. Tous nos types de machine, par exemple, utilisent le module Puppet de configuration, que nous avons décrit, du protocole SNMP, indispensable pour que Cacti monitore une machine, et le module de l’outil s3cmd nous permettant de faire fonctionner notre système de backup sur chaque machine. Ensuite, chaque type de machine a ses installations/configurations spécifiques.

Exemple du descripteur de nœuds « nodes.pp » du Puppet Master :

class web-node {
      include snmp-module
      include s3cmd-module
      include web-module
}

Exemple du descripteur « init.pp » du module « snmp » du Puppet Master :

class snmp {
      package {
            « snmpd »:
            ensure => installed;
      }

      file { « /etc/default/snmpd »:
            ensure => present,
            owner => root,
            group => root,
            mode => 0644,
            source => « puppet:///snmp/snmpd »,
            require => Package["snmpd"],
            notify => Service["snmpd"];
      }

      file { « /etc/snmp/snmpd.conf »:
            ensure => present,
            owner => root,
            group => root,
            mode => 0644,
            source => « puppet:///snmp/snmpd.conf »,
            require => Package["snmpd"],
            notify => Service["snmpd"];
      }

      service { « snmpd »:
            ensure => true,
            hasrestart => true,
            restart => « /etc/init.d/snmpd restart »,
            hasstatus => true;
      }
}

Très simple de mise en place, il nous permet de démarrer une machine en un clic sur un pic de charge. « Mais… », me direz-vous, « il faut bien installer le client sur la nouvelle machine ? ». Et oui, d’autant plus qu’il y a un système de requête/acceptation de certificat entre le client et le master afin que n’importe qui ne puisse accéder aux configurations. « Très simple ! », vous répondrais-je, au lieu d’utiliser une IHM, comme Elastic Fox, afin de se connecter aux APIs des services Amazon, il suffit de s’y connecter en lignes de commande via un script qui instancie un EC2, éventuellement crée un volume EBS et l’associe, se connecte en SSH sur la nouvelle machine et installe le client, se connecte sur le master et accepte la requête de certificat, redémarre le client sur la nouvelle machine et « hop ! ». La machine s’installe et se configure toute seule ! « Magique ! » me direz-vous, « Ca devrait être pourtant classique » vous répondrais-je… Les possibilités de réactivité et de dynamisme inhérents à EC2 et les AWS de manière générale nous impose cela, sinon ce serait sous exploiter l’outil, voire més-exploiter.

L’auto-scalabilité, que nous n’avons pas (pour l’instant ;ob) mise en place dans notre cas, consisterait, par exemple, à déclencher ce script sur le dépassement d’une valeur d’un graphe Cacti, instanciant donc une nouvelle machine pour supporter la période de pic, instance qui serait « terminée » suite au repassage en dessous de ce seuil sur le graphe. Les possibilités sont énormes.

Le déploiement automatisé
Du fait de la variation du nombre d’instances en fonction de la charge et surtout du nombre potentiellement important desdites instances, il n’est pas envisageable d’effectuer les opérations de maintenance et de déploiement unitairement sur chaque machine (et encore pire à la main !), ce qui non seulement serait chronophage, mais de surcroît source d’erreurs. Il est alors indispensable d’utiliser des outils spécialisés dans l’automatisation et l’exécution parallèle de tâches, tel que Capistrano, dont les bénéfices sont multiples :

• scripter un certain nombre de tâches (livraisons, backups, publication/maintenance du site, …) et de les exécuter en parallèle sur X machines,

• assurer la reproductibilité d’une tâche,

• exécuter rapidement des tâches complexes sur X serveurs en une seule commande,

• capitaliser un savoir faire.

Cet outil est très simple d’utilisation et très pratique et exécute des tâches en parallèle, sur un groupe de serveurs que l’on définit, en se connectant en ssh :

ssh_options[:keys] = « ~/.ssh/la_cle_privee »
ssh_options[:user] = « le_user »

Il suffit de définir une liste de serveurs correspondant à un groupe, « sql » par exemple :

role :sql, « alias_sql1  » , « alias_sql2  » , … , « alias_sqlx »

Et ensuite il reste à définir les tâches, que l’on peut décrire intégralement dans le descripteur…

task :dump_sql, :roles => :sql do
      run « rm -f /mnt/backup/`hostname`.`date +%w`-* »
      run « mysqldump –pmon_pwd -u mon_user ma_base | gzip -cq6 > /mnt/backup/`hostname`.`date +%w-%y%m%d_%H%M`.sql.gz »
end

… ou bien dans un fichier « .sh » que l’on uploade et que l’on exécute sur la machine distante

task :store_sql, :roles => :sql do
      upload « /root/cap-scripts/cap-backup_sql.sh », « /usr/local/sbin », :via => :scp
      run « /usr/local/sbin/cap-backup_sql.sh »
end

Il suffit ensuite d’exécuter la simple commande « cap dump_sql » ou « cap store_sql ».

Backups
Et oui, mettre ses données de base SQL sur EBS (dans le cas où l’on n’utilise pas SimpleDB du fait du besoin d’un minimum de modèle relationnel) ne suffit pas, parce que :

• EBS assure une durabilité très respectable par réplication réseau, mais reste l’équivalent d’un disque dur, même si plus fiable,

• il n’y a pas que les données de base SQL (ou autres) qui sont importantes, il y a également vos logs principaux et les configurations de vos outils (Cacti, Puppet, Capistrano, …).

Nous utilisons l’outil en ligne de commande « s3cmd » afin de stocker nos backups. Cet outil est utilisé dans nos tâches Capistrano appelées par cron. Très simple d’utilisation, il nous permet d’utiliser les API’s S3 et offre la possibilité de transférer les données en HTTPS et également de les stocker sous un format crypté.

Tips and tricks
DNS
Il arrive de rencontrer quelques soucis DNS au niveau du réseau Amazon pour les instances EC2. Un conseil donc, positionner des hostname plus parlant (au lieu des « domu -xxxx») et utilisez le fichier des « hosts » que vous déployez ensuite via Puppet !

CDN
Nous utilisons S3 dans notre architecture afin de mettre à disposition les images et autres statiques de notre application à disposition de notre Content Delivery Network, à savoir Panther. Inutile, en effet, de maintenir un serveur Web à cette seule fin, S3 est là pour ça pour un coût minime.

Gestion des Logs
Il serait, à mon avis intéressant, de gérer également les logs de manière centralisée. Nous ne l’avons pas mis en place et, par conséquent, je ne ferai pas de recommandations sur un sujet que je n’ai pas testé moi-même. Cependant, pour indication, il est possible de mettre en place un système de logs réseaux, sous Linux par exemple, afin de centraliser et de mutualiser les logs, logs qu’il est ensuite possible d’analyser. Ca vaut le coup pour une infrastructure ou une application distribuée de connaître le comportement ou les différences de comportement des éléments qui la constitue.

Webistrano
Webistrano est une IHM permettant d’accéder aux fonctionnalités de Capistrano et introduisant une notion de gestion de projet par la possibilité de gérer les accès aux tâches en fonction de son profil, de tracer qui a déployé quoi sur quel serveur et d’envoyer des alertes mails sur certaines actions. Nous ne l’avons pas testé en production, mais cela peut s’avérer intéressant à prendre en considération.

Conclusion
Le but de ce post n’est pas de faire la publicité de tel ou tel outil, mais de vous inciter à considérer l’automatisation de votre infrastructure qui, si elle devrait déjà être en place dans vos infrastructures actuelles internes, devient indispensable sous AWS pour peu que l’on souhaite faire de la scalabilité, être réactif ou simplement tirer parti de l’outil mis à disposition.

Je dirais que les principes fondamentaux d’une bonne infrastructure sont au nombre de 3 : KISS, DRY et YAGNI.

• KISS pour « Keep It Simple, Stupid », à savoir inutile de chercher à complexifier l’infrastructure, la plus efficace sera la plus simple.

• DRY pour « Don’t Repeat Yourself » , à savoir ce qu’il est possible de scripter et d’automatiser faites-le ! Ca vous prendra un peu plus de temps la première fois, mais vous aurez une tâche réfléchie, reproductible, et vous n’aurez surtout pas besoin de le faire une seconde fois (quoi de plus ennuyeux que de se répéter).

• YAGNI pour « You Ain’t Gonna Need It », à savoir n’installez sur vos machine que ce dont vous avez besoin. Plus vous installerez d’outils inutiles ou one-shot, plus votre infrastructure aura potentiellement des trous de sécurité et pourra introduire des effets de bords. Sans aller forcément jusque là, disons qu’elle sera moins facilement maintenable.

Ces principes vous paraissent drôles pour certains ou peut-être un peu ringard pour d’autres, mais si avant de faire une tâche sur une infrastructure on se demandait si ce que l’on va entreprendre ne rentre pas dans un de ces cas, je pense que les infrastructures, de manière générale, seraient plus fiables, homogènes et performantes.

Frédéric FAURE