Übersetzung der Transkription des Podcasts, die im Vorfeld des Kursbeginns erstellt wurde
Docker Compose ist ein erstaunliches Tool zum Erstellen von Desktops
Umgebung für den in Ihrer Anwendung verwendeten Stack. Es ermöglicht Ihnen zu definieren
jede Komponente Ihrer Anwendung, nach einer klaren und einfachen Syntax .
Mit dem Aufkommen von Diese YAML-Dateien können beim Arbeiten direkt in der Produktionsumgebung verwendet werden
Cluster .
Aber bedeutet das, dass Sie dieselbe Docker-Compose-Datei in verwenden können?
Entwicklungsprozess und Produktionsumgebung? Oder verwenden Sie dieselbe Datei für
Inszenierung? Nun, im Allgemeinen ja, aber für eine solche Funktionalität benötigen wir Folgendes:
- Variableninterpolation: Für einige werden Umgebungsvariablen verwendet
Werte, die sich in jeder Umgebung ändern. - Konfigurationsüberschreibung: die Möglichkeit, eine zweite (oder eine beliebige) zu definieren
eine weitere Folgedatei) Docker-Compose-Datei, die etwas daran ändern wird
die erste, und Docker Compose kümmert sich um das Zusammenführen beider Dateien.
Unterschiede zwischen Entwicklungs- und Produktionsdateien
Während der Entwicklung möchten Sie höchstwahrscheinlich nach Codeänderungen suchen
Echtzeitmodus. Dazu wird in der Regel das Volume mit dem Quellcode eingebunden
Ein Container, der die Laufzeit für Ihre Anwendung enthält. Aber für eine Produktionsumgebung
dieser Weg ist nicht geeignet.
In der Produktion haben Sie einen Cluster mit mehreren Knoten und das Volume ist lokal
relativ zum Host, auf dem Ihr Container (oder Dienst) ausgeführt wird, sodass Sie dies nicht tun
Sie können den Quellcode ohne komplexe Vorgänge bereitstellen, zu denen auch gehören
Codesynchronisation, Signale usw.
Stattdessen möchten wir normalerweise ein Bild mit einer bestimmten Version Ihres Codes erstellen.
Es ist üblich, es mit dem entsprechenden Tag zu kennzeichnen (Sie können die Semantik verwenden
Versionierung oder ein anderes System Ihrer Wahl).
Konfigurationsüberschreibung
Angesichts der Unterschiede und der Tatsache, dass Ihre Abhängigkeiten in den Szenarien unterschiedlich sein können
Für die Entwicklung und Produktion ist klar, dass wir unterschiedliche Konfigurationsdateien benötigen werden.
Docker Compose unterstützt das Zusammenführen verschiedener Compose-Dateien
Holen Sie sich die endgültige Konfiguration. Wie es funktioniert, sehen Sie an einem Beispiel:
$ 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 0Wie bereits erwähnt, unterstützt Docker Compose das Zusammenführen mehrerer Compose-
Dateien können Sie auf diese Weise verschiedene Optionen in der zweiten Datei überschreiben. Zum Beispiel:
$ 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 0Diese Syntax ist im Entwicklungsprozess nicht sehr praktisch, wenn der Befehl eingegeben wird
muss mehrmals durchgeführt werden.
Glücklicherweise sucht Docker Compose automatisch nach einer speziellen Datei namens
docker-compose.override.yml um Werte zu überschreiben docker-compose.yml. Wenn
Benennen Sie die zweite Datei um. Sie erhalten das gleiche Ergebnis, nur mit dem ursprünglichen Befehl:
$ 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 0Okay, das ist leichter zu merken.
Variable Interpolation
Unterstützung für Konfigurationsdateien und Standardwerte. Das heißt, Sie können Folgendes tun:
services:
my-service:
build:
context: .
image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...Und wenn ja Docker-Compose Build (oder Push) ohne Umgebungsvariable
$MY_SERVICE_VERSION, der Wert wird verwendet neuesteaber wenn du es einstellst
Der Wert der Umgebungsvariablen vor dem Build wird beim Erstellen oder Pushen verwendet
registrieren private.registry.mine.
Meine Prinzipien
Ansätze, die für mich bequem sind, können für Sie nützlich sein. Ich folge dem
einfache Regeln:
- Alle meine Stacks für Produktion, Entwicklung (oder andere Umgebungen) sind durch definiert
Docker-Compose-Dateien. - Die Konfigurationsdateien, die benötigt werden, um alle meine Umgebungen abzudecken, max.
vermeide Dopplungen. - Ich brauche einen einfachen Befehl, um in jeder Umgebung zu funktionieren.
- Die Hauptkonfiguration ist in der Datei definiert docker-compose.yml.
- Umgebungsvariablen werden zum Definieren von Bild-Tags oder anderem verwendet
Variablen, die sich von Umgebung zu Umgebung ändern können (Staging, Integration,
Produktion). - Als Werte für werden variable Werte für die Produktion verwendet
Dies minimiert standardmäßig die Risiken, wenn Sie den Stack in der Produktion ohne ausführen
Umgebungsvariable festlegen. - Um einen Dienst in einer Produktionsumgebung zu starten, verwenden Sie den Befehl Docker-Stack-Bereitstellung – Compose-Datei docker-compose.yml – with-registry-auth my-stack-name.
- Mit dem Befehl wird die Arbeitsumgebung gestartet docker-komponieren -d.
Schauen wir uns ein einfaches Beispiel an.
# 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
...ich kann nutzen docker-compose (docker-compose up)um den Stapel laufen zu lassen
Entwicklungsmodus mit eingebundenem Quellcode /project/src.
Ich kann die gleichen Dateien in der Produktion verwenden! Und genau das könnte ich gebrauchen
die gleiche Datei docker-compose.yml zur Inszenierung. Um dies zu erweitern
Für die Produktion muss ich nur das Bild erstellen und mit einem vordefinierten Tag senden
im CI-Stadium:
export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml pushIn der Produktion kann dies mit den folgenden Befehlen ausgeführt werden:
export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-authUnd wenn Sie dasselbe auf der Bühne tun möchten, müssen Sie es nur definieren
Notwendige Umgebungsvariablen für die Arbeit in der Staging-Umgebung:
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-authAus diesem Grund haben wir zwei verschiedene Docker-Compose-Dateien verwendet, ohne
Duplikatkonfigurationen können für jede Ihrer Umgebungen verwendet werden!
Erfahren Sie mehr über den Kurs
Source: habr.com