Publié le 14 avril 2019, mis à jour le 18 décembre 2023.

Pourquoi conteneuriser mon application, quelles sont les erreurs à éviter lors d'une migration d'une machine virtuelle (VM) à Docker, voici les questions auquel cet article a pour but de répondre.

Pourquoi conteneuriser ?

Les conteneurs prennent le dessus sur les machines virtuelles (VM), car ils rendent l’installation plus facile et plus rapide, ils démarrent plus vite et prennent moins d’espace dans votre ordinateur. Cet article de Farhad Malik vous aide à comprendre les raisons techniques de ce gain de performance.

Si vous développez une application qui tourne dans une VM, voici la procédure à suivre pour migrer vers une application conteneurisée avec Docker et Docker-Compose.

Les questions à se poser avant de conteneuriser

  1. La première chose à faire est de prendre un white board et de dessiner un schéma de l’architecture existante, par exemple en utilisant le modèle C4. Assurez vous que vous indiquez bien le langage/framework de chaque brique (une brique étant une API, une BDD, etc), la manière dont elles communiquent entre elles et avec les autres services, les crons qui peuvent être exécutés etc…
    Faites attention à dessiner votre application de production, ou au moins votre application de staging pour vous aider à être le plus iso prod possible.

  2. Ensuite assurez-vous d’être capable de faire tourner l’application “the old way” sur votre machine, c’est-à-dire dans la VM. Cela vous aidera à identifier les routes non authentifiées que vous pouvez facilement appeler pour tester votre conteneurisation, à comprendre le provisionning de la base de données, etc.

Profitez-en pour mesurer votre temps d’installation, ce qui vous permettra de mesurer l’impact de votre nouvel environnement docker.

  1. Pour chaque brique de votre application, répondez à ces questions pour lister les étapes dont vous aurez besoin dans votre Dockerfile :
    1. Quel processus lance l’application ? Par exemple pour une application node cela peut être node ./server.js. Quels fichiers doivent être dans le docker au moment du runtime ?
    2. Les images de base existent-elles déjà dans le docker hub ? Sont-elles maintenues ? Si c’est le cas une version “alpine”, généralement la plus légère, est-elle disponible ?
    3. Quelles variables d’environnement sont nécessaires ? Vous devriez regarder .env file.
  2. Construisez chaque Dockerfile. Commencez par l’instruction FROM, puis avec COPY, copiez les fichiers nécessaires, enfin déclarez les variables d’environnements avec l’instruction ENV. Puis, avec l’instruction RUN, exécutez les commandes nécessaires pour construire le fichier binaire et utilisez l’instruction CMD pour être sûr qu’il sera exécuté. Souvenez vous, un conteneur correspond à un process et un seul. Testez alors chaque partie séparément en runnant docker build -t IMAGE_TAG et ensuite docker run -p HOST_PORT : CONTAINER_PORT IMAGE_TAG
  3. Finalement, connectez tous vos services avec docker-compose. Pour bénéficier du live reload et garder vos fixtures dans la base de données potentielle, montez certains volumes
  4. Testez que votre déploiement en staging fonctionne toujours.

Une dernière réflexion

Quand vous conteneurisez votre application, il est simple de séparer le reverse proxy, l’application et la base de données, et il est souvent tentant d’en faire plus en transformant votre application monolithique en microservices.

Cependant ce n’est pas toujours une bonne idée car cela peut transformer votre conteneurisation en un procédé bien plus complexe. Conteneurisez d’abord votre application monolithique, ensuite vous serez capable de l’améliorer et de créer des microservices les uns après les autres. Plus tard vous pourrez même transformer chacun de ces services ressources Kubernetes pour bénéficier d’une software factory complètement iso ! Pour comprendre la différence entre Kubernetes et Docker lisez cet article.