🥇Docker Compose: van ontwikkeling tot productie

De transcriptie van de podcast is voorbereid in aanloop naar de start van de cursus ‘Linux Beheerder’

Docker Compose is een geweldig hulpmiddel voor het creëren van een werk
omgeving voor de stack die in uw applicatie wordt gebruikt. Het stelt u in staat om elke component van uw applicatie te definiëren, met een duidelijke en eenvoudige syntaxis in
YAML- bestanden
Met de komst van.

docker compose v3 kunnen deze YAML-bestanden direct in een productieomgeving worden gebruikt, bij het werken met een cluster.
Maar betekent dit dat u hetzelfde docker-compose bestand kunt gebruiken in Docker Swarm.

het ontwikkelingsproces en in de productieomgeving? Of hetzelfde bestand voor
staging? Nou, over het algemeen — ja, maar voor deze functionaliteit hebben we het volgende nodig:
Interpolatie van variabelen: het gebruik van omgevingsvariabelen voor bepaalde

waarden die in elke omgeving veranderen.
Herconfiguratie: de mogelijkheid om een tweede (of een andere) docker-compose bestand te definiëren, dat iets zal veranderen ten opzichte van
het eerste, en docker compose zal zorgen voor het samenvoegen van beide bestanden.
Verschillen tussen bestanden voor ontwikkeling en productie
Tijdens de ontwikkeling wilt u waarschijnlijk wijzigingen in de code in

realtime controleren. Hiervoor wordt meestal de broncodevolume gemonteerd in

de container waarin de runtime voor uw applicatie zich bevindt. Maar voor de productieomgeving
is deze aanpak niet geschikt.
In de productie heeft u een cluster met meerdere nodes, en het volume is lokaal ten opzichte van de node waarop uw container (of service) draait, dus u kunt niet
de broncode monteren zonder complexe handelingen die synchronisatie van de code, signalen, enz. omvatten.

In plaats daarvan willen we meestal een afbeelding maken met een specifieke versie van uw code.
Deze wordt doorgaans gemarkeerd met een overeenkomstig label (u kunt semantische
versiebeheer of een ander systeem naar uw keuze gebruiken).
Herconfiguratie

Gezien de verschillen en het feit dat uw afhankelijkheden kunnen verschillen in ontwikkelings- en productie-scenario's, is het duidelijk dat we verschillende configuratiebestanden nodig hebben.
Docker compose ondersteunt het samenvoegen van verschillende compose-bestanden voor
de uiteindelijke configuratie. Hoe dit werkt, kan worden gezien aan de hand van het voorbeeld:

Herconfiguratie

Gezien de verschillen en het feit dat uw afhankelijkheden kunnen variëren in scenario's
van ontwikkeling en productie, is het duidelijk dat we verschillende configuratiebestanden nodig hebben.

Docker Compose ondersteunt het samenvoegen van verschillende compose-bestanden voor
het verkrijgen van de uiteindelijke configuratie. Hoe dit werkt, is te zien aan het volgende voorbeeld:

$ 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

Zoals eerder vermeld, ondersteunt docker compose het samenvoegen van meerdere compose-
bestanden, wat het mogelijk maakt om verschillende parameters in het tweede bestand te overschrijven. Bijvoorbeeld:

$ 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

Deze syntaxis is niet erg handig tijdens de ontwikkeling, wanneer de opdracht
meerdere keren uitgevoerd moet worden.

Gelukkig zoekt docker compose automatisch naar een speciaal bestand met de naam
docker-compose.override.yml om waarden te overschrijven docker-compose.yml. Als
de tweede bestand te hernoemen, dan zou je hetzelfde resultaat krijgen, maar met de oorspronkelijke opdracht:

$ 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

Goed, zo is het makkelijker te onthouden.

Variabele interpolatie

Configuratiebestanden ondersteunen interpolatie
van variabelen en standaardwaarden. Dit betekent dat je het volgende kunt doen:

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

En als je uitvoert docker-compose build (of push) zonder een omgevingsvariabele
$MY_SERVICE_VERSION, wordt de waarde gebruikt latest, maar als je de waarde van de omgevingsvariabele voor de build instelt, wordt deze gebruikt tijdens de build of push
naar de register
private.registry.mine Mijn principes.

Mijn principes

De benaderingen die voor mij handig zijn, kunnen ook voor u nuttig zijn. Ik volg deze
eenvoudige regels:

Al mijn stacks voor productie, ontwikkeling (of andere omgevingen) worden gedefinieerd via
docker-compose bestanden.
De configuratiebestanden die nodig zijn om al mijn omgevingen te dekken, vermijden zoveel mogelijk
duplicatie.
Ik heb één eenvoudige opdracht nodig om in elke omgeving te werken.
De hoofdconfiguratie wordt gedefinieerd in het bestand docker-compose.yml.
Omgevingsvariabelen worden gebruikt om de tags van afbeeldingen of andere
variabelen te definiëren die van omgeving tot omgeving kunnen veranderen (staging, integratie,
productie).
Waarden van variabelen voor productie worden gebruikt als standaardwaarden, dit minimaliseert risico's bij het uitvoeren van de stack in productie zonder
een ingestelde omgevingsvariabele.
Om de service in de productieomgeving uit te voeren, wordt de opdracht
docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name gebruik om de werkomgeving te starten met de opdracht.
Laten we eens kijken naar een eenvoudig voorbeeld. docker-compose up -d.

Ik kan

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

docker-compose (docker-compose up) gebruiken om de stack in deontwikkelingsmodus te starten met de broncode gemount in
Ik kan dezezelfde bestanden ook op productie gebruiken! En ik zou precies /project/src.

dezelfde file
voor staging kunnen gebruiken. Om dit in docker-compose.yml productie te implementeren, hoef ik alleen maar de afbeelding met een vooraf gedefinieerde tag te bouwen en te pushen
in CI:
export MY_SERVICE_VERSION=1.2.3 docker-compose -f docker-compose.yml build docker-compose -f docker-compose.yml push

In productie kan dit worden uitgevoerd met de volgende opdrachten:

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

En als u hetzelfde op staging wilt doen, moet u gewoon de

noodzakelijke omgevingsvariabelen definiëren om in de stagingomgeving te werken:
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

Uiteindelijk hebben we twee verschillende docker-compose bestanden gebruikt, die zonder

duplicatie van configuraties voor elke van uw omgevingen kunnen worden gebruikt!
Meer weten over de cursus

Theorie en praktijk van het gebruik van ClickHouse in echte applicaties. Alexander Zaijcev (2018) ‘Linux Beheerder’

Bron: habr.com