Sur la JVM, c’est la mémoire qui dimensionne

Le déploiement est la partie facile

C’est l’un des grands avantages de Spring Boot : on obtient un seul livrable, capable de fonctionner sur de nombreux systèmes d’exploitation. Rien à installer sur le serveur au-delà de la machine virtuelle Java — pas d’environnement à reconstituer, pas de dépendances à faire correspondre.

Le même fichier tourne sur le poste du développeur, en recette et en production. Cela supprime toute une catégorie d’incidents de mise en ligne, ceux où l’environnement diffère sans qu’on sache dire en quoi.

La mémoire, et le piège du conteneur

Une application JVM réserve de la mémoire et la garde : elle ne la rend pas au système comme le ferait un script PHP. Le dimensionnement se fait donc sur la mémoire, pas sur le disque ni sur le nombre de visites.

Il faut surtout lui fixer un plafond explicite, aligné sur ce que la machine peut offrir. Sans cela, la JVM se croit seule et prend tout — c’est le mode d’échec le plus fréquent d’une application Java en conteneur : le processus est tué par le système, sans erreur applicative pour l’expliquer, et cela ressemble à une panne aléatoire.

La compilation native change la donne

Quand le projet s’y prête, la compilation native via GraalVM et Native Image produit un binaire optimisé. Deux conséquences directes sur l’hébergement : un démarrage quasi instantané, et une empreinte mémoire nettement réduite.

Une application qui aurait demandé une machine confortable tient alors sur bien moins, et supporte d’être arrêtée et relancée souvent — ce qui rend enfin raisonnable de la mettre en conteneur. Tout ne s’y prête pas, et nous vérifions avant de le promettre.

Java et Kotlin en conteneur

C’est le mode de déploiement le plus fréquent aujourd’hui, et celui où une application JVM se comporte le moins bien si l’on n’y prend pas garde. Quatre points, dans l’ordre où ils font mal :

La mémoire, encore. Une JVM regarde la machine pour décider ce qu’elle peut prendre. Dans un conteneur, elle doit regarder la limite du conteneur, pas celle de l’hôte — sinon elle se croit seule sur une grosse machine, réserve en conséquence, et le système la tue. L’application disparaît sans erreur applicative : rien dans les journaux n’explique l’arrêt, et cela ressemble à une panne aléatoire pendant des semaines.

Le temps de démarrage. Une JVM classique met des dizaines de secondes à être prête. Or l’orchestrateur, lui, veut savoir vite si le conteneur va bien : sans un délai de grâce correctement réglé, il tue le conteneur avant qu’il ait fini de démarrer, et le relance — indéfiniment.

La taille de l’image. Construire l’image en deux temps — compilation d’un côté, exécution de l’autre — évite d’embarquer l’outillage de construction en production. On divise le poids, donc le temps de déploiement et la surface d’attaque.

La compilation native. C’est ce qui réconcilie vraiment la JVM et le conteneur : GraalVM et Native Image produisent un binaire qui démarre quasi instantanément et consomme une fraction de la mémoire. L’application supporte alors d’être arrêtée et relancée souvent, ce qui est le mode de vie normal d’un conteneur. Tout ne s’y prête pas — nous vérifions avant de le promettre.

Serveur privé ou conteneur

Le serveur privé reste le plus simple : la machine est à vous, l’application tourne dessus, nous l’exploitons. C’est le choix par défaut pour une application unique et stable.

Le conteneur prend l’avantage dès qu’il y a plusieurs applications à faire cohabiter, plusieurs environnements à garder identiques, ou des déploiements fréquents. Nous exploitons Docker en mode Swarm : les conteneurs sont répartis sur plusieurs machines, replanifiés si un nœud tombe, et mis à jour par remplacement progressif des instances.

Ce qu’il y a autour

Un reverse proxy devant l’application, qui porte le certificat SSL et permet de basculer d’une version à l’autre sans coupure. Les journaux sortis du processus. Les métriques de la machine surveillées comme sur nos autres serveurs. Et la base de données — Hibernate parlant volontiers à plusieurs sources à la fois, il faut savoir lesquelles vivent chez nous et lesquelles restent chez vous.