Nach Docker + Laravel =? Ich möchte über eine eher ungewöhnliche Art sprechen, das Docker-Compose-Dienstprogramm zu verwenden.
Für den Anfang, für diejenigen, die nicht wissen, warum Docker-Compose benötigt wird. Dies ist ein Dienstprogramm, mit dem Sie eine Reihe verwandter Dienste, die in Docker-Containern gepackt sind, auf einem separaten Host ausführen können. Die ursprüngliche Version wurde in Python geschrieben und kann auf zwei Arten installiert werden:
- über den Paketmanager des Betriebssystems (
apt install docker-compose für Ubuntu und yum install docker-compose.noarch für Centos) - über Python Dependency Manager (
pip install docker-compose )
Das Problem mit der ersten Methode ist, dass in der Regel in den Repositorys des Docker-Compose-Betriebssystems der alten Version. Dies ist ein Problem, wenn Sie die neueste Version des Docker-Dämons verwenden oder Funktionen verwenden müssen, die für eine bestimmte Version des Dateiformats docker-compose.yaml spezifisch sind (eine Matrix der unterstützten Funktionen nach Formatversionen und Versionen des Docker-compose-Dienstprogramms finden Sie auf der offiziellen Docker-Website).
Jetzt Docker-Entwickler hat das Dienstprogramm unterwegs neu geschrieben , einen Fehler gemacht, das Python-Skript mit der Umgebung tatsächlich in ein einziges Paket gepackt und als Binärdatei bereitgestellt, mit der Sie es auf folgende Weise installieren können (dies ist die derzeit empfohlene Methode):
Wir sehen uns die neueste Version unter https://github.com/docker/compose/releases an und laden sie herunter
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
Legen Sie die Rechte zum Ausführen der Anwendung fest
$ sudo chmod +x /usr/local/bin/docker-compose
Darüber hinaus können Sie die automatische Vervollständigung für die Befehlsinterpreter bash und zsh festlegen
Überprüfen Sie die Installation
$ docker-compose --version docker-compose version 1.22.0, build 1719ceb
Ich glaube, dass eine einzelne Binärdatei sehr cool ist, weil Wir müssen keine Python-Abhängigkeiten ziehen. Ja, und im Allgemeinen - vielleicht ist unsere Python-Umgebung auf dem Zielcomputer, den wir konfigurieren möchten, vollständig defekt !!!
Verwirrungsbeispiel in einer Python-Umgebung
Aber es gibt noch einen vierten Weg, über den ich sprechen wollte. Dies ist die Möglichkeit, Docker-Compose über Docker auszuführen. In der Tat gibt es bereits offizielle Bilder im Docker Hub ( https://hub.docker.com/r/docker/compose/ ). Warum könnten sie gebraucht werden?
- wenn wir mit mehreren Versionen von Docker-Compose gleichzeitig arbeiten möchten (obwohl normalerweise die letzte stabile Version ausreicht)
- Wenn wir kein Python haben oder es nicht verwenden möchten (zum Beispiel haben wir eine leichtgewichtige Distribution von CoreOS Container Linux )
- Verwendung in CI / CD-Pipelines.
Lass es uns versuchen!
Wie wir normalerweise Container gestartet haben:
$ docker-compose up -d
Über ein in einem Docker-Container verpacktes Dienstprogramm:
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v "$PWD:/rootfs/$PWD" -w="/rootfs/$PWD" docker/compose:1.13.0 up -d
Zu ausführlich, oder? Das Gehirn kann gebrochen werden, um sich an all diese Parameter zu erinnern. Deshalb werden wir versuchen, unser Leben einfacher zu machen und einen Wrapper in Shell-Sprache zu schreiben. Aber zuerst schauen wir uns die übergebenen Parameter an:
--rm - entfernt den temporären Container nach dem Stoppen, d.h. Wir lassen keinen Müll im System-v /var/run/docker.sock:/var/run/docker.sock - Ohne dies kann Docker-Compose keine Verbindung zum Docker-Daemon auf dem Host herstellen-v "$PWD:/rootfs/$PWD" -w="/rootfs/$PWD" - Ermöglicht das Weiterleiten des aktuellen Verzeichnisses im Container, sodass das Dienstprogramm die Docker-Compose-Datei sieht
Es fehlt uns immer noch die Möglichkeit, Werte in der Docker-Compose-Datei zu interpolieren. Dies ist der Prozess, durch den das Dienstprogramm Umgebungsvariablen in einer YAML-Datei ersetzt. Zum Beispiel in einem Fragment
version: "2.1" services: pg: image: postgres:9.6 environment: POSTGRES_USER: ${POSTGRES_DB_USER} POSTGRES_PASSWORD: ${POSTGRES_DB_PASSWORD}
Die Variablen POSTGRES_DB_USER und POSTGRES_DB_PASSWORD werden aus der Umgebung gelesen. Auf diese Weise können Docker-Compose-Dateien mit einem gewissen Grad an Komfort erstellt werden. Das heißt, Wir müssen die Umgebung vom Host-Computer erfassen und in den Container übertragen.
Lösen wir das Problem, indem wir ein Bash-Skript schreiben.
#!/bin/sh # TMPFILE=$(mktemp) # env > "${TMPFILE}" # VERSION="1.13.0" # docker-compose docker run \ --rm \ -e PWD="$PWD" \ --env-file "${TMPFILE}" \ -v /var/run/docker.sock:/var/run/docker.sock \ -v "$PWD:/rootfs/$PWD" \ -w="/rootfs/$PWD" \ docker/compose:"${VERSION}" \ "$@" # rm "{$TMPFILE}"
Zusätzliche Zeilen erschienen:
-e PWD="$PWD" - leiten Sie für alle Fälle das aktuelle Verzeichnis weiter--env-file "${TMPFILE}" - hier werden alle anderen Umgebungsvariablen vom Host-Computer übertragendocker/compose:"${VERSION}" - der Name des Bildes, nehmen Sie die Version aus der Variablen"$@" - Mit dieser Konstruktion können Sie das Skript so verwenden, als wäre es das Docker-Compose-Dienstprogramm, d. h. Übergibt seine Argumente transparent an den Docker-Container.
Wir können das Skript beispielsweise in /usr/local/bin/docker-compose speichern, das eXecute-Flag darauf setzen und es verwenden. Das obige Skript gibt nicht vor, zu 100% frei von Fehlern oder Mängeln zu sein, sondern veranschaulicht die Methode.
Wir selbst verwenden CI / CD-Pipelines auf diese Weise. Dies spart sogar teilweise Verkehr. Das Docker-Zielbild wird aus dem lokalen Cache entnommen.