🥇Docker Compose: van ontwikkeling tot productie

De vertaling van het podcasttranscript werd voorbereid ter voorbereiding op de start van de cursus. "Beheerder Linux»

Docker Compose is een geweldige tool voor het maken van een werkende
omgeving voor de stack die in uw applicatie wordt gebruikt. Hiermee kunt u definiëren
elk onderdeel van uw applicatie, volgens een duidelijke en eenvoudige syntaxis in YAML-
bestanden.

Met de komst van docker compose v3 Deze YAML-bestanden kunnen direct in productie worden gebruikt bij het werken met
cluster Docker Zwerm.

Maar betekent dit dat u hetzelfde docker-compose-bestand kunt gebruiken in
ontwikkelingsproces en in de productieomgeving? Of gebruik hetzelfde bestand voor
enscenering? Nou, over het algemeen wel, maar voor deze functionaliteit hebben we het volgende nodig:

Variabele interpolatie: omgevingsvariabelen gebruiken voor sommige
waarden die in elke omgeving veranderen.
Configuratie overschrijven: mogelijkheid om een tweede (of een willekeurige) configuratie te definiëren
een ander volgend) docker-compose-bestand dat iets relatiefs zal veranderen
Eerst zal docker compose beide bestanden samenvoegen.

Verschillen tussen ontwikkelings- en productiebestanden

Tijdens de ontwikkeling zult u waarschijnlijk de codewijzigingen willen inchecken in
in realtime. Voor dit doel wordt het broncodevolume meestal in
de container die de runtime voor uw toepassing bevat. Maar voor de productieomgeving
Deze methode is niet geschikt.

In productie heb je een cluster met veel knooppunten en het volume is lokaal voor de
relatief ten opzichte van het knooppunt waarop uw container (of service) draait, dus u hoeft niet
Je kunt de broncode mounten zonder complexe handelingen, waaronder
codesynchronisatie, signalen, enz.

In plaats daarvan willen we doorgaans een afbeelding maken met een specifieke versie van uw code.
Het is gebruikelijk om het te markeren met een passende tag (u kunt een semantische tag gebruiken
versiebeheer of een ander systeem naar eigen goeddunken).

Configuratie overschrijven

Houd rekening met de verschillen en het feit dat uw afhankelijkheden in verschillende scenario's kunnen verschillen
ontwikkeling en productie, is het duidelijk dat we verschillende configuratiebestanden nodig hebben.

Docker Compose ondersteunt het combineren van verschillende Compose-bestanden om
het verkrijgen van de uiteindelijke configuratie. Hoe dit werkt, kunt u zien in het 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  | < 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

Zoals vermeld, ondersteunt docker compose het combineren van meerdere compose-
bestanden, hiermee kunt u verschillende parameters in het tweede bestand 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  | < 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

Deze syntaxis is niet erg handig tijdens de ontwikkeling, wanneer de opdracht
zal meerdere keren herhaald moeten worden.

Gelukkig zoekt docker compose automatisch naar een speciaal bestand met de naam
docker-compose.override.yml waarden overschrijven havenarbeider-compose.yml. als
Als u de naam van het tweede bestand wijzigt, krijgt u hetzelfde resultaat, maar gebruikt u 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  | < 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

Oké, nu is het makkelijker te onthouden.

Interpolatie van variabelen

Ondersteuning voor configuratiebestanden interpolatie
variabelen en standaardwaarden. U kunt dus het volgende doen:

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

En als je dat doet docker-compose build (of push) zonder omgevingsvariabele
$MIJN_SERVICE_VERSIE, de waarde zal worden gebruikt laatste, maar als je installeert
de waarde van de omgevingsvariabele vóór de build, deze zal worden gebruikt tijdens de build of push
naar het register privé.register.mijn.

Mijn principes

De benaderingen die voor mij werken, werken misschien ook voor jou. 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, zijn als volgt:
duplicatie vermijden.
Ik heb één eenvoudig commando nodig om in elke omgeving te kunnen werken.
De hoofdconfiguratie is gedefinieerd in het bestand havenarbeider-compose.yml.
Omgevingsvariabelen worden gebruikt om afbeeldingslabels of andere
variabelen die van omgeving tot omgeving kunnen verschillen (staging, integratie,
productie).
De waarden van de productievariabelen worden gebruikt als waarden voor
Standaard minimaliseert dit de risico's bij het uitvoeren van de stack in productie zonder
omgevingsvariabele instellen.
Om de service in de productieomgeving te starten, gebruikt u de opdracht docker stack implementatie - compose-bestand docker-compose.yml -met-register-auth mijn-stack-naam.
De werkomgeving wordt gestart met de opdracht docker-opstellen up -d.

Laten we eens naar een eenvoudig voorbeeld kijken.

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

Ik kan gebruiken docker-compose (docker-compose omhoog)om de stapel te starten in
ontwikkelingsmodus met de broncode gemonteerd in /project/bron.

Ik kan deze bestanden ook in productie gebruiken! En ik zou het zeker kunnen gebruiken
hetzelfde bestand havenarbeider-compose.yml voor enscenering. Om dit verder uit te breiden
productie, ik hoef alleen maar een afbeelding te bouwen en te verzenden met een vooraf gedefinieerde tag
in de CI-fase:

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 je hetzelfde op het podium wilt doen, hoef je alleen maar te definiëren
Noodzakelijke omgevingsvariabelen voor het werken in de stagingomgeving:

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
U kunt configuratieduplicaties voor al uw omgevingen gebruiken!

Lees meer over de cursus "Beheerder Linux»

Bron: www.habr.com