Comment Dockeriser son site web ? Comment dessiner son architecture en containers ?
La situation idéale pour concevoir une architecture à base de containers est de partir de zéro et d'imaginer le site en termes de microservices qui vont s'exécuter dans des containers. Mais lorsqu'on dispose déjà d'un site de contenu, d'un site d'e-commerce, avec sa base de données, ses serveurs applicatifs, ses serveurs http et autres serveurs de cache, la première question que l'on va se poser c'est comment répartir ces composants dans des containers, puis combien de containers faudra-t-il pour tenir la charge actuelle ?
A chaque container son process
Pour Mario Loriedo, consultant chez Zenika, il existe une règle assez simple lorsqu'il s'agit de décider comment répartir les différents modules d'une application ou d'un site web dans des conteneurs : chaque containeur doit contenir un seul process. Cela veut dire que si le site est constitué par un serveur d’application comme par exemple Node.js et un moteur de base de données comme MySQL, ces deux composants seront déployés dans deux conteneurs distincts. "Pour un site web statique, sans base de données, un seul conteneur peut s'avérer suffisant", explique le consultant. "Pour des sites plus complexes, on retrouvera un conteneur pour le serveur web, un pour la base de données, un autre pour Elastic Search, et enfin un conteneur pour un reverse proxy comme Nginx".
Une architecture qui devient agile
"Ce qui est très intéressant, c’est que l’on peut ensuite faire évoluer très facilement l’application", ajoute Stéphane Vincent, directeur des offres et de l’innovation chez Alter Way. "C’est l’architecture logicielle qui dicte le nombre de containers que l’on va avoir puis on assemble les containers dont on a besoin pour constituer l’architecture logicielle." Il est ainsi possible de démarrer sur une application standard LAMP (Linux, Apache, MySQL, PHP), puis d'introduire un serveur de cache Redis. "En architecture monolithique, il faut tout reconstruire, alors qu'avec Docker, on met en place un nouveau container avec Redis. Cette souplesse permet aussi le remplacement à la volée d'un container si celui-ci s'avère défaillant", ajoute Stéphane Vincent. "Si un bug est détecté sur une version de MySQL, on se contente de retirer le container et mettre en place un container avec une version patchée de MySQL." Cette souplesse à un impact tant au niveau des développeurs, en intégration continue, qu'en recette et en production.