ProHoster > Bloc > Administració > Docker Compose: del desenvolupament a la producció

Docker Compose: del desenvolupament a la producció

Traducció de la transcripció del podcast elaborada en previsió de l'inici del curs "Administrador Linux"

Docker Compose: del desenvolupament a la producció

Docker Compose és una eina sorprenent per crear escriptoris
entorn per a la pila utilitzada a la vostra aplicació. Et permet definir
cada component de la vostra aplicació, seguint una sintaxi clara i senzilla a YAML-
Fitxers.

Amb l'arribada de docker compose v3 aquests fitxers YAML es poden utilitzar directament a l'entorn de producció, quan es treballa amb
clúster docker Swarm.

Però vol dir això que podeu utilitzar el mateix fitxer de composició docker-compose?
procés de desenvolupament i entorn de producció? O utilitzeu el mateix fitxer per
posada en escena? Bé, en general, sí, però per a aquesta funcionalitat necessitem el següent:

  • Interpolació de variables: utilitzant variables d'entorn per a alguns
    valors que canvien en cada entorn.
  • Anulació de configuració: la capacitat de definir un segon (o qualsevol
    un altre fitxer de seguiment) docker-compose que canviarà alguna cosa respecte
    el primer, i docker compose s'encarregarà de combinar tots dos fitxers.

Diferències entre fitxers de desenvolupament i de producció

Durant el desenvolupament, probablement voldreu comprovar si hi ha canvis de codi
mode en temps real. Per fer-ho, normalment, es munta el volum amb el codi font
un contenidor que conté el temps d'execució de la vostra aplicació. Però per a un entorn de producció
aquesta manera no és adequada.

En producció teniu un clúster multinode i el volum és local
en relació amb l'amfitrió on s'està executant el vostre contenidor (o servei), així que no ho feu
podeu muntar el codi font sense operacions complexes, que inclouen
sincronització de codi, senyals, etc.

En canvi, normalment volem crear una imatge amb una versió específica del vostre codi.
És habitual marcar-lo amb l'etiqueta adequada (podeu utilitzar la semàntica
versions o un altre sistema que escolliu).

Anul·lació de configuració

Tenint en compte les diferències i que les vostres dependències poden diferir en els escenaris
desenvolupament i producció, és evident que necessitarem diferents fitxers de configuració.

Docker Compose admet la fusió de diferents fitxers de redacció
obtenir la configuració final. Com funciona es pot veure en un exemple:

$ 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

Com s'ha dit, docker compose admet la fusió de múltiples
fitxers, això us permet anul·lar diverses opcions del segon fitxer. Per exemple:

$ 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

Aquesta sintaxi no és molt convenient en el procés de desenvolupament, quan l'ordre
s'ha de fer diverses vegades.

Afortunadament, Docker Compose busca automàticament un fitxer especial anomenat
docker-compose.override.yml per anul·lar valors docker-compose.yml. Si
canviar el nom del segon fitxer, obtindreu el mateix resultat, només utilitzant l'ordre original:

$ 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

D'acord, és més fàcil de recordar.

Interpolació variable

Suport de fitxers de configuració interpolació
les variables i valors per defecte. És a dir, podeu fer el següent:

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

I si ho fas compilació docker-compose (o push) sense variable d'entorn
$MY_SERVICE_VERSION, s'utilitzarà el valor últimperò si ho poses
el valor de la variable d'entorn abans de la construcció, s'utilitzarà quan es construeixi o s'impulsarà
per registrar-se el.registre.privat.la meva.

Els meus principis

Els enfocaments que em resulten convenients us poden ser útils. Jo segueixo això
regles senzilles:

  • Totes les meves piles per a la producció, el desenvolupament (o altres entorns) es defineixen
    fitxers docker-compose.
  • Els fitxers de configuració necessaris per cobrir tots els meus entorns, màx.
    evitar la duplicació.
  • Necessito una comanda senzilla per treballar en tots els entorns.
  • La configuració principal es defineix al fitxer docker-compose.yml.
  • Les variables d'entorn s'utilitzen per definir etiquetes d'imatge o altres
    variables que poden canviar d'un entorn a un altre (escenificació, integració,
    producció).
  • Els valors de les variables per a la producció s'utilitzen com a valors per
    per defecte, això minimitza els riscos si executeu la pila en producció sense
    establir una variable d'entorn.
  • Per iniciar un servei en un entorn de producció, utilitzeu l'ordre docker stack deploy - fitxer de composició docker-compose.yml - amb-registry-auth el meu-nom-pila.
  • L'entorn de treball s'inicia amb l'ordre docker-compose up -d.

Vegem un exemple senzill.

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

Puc utilitzar docker-compose (docker-compose)per executar la pila
mode de desenvolupament amb el codi font muntat /projecte/src.

Puc utilitzar els mateixos fitxers en producció! I podria utilitzar exactament
mateix fitxer docker-compose.yml per a la posada en escena. Per ampliar això a
producció, només necessito construir i enviar la imatge amb una etiqueta predefinida
a l'etapa CI:

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

En producció, això es pot executar amb les ordres següents:

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

I si vols fer el mateix a l'escenari, només has de definir
variables d'entorn necessàries per treballar en l'entorn de preparació:

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

Com a resultat, hem utilitzat dos fitxers Docker-compose diferents, que, sense
les configuracions duplicades es poden utilitzar per a qualsevol dels vostres entorns!

Més informació sobre el curs "Administrador Linux"

Font: www.habr.com

Afegeix comentari