Introduction

Ce billet est un retour d’expérience sur une plateforme  d’hébergement scalable sous docker pour  un projet PHP/Symfony. La partie persistence est assurée par MongoDB, et Mysql.

Périmètre du projet : changement d’infrastructure

Contexte et périmètre

Le projet est un logiciel de gestion / comptabilité en ligne.

Initialement, l’infrastructure d’hébergement était sur une machine qui  embarquait l’ensemble des services (Apache, PHP, MongoDb, Mysql).

Dans le cadre d’un partenariat avec une banque, une des exigeance était que les serveurs de données soient isolés d’Internet dans une « zone démilitarisée ».

Contraintes

On a quelques contraintes importantes :

• Limiter le nombre de serveurs pour limiter le prix du support niveau 1
• Les serveurs de données, de backup et de monitoring doivent être isolés d’Internet
• Le trafic du service est susceptible d’augmenter rapidement

Dispositif mis en place

Schéma générale

Cette infra est composée principalement 3 étages :

• des reverse proxies qui font répartiteurs de charge
• des frontaux web (PHP / Symfony)
• des serveurs de données (mongo, mariaDb, glusterFS)
• des serveurs de backup / monitoring / logs (avec certaines données dans un SAN)

Principes utilisés lors du montage

Nous avons bâti cette plateforme sur quelques principes de base :

• Toutes les machines doivent être jetables et faciles à reconstruire
• les serveurs de données et de backup sont isolées d’internet

Technologies choisies

Docker

Schématiquement, docker permet de créer des machines virtuelles, mais qui tournent à la vitesse du processeur, sans perte de vitesse par rapport au host.

Nous avons choisi docker pour isoler les différents services qui tournent sur les machines, ainsi que pour simplifier les recettes ansible de maintenance de la plateforme.

L’isolation des services apportée par docker est notamment précieuse pour séparer l’installation des services de données. Les installations de MariaDb, GlusterFS et MongoDb n’ont pas d’interactions entre elles.

Ansible

Ansible est un système d’orchestration qui permet d’automatiser l’installation d’un serveur. L’utilisation de docker nous a permis de simplifier de façon drastique les recettes ansible à utiliser pour maintenir la plateforme.

Cluster Galera / MariaDb

On a utilisé le système Galera pour mettre en cluster plusieurs bases MariaDb (Mysql).

ReplicaSet MongoDb

On a utilisé un ReplicaSet MongoDb de 3 machines.

Système de fichier en cluster : GlusterFS

Pour avoir des réplications temps réel des fichiers sur les 3 machines de données, on utilise le système GlusterFS

Répartition de charge : nginx

Pour la répartition de charge, on est partis sur un nginx (dans un docker) configuré en proxy, qui permet d’envoyer les requêtes des internautes sur les 3 fronts web.

Front web : image docker custom pour symfony

Les front web tournent sur une image docker custom que l’on a adapté à notre projet pour faire tourner un code PHP/Symfony avec pas mal de dépendances nécessaires.

Bilan des courses

Les mauvaises surprises

• Quand une machine glusterFS tombe, elle est un peu compliquée à remonter et à réinsérer dans le cluster
• On n’a pas trouvé de solution satisfaisante pour faire tourner des cron (installées sur les front web) en garantissant qu’elles ne sont lancée qu’une fois. Actuellement, c’est ansible qui se charge de n’installer les crons que sur un seul frontal web.
• Nous n’avons pas mis en place de failover automatique entre les frontaux web et les base SQL. Si la base master tombe, on doit basculer manuellement les front sur un autre serveur du cluster.
• Les droits à donner au container GlusterFS sont importants.

Les bonnes surprises

• Docker en prod, ça marche, c’est stable. On l’avait déjà en prod sur des services plus simples. Là on se rend compte en grandeur réelle sur une vraie infra à quel point ça nous simplifie la vie.
• Nos tests de « failure » montrent que les 3 cluster de données se comportent bien. Les services continuent correctement à tourner, aucun cluster n’est parti en vrille pendant les arrêts brutaux de machine,…
• La recette ansible, sans être simplissime, reste humainement maintenable. La conjonction Docker / Ansible, pour nous, c’est une équipe qui marche.
• Les remontées de logs à partir de docker et systemd ont pluôt tendance à simplifier les choses (dans un logstash / kibana)

Conclusion

L’investissement en temps et en compétences que l’on a fait conjointement sur docker et sur ansible porte ses fruits. Nos projets ont gagné en stabilité et en vitesse de déploiement.

Le chemin n’est pas simple et docker pose des questions architecturales et en termes de sécurité / maintenance qui ne sont pas simples, mais nous sommes convaincus chez Kibatic que ces infrastructures représentent l’avenir de l’hébergement.