Seitenvergleich

Welche Runtimes gibt es?

Umgebungsvariablen

Umgebungsvariablen haben mehrere wichtige Zwecke:

• Konfiguration: Sie ermöglichen die Konfiguration innerhalb des Containers. Beispielsweise können Datenbank-URLs, API-Schlüssel oder andere Konfigurationseinstellungen, die sich je nach Umgebung (Entwicklung, Test, Produktion) unterscheiden können, über Umgebungsvariablen festgelegt werden.

• Geheimnisverwaltung: Sensible Informationen wie Passwörter oder Tokens können als Umgebungsvariablen übergeben werden, anstatt sie hart in das Docker-Image oder den Quellcode einzukodieren. Dies verbessert die Sicherheit und Flexibilität.

• Anpassung von Verhalten: Umgebungsvariablen können verwendet werden, um das Verhalten der Anwendung anzupassen. Beispielsweise kann ein DEBUG-Modus aktiviert werden, um zusätzliche Log-Ausgaben zu erhalten, ohne den Code zu ändern.

brandbox.docker.env

In der Datei werden typischerweise die Umgebungsvariablen für brandbox abgelegt. 

...

version: '2.4'
services:

  application:
    image: [...]:latest
    environment:
      MYSQL_HOST: database.${COMPOSE_PROJECT_NAME}
      [...]

$COMPOSE_PROJECT_NAME

Die Variable hat einen besonderen Stellenwert. Darüber wird der Docker-Namespace organisiert. Domain und Ordner werden darüber verwaltet und zusammengehalten.  

Konfiguration über Bind-Mounts

Viele Docker-Images benötigen eine zentrale Konfiguration innerhalb des Containers, damit die darunterliegende Anwendung lauffähig ist. Diese Konfigurationen sollen über eine Bind-Mount von außen in den Container gemappt werden.
Anwendungsfall: man möchte für Debug-Zwecke Slow-Logging im MariaDB-Container aktivieren. Da die zu Grunde liegende my.cnf, in der diese Einstellung gemacht wird, sich im Image und innerhalb des Containers befindet, lässt sich diese Änderung nicht persistent machen. Man müsste stattdessen eine Shell im Container öffnen, die Datei im Container anpassen und danach den Datenbankserver neu starten. Aufgrund fehlender Tools und Rechte ist dies oft überhaupt nicht möglich. In diesem Fall bietet es sich an, die my.cnf einfach über einen Bind-Mount in den Container zu mappen:

volumes:
  ...
  - ./config/mariadb:/etc/mysql/conf.d

Das Verzeichnis ./config/mariadb befindet sich parallel zur docker-compose.yml und enthält alle notwendigen Konfigurationsdateien, die MariaDB im Verzeichnis /etc/mysql/conf.d erwartet. So können Einstellungen an der Konfiguration von außen einfach geändert werden, es muss lediglich der Container bei einer Änderung neu gestartet werden.

Internes Netz und externes Netz

...

  yourContainer:
    image: [...]
    networks:
      internal:
        aliases:
          - your-url.${COMPOSE_PROJECT_NAME}
    ports:
      - "1234"

• image: Hier sollte der Name des Docker-Images angegeben werden. Die Platzhalter [...] sollten durch den tatsächlichen Namen des Images ersetzt werden.

• networks: Unter networks wird das Netzwerk definiert, dem der Container zugeordnet werden soll. Hier verwenden Sie internal, was darauf hindeutet, dass es sich um ein internes Netzwerk handelt. Stellen Sie sicher, dass dieses Netzwerk in der docker-compose.yml unter dem Abschnitt networks definiert ist.

• aliases: Die Verwendung von aliases unter dem Netzwerk internal ist korrekt. Hier wird der DNS-Alias für den Container innerhalb des Netzwerks festgelegt.

• ports: Der Port 1234 wird nach außen freigegeben. Dies sollte der Port sein, auf dem die Anwendung im Container läuft. Die Syntax "1234" bedeutet, dass der Port 1234 des Containers auf denselben Port des Host-Systems abgebildet wird. Sie können auch eine andere Port-Konfiguration verwenden, z.B. "HostPort:ContainerPort".

networks

networks:
  internal:
    external:
      name: shared

Abhängigkeiten zwischen Containern

Es ist möglich, Abhängigkeiten zwischen Containern im Projekt aufzubauenzu definieren. Es ist bspw. sinnvoll zu erzwingenbeispielsweise sinnvoll, sicherzustellen, dass die Datenbank gestartet ist, bevor die Application Anwendung zur Verfügung steht. 

version: '2.4'
services:

  application:
    depends_on:
      database:
        condition: service_healthy
      image-processing:
        condition: service_started

Beachten Sie , dass depends_on nicht garantiert, dass die aufgelisteten Dienste voll funktionsfähig sind, bevor der abhängige Dienst gestartet wird. Es garantiert nur, dass sie vorher gestartet werden. Für Dienste wie Datenbanken ist den Unterschied zwischen den Bedingungen service_started und service_healthy:

• service_started: Diese Bedingung stellt sicher, dass der Dienst (z.B. die Datenbank) lediglich gestartet wurde. Sie garantiert jedoch nicht, dass der Dienst vollständig funktionsfähig oder bereit zur Nutzung ist.

• service_healthy: Diese Bedingung geht einen Schritt weiter und stellt sicher, dass der Dienst auch die Health-Check-Tests erfolgreich bestanden hat und somit vollständig betriebsbereit ist.

Für Dienste wie Datenbanken, bei denen es wichtig ist, dass sie nicht nur gestartet, sondern auch betriebsbereit sind, ist oft ein zusätzlicher Mechanismus erforderlich, um sicherzustellen, dass sie vollständig betriebsbereit sindder Dienst vollständig verfügbar ist, bevor Anwendungen, die von ihnen abhängen, die abhängigen Dienste gestartet werden.

Healthcheck

Die Garantie, dass der Dienst voll funktionsfähig ist, bringt ein HealtcheckHealthcheck. Der wird bspw. in der Datenbank durchgeführt:

version: '2.4'
services:
  database:
    healthcheck:
      test: ["CMD", "mysql", "-uroot", "-proot", "-e", "SELECT version();"]
      interval: 1m
      timeout: 10s
      retries: 3

...