Technologie - Docker : conteneuriser vos applications, du poste de développement à la production

Qu'est-ce que Docker ?

Docker fait tourner une application dans un conteneur, un environnement isolé qui contient tout ce dont elle a besoin : le langage, les bibliothèques système, les dépendances, la configuration. Le conteneur se comporte de la même façon sur le portable d'un développeur, sur un serveur de recette et en production.

Cinq mots reviennent tout le temps :

• Dockerfile : un fichier texte, versionné avec le code, qui décrit étape par étape comment construire l'image
• Image : le résultat de cette construction, un paquet figé qui contient l'application et tout ce qu'il faut pour la démarrer
• Conteneur : une image en cours d'exécution. On peut lancer plusieurs conteneurs à partir de la même image
• Registre : l'endroit où l'on stocke les images pour les partager, comme Docker Hub, le registre de GitLab ou celui de votre fournisseur cloud
• Docker Compose : un outil qui démarre d'une seule commande plusieurs conteneurs qui travaillent ensemble (l'application, sa base de données, son cache), décrits dans un même fichier

Comment nous utilisons Docker

Nous nous en servons à chaque étape d'un projet, dans le cadre de notre démarche DevOps.

Un environnement de développement qui démarre en une commande

Un développeur qui arrive sur un projet clone le dépôt et lance docker compose up. L'application, sa base de données et les autres services démarrent dans les bonnes versions, sans rien installer d'autre que Docker. Personne ne passe sa première journée à chercher la bonne version de PostgreSQL ou de Python, et un projet repris deux ans plus tard redémarre de la même façon.

Des images de production construites en plusieurs étapes

Le Dockerfile de production est découpé en étapes (multi-stage build). La première installe les outils de compilation et construit l'application. L'image finale ne récupère que le résultat, sans compilateur ni dépendances de développement. Elle est plus petite, se télécharge plus vite à chaque déploiement et contient moins de logiciels où une faille pourrait se cacher.

Le même Dockerfile, du poste à la production

Le même Dockerfile sert sur le poste du développeur et en production : le développeur travaille sur une des étapes, la CI construit l'image finale. Elle la construit pour chaque environnement et la déploie, en recette puis en production sur un cluster Kubernetes, toujours à partir de ce fichier. La recette et la production sont donc construites de la même façon. Le déploiement suit une démarche GitOps : la version de l'image à déployer est écrite dans un dépôt Git, et le cluster s'aligne dessus.

---

Ce que Naeka peut faire pour vous

Conteneuriser une application existante

Une application installée à la main sur un serveur, avec des dépendances dont plus personne ne connaît la liste exacte, devient difficile à mettre à jour et impossible à recréer. Nous écrivons son Dockerfile, faisons la liste de ce dont elle a vraiment besoin, sortons la configuration et les secrets de l'image, et vérifions qu'elle se comporte de la même façon une fois dans son conteneur. Sur Kazaplan, pour Adeo, la première phase comprenait la migration d'applications sous Docker.

Des images de production sûres

Nous construisons vos images de production avec quelques règles simples :

• l'application tourne avec un utilisateur sans privilèges, défini dans l'image ou imposé par Kubernetes
• l'image part d'une base légère, avec le moins de paquets possible
• les versions sont épinglées, de l'image de base aux dépendances, pour qu'aucune mise à jour n'arrive en production sans qu'on l'ait décidée
• chaque image est analysée dans la CI, à la recherche de vulnérabilités connues

La recherche de vulnérabilités connues fait aussi partie de ce que nous vérifions quand nous évaluons la maturité de production d'une application.

Passer de Docker Compose à Kubernetes

Beaucoup d'applications tournent en production avec Docker Compose sur un seul serveur. Ça marche bien, jusqu'au jour où il faut une deuxième machine, des déploiements sans coupure ou un redémarrage automatique quand un service tombe. Nous reprenons vos fichiers Compose, en tirons des manifests ou des charts Helm, et déplaçons l'application sur Kubernetes en gardant les mêmes images. Nous vous aidons aussi à décider si le passage en vaut la peine : pour une petite application sur un seul serveur, Compose suffit souvent.

Des applications Python et Django conteneurisées

Nous développons en Python depuis 2009, surtout avec Django. Une application Django dans un conteneur a ses propres points d'attention : le serveur d'application (Gunicorn ou Uvicorn), les fichiers statiques, les migrations de base de données à lancer avant la nouvelle version, les tâches de fond dans un conteneur à part. Nous les traitons dès l'écriture du Dockerfile.

Vous voulez conteneuriser votre application ?

Écrivez-nous en décrivant comment elle est déployée aujourd'hui. Nous regardons avec vous ce que Docker y changerait et le travail que ça demanderait.