Quelques avantages de Docker

published on April 5, 2017, 7:53 a.m. by eliotberriot | 0

Suite à une discussion avec @Exagone313 je me suis rendu compet qu'il n'était pas toujours évident de faire ressortir les avantages et les inconvénients de Docker.

Docker c'est quoi ?

Docker c'est une galaxie d'outils permettant de faire tourner des containers (un peu comme des machines virtuelles, mais en beaucoup plus léger, et qui bootent beaucoup plus rapidement).

Il y a le docker-engine, qui fait tourner les containers proprement dits, mais également le Docker Hub, où l'ont peut déployer et partager ses images (des templates de containers), docker-compose pour décrire et lancer des configurations de containers plus complexes etc.

Exemple

Une fois docker installé, mettons que vous vouliez remonter dans le temps sur une Debian 6. Il vous suffit de faire:

docker run -it debian:6 bash

docker run va lancer un container. -it précise que c'est en mode interactif. debian:6 précise l'image et le tag à utiliser. bash est la commande à lancer dans le container en question.

Si l'image debian:6 n'est pas présente sur ma machine, elle sera automatiquement récupérée depuis le Docker Hub (pour peut qu'elle existe). Ensuite, un nouveau container est créé a partir de cette image, et la commande bash est lancé dedans.

J'ai fait bash mais j'aurai pu faire docker run -it debian:6 ls /etc et cela aurait foncionné tout pareil (lister le contenu du dossier /etc dans le container).

À quoi ça sert ?

Si vous ne tenez pas particulièrement à faire tourner une Debian 6, l'exemple précédent ne vous sert à rien. Par contre cela peut servir à tester / déployer de très nombreux outils en une seule commande.

Prenez PostgreSQL par exemple. Si vous voulez tester cet outil sans Docker, vous allez devoir installer le serveur PostgreSQL sur votre machine, ce qui inclut un certain nombre de dépendances. Les paquets à installer peuvent varier selon si vous vous trouvez sur Debian, CentOS, Windows...

Avec Docker, il vous suffit de lancer docker run -d --name test-postgres postgres et vous avez un serveur PostgreSQL qui tourne localement sur votre machine, complêtement isolé de votre réseau. Une fois que vous avez fini vos tests, vous pouvez simplement faire un docker stop test-postgres puis un docker rm test-postgres pour supprimer le container.

Pour des scenarios plus complexes, les gains sont encore plus évident. Le projet sur lequel je travaille au boulot est un projet Django / Python 3.4, qui requiert également Redis, PostgreSQL, ElasticSearch et Celery pour fonctionner. Certains développeurs travaillent sur Debian, d'autres sur Ubuntu, d'autres sur MacOS, ce qui fait qu'il serait lourd, fragile et complexe de créer des scripts d'installation pour chaque cas. D'ailleurs, certains développeurs ont peut être déjà un serveur PostgreSQL ou Redis qui tourne sur leur machine pour d'autres projets, dans des versions différentes.

Avec Docker et docker-compose, il leur suffit de cloner le dépôt Git du projet et de lancer un docker-compose up pour installer l'ensemble des dépendances, et lancer les containers du projet (l'application, le serveur de base de données, de cache, etc.).

On passe d'un setup de plusieurs heures auparavant (installer tout à la main ou de façon semi automatique, configurer les différents services...) à quelques minutes, qui sont simplement consacrées à la récupération des containers et à la configuration du projet en lui même (et pas de ses dépendances).

Maintenant, si un développeur arrête de travailler sur le projet, il lui suffit de faire docker-compose down pour supprimer tous les containers liés au projet.

Bien sûr, il pourrait aussi faire le travail manuellement:

  • Aller dans leur serveur de BDD et supprimer les database du projet
  • Supprimer les clés dans leur cache
  • Désinstaller Celery et Elasticsearch
  • Supprimer Python 3.4 et les paquests installés spécifiquement pour le projet
  • J'en oublie sûrement, et c'est bien le problème

Il est tout simplement beaucoup plus simple et robuste de le faire avec un docker-compose down.

Pour l'open-source, le gain est ainsi énorme puisqu'il est possible de partager très simplement une application et la configuration docker correspondante, permettant des déploiements beaucoup plus rapides et plus simples.

Exemple de configuration Docker-compose

Voici une configuration docker-compose type:

version: '2'

services:
    database:
        image: postgres:9.4.2  # j'ai besoin d'une version très précise

    redis:
        image: redis

    application:
        image: monimageperso
        # la commande exécutée dans le container lors du up
        command: run_the_application_server
        volumes:
            # on monte le code du projet pour que les changements locaux
            # soient reflétés dans le container
            - .:/code

Avec ça, en moins de 20 lignes j'ai une configuration pour une base de données, un cache et mon application, le tout de façon complêtement isolée du reste de mon système: l'application pourra par exemple parler à la base de données, mais celle-ci est invisible pour le reste de mon système.

Si je partage ça avec un autre développeur, cela fonctionnera exactement de la même manière sur sa machine que sur la mienne. Et si un jour, je veux rajouter un quatrième service:

background_tasks:
    image: celery

Je peux le faire très facilement. Tout développeur qui utilisera mon version mise à jour aura le nouveau service de lancé, sans autre chose à faire.

Au delà

Docker est bien sûr beaucoup plus complexe que ça et gère de nombreuses autres fonctionnalités, notamment liées à des déploiement de grande envergure. Docker-swarm, par exemple, permet de déployer des applications à grande échelle (par exemple 50 instance de mon application réparties sur 4 serveurs, et 3 serveurs de cache), de vérifier que les containers sont en bonne santé et de les redémarrer si besoin.

La partie networking est également extrêmement riche, il est ainsi possible de créer à la volée des réseaux spécifiques et d'y rattacher certains containers.

Voilà, j'espère que les avantages d'utiliser Docker sont un peu plus clairs :)

0 comments

publish