🥇Docker Compose: a fejlesztéstől a produkcióig

A podcast transcription translation has been prepared in anticipation of the course launch „Linux Adminisztrátor”

A Docker Compose — a remarkable tool for creating a working
environment for the stack used in your application. It allows you to define
every component of your application, following a clear and simple syntax in YAML-
files..

With the advent of docker compose v3, these YAML files can be used directly in the working environment when working with
the cluster. Docker Swarm.

But does this mean that you can use the same docker-compose file in
the development process and in the production environment? Or use the same file for
staging? Well, generally — yes, but for this functionality we need the following:

Variable interpolation: using environment variables for some
values that change in each environment.
Configuration overriding: the ability to define a second (or any
subsequent) docker-compose file that modifies something in relation to
the first one, and docker compose will handle merging both files.

Differences between files for development and production

During development, you will likely want to check code changes in
real-time mode. For this, typically, the source code volume is mounted in
the container that runs your application runtime. However, for a production environment,
this method is not suitable.

In production, you have a cluster with multiple nodes, and the volume is local to
the node where your container (or service) is running, so you cannot
mount the source code without complex operations that include
code synchronization, signals, etc.

Instead, we typically want to create an image with a specific version of your code.
It is customary to tag it with a corresponding label (you can use semantic
versioning or another system at your discretion).

Configuration overriding

Given the differences and that your dependencies may vary in development and
production scenarios, it is clear that we will need different configuration files.

Docker compose supports combining various compose files to
obtain the final configuration. How this works can be seen in the example:

$ 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

Ahogy mondták, a docker compose támogatja több compose-
fájl egyesítését, ez lehetővé teszi különböző paraméterek felülbírálását a második fájlban. Például:

$ 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

Ez a szintaxis nem túl kényelmes a fejlesztés során, amikor a parancsot
többször is végre kell hajtani.

Szerencsére a docker compose automatikusan keres egy speciális fájlt a következő néven:
docker-compose.override.yml értékek felülbírálására docker-compose.yml. Ha
ha átnevezed a második fájlt, ugyanazt az eredményt kapod, csak az eredeti parancs használatával:

$ 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

Jó, így könnyebb megjegyezni.

Változók interpolálása

A konfigurációs fájlok támogatják a változók interpolálását
és az alapértelmezett értékeket. Tehát az alábbiakat megteheted: services: my-service: build: context: . image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest} ...

És ha a következő parancsot futtatod:

docker-compose build (vagy push) változós környezet nélkül $MY_SERVICE_VERSION
, akkor az érték, de ha beállítod latesta környezeti változó értékét a build előtt, az a build vagy push során fog felhasználódni
a regisztrációhoz
private.registry.mine Az elveim.

Elveim alapelveim

Azok a megközelítések, amelyek nekem kényelmesek, Önnek is hasznosak lehetnek. Követem ezeket
az egyszerű szabályokat:

Minden stackem a produkcióhoz, fejlesztéshez (vagy más környezetekhez) a
docker-compose fájlokon keresztül van meghatározva.
A konfigurációs fájlok, amelyek szükségesek az összes környezetem lefedéséhez, maximálisan
kerülik a duplikációt.
Szükségem van egy egyszerű parancsra minden környezethez.
A fő konfiguráció a docker-compose.yml.
fájlban van meghatározva.
A környezeti változók az image címkék vagy más
változók meghatározására szolgálnak, amelyek környezetről környezetre változhatnak (staging, integráció,
produkció).
A produkciós környezethez szükséges változók alapértelmezett értékként szolgálnak,
ez minimalizálja a kockázatokat, ha a stacket a produkcióban indítják el anélkül, hogy
meghatározott környezeti változó lenne. A szolgáltatás produkciós környezetben való futtatásához a következő parancsot használjuk:.
docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name docker-compose up -d.

A munkaidő környezetét a következő parancs segítségével indítjuk:

# 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}
...

és

# 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
...

Nézzünk meg egy egyszerű példát. A docker-compose (docker-compose up) használatávalelindíthatom a stacket
fejlesztési módban, a forráskódot pedig a következőképpen csatlakoztathatom: /project/src.

Ugyanazokat a fájlokat a produkcióban is használhatom! És pont ugyanazt a
fájlt alkalmazhatnám docker-compose.yml staginghez. Ahhoz, hogy ezt a
produkcióra telepítsem, csak annyit kell tennem, hogy összeállítom és eljuttatom az image-t a meghatározott címkével
a CI fázisban:

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

A produkciós környezetben az alábbi parancsokkal indíthatjuk el:

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

És ha ugyanezt szeretnék megtenni a stagingen, egyszerűen meg kell határoznom
a szükséges környezeti változókat a staging környezethez:

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

Végül két különböző docker-compose fájlt használtunk, amelyek duplikációs konfigurációk nélkül
bármelyik környezetéhez használhatóak!

Tudjon meg többet a tanfolyamról „Linux Adminisztrátor”

Forrás: habr.com