ProHoster > blog > amministrazione > Docker Compose: dallo sviluppo alla produzione

Docker Compose: dallo sviluppo alla produzione

Traduzione della trascrizione del podcast preparata in previsione dell'inizio del corso "Amministratore Linux"

Docker Compose: dallo sviluppo alla produzione

Docker Compose è uno strumento straordinario per creare un file funzionante
ambiente per lo stack utilizzato nella tua applicazione. Ti permette di definire
ogni componente della tua applicazione, seguendo una sintassi chiara e semplice in YAML-
File.

Con l'avvento di la finestra mobile compone v3 questi file YAML possono essere utilizzati direttamente nell'ambiente di produzione quando si lavora con
grappolo Sciame portuale.

Ma questo significa che puoi utilizzare lo stesso file docker-compose in
processo di sviluppo e nell’ambiente di produzione? Oppure usa lo stesso file per
messa in scena? Ebbene, in generale sì, ma per questa funzionalità abbiamo bisogno di quanto segue:

  • Interpolazione delle variabili: utilizzo delle variabili di ambiente per alcuni
    valori che cambiano in ogni ambiente.
  • Override della configurazione: possibilità di definire un secondo (o qualsiasi
    un altro successivo) file docker-compose che cambierà qualcosa riguardo
    innanzitutto, e docker compose si occuperà di unire entrambi i file.

Differenze tra file di sviluppo e di produzione

Durante lo sviluppo, molto probabilmente vorrai verificare le modifiche al codice
tempo reale. Per fare ciò, di solito viene montato il volume con il codice sorgente
contenitore che contiene il runtime per la tua applicazione. Ma per un ambiente di produzione
Questo metodo non è adatto.

In produzione, hai un cluster con molti nodi e il volume è locale
relativo al nodo su cui è in esecuzione il tuo contenitore (o servizio), quindi non lo fai
puoi montare il codice sorgente senza operazioni complesse che includono
sincronizzazione del codice, segnali, ecc.

Invece, di solito vogliamo creare un'immagine con una versione specifica del tuo codice.
È consuetudine contrassegnarlo con il tag appropriato (è possibile utilizzare semantic
controllo delle versioni o un altro sistema a tua discrezione).

Sostituzione della configurazione

Date le differenze e le dipendenze potrebbero differire negli scenari
sviluppo e produzione, è chiaro che avremo bisogno di file di configurazione diversi.

Docker Compose supporta l'unione di diversi file di composizione in
ottenere la configurazione finale. Come funziona può essere visto nell'esempio:

$ 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

Come detto, Docker Compose supporta la combinazione di più composizioni:
file, ciò consente di sovrascrivere vari parametri nel secondo file. Per esempio:

$ 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

Questa sintassi non è molto comoda durante lo sviluppo, quando il comando
dovrà essere fatto molte volte.

Fortunatamente, docker compose cerca automaticamente un file speciale chiamato
docker-compose.override.yml per sovrascrivere i valori finestra mobile-compose.yml. Se
rinomina il secondo file, ottieni lo stesso risultato, usando solo il comando originale:

$ 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, è più facile da ricordare.

Interpolazione di variabili

Supporto dei file di configurazione interpolazione
variabili e valori predefiniti. Cioè, puoi fare quanto segue:

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

E se lo fai docker-compose build (o push) senza variabile d'ambiente
$MY_SERVICE_VERSION, verrà utilizzato il valore con i più recentima se imposti
il valore della variabile d'ambiente prima della compilazione, verrà utilizzato durante la compilazione o il push
al registro private.registro.mine.

I miei principi

Gli approcci che funzionano per me potrebbero funzionare anche per te. Seguo questi
regole semplici:

  • Tutti i miei stack per la produzione, lo sviluppo (o altri ambienti) sono definiti tramite
    file docker-compose
  • File di configurazione necessari per coprire il più possibile tutti i miei ambienti
    evitare duplicazioni.
  • Ho bisogno di un semplice comando per lavorare in ogni ambiente.
  • La configurazione principale è definita nel file finestra mobile-compose.yml.
  • Le variabili d'ambiente vengono utilizzate per definire tag di immagine o altro
    variabili che possono variare da ambiente ad ambiente (staging, integrazione,
    produzione).
  • I valori delle variabili di produzione vengono utilizzati come valori per
    per impostazione predefinita, ciò riduce al minimo i rischi se lo stack viene avviato in produzione senza
    imposta la variabile di ambiente.
  • Per avviare un servizio in un ambiente di produzione, utilizzare il comando distribuzione dello stack docker - compose-file docker-compose.yml -with-registry-auth nome-stack.
  • L'ambiente di lavoro viene avviato utilizzando il comando docker-comporre up -d.

Diamo un'occhiata a un semplice esempio.

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

posso usare docker-compose (docker-compose up)per eseguire lo stack
modalità di sviluppo con codice sorgente montato in /progetto/src.

Posso usare questi stessi file in produzione! E potrei sicuramente usare
stesso file finestra mobile-compose.yml per la messa in scena. Per espandere questo a
produzione, devo solo creare e inviare l'immagine con un tag predefinito
nella fase CI:

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

In produzione, questo può essere eseguito utilizzando i seguenti comandi:

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

E se vuoi fare lo stesso sul palco, basta definirlo
variabili d'ambiente necessarie per lavorare nell'ambiente di staging:

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

Di conseguenza, abbiamo utilizzato due diversi file docker-compose, che senza
Le configurazioni duplicate possono essere utilizzate per qualsiasi ambiente tu abbia!

Scopri di più sul corso "Amministratore Linux"

Fonte: habr.com

Aggiungi un commento