Déployer simplement une application conteneurisée en production

Nous développeurs, même si ce n'est pas notre métier principal, avons souvent besoin de gérer serveurs, VPS, et autres infrastructures pour nos projets. C'est rarement le cas dans les grosses entreprises, mais dans des startups ou pour des projets personnels nous sommes souvent obligés de tout gérer nous-mêmes.

Moi, j'adore ça avoir la main sur le projet de bout en bout ! Penser et déployer l'infrastructure nécessaire au bon fonctionnement de mon code fait partie, selon moi, de la conception et du développement du projet.

Là où c'est assez simple pour un développeur de louer un serveur ou un VPS chez un hébergeur classique pour y installer son environnement docker, le monde du cloud peut sembler un peu décontenançant. Effectivement, nous savons facilement faire le parallèle entre un VPS et notre propre machine physique. Ce n'est qu'une machine quelque part ailleurs sur la terre. Et, cette machine fonctionne exactement comme la nôtre.

Le cloud apporte beaucoup de nouveau vocabulaire, de nouveaux outils, et de nouveaux concepts. Sur quoi tourne mon projet ? Du coup, je build mes conteneurs dans un conteneur ? À quoi sert Kubernetes ? Pour les développeurs habitués aux machines traditionnelles, le cloud est un peu plus "flou".

C'est d'ailleurs pourquoi j'écris cet article. Pour démystifier un peu la bête. En prenant un exemple simple : mon blog. Je veux vous montrer comment déployer une application docker simple sur le cloud. Et, pour changer nous n'allons pas parler de Google Cloud Platform ou de Amazon Web Services. Pour cet article, nous allons utiliser Hidora, une plateforme cloud européenne dont les data centers se situent en Suisse.

L'environnement Docker de développement que nous installons sur notre machine locale est plutôt simple. Après avoir installé Docker, nous pouvons directement créer une nouvelle image pour notre projet ou utiliser des images existantes.

Lorsque l'on souhaite déployer ce même projet en production, nous faisons face à un peu plus de possibilités. Ce n'est pas plus mal, il ne faut juste pas se perdre.

Les environnements Docker préconfigurés

Mon blog utilise un CMS appelé Ghost. Il est codé en JavaScript. Plus spécifiquement, il utilise l'environnement Node.js. Voici ce que propose le cloud provider Hidora pour ce genre d'application (au passage j'expliquerais un peu l'interface pour que tout le monde comprenne mieux) :

Dans la zone de gauche, nous retrouvons nos conteneurs. Il y a déjà un conteneur Node.js, car c'est l'option qui est sélectionné dans la barre du haut. Il y a aussi d'autres emplacements prévus pour des types d'applications spécifiques.

Vous pouvez donc ajouter les conteneurs nécessaires à votre projet très simplement. Par exemple, pour ajouter un front NGINX devant notre application Node.js, nous pouvons cliquer sur "équilibrage" et sélectionner la version de NGINX dont nous avons besoin.

Dans la partie du centre, on retrouve tous les paramètres qui concernent le conteneur sélectionné. Hidora nous laisse paramétrer la scalabilité verticale, c'est-à-dire la puissance allouée à notre conteneur et la scalabilité horizontale, c'est-à-dire le nombre de conteneurs que l'on souhaite lancer simultanément.

Pour chaque conteneur, il est aussi possible de gérer le stockage dont il a besoin, la version de son image Docker et le délai que nous lui imposons au redémarrage (au cas où il devrait attendre le démarrage d'un autre conteneur un peu plus long). Nous pouvons également choisir s'il aura droit à une adresse IP publique ou s'il devra passer par le Shared Load Balancer de la plateforme.

Dans la dernière partie, celle de droite, nous pouvons voir le prix que l'environnement tel que nous l'avons paramétré nous coutera. Au survol de la jauge, le détail s'affiche.

Les environnements Docker personnalisés

En utilisant la solution précédente pour mon blog, je vais devoir installer moi-même Ghost dans le docker Node.js. Et, je n'ai pas trop envie de ça. Cela m'imposera beaucoup plus de contraintes lors de la maintenance.

Ce n'est pas un gros problème, puisque les clouds providers nous donnent plusieurs possibilités flexibles pour notre architecture Docker. Hidora ne fait pas exception.

Nous pouvons monter entre autres notre architecture avec Kubernetes. Plusieurs avantages à cela, dont :

• utiliser un outil avec lequel nous sommes à l'aise
• gérer notre architecture cloud directement avec les commandes kube ou helm classiques en local

Comme je suppose que certains de mes lecteurs ne connaissent pas Kubernetes et que je souhaite que cet article reste le plus accessible possible, nous n'allons pas voir cette solution ici. Dans le même style, il est possible d'indiquer le lien vers un fichier Docker Compose et de déployer un environnement grâce à celui-ci.

La solution que j'ai choisie est celle que j'ai appelé « la page blanche ». Hidora nous permet d'éviter de choisir un environnement prédéfini (Node.js, PHP, etc) mais de monter notre environnement de toutes pièces en choisissant les images docker que nous souhaitons utiliser.

Nous nous retrouvons donc face à la même interface que précédemment, mais sans aucune pré-configuration de l'environnement. Nous ne sommes pas dépaysés.

Installation de mon application

Voici étape par étape comment je monte cet environnement de test. Pour rappel le but est de monter une copie de mon blog utilisant le CMS Ghost.

Proxy

Je reste sur NGINX pour le point d'entrée de mon environnement.

C'est une bonne pratique de refuser de donner directement accès à une application Node.js. Pour éviter les failles de sécurité, il vaut mieux faire passer le flux de données par un proxy comme NGINX.

NGINX n'aura pas beaucoup de choses à faire. Même si tout passera par lui, il ne fera que transmettre les informations et les chiffrer. En plus, il est plutôt bien optimisé alors je ne me suis réservé qu'un cloudlet. Néanmoins, je permets au système de lui en attribuer deux au cas où il y aurait un petit pic de charge imprévu.

Autre détail, concernant le stockage attribué a NGINX, je le mets au minimum autorisé par Hidora car dans ce conteneur, il n'y aura que NGINX et sa configuration. Cinq giga c'est déjà un peu trop. Cela nous permet de réduire le "coût maximum" de notre environnement.

J'active aussi l'accès direct via IPv4. C'est le point d'entrée de notre environnement. C'est ici que l'on fera pointer notre nom de domaine plus tard.

Applicatif

Dans "App. Serveurs", sélectionnons le tag de l'image Docker de Ghost. À la version latest bien-sûr. De toute façon, vous pourrez la changer plus tard pour les cas particuliers.

Comme c'est l'élément de notre environnement qui va répondre aux utilisateurs, j'ai choisi de réserver deux cloudlets et d'accepter une scalabilité verticale jusqu'à 4 cloudlets. Pour la scalabilité horizontale, je reste sur un seul conteneur, comme pour NGINX.

Arrêtons-nous un instant sur cette notion de scalabilité pour que les choses soient bien claires pour tout le monde.

La scalabilité horizontale consiste à augmenter le nombre d'instances du serveur applicatif (conteneur, serveur, VPS, etc) qui vont faire tourner la même application. Une duplication pure et dure du serveur applicatif en spécifiant tout de même comment les données vont être gérées entre ses différentes instances.

La scalabilité verticale concerne quant à elle la puissance allouée aux instances. Elle est exprimée en cloudlets qui correspondent pour chacun d'eux à 128 MiB et 400MHz. Selon la puissance dont à besoin votre application vous pouvez réserver le nombre de cloudlets correspondants. Je sais que le CMS Ghost a besoin de plus de 128 MiB pour fonctionner alors je réserve tout de suite deux cloudlets.

Pour palier à certains pics de charge ponctuels, nous pouvons prévoir une limite de scalabilité plus haute. Comme vous avez pu le voir sur la capture d'écran ci-dessus, j'ai indiqué une limite de scalabilité de quatre cloudlets. Ce qui veut dire qu'en temps normal je paierais pour deux cloudlets mais si Hidora se rend compte que mon application a besoin de plus de puissance, elle lui en fournira dans la limite de quatre cloudlets. Cela nous permet d'être flexible selon les situations que nous pourrions rencontrer tout en maitrisant notre budget.

Attention toutefois, les cloudlets réservés ne sont pas facturés au même prix que les cloudlets "flexibles". C'est d'ailleurs pour cela que je réserve deux cloudlets pour Ghost. J'aurais pu n'en réserver qu'un et laisser le système gérer la suite. Mais, les cloudlets réservés coûtent moins cher que les autres. Si vous savez à l'avance la puissance dont a besoin votre application, il est plus avantageux de réserver le nombre de cloudlets correspondants.

Bien sûr, la topologie de votre environnement peut être changée plus tard. Si vous vous rendez compte que l'un de vos conteneurs consomme régulièrement plus que prévu (peut-être à cause du succès de votre application), il est toujours possible de lui réserver plus de cloudlets pour faire baisser votre facture. Les cloudlets supplémentaires devraient être utilisés uniquement pour pallier ces imprévus.

Maintenant que vous savez tout sur la scalabilité, passons à la suite. Le dernier détail que j'aimerais mentionner pour la partie applicative est que j'ai désactivé l'option "Accès via SLB". Il s'agit du Shared Load Balancer d'Hidora. Très pratique pour les tests, il donne néanmoins un accès direct au conteneur de Ghost ce que nous ne voulons pas en production. Le flux doit passer par NGINX.

Stockage et base de données

Par défaut, Ghost en production utilise MySQL comme base de données, mais la version conteneurisée préfère SQLite. La base de données est donc écrite sur le disque.

Ce qui nous mène au stockage de nos informations. Comme l'image docker de Ghost définit un volume pour ses données (incluant la base de données, les images, les thèmes, etc), Hidora crée automatiquement un bind mount vers le système de fichier local. C'est-à-dire qu'il crée un lien entre le conteneur et le système de fichier local pour que les données soient persistées et ne disparaissent pas à la destruction du conteneur.

Pour une petite application comme la nôtre, c'est largement suffisant. Nous n'allons donc rien faire de plus. Mais, imaginez que nous souhaitions répliquer notre donnée sur un cluster de stockage ou, plus simple, que nous souhaitions partager des données entre nos conteneurs.

Pour cela, il aurait fallu créer un nœud pour un Shared Storage. Ensuite dans la configuration de tous les conteneurs ayant besoin de partager des informations, en cliquant sur le bouton "Volumes", nous aurions dû modifier le volume pour le faire pointer vers le nouveau nœud.

D'autres méthodes existent pour faire communiquer les conteneurs entre eux. Nous n'allons pas les lister ici, car ce n'est pas l'objet de cet article. Je voulais juste vous montrer une méthode simple pour que vous sachiez que c'est possible.

De même pour la base de données, sachez qu'il est possible de paramétrer Ghost pour qu'il en utilise une à l'extérieur de son conteneur. Vous devrez créer un nouveau nœud pour celle-ci.

C'est tout pour moi, je ne vous dis pas tout mais il y a encore beaucoup de choses que vous pourrez découvrir par vous-même.

Qui est Hidora ?

Quelques mots sur Hidora avant de vous laisser. J'ai découvert cette entreprise suisse lors de mon travail sur les provider cloud et leurs solutions.

Il s'agit déjà d'un point intéressant : Hidora est suisse et n'héberge ses données que sur le territoire suisse. Ce qui veut dire que vos données seront hébergées sur le sol européen. Loin du Patriote Act et de ce qu'il implique. Comme toutes les entreprises suisses qui travaillent avec des clients européens, Hidora est GDPR compliant.

Avant d'écrire cet article, j'ai testé la plateforme pendant un peu plus d'un mois avec mes propres projets. L'interface est familière, beaucoup de cloud provider utilisent Jelastic comme solution de cloud en PaaS. Et, je dois dire que la structure mise en place par Hidora semble très stable.

Enfin, Hidora a été fondé par Mathieu ROBIN avec qui j'ai pu personnellement discuter et deux autres co-founder. Des techos passionnés qui essaient d'apporter des solutions simples aux développeurs tout en pensant aux problématiques de nos métiers (omniprésence des GAFA dans le paysage cloud, etc). Il s'agit d'une alternative appréciable aux GCP, AWS et companies.