Docker Compose : du développement à la production

Traduction de la transcription du podcast préparée en prévision du début du cours "Administrateur Linux"

Docker Compose est un outil incroyable pour créer un bureau
environnement pour la pile utilisée dans votre application. Il permet de définir
chaque composant de votre application, suivant une syntaxe claire et simple dans YAML-
des dossiers.

Avec l'avènement de docker composer v3 ces fichiers YAML peuvent être utilisés directement dans l'environnement de production, lorsque vous travaillez avec
grappe Docker Swarm.

Mais cela signifie-t-il que vous pouvez utiliser le même fichier docker-compose dans
processus de développement et environnement de production ? Ou utilisez le même fichier pour
mise en scène? Eh bien, en général, oui, mais pour une telle fonctionnalité, nous avons besoin des éléments suivants :

• Interpolation de variables : utiliser des variables d'environnement pour certains
  des valeurs qui changent dans chaque environnement.
• Remplacement de configuration : possibilité de définir un deuxième (ou tout autre
  un autre suivi) fichier docker-compose qui changera quelque chose concernant
  le premier, et docker compose se chargera de fusionner les deux fichiers.

Différences entre les fichiers de développement et de production

Pendant le développement, vous souhaiterez probablement vérifier les modifications du code dans
mode temps réel. Pour ce faire, le volume contenant le code source est généralement monté dans
un conteneur qui contient le runtime de votre application. Mais pour un environnement de production
cette méthode ne convient pas.

En production vous disposez d'un cluster multi-nœuds et le volume est local
par rapport à l'hôte sur lequel votre conteneur (ou service) s'exécute, vous ne devez donc pas
vous pouvez monter le code source sans opérations complexes, notamment
synchronisation du 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 le marquer avec la balise appropriée (vous pouvez utiliser la sémantique
versioning ou un autre système de votre choix).

Remplacement de la configuration

Compte tenu des différences et du fait que vos dépendances peuvent différer selon les scénarios
développement et 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 de composition vers
obtenez la configuration finale. Comment cela fonctionne peut être vu dans un exemple :

$ 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  | < hello! >
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 indiqué, Docker Compose prend en charge la fusion de plusieurs compositions.
fichiers, cela vous permet de remplacer diverses options 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  | < bye! >
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 dans le processus de développement, lorsque la commande
doit être fait plusieurs fois.

Heureusement, Docker Compose recherche automatiquement un fichier spécial appelé
docker-compose.override.yml pour remplacer les valeurs docker-compose.yml. Si
renommez le deuxième fichier, vous obtiendrez le même résultat, uniquement en utilisant 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  | < bye! >
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

D'accord, c'est plus facile à retenir.

Interpolation de variables

Prise en charge des fichiers de configuration interpolation
variables et les valeurs par défaut. Autrement dit, vous pouvez effectuer les opérations suivantes :

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

Et si tu le fais build docker-compose (ou push) sans variable d'environnement
$MY_SERVICE_VERSION, la valeur sera utilisée Nouveautésmais 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
enregistrer private.registry.mine.

Mes principes

Les approches qui me conviennent peuvent vous être utiles. je suis ça
règles simples :

• Toutes mes piles de production, de développement (ou autres environnements) sont définies via
  fichiers docker-compose.
• Les fichiers de configuration nécessaires pour couvrir tous mes environnements, max.
  éviter les doubles emplois.
• J'ai besoin d'une commande simple pour travailler dans tous les environnements.
• La configuration principale est définie dans le fichier docker-compose.yml.
• Les variables d'environnement sont utilisées pour définir des balises d'image ou d'autres
  variables qui peuvent changer d'un environnement à l'autre (staging, intégration,
  production).
• Les valeurs des variables de production sont utilisées comme valeurs par
  par défaut, cela minimise les risques si vous exécutez la pile en production sans
  définir la variable d'environnement.
• Pour démarrer un service dans un environnement de production, utilisez la commande déploiement de la pile docker - compose-file docker-compose.yml - avec-registry-auth mon-nom-stack.
• L'environnement de travail est démarré avec 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}
...

И

# 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 exécuter la pile à
mode de développement avec le code source monté dans /projet/src.

Je peux utiliser les mêmes fichiers en production ! Et je pourrais utiliser exactement
même fichier docker-compose.yml pour la mise en scène. Pour étendre cela à
production, j'ai juste besoin de construire et d'envoyer l'image avec une balise prédéfinie
au stade 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 tu veux faire pareil sur scène, il te suffit de définir
variables d'environnement nécessaires pour travailler dans l'environnement de test :

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 conséquence, nous avons utilisé deux fichiers docker-compose différents, qui, sans
les configurations en double peuvent être utilisées pour n’importe lequel de vos environnements !

En savoir plus sur le cours "Administrateur Linux"

Source: habr.com