Docker Compose: de evoluo ĝis produktado

Traduko de la transskribo de la podkasto preparita antaŭ la komenco de la kurso "Linuksa Administranto"

Docker Compose estas mirinda ilo por krei labortablon
medio por la stako uzata en via aplikaĵo. Ĝi permesas vin difini
ĉiu komponanto de via aplikaĵo, sekvante klaran kaj simplan sintakson en YAML-
dosierojn.

Kun la apero de docker compose v3 ĉi tiuj YAML-dosieroj povas esti uzataj rekte en la produktadmedio, kiam oni laboras kun
grapolo Docker Svarmo.

Sed ĉu tio signifas, ke vi povas uzi la saman docker-compose dosieron en
evoluprocezo kaj produktadmedio? Aŭ uzu la saman dosieron por
surscenigo? Nu, ĝenerale, jes, sed por tia funkcio ni bezonas la jenon:

• Variebla interpolado: uzante mediovariablojn por iuj
  valoroj kiuj ŝanĝiĝas en ĉiu medio.
• Agordo superregado: la kapablo difini sekundon (aŭ ajnan
  alia sekvaĵo) docker-compose dosiero kiu ŝanĝos ion koncerne
  la unua, kaj docker compose zorgos kunfandi ambaŭ dosierojn.

Diferencoj inter disvolviĝo kaj produktado dosieroj

Dum evoluo, vi plej verŝajne volos kontroli por kodoŝanĝoj en
realtempa reĝimo. Por fari tion, kutime, la volumo kun la fontkodo estas muntita enen
ujo kiu enhavas la rultempon por via aplikaĵo. Sed por medio de produktado
ĉi tiu maniero ne taŭgas.

En produktado vi havas plurnodan areton kaj la volumeno estas loka
rilate al la gastiganto, sur kiu funkcias via ujo (aŭ servo), do vi ne faras
vi povas munti la fontkodon sen kompleksaj operacioj, kiuj inkluzivas
kodsinkronigado, signaloj, ktp.

Anstataŭe, ni kutime volas krei bildon kun specifa versio de via kodo.
Estas kutime marki ĝin per la taŭga etikedo (vi povas uzi semantikon
versionado aŭ alia sistemo de via elekto).

Anstataŭigo de agordo

Konsiderante la diferencojn kaj ke viaj dependecoj povas diferenci en scenaroj
disvolviĝo kaj produktado, estas klare, ke ni bezonos malsamajn agordajn dosierojn.

Docker-komponado subtenas kunfandi malsamajn komponajn dosierojn al
akiri la finan agordon. Kiel ĝi funkcias, oni povas vidi en ekzemplo:

$ 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

Kiel dirite, docker compose subtenas kunfandi plurajn komponadon-
dosierojn, ĉi tio ebligas al vi superregi diversajn opciojn en la dua dosiero. Ekzemple:

$ 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

Ĉi tiu sintakso ne estas tre oportuna en la procezo de disvolviĝo, kiam la komando
devas esti farita plurfoje.

Feliĉe, docker compose aŭtomate serĉas specialan dosieron nomitan
docker-compose.override.yml por superregi valorojn docker-compose.yml. Se
renomu la duan dosieron, vi ricevos la saman rezulton, nur uzante la originalan komandon:

$ 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

Bone, tio estas pli facile memorebla.

Varia Interpolado

Subteno de agordaj dosieroj interpolado
variabloj kaj defaŭltajn valorojn. Tio estas, vi povas fari la jenon:

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

Kaj se vi faros docker-compose konstruo (aŭ puŝo) sen mediovariablo
$MY_SERVICE_VERSION, la valoro estos uzata lastansed se vi starigas
la valoro de la mediovariablo antaŭ la konstruo, ĝi estos uzata dum konstruado aŭ puŝado
registri privata.registro.mine.

Miaj principoj

Aliroj, kiuj estas oportunaj por mi, povas esti utilaj por vi. Mi sekvas ĉi tion
simplaj reguloj:

• Ĉiuj miaj stakoj por produktado, evoluo (aŭ aliaj medioj) estas difinitaj tra
  docker-compose dosieroj.
• La agordaj dosieroj necesaj por kovri ĉiujn miajn mediojn, maks.
  eviti duobligon.
• Mi bezonas unu simplan komandon por labori en ĉiu medio.
• La ĉefa agordo estas difinita en la dosiero docker-compose.yml.
• Mediaj variabloj estas uzataj por difini bildajn etikedojn aŭ aliajn
  variabloj kiuj povas ŝanĝiĝi de medio al medio (scenigo, integriĝo,
  produktado).
• La valoroj de variabloj por produktado estas uzataj kiel valoroj de
  defaŭlte, ĉi tio minimumigas la riskojn se vi kuras la stakon en produktado sen
  starigis mediovariablon.
• Por komenci servon en produktadmedio, uzu la komandon docker stack deploy - compose-file docker-compose.yml - with-registry-auth mia-stack-nomo.
• La labormedio estas komencita per la komando docker-compose up -d.

Ni rigardu simplan ekzemplon.

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

Mi povas uzi docker-compose (docker-komponi supren)kuri la stakon ĉe
disvolva reĝimo kun fontkodo muntita en /projekto/src.

Mi povas uzi la samajn dosierojn en produktado! Kaj mi povus uzi ĝuste
sama dosiero docker-compose.yml por surscenigo. Por pligrandigi ĉi tion al
produktado, mi nur bezonas konstrui kaj sendi la bildon kun antaŭdifinita etikedo
en la CI-stadio:

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

En produktado, ĉi tio povas esti rulita per la sekvaj komandoj:

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

Kaj se vi volas fari la samon sur la scenejo, vi nur bezonas difini
necesaj mediovariabloj por labori en la ensceniga medio:

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

Kiel rezulto, ni uzis du malsamajn docker-komponajn dosierojn, kiuj, sen
duplikataj agordoj povas esti uzataj por iu ajn el viaj medioj!

Lernu pli pri la kurso "Linuksa Administranto"

fonto: www.habr.com