Premiers pas avec Docker

Il est aujourd'hui facile pour un développeur d'utiliser un environnement de travail qui ne correspond pas à l'environnement de production final.

Par exemple, un développeur utilisant la version macOS de PHP n'exécutera probablement pas la même version que le serveur Linux hébergeant le code de production. Même si les versions sont identiques. Il faut alors gérer les différences de configuration et d'environnement de la version de PHP, (par exemple les permission sur les fichiers ne sont pas gérés de la même manière entre les deux systèmes d'exploitation).

Lorsqu’un développeur doit déployer son code sur les machines de production et que cela ne fonctionne pas; L'environnement de production doit-il être configuré pour correspondre à la machine du développeur, ou les développeurs ne doivent-ils travailler que dans des environnements correspondant aux machines de productions ?

Dans un monde idéal, tout devrait être cohérent, de l'ordinateur du développeur aux serveurs de production. Cependant, cette utopie a toujours été difficile à réaliser. Tout le monde a sa propre façon de travailler et ses préférences personnelles. Il est déjà assez difficile d'appliquer la même cohérence sur plusieurs plates-formes lorsqu'il s'agit d'un seul ingénieur travaillant sur ses propres systèmes, sans parler d'une équipe d'ingénieurs travaillant avec une équipe potentiellement composée de centaines de développeurs.

Docker est une solution à ces problèmes. En créant des "environnements" qui vont suivre le cycle de vie d'une application de son développement à sa mise en production.

Prenons l'exemple d'un administrateur système possédant 6VMs pour ses différents services (base de données, serveurs web, load balancer).

Dans un premier temps, on lui demande de déployer sur les serveurs web une application qui dépend d'un logiciel quelconque de version 1. Tout se passe bien. Un jour, on lui demande de déployer un module supplémentaire de l'application qui nécessite quant à elle la version 2 du même logiciel. C'est alors qu'un problème se pose. Les applications ne peuvent pas cohabiter sur le même serveur si on les déploie de manière "classique".

Que peut-on faire ?

- Demander plus de serveurs ? C'est la solution la plus sûre, mais aussi la plus coûteuse. Il n'est pas toujours possible de déployer de nouvelles machines.

- Revoir l'architecture en déployant la seconde application sur un autre serveur existant (load balancer ou base de données). Encore une fois cette solution n'est pas optimale, en cas de panne sur un des composants, nous avons deux points de faute au lieu d'un si chaque VM avait son rôle précis.

- Essayer d'installer les deux versions du logiciel sur la même machine. C'est sûrement possible et ça semble être un bon "quick win". En revanche, cette solution est difficilement maintenable dans le temps. On peut évoquer l'application des patchs de sécurité qui vont être compliqués à effectuer.

Docker permet de faire tourner sur une même machine les deux applications et permet en plus de gérer plus facilement les mises à jour de chaque application de manière indépendante en recréant simplement de nouveaux conteneurs.