🎯 Objectif : Découvrez dans cette page, comment utiliser les configs services et les secrets services dans Docker Swarm Mode.

Introduction

L'anti-pattern volume as config

Pour déployer sur l'orchestrateur Docker Swarm, il est possible d'utiliser la syntaxe compose en emportant quelques éléments supplémentaires: Compose file version 3 reference | Docker Documentation

L'anti-pattern parle ici d'utiliser les volumes comme espace de stockage embarquant un fichier de configuration. Cependant, il est fortement déconseillé d'utiliser cette méthode. 

Pourquoi est-ce un anti-pattern ?

Prenons un cas d'usage simple utilisant le service Nginx nécessitant un fichier de configuration. 

Notre Swarm possède 3 nœuds, un manager et deux worker. Lors du déploiement, le service est lancé sur un nœud aléatoire et créer son volume. c'est à partir d'ici, que l'on va pouvoir modifier le fichier de configuration Nginx depuis l'extérieur.

Cette solution fonctionne, cependant, si le service Nginx vient à tomber, il peux être recréer aléatoire sur une autre nœud. Il est donc fort probable de se retrouver dans la situation suivante.

Solution

Pour solutionner cette situation, Swarm Mode a apporté une nouvelle fonctionnalité dans la structure des fichiers compose. Le champ "config".

Pour cela, reprenons le cas d'usage Nginx.

Voici notre fichier de configuration "site.conf"

server {
  listen 443 ssl;
  server_name localhost;
  ssl_certificate /run/secrets/site.crt;
  ssl_certificate_key /run/secrets/site.key;

  location / {
  root /usr/share/nginx/html;
  index index.html index.htm;
  }
}

On utilise ensuite la syntaxe compose pour déployer notre service sur le Swarm.

networks:
  public:
    driver: overlay

configs:
  nginx_config:

    file: ./site.conf
services:
  web:
    image: nginx
  networks:
    - public
  ports:
    - "80:80"
  configs:
    - source: nginx_config
      target: /etc/nginx/conf.d/site.conf

La configuration créée va être stocker dans le noeud manager, puis lors du lancement du service, montée dans le container.

Dans le cas ou le service tombe et qu'il est remonté dans un autre nœud, il va accéder à nouveau à sa configuration.

Si c'est le nœud Manager qui tombe, l'ensemble du cluster tombe.

Dans le cas ou le Swarm possède plusieurs Managers, la configuration est stockée sur chacun d'entre eux pour un maximum de résilience.

Nous avons omis un détail ici cependant. Pour être accessible en HTTPS, Nginx à besoin de deux fichier que l'on peux voir dans "site.conf", le certificat : "site.crt" et la clé de chiffrement : "site.key".

 En situation réelle : utilisation des Secrets services

En situation réel, ces fichiers sont des données sensibles et nécessitent d'être traités différemment. Pour cela, nous allons utiliser les "Secrets configuration".

networks:
  public:
    driver: overlay

configs:
  nginx_config:
    file: ./site.conf

secrets:
  cert_secret:
    file: ./site.crt
  key_secret:
    file: ./site.key

services:
  web:
    image: nginx
  networks:
    - public
  ports:
    - "80:80"
  configs:
    - source: nginx_config
      target: /etc/nginx/conf.d/site.conf
  secrets:
    - cert_secret
    - key_secret

Ici on créer deux secrets correspondant au certificat ainsi qu'a la clés que nous indiquons ensuite dans le service comme on peux le faire avec les networks.

🔍 A savoir : par défaut, les fichiers sont montés dans le container dans "/run/secrets/<secret_name>" pour les secrets et dans "/<config_name>" pour les configs. Il est possible de spécifier l'emplacement grâce a la balise "target".