Docker Compose: od rozwoju do produkcji

Tłumaczenie transkrypcji podcastu przygotowanej w oczekiwaniu na rozpoczęcie kursu „Administrator Linuksa”

Docker Compose to niesamowite narzędzie do tworzenia pracy
środowisko stosu używanego w aplikacji. Pozwala określić
każdego komponentu aplikacji, stosując jasną i prostą składnię YAML-
akta.

Z nadejściem docker compose v3 tych plików YAML można używać bezpośrednio w środowisku produkcyjnym podczas pracy
grupa Rój dokerów.

Ale czy to oznacza, że ​​możesz użyć tego samego pliku tworzenia dokera w
procesie rozwoju i w środowisku produkcyjnym? Lub użyj tego samego pliku dla
inscenizacja? Cóż, ogólnie tak, ale do tej funkcjonalności potrzebujemy:

• Interpolacja zmiennych: w niektórych przypadkach używanie zmiennych środowiskowych
  wartości, które zmieniają się w każdym środowisku.
• Nadpisanie konfiguracji: możliwość zdefiniowania drugiego (lub dowolnego
  kolejny kolejny) plik docker-compose, który zmieni coś w zakresie
  najpierw, a docker compose zajmie się połączeniem obu plików.

Różnice pomiędzy plikami deweloperskimi i produkcyjnymi

Podczas programowania najprawdopodobniej będziesz chciał sprawdzić zmiany w kodzie
czas rzeczywisty. W tym celu zwykle montuje się wolumin z kodem źródłowym
kontener zawierający środowisko uruchomieniowe Twojej aplikacji. Ale dla środowiska produkcyjnego
Ta metoda nie jest odpowiednia.

W środowisku produkcyjnym masz klaster z wieloma węzłami, a wolumin jest lokalny
względem węzła, na którym działa Twój kontener (lub usługa), więc tego nie robisz
możesz zamontować kod źródłowy bez skomplikowanych operacji, które obejmują
synchronizacja kodów, sygnałów itp.

Zamiast tego zwykle chcemy utworzyć obraz z określoną wersją Twojego kodu.
Zwyczajowo oznacza się go odpowiednim tagiem (można użyć semantic
wersjonowanie lub inny system według własnego uznania).

Zastąpienie konfiguracji

Biorąc pod uwagę różnice i zależności, które mogą się różnić w scenariuszach
rozwoju i produkcji, jasne jest, że będziemy potrzebować różnych plików konfiguracyjnych.

Docker Compose obsługuje łączenie różnych plików Compose
uzyskać ostateczną konfigurację. Jak to działa można zobaczyć na przykładzie:

$ 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

Jak powiedziano, docker compose obsługuje łączenie wielu kompozycji -
plików, pozwala to na nadpisanie różnych parametrów w drugim pliku. Na przykład:

$ 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

Ta składnia nie jest zbyt wygodna podczas programowania, gdy polecenie
trzeba będzie to robić wiele razy.

Na szczęście docker compose automatycznie szuka specjalnego pliku o nazwie
docker-compose.override.yml aby zastąpić wartości docker-compose.yml. Jeśli
zmień nazwę drugiego pliku, otrzymasz ten sam wynik, tylko używając oryginalnego polecenia:

$ 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, łatwiej to zapamiętać.

Interpolacja zmiennych

Obsługa plików konfiguracyjnych interpolacja
zmienne i wartości domyślne. Oznacza to, że możesz wykonać następujące czynności:

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

A jeśli to zrobisz Kompilacja docker-compose (lub push) bez zmiennej środowiskowej
$MY_SERVICE_VERSION, wartość zostanie użyta firmyale jeśli ustawisz
wartość zmiennej środowiskowej przed kompilacją, będzie ona używana podczas budowania lub wypychania
do rejestru private.registry.mine.

Moje zasady

Podejścia, które sprawdziły się w moim przypadku, mogą zadziałać także w twoim przypadku. Śledzę te
proste zasady:

• Wszystkie moje stosy do produkcji, rozwoju (lub innych środowisk) są zdefiniowane poprzez
  pliki docker-compose
• Pliki konfiguracyjne potrzebne do objęcia w jak największym stopniu wszystkich moich środowisk
  unikać powielania.
• Potrzebuję jednego prostego polecenia do pracy w każdym środowisku.
• Główna konfiguracja jest zdefiniowana w pliku docker-compose.yml.
• Zmienne środowiskowe służą do definiowania tagów graficznych lub innych
  zmienne, które mogą różnić się w zależności od środowiska (staging, integracja,
  produkcja).
• Wartości zmiennych produkcyjnych są używane jako wartości dla
  domyślnie minimalizuje to ryzyko, jeśli stos zostanie uruchomiony w środowisku produkcyjnym bez
  ustaw zmienną środowiskową.
• Aby uruchomić usługę w środowisku produkcyjnym, użyj komendy wdrażanie stosu dokerów - plik tworzenia docker-compose.yml -with-registry-auth nazwa-mojego stosu.
• Środowisko pracy jest uruchamiane za pomocą polecenia docker-compose up -d.

Spójrzmy na prosty przykład.

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

mogę użyć docker-compose (docker-compose up)aby uruchomić stos
tryb programistyczny z zamontowanym kodem źródłowym /projekt/src.

Mogę używać tych samych plików w produkcji! I zdecydowanie mógłbym skorzystać
ten sam plik docker-compose.yml do inscenizacji. Aby rozszerzyć to do
produkcji, wystarczy, że zbuduję i wyślę obraz z predefiniowanym tagiem
na etapie CI:

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

W środowisku produkcyjnym można to uruchomić za pomocą następujących poleceń:

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

A jeśli chcesz zrobić to samo na scenie, musisz tylko zdefiniować
niezbędne zmienne środowiskowe do pracy w środowisku testowym:

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

W rezultacie użyliśmy dwóch różnych plików tworzenia dokera, które bez
Zduplikowanych konfiguracji można używać w dowolnym środowisku!

Dowiedz się więcej o kursie „Administrator Linuksa”

Źródło: www.habr.com