Ressortez vos partitions pour Docker Compose 1.5


Le 3 novembre dernier a vu arriver un gros lot de nouveautés pour l’écosystème Docker. Cet article du blog SFEIR couvre ces annonces et il est temps de s’intéresser cette fois à Docker Compose !

La nouvelle version de Docker Compose rend l’orchestration de containers plus simple et permet :
– d’utiliser des variables d’environnement au runtime
– de surcharger des propriétés du fichier Compose

Voyons ensemble comment exploiter ces nouvelles techniques pour mieux organiser nos fichiers Compose.

Compatibilité

Tout d’abord, il faut préciser que Compose 1.5 nécessite un Docker en version 1.8 minimum. Mettez à jour votre poste de développement (et votre prod) !

Par exemple sous Mac OSX, on met à jour nos commandes Docker (brew va s’occuper de mettre à jour les dépendances) et on met à jour notre VM :

brew upgrade docker-compose
docker-machine upgrade dev

A noter que Compose est maintenant disponible pour Windows via l’installation de la Docker Toolbox (existe aussi pour Mac même si je lui préfère la simplicité de Homebrew).

Variables

Le but ici est de “variabiliser” son fichier Compose. La fonctionnalité était déjà utilisable depuis quelques mois et est maintenant officiellement disponible.

La substitution de variables peut être utilisée sur les balises mono-valeur (comme image ou command), liste (comme expose ou ports) et dictionnaires (comme volumes ou environment). Bref, partout, et il ne faut pas s’en priver.

Les utilisations de $SHELL_VAR ou ${SHELL_VAR} dans le fichier vont être remplacées par la valeur de la variable d’environnement définie dans le shell qui fait tourner docker-compose. La substitution s’effectue au moment du up.

Si la variable $CONTAINER_VAR doit être évaluée à l’intérieur du container, il faut l’échapper par un autre signe dollar ainsi : $$CONTAINER_VAR. Pensez à modifier vos anciens fichiers compose utilisant la notation ${DB_PORT_3306_TCP_ADDR}.

Défaut de jeunesse, les valeurs par défaut ne sont pas encore supportées.

Par exemple, il est possible d’utiliser un seul fichier docker-compose.yml pour lancer une base de données dans des versions différentes :

db:
  image: mariadb:$MARIADB_VERSION

Shell 1 :

> export MARIADB_VERSION=5.5.46
> echo $MARIADB_VERSION
5.5.46 # OK
> docker-compose up
Pulling db (mariadb:5.5.46)...

Shell 2 :

> echo $MARIADB_VERSION
 # n'affiche rien, la variable n'est pas définie
> docker-compose up
WARNING: The MARIADB_VERSION variable is not set. Defaulting to a blank string.
Pulling db (mariadb:latest)...

On peut donc maintenant s’affranchir des chemins ou versions définis en dur dans le fichier docker-compose.yml.

Associé avec un outil comme direnv, pour gérer des variables d’environnement pour dossier, c’est pratique !

Override

Le but ici est de combiner plusieurs fichiers Compose pour donner un comportement global différent suivant l’exécution voulue.

Le fichier docker-compose.yml de base définit la structure de l’application. Il est possible de spécifier d’autres fichiers pour le surcharger en modifiant ou ajoutant des propriétés sur des services existants et aussi d’ajouter des services supplémentaires.

Par défaut, Compose lit les deux fichiers suivants :
– docker-compose.yml
– docker-compose.override.yml (optionel)

Il est possible d’utiliser des noms de fichiers différents avec l’option `-f :

docker-compose -f docker-compose.yml \
               -f docker-compose.dev.yml \
               -f docker-compose.monitor.yml \
               up -d

Le fichier docker-compose.yml définit la structure des services :

web:
  image: sfeir/web:latest
  links:
    - db

db:
  image: postgres:latest

Le fichier docker-compose.dev.yml modifie des propriétés pour le développement :

web:
  build: dockerFiles/web
  environnement:
    - DEBUG: 'true'

Le fichier docker-compose.monitor.yml ajoute un service pour surveiller les containers (avec le simple, mais pratique docker-ui ) :

dockerui:
  image: dockerui/dockerui
  privileged: true
  ports:
    - "9000:9000"
  volumes:
    - /var/run/docker.sock:/var/run/docker.sock

Voici comment Compose gère la combinaison pour les différents type de propriétés (voir la doc pour plus de détails) :
– mono-valeur : la nouvelle valeur remplace (build et image sont considérées comme équivalentes)
– liste : les ensembles de valeurs sont concaténés
– dictionnaire : les ensembles sont concaténés et les entrées contenant la même clé voient leurs valeurs remplacées

L’exception pour links et volumes_from : les valeurs ne sont pas combinées pour éviter des dépendances implicites. Il faut donc toujours définir entièrement ces propriétés si elles sont surchargées.

Cette fonctionnalité permet de ne pas définir des propriétés spécifiques à un environnement dans le fichier Compose de base. Ceci permet aussi de rajouter des comportements (via de nouveaux services) sans modifier le fichier de base.

Extends

Une autre manière de réutiliser un fichier Compose s’effectue avec la propriété extends. Cette fonctionnalité existait déjà auparavant, mais en voici un rappel en contraste avec la surcharge vu au-dessus.

Ici, l’idée est de définir un ensemble de propriétés qui va être utilisé par plusieurs services.

Le fichier common-services.yml contient une définition d’un service :

webapp:
  build: .
  command: run.sh
  ports:
    - "8000:8000"
  volumes:
    - "/data"

Dans le fichier docker-compose.yml :

web1:
  extends:
    file: common-services.yml
    service: webapp
  environment:
    - CONFIG_PATH: /code/config–1

web2:
  extends:
    file: common-services.yml
    service: webapp
  environment:
    - CONFIG_PATH: /code/config–2

web2x:
  extends: web2
  environment:
    - DEBUG: ‘true’

Sur la même base du service webapp, on a défini deux services web1 et web2 qui ont seulement une variable d’environnement différente.
La définition du service web2x utilise la propriété extends pour réutiliser un service définit dans le même fichier.

Le mécanisme de combinaison des propriétés est le même entre extends et la surcharge.

C’est utile pour mutualiser des définitions communes de services et éviter les problèmes inhérents au copier/coller.

Conclusion

Ces nouveaux ajouts à Docker Compose ne changent pas la manière dont sont lancés les containers, mais simplifient grandement l’écriture des fichiers de configuration Compose, et ce, de manière propre.

D’autres ajouts ont aussi été apportés, allez faire un tour sur la release note.
Une curiosité est l’accès en expérimental du Networking maintenant en version finale avec la dernière version de Docker Engine. Ce sujet sera traité prochainement sur le blog SFEIR. Stay tuned !

Et consultez aussi la documentation, vous serez étonnés de l’ensemble des fonctionnalités proposées par Compose et comment orchestrer simplement et avec précision vos containers.

Vous aimerez aussi...