Docker Compose : de la conception à la production

La transcription du podcast a été réalisée en prévision du début du cours « Administrateur Linux »

Docker Compose est un outil incroyable pour créer un environnement de travail
pour la pile utilisée dans votre application. Il vous permet de définir
chaque composant de votre application en suivant une syntaxe claire et simple dans des fichiers YAML.
Avec l'apparition de.

docker compose v3, ces fichiers YAML peuvent être utilisés directement en environnement de travail, lors de l'utilisation d'un cluster.
Docker Swarm Mais cela signifie-t-il que vous pouvez utiliser le même fichier docker-compose dans.

le processus de développement et en environnement de production? Ou utiliser ce même fichier pour
le staging? Eh bien, en général — oui, mais pour cette fonctionnalité, nous avons besoin de ce qui suit:
Interpolation des variables : utilisation de variables d'environnement pour certains

• valeurs qui changent dans chaque environnement.
  Redéfinition de la configuration : possibilité de définir un second (ou tout autre fichier
• docker-compose subséquent) qui modifiera quelque chose par rapport au
  premier, et docker compose se chargera de fusionner les deux fichiers.
  Différences entre les fichiers pour le développement et la production

Lors du développement, vous souhaiterez probablement vérifier les modifications de code en

temps réel. Pour cela, généralement, le volume contenant le code source est monté dans
le conteneur où se trouve le runtime de votre application. Mais pour un environnement de production,
ce moyen n'est pas approprié.
En production, vous avez un cluster avec de nombreux nœuds, et le volume est local par

rapport au nœud sur lequel fonctionne votre conteneur (ou service), donc vous ne
pouvez pas monter le code source sans opérations complexes, impliquant
synchronisation de code, signaux, etc.
Au lieu de cela, nous souhaitons généralement créer une image avec une version spécifique de votre code.

Il est d'usage de pointer un tag correspondant (vous pouvez utiliser le versionnement sémantique ou un autre système à votre convenance).
Redéfinition de la configuration
Étant donné les différences et le fait que vos dépendances peuvent varier selon les scénarios

de développement et de production, il est clair que nous aurons besoin de fichiers de configuration différents.

Docker compose prend en charge la fusion de différents fichiers compose pour
obtenir la configuration finale. Comment cela fonctionne peut être observé à travers l'exemple suivant:

Docker Compose supporte la fusion de plusieurs fichiers Compose pour
obtenir la configuration finale. Comment cela fonctionne peut être vu à travers l'exemple suivant :

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | 
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Comme mentionné, docker compose prend en charge la fusion de plusieurs compose-
fichiers, ce qui permet de remplacer divers paramètres dans le deuxième fichier. Par exemple :

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | 
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Cette syntaxe n'est pas très pratique pendant le développement, lorsque la commande
doit être exécutée plusieurs fois.

Heureusement, docker compose recherche automatiquement un fichier spécial nommé
docker-compose.override.yml pour remplacer les valeurs docker-compose.yml. Si
renommer le deuxième fichier donnera le même résultat, mais avec la commande d'origine :

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | 
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

C'est bien, c'est plus facile à retenir.

Interpolation des variables

Les fichiers de configuration prennent en charge l'interpolation
des variables et des valeurs par défaut. Cela signifie que vous pouvez faire ce qui suit :

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

Et si vous exécutez docker-compose build (ou push) sans la variable d'environnement
$MY_SERVICE_VERSION, la valeur par défaut sera utilisée latest, mais si vous définissez
la valeur de la variable d'environnement avant la construction, elle sera utilisée lors de la construction ou du push
vers le registre private.registry.mine.

Mes principes

Les approches qui me conviennent peuvent également vous être utiles. Je suis ces
règles simples :

• Tous mes stacks pour la production, le développement (ou d'autres environnements) sont définis à l'aide de
  fichiers docker-compose.
• Les fichiers de configuration nécessaires pour couvrir tous mes environnements évitent au maximum
  la duplication.
• J'ai besoin d'une seule commande pour fonctionner dans chaque environnement.
• La configuration principale est définie dans le fichier docker-compose.yml.
• Les variables d'environnement sont utilisées pour définir les tags des images ou d'autres
  variables qui peuvent changer d'un environnement à l'autre (staging, intégration,
  production).
• Les valeurs des variables pour la production sont utilisées comme valeurs par
  défaut, ce qui minimise les risques en cas de lancement de stack en production sans
  variable d'environnement définie.
• Pour démarrer le service dans un environnement de production, on utilise la commande docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name.
• L'environnement de travail est démarré à l'aide de la commande docker-compose up -d.

Regardons un exemple simple.

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

Et

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

Je peux utiliser docker-compose (docker-compose up), pour démarrer le stack en
mode développement avec le code source monté dans /project/src.

Je peux utiliser ces mêmes fichiers en production ! Et je pourrais utiliser exactement
le même fichier docker-compose.yml pour le staging. Pour déployer cela en
production, il suffit de construire et de pousser l'image avec un tag prédéfini
à l'étape CI :

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

En production, cela peut être exécuté avec les commandes suivantes :

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Et si vous souhaitez faire la même chose en staging, il suffit de définir
les variables d'environnement nécessaires pour fonctionner dans l'environnement de staging :

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

En fin de compte, nous avons utilisé deux fichiers docker-compose différents, qui sans
duplication des configurations peuvent être utilisés pour n'importe lequel de vos environnements !

En savoir plus sur le cours « Administrateur Linux »

Source : habr.com