Bonjour à tous ! 4ème jour de la semaine et j’arrive à suivre le rythme :). L’article d’aujourd’hui va couvrir la conférence de Raphaël Benitte (Ekino) qui a été réalisée durant la 8ème édition de Be-Zend. Il nous a présenté une longue liste d’outils intégrés par lui et ses collègues (nommé l’équipe dans cet article pour plus de simplicité) lors du développement d’un projet web pour Canal+. Le but était d’assurer la qualité du développement et d’automatiser le processus de mise en production.

1. Environnements de travail reproductibles et contrôle de la qualité
2. Automatisation
3. Scalabilité et infrastructure
4. Monitoring et exploitation

Environnements de travail reproductibles et contrôle de la qualité

La première étape du projet a consisté à la réalisation d’environnements de travail reproductibles. Pour se faire, l’équipe c’est orientée sur de la virtualisation et plus spécifiquement sur Vagrant dans le but de piloter des VM reproduisants l’état de la production. En complément, vient s’ajouter Puppet permettant de faciliter l’installation et la configuration des VM via une liste de modules prêts à l’emploi.

Une fois tout le système mis en place, il était nécessaire d’ajouter des contrôles sur la qualité du code et de tester celui-ci. Pour vérifier les différentes parties du projet, plusieurs méthodes ont été exploitées:

• Les tests unitaires:
  • PHPUnit: pour le code PHP.
  • Jasmine: pour le code Javascript.
  • rspec-puppet: pour tester les installations et configurations réalisées via Puppet.
• Les tests fonctionnels:
  •  Behat: pour reproduire les scénarios joués par les utilisateurs sur le site web. L’écriture des tests se rapprochent de la structure des stories en agile ce qui facilite son utilisation.
• Pull-Request: Joliment nommé pouce driven programming, la technique est simple. Un code est mergé dans l’unique cas où deux autres développeurs sont venus donner leur aval via un pouce levé. Ainsi, le code est validé par plusieurs développeurs et un partage de connaissance est effectué.

Automatisation

Une fois l’étape précédente bien intégrée, l’équipe c’est attelée à automatiser toutes ces opérations. Une fois encore, toute une série d’outils ont été utilisés:

• Jenkins: Sans grande surprise, il permet de lancer automatiquement les tests. De plus, il offre la possibilité d’exposer certains jobs au client comme démarrer une machine de test. Via des plugins, il est possible d’enchaîner une série de tâches suite à un push sur le dépôt git.
• Capistrano: Cet outil permet de gérer le déploiement sur les serveurs distants et de façon paralléliser. La mise en production se retrouve facilité.
• Puppet: Une nouvelle fois utilisé, il permet de générer de façon automatique les documentations.

La mise en ligne se fait donc de la sorte:

1. Le code se trouve sur Github. Lorsque l’on demande une mise en production, Jenkins sera notifié.
2. Jenkins demande à Capistrano de démarrer une machine et y lance les tests.
3. En cas de succès, Jenkins va récupérer le code compilé via les tests et le placer dans un dépôt Github.
4. Capistrano gère ensuite le déploiement sur les serveurs de production en se basant sur ce code.

Scalabilité et infrastructure

Maintenant que les outils nécessaires à la validation du codes ont été installés, qu’il est possible de reproduire des environnements et d’automatiser le tout, il est nécessaire de parler de l’infrastructure utilisée et de la scalabilité. Ainsi, le projet a exploité 5 types d’environnements:

1. Environnement de développement: A la demande, il possède les mêmes outils qu’en production mais avec une puissance amoindrie.
2. Environnement de recette: A la demande, il est similaire à celui de développement mais permet de faire des démonstrations et offre la possibilité au client de tester les évolutions.
3. Environnement de pre-production: A la demande, c’est une copie conforme de la production (aux niveaux des outils présents et des ressources machines).
4. Environnement de production: Toujours démarré, c’est la version accessible par les utilisateurs finaux.
5. Machine dédiée au support: Ne possède que des outils dédiés au monitoring.

Toutes les machines sont hébergées sur AWS. Pour une optimisation des coûts, celles-ci ne sont démarrées que si nécessaire (en dehors de celles de production). Le tout est géré via Jenkins. AWS offre également d’autres atouts. Il permet par exemple de faciliter une montée en version. En effet, lors d’une mise en production, de nouveaux serveurs sont démarrés et le code est déployé dessus. Si aucun problème n’est rencontré, les DNS sont progressivement basculés sur ces derniers puis les serveurs avec l’ancien code sont stoppés. De plus, une liste d’outils offerts par Amazon permettent de gérer efficacement la montée en charge avec de l’auto-scaling. D’autres services sont utilisés:

• EBS: service offrant du stockage.
• EC2: service offrant l’accès à des machines.
• ELB: service offrant un load balancing entre les machines.
• Security groups: gère les autorisations aux services EBS / EC2 / ELB.
• CloudFormation: génère la stack (environnement) nécessaire à partir d’un simple JSON.
• Route 53: gère le switch des DNS.

Monitoring et exploitation

Maintenant que tout est en place, il ne reste plus qu’à surveiller l’ensemble. Ainsi, on a une nouvelle fois plusieurs outils qui sont exploités:

• Sensu: Framework de monitoring. Il permet de réaliser facilement des indicateurs, pour s’assurer qu’un processus est toujours fonctionnel par exemple. Il propose également une intégration avec Puppet (sensu-puppet). Cela permet directement depuis Puppet, d’ajouter des indicateurs sur les différents services au moment de leur installation. Une interface graphique existe également pour contrôler le tout: Uchiwa.
• Pour les logs, c’est la combinaison de Fluentd, Elasticsearch et Kibana qui est utilisée. Fluentd a été choisi à la place du classique Logstash car au moment du choix, ce-dernier utilisait une JVM (ce que l’équipe a jugé comme un inconvénient).
• Pour les métriques, c’est Graphite qui en a la charge. Il permet de mesurer les performances et également d’optimiser le sizing des instances Amazon.
• Pour finir, il est bon de noter que la documentation est étroitement liée à tout ceci. En effet, l’équipe centralise les différentes démarches a réaliser en cas d’arrêt inopiné des services.

Pour conclure, Raphaël a tenu à préciser que la mise en place de tout cet écosystème demande beaucoup d’investissement. Ainsi, il est bon d’en mesurer l’intérêt sur votre projet et de les mettre en place progressivement en fonction des besoins.