Docker Compose: van ontwikkeling tot productie

Vertaling van de transcriptie van de podcast, voorbereid voorafgaand aan de start van de cursus "Linux-beheerder"

Docker Compose is een geweldig hulpmiddel voor het maken van een werk
omgeving voor de stack die in uw toepassing wordt gebruikt. Het geeft je de mogelijkheid om te definiëren
elk onderdeel van uw applicatie, volgens een duidelijke en eenvoudige syntaxis YAML-
bestanden.

Met de komst van docker compone v3 deze YAML-bestanden kunnen direct in de productieomgeving worden gebruikt tijdens het werken met
TROS Docker Zwerm.

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

• Variabele interpolatie: voor sommigen wordt gebruik gemaakt van omgevingsvariabelen
  waarden die in elke omgeving veranderen.
• Configuratie-override: mogelijkheid om een ​​tweede (of een andere) te definiëren
  een ander volgend) docker-compose-bestand dat iets zal veranderen met betrekking tot
  eerst, en docker compose zorgt voor het samenvoegen van beide bestanden.

Verschillen tussen ontwikkelings- en productiebestanden

Tijdens de ontwikkeling wilt u waarschijnlijk codewijzigingen controleren
echte tijd. Om dit te doen, wordt meestal het volume met de broncode aangekoppeld
container die runtime voor uw toepassing bevat. Maar dan voor een productieomgeving
Deze methode is niet geschikt.

In productie heb je een cluster met veel knooppunten en is het volume lokaal
relatief ten opzichte van het knooppunt waarop uw container (of service) draait, zodat u dat niet doet
u kunt de broncode koppelen zonder ingewikkelde bewerkingen
codesynchronisatie, signalen, etc.

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

Configuratie negeren

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

Docker compose ondersteunt het samenvoegen van verschillende compose-bestanden naar
verkrijgen van de definitieve configuratie. Hoe dit werkt kun je 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 gezegd ondersteunt docker compose het combineren van meerdere composes -
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 vele malen moeten gebeuren.

Gelukkig zoekt docker compose automatisch naar een speciaal bestand met de naam
docker-compose.override.yml waarden te overschrijven havenarbeider-compose.yml. als
hernoem het tweede bestand, je krijgt hetzelfde resultaat, alleen met behulp van de originele 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é, dat is makkelijker te onthouden.

Interpolatie van variabelen

Ondersteuning voor configuratiebestanden interpolatie
variabelen en standaardwaarden. Dat wil zeggen, u kunt 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
$MY_SERVICE_VERSION, wordt de waarde gebruikt laatstemaar als je instelt
de waarde van de omgevingsvariabele vóór de build, deze zal worden gebruikt bij het bouwen of pushen
naar het register private.registry.mine.

Mijn principes

De aanpak die voor mij werkt, werkt mogelijk ook voor jou. Ik volg deze
eenvoudige regels:

• Al mijn stapels voor productie, ontwikkeling (of andere omgevingen) worden gedefinieerd via
  docker-compose-bestanden
• Configuratiebestanden die nodig waren om al mijn omgevingen zoveel mogelijk te dekken
  vermijd dubbel werk.
• Ik heb één eenvoudige opdracht nodig om in elke omgeving te kunnen werken.
• De hoofdconfiguratie wordt gedefinieerd in het bestand havenarbeider-compose.yml.
• Omgevingsvariabelen worden gebruikt om afbeeldingstags of andere te definiëren
  variabelen die van omgeving tot omgeving kunnen variëren (staging, integratie,
  productie).
• De waarden van productievariabelen worden gebruikt als waarden voor
  standaard minimaliseert dit de risico's als de stapel zonder productie in productie wordt genomen
  omgevingsvariabele instellen.
• Om een ​​service in een productieomgeving te starten, gebruikt u de opdracht docker stack implementeren - compose-bestand docker-compose.yml -with-registry-auth mijn-stack-naam.
• De werkomgeving wordt gestart met behulp van de opdracht docker-opstellen up -d.

Laten we 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)om de stapel in te voeren
ontwikkelingsmodus met de broncode erin gemonteerd /project/src.

Ik kan dezelfde bestanden gebruiken in productie! En ik zou het zeker kunnen gebruiken
hetzelfde bestand havenarbeider-compose.yml voor enscenering. Om dit uit te breiden naar
productie, hoef ik alleen maar de 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 behulp van 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 staging-omgeving:

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

Als gevolg hiervan hebben we twee verschillende docker-compose-bestanden gebruikt, waarvan zonder
Dubbele configuraties kunnen worden gebruikt voor elke omgeving die u heeft!

Lees meer over de cursus "Linux-beheerder"

Bron: www.habr.com