[Docker] Einführung in Docker Compose Grundlegende Zusammenfassung von Docker-Compose.yml

Als Memorandum

Ich wollte organisieren, wie man docker-compose.yml und seine Gliederung einmal schreibt, also werde ich es schreiben.

Umgebung

-Host-Betriebssystem: Windows 10 Home ・ Gastbetriebssystem: wsl2 Ubuntu 20.04 ・ Docker Version 19.03 ・ Docker Compose Version 1.25.0

Verzeichnisstruktur / Dateiinhalt

In diesem Artikel nehmen wir die folgende Verzeichnisstruktur als Beispiel. (Dieser Artikel wurde als Referenz verwendet.)

.
|
├── infra
│   ├── mysql
│   │   ├── Dockerfile
│   │   └── my.cnf
│   ├── nginx
│   │   └── default.conf
│   └── php
│       ├── Dockerfile
│       └── php.ini
├── docker-compose.yml
└── backend
└── Verzeichnis zur Installation von Laravel

· Anwendungsserver ・ Webserver ・ Datenbankserver

Es ist eine Konfiguration zum Erstellen einer LEMP-Architektur, die aus drei Schichten besteht. Im ursprünglichen Artikel wird Laravel als Framework von PHP übernommen, diesmal jedoch nicht behandelt, da der Zweck darin besteht, das Wissen von docker-compose.yml zu organisieren.

Der Inhalt von docker-compose.yml lautet wie folgt.

version: "3"
services:
  app:
    build: ./infra/php
    volumes:
      - ./backend:/work
    depends_on:
      - web
  web:
    image: nginx:1.18-alpine
    ports:
      - "10080:80"
    volumes:
      - ./backend:/work
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - db
    working_dir: /work

  db:
    build: ./infra/mysql
    volumes:
      - db-store:/var/lib/mysql

volumes:
  db-store:

docker-compose.yml ist in einem Dateiformat namens yml (yaml) geschrieben. Für yml sollte Folgendes beachtet werden.

• Drücken Sie die hierarchische Struktur mit Einrückung aus. Um die Lesbarkeit zu gewährleisten, wird eine Hierarchie häufig durch zwei Einrückungen dargestellt. -Das - am Zeilenanfang steht für ein Array. - In derselben Hierarchie befinden sich Elemente desselben Arrays. -Beschreibungen wie key: value repräsentieren einen Hash. Nach dem :.

Häufig verwendete Schlüssel

build: Wird beim Generieren eines Bildes aus einer Docker-Datei definiert. .. Beschreiben Sie den Dateipfad der Docker-Datei im Wert. (Es spielt keine Rolle, ob es sich um einen relativen oder einen absoluten Pfad handelt. Außerdem sucht Docker Compose im beschriebenen Dateipfad nach einer Datei mit dem Namen Dockerfile, sodass Sie die Dockerfile weglassen können.)

app:
  build: ./infra/php

In diesem Fall wird das Bild, das die Grundlage für den App-Container bildet, aus der Docker-Datei in ./infra/php erstellt.

image: Gibt das Basis-Image an, auf dem der Container basiert. Wenn Sie beispielsweise das offizielle Image unverändert verwenden möchten, definieren Sie dies anstelle von Build.

 web:
   image: nginx:1.18-alpine

Hier wird aus dem offiziellen Image von nginx ein Webcontainer generiert.

• Aus den oben genannten Gründen sind Build und Image nicht für einen Container kompatibel. Es ist jedoch möglich, die beiden für verschiedene Container in einer docker-compose.yml zu verwenden.

ports: Gibt den Port an, den der Container verfügbar macht. Das Format lautet "Portnummer auf der Hostseite: Portnummer auf der Containerseite".

• In Yaml-Dateien können Formate wie aa :: bb als Zeit interpretiert werden, sodass es sicher ist, die Zeichenfolge in doppelte Anführungszeichen zu setzen.

web:
  image: nginx:1.18-alpine
  ports:
    - "10080:80"

In diesem Beispiel sind Port 10080 auf der Hostseite und Port 80 auf der Containerseite zugeordnet. (Port 80 ist die Standardportnummer für Nginx)

expose:

Obwohl diesmal nicht definiert, verwenden Sie exponieren anstelle von Ports, wenn Sie den Port des Containers nicht für die Hostseite verfügbar machen und ihn nur für einen anderen verknüpften Container öffnen möchten.

depends_on:

Definiert Containerabhängigkeiten.

web:
    image: nginx:1.18-alpine
    ports:
      - "10080:80"
    volumes:
      - ./backend:/work
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - db

Das obige Beispiel definiert, dass der Webcontainer vom Datenbankcontainer abhängt. Insbesondere wird die Reihenfolge definiert, in der der Datenbankcontainer aktiviert und dann der Webcontainer aktiviert wird.

Es steuert jedoch nur die Reihenfolge des Container-Starts und der Webserver wartet nicht, bis der Datenbankserver auf dem Container bereit ist.

Wenn Sie solche Spezifikationen vornehmen möchten, müssen Sie auf der Anwendungsseite Maßnahmen ergreifen.

volumes

Stellen Sie das Volumen auf den Behälter. Ich denke, es ist ein Begriff, den viele Menschen nicht verstehen, daher ist das Folgende eine kurze Erklärung.

-Volume: Ein Datenspeicherbereich zum Speichern von Daten, auch nachdem der Container zerstört wurde. Einfach ausgedrückt, das Verzeichnis, in dem die Daten im Container gespeichert sind -Mount: Zum Laden einer externen Datei in Linux.

Grob gesagt geht es um Shioume: "Da Container nicht für die Langzeitlagerung geeignet sind, speichern wir sie in einem externen Betriebssystem." (Ich denke, es ist unpraktisch, den Container zu betreten und PHP mit VIM zu bearbeiten ...)

Volumes werden im Format "Host-seitiges Verzeichnis mounten: Container-seitiges Verzeichnis" definiert.

app:
  build: ./infra/php
  volumes:
    - ./backend:/work

Hier wird das Arbeitsverzeichnis (und die Dateien und Verzeichnisse darunter) im App-Container im Host-Verzeichnis ./backend auf der Host-Seite bereitgestellt.

Zusammenfassung / Ergänzung

Es gibt viele andere Schlüssel, die definiert werden können, aber im Moment habe ich die grundlegenden zusammengefasst. Zunächst möchte ich Build und Volumes verstehen.