Runtimes und Container

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.

docker-compose.yml

Der transparentere Weg, Umgebungsvariablen zu verwalten ist direkt in der docker-compose.yml.

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.

Internes Netz und externes Netz

Docker verwaltet unterschiedliche Netzwerke. Dazu gehört auch ein Netzwerk für den Namespace des Projekts. Um nun Container in das Projekt zu integrieren, muss das in der docker-compose.yml entsprechend notiert werden. Folgend der schematische Aufbau für diesen Fall.

  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 aufzubauen. Es ist bspw. sinnvoll zu erzwingen, dass die Datenbank gestartet ist, bevor die Application 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 oft ein zusätzlicher Mechanismus erforderlich, um sicherzustellen, dass sie vollständig betriebsbereit sind, bevor Anwendungen, die von ihnen abhängen, gestartet werden.

Healthcheck

Die Garantie, dass der Dienst voll funktionsfähig ist, bringt ein Healtcheck. 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