Comment Waycom est parvenu à commercialiser des infrastructures en containers

L’enjeu de tout orchestrer pour bénéficier des montées en charge automatiques

« Nous avons mis en production notre première infrastructure en containers pour l’un de nos clients en décembre 2017, soit quatre ans après avoir commencé à plancher sur Docker, le logiciel à la base de cette technologie », raconte Frédéric Deletang.

Cherchant d’abord la valeur que Docker pourrait représenter pour son métier d’hébergeur-infogéreur, Waycom s’est petit à petit forgé l’idée qu’isoler des applications en containers permettrait à ses clients de ne plus avoir à s’occuper de l’infrastructure sous-jacente, y compris depuis le code de leurs applications, lesquelles pourraient par conséquent monter en charge plus librement.

Du côté des techniciens de Waycom, cette isolation servirait à obtenir des métriques plus précises sur l’infrastructure, ce qui aiderait l’infogéreur à mener plus efficacement sa mission.

« Docker seul demande beaucoup d’opérations manuelles et, sur une plus large échelle, la charge de travail deviendrait trop importante pour tout gérer à la main », se souvient Frédéric Deletang. « Notre premier défi a été de valider un orchestrateur ; nous avions testé avec succès l’orchestrateur Docker Compose qui permet de mettre des applications en production avec seulement deux commandes. Mais nos clients nous ont plutôt incités à leur construire des clusters avec l’outil concurrent Kubernetes, en Open source. Celui-ci est désormais plus répandu sur le marché, mais il ne résout pas nativement la problématique du stockage persistant. Il nous fallait donc trouver comment lui apporter cette fonction. »

Mettre tout le stockage dans un POD Kubernetes

Waycom teste d’abord le système de stockage Software-Defined et Open source Ceph, conçu pour proposer aux machines virtuelles un SAN virtuel à partir des disques installés dans les mêmes nœuds qu’elles. « Le problème est que, malgré nos efforts, Ceph n’est pas conçu pour fonctionner avec des containers », se désole Frédéric Deletang. Et d’expliquer que dans le cadre d’un cluster Kubernetes, il n’est pas question d’ajouter un pilote SAN à un hyperviseur, comme on le fait avec des machines virtuelles et, plus particulièrement, sur des infrastructures hyperconvergées.

Ici, la méthode consiste plutôt à créer un POD (sorte de coquille qui englobe un container, dans le vocabulaire Kubernetes) qui ne sert qu’à utiliser les disques du nœud hôte. Ensuite, il faut configurer Kubernetes pour que les POD correspondant aux containers des bases de données soient toujours installés à côté du POD de stockage.

Deux extensions commerciales tierces permettent à Kubernetes de fonctionner ainsi : StorageOS et Portworx. « Après plusieurs essais, Portworx s’est avéré bien plus simple à mettre en place et avait déjà plus de références que StorageOS », juge Frédéric Deletang qui mesure la jeunesse des solutions dans l’écosystème des containers.

Portworx fonctionne comme un DaemonSet, à savoir une fonction de Kubernetes en charge de déployer et de maintenir une certaine catégorie de PODs. Ce DaemonSet se configure au moyen d’un fichier YAML. « Il suffit d’éditer ce fichier pour dire à Kubernetes de déployer trois copies du POD de stockage sur le cluster. De cette manière, si le nœud qui contient la base de données vient à tomber, Kubernetes a des alternatives pour lancer à nouveau cette base de données avec son stockage », explique Frédéric Deletang.

Toute la subtilité de Portworx est qu’il synchronise régulièrement les contenus des PODS de stockage, afin de ne pas perdre d’informations lorsque la base de données migre d’un nœud à l’autre au sein du même cluster.

De simples serveurs plutôt que des infrastructures hyperconvergées

Après un PoC en septembre 2017, le cluster de containers est déployé en décembre. « Ce cluster est constitué de 6 serveurs Dell classiques. Il est intéressant de noter que nous n’avons pas opté pour une infrastructure hyperconvergée, plus chère au catalogue du constructeur, puisque Portworx transforme de fait un simple serveur avec ses disques en l’équivalent d’une infrastructure hyperconvergée », souligne le directeur technique de Waycom.

Début 2018, le client pour lequel Waycom a mis au point ce cluster (et dont le prestataire ne souhaite pas dévoiler le nom), passe commande pour 5 clusters supplémentaires, identiques au premier. Pour lui, il s’agit d’avoir un cluster dédié au développement, un autre à la pré-production (tests, etc.), un troisième à la production-même, puis de tout multiplier par deux pour des questions de redondance.

« Portworx dispose d’une fonction de snapshot qui permet de copier l’image du POD de stockage d’un cluster à l’autre. Nous ne l’avons cependant pas utilisée ici car, dans le cas très particulier du SQL, il vaut mieux laisser le soin aux bases de données de se répliquer elles-mêmes sur un autre cluster », indique Frédéric Deletang.

L’atout de Portworx : simplifier une infrastructure en containers

Au quotidien, les techniciens de Waycom en charge de l’infogérance de ces clusters trouvent Portworx si simple qu’ils n’ont même pas utilisé l’interface graphique fournie avec pour créer des fichiers YAML, Lighthouse. « En revanche, nous l’avons lié au logiciel Prometheus qui nous sert à monitorer toute l’activité de nos infrastructures de containers, afin d’y inclure les ressources de stockage », précisent-ils.

« Nous avons réussi à faire le lien vers LightHouse en regardant tout simplement les guides publiés sur le site de Portworx et qui sont très faciles à suivre. D’une manière générale, ce qui a trait à Portworx est d’ailleurs bien plus facile que tout le reste de l’écosystème des containers, à commencer par Kubernetes lui-même », ajoutent-ils.

« Même en ce qui concerne le support, nous n’avons pas de tickets d’incidents à ouvrir. La licence nous donne droit à une messagerie instantanée sur Slack qui nous permet de nous adresser directement à des techniciens, lesquels sont très réactifs », se félicite pour sa part Frédéric Deletang.

Au final, Waycom retient surtout que la facilité d’usage de Portworx a été déterminante pour le respect des délais inscrits dans le cahier des charges.

« Nous avons donc obtenu notre avantage concurrentiel avec la maîtrise des infrastructures en containers. D’autant que ce sont des infrastructures que nous pouvons mieux industrialiser, c’est-à-dire que nous pouvons même standardiser des configurations pour des besoins-types », conclut Frédéric Deletang.

Il est à noter qu’une entreprise doit au préalable utiliser elle-même Docker pour préparer ses applications au bon format, condition sine qua none pour qu’elles puissent être déployées sur l’infrastructure Kubernetes d’un hébergeur.