Comment conteneuriser mon application legacy ?

Pourquoi conteneuriser mon application, quelles sont les erreurs à éviter, 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. Pour comprendre les raisons techniques de ce gain de performances, vous pouvez vous lire cet article très bien documenté.

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 language/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 avec 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> and 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 micro services 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 !

Aurore Malherbes

Aurore Malherbes

Aurore is the CTO of Padok. Previously architect developer in the world of mobile, she decided to move to the ops world, with one mission: put the develpment team in the best conditions with a fast dev environment and a reliable production.

Qu'en pensez-vous ? Laissez vos commentaires ici !