Docker Compose: kehityksestä tuotantoon

Käännös kurssin alkamista ennakoiden laaditusta podcastin transkriptiosta "Linux-järjestelmänvalvoja"

Docker Compose on hämmästyttävä työkalu työpöydän luomiseen
ympäristö sovelluksessasi käytetylle pinolle. Sen avulla voit määritellä
sovelluksesi jokainen osa selkeän ja yksinkertaisen syntaksin mukaan YAML-
tiedostot.

Tulon myötä Docker Compose v3 näitä YAML-tiedostoja voidaan käyttää suoraan tuotantoympäristössä työskennellessäsi
klusterin Docker-parvi.

Mutta tarkoittaako tämä, että voit käyttää samaa Docker-Compose -tiedostoa
kehitysprosessi ja tuotantoympäristö? Tai käytä samaa tiedostoa
lavastus? No, yleensä kyllä, mutta tällaista toimintaa varten tarvitsemme seuraavat:

• Muuttujien interpolointi: ympäristömuuttujien käyttö joillekin
  arvot, jotka muuttuvat jokaisessa ympäristössä.
• Kokoonpanon ohitus: kyky määrittää toinen (tai mikä tahansa
  toinen seuranta) docker-compose-tiedosto, joka muuttaa jotain
  ensimmäinen ja docker compose huolehtivat molempien tiedostojen yhdistämisestä.

Erot kehitys- ja tuotantotiedostojen välillä

Kehityksen aikana haluat todennäköisesti tarkistaa koodin muutokset
reaaliaikainen tila. Tätä varten yleensä lähdekoodilla varustettu asema on asennettu
säilö, joka sisältää sovelluksesi suoritusajan. Mutta tuotantoympäristöön
tämä tapa ei sovi.

Tuotannossa sinulla on monen solmun klusteri ja volyymi on paikallinen
suhteessa isäntään, jossa säilösi (tai palvelusi) on käynnissä, joten et
voit liittää lähdekoodin ilman monimutkaisia ​​toimintoja, joita ovat mm
koodin synkronointi, signaalit jne.

Sen sijaan haluamme yleensä luoda kuvan tietyllä koodiversiolla.
On tapana merkitä se sopivalla tunnisteella (voit käyttää semanttista
versiointi tai jokin muu valitsemasi järjestelmä).

Kokoonpanon ohitus

Ottaen huomioon erot ja se, että riippuvuutesi voivat vaihdella skenaarioissa
kehitystä ja tuotantoa, on selvää, että tarvitsemme erilaisia ​​konfiguraatiotiedostoja.

Dockerin kirjoitus tukee eri kirjoitustiedostojen yhdistämistä
hanki lopullinen kokoonpano. Kuinka se toimii, voidaan nähdä esimerkissä:

$ 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

Kuten sanottu, Docker Compose tukee useiden kirjoitusten yhdistämistä.
tiedostot, tämän avulla voit ohittaa toisen tiedoston eri vaihtoehdot. Esimerkiksi:

$ 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

Tämä syntaksi ei ole kovin kätevä kehitysprosessissa, kun komento
on tehtävä useita kertoja.

Onneksi Docker Compose etsii automaattisesti erityistä tiedostoa nimeltä
docker-compose.override.yml ohittaa arvot docker-compose.yml. jos
Nimeä toinen tiedosto uudelleen, saat saman tuloksen, vain käyttämällä alkuperäistä komentoa:

$ 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

Okei, se on helpompi muistaa.

Muuttujan interpolointi

Asetustiedostojen tuki interpolointi
muuttujia ja oletusarvot. Eli voit tehdä seuraavaa:

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

Ja jos teet telakka-kirjoitus (tai työnnä) ilman ympäristömuuttujaa
$MY_SERVICE_VERSION, arvoa käytetään uusinmutta jos asetat
ympäristömuuttujan arvo ennen rakentamista, sitä käytetään rakentamisessa tai työntämisessä
rekisteröityä private.registry.mine.

Minun periaatteeni

Minulle sopivat lähestymistavat voivat olla hyödyllisiä sinulle. Seuraan tätä
yksinkertaiset säännöt:

• Kaikki pinot tuotantoa, kehitystä (tai muita ympäristöjä varten) varten on määritelty
  Docker-kirjoitustiedostoja.
• Asetustiedostot, jotka tarvitaan kattamaan kaikki ympäristöni, max.
  välttää päällekkäisyyttä.
• Tarvitsen yhden yksinkertaisen komennon toimiakseni kaikissa ympäristöissä.
• Pääkonfiguraatio on määritelty tiedostossa docker-compose.yml.
• Ympäristömuuttujia käytetään kuvatunnisteiden tai muun määrittämiseen
  muuttujat, jotka voivat muuttua ympäristöstä toiseen (lavastaminen, integrointi,
  tuotanto).
• Tuotannon muuttujien arvoja käytetään arvoina by
  oletusarvoisesti tämä minimoi riskit, jos käytät pinoa tuotannossa ilman
  aseta ympäristömuuttuja.
• Voit käynnistää palvelun tuotantoympäristössä käyttämällä komentoa docker-pinon käyttöönotto - kirjoita-tiedosto docker-compose.yml - with-registry-auth my-pino-nimi.
• Työympäristö käynnistetään komennolla docker-säveltää ylös -d.

Katsotaanpa yksinkertaista esimerkkiä.

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

osaan käyttää telakka-kirjoita (telakka-kirjoita ylös)suorittaa pinon
kehitystila, johon on asennettu lähdekoodi /projekti/src.

Voin käyttää samoja tiedostoja tuotannossa! Ja voisin käyttää täsmälleen
sama tiedosto docker-compose.yml lavastusta varten. Laajentaaksesi tämän
tuotantoa, minun täytyy vain rakentaa ja lähettää kuva ennalta määritetyllä tunnisteella
CI-vaiheessa:

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

Tuotannossa tämä voidaan suorittaa seuraavilla komennoilla:

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

Ja jos haluat tehdä saman lavalla, sinun tarvitsee vain määritellä
esitysympäristössä toimimiseen tarvittavat ympäristömuuttujat:

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

Tuloksena käytimme kahta erilaista Docker-Compose -tiedostoa, jotka ilman
päällekkäisiä määrityksiä voidaan käyttää missä tahansa ympäristössäsi!

Lue lisää kurssista "Linux-järjestelmänvalvoja"

Lähde: will.com