Docker: Komposition von Containern

In diesem Fall hat der Container aber noch keine Funktion, d.h. in der Realität nimmt man ein Image auf dem das fertige Programm schon installiert ist und automatisch mit dem Container gestartet wird. Aber wenn man sich ein eigenes Image mit einem eigenen Programm bauen möchte, ist es natürlich einfacher mit einem Basis-Image einer Linux-Distribution anzufangen. Um den Container zu konfigurieren kann man bestimmte Parameter, wie offene Ports, direkt beim Start mit dem “docker run” Befehl übergeben oder um benötigte Programme zu installieren sich mit dem Container verbinden (wie eine SSH Verbindung). Einfacher geht das Erstellen eines Images mithilfe einer Dockerfile-Datei. In dieser Datei wird eine Anleitung konfiguriert, die schrittweise das entsprechende Image zusammenbaut und konfiguriert.

Wenn man ein eigenes Image erstellt hat, kann man dieses im Docker-Hub hochladen und privat oder öffentlich verfügbar machen. Alternativ kann man auch im eigenen lokalen Netzwerk auf einem Server eine Docker Registry als Sammelstelle für Container-Images erstellen. Die Registry ist wiederum ein Container in der Docker-Umgebung und kann die Images sammeln und zur Verfügung stellen. Dabei können auch Versionsnummern vergeben werden um ein Image nach Änderungen neu zu speichern und weiterhin die Möglichkeit zu haben zu einer älteren Version zurückzukehren. Ein eigener Server mit den benötigten Images im lokalen Netz hat den weiteren Vorteil, dass die Übertragungsraten höher sein dürften als wenn jedes Image erst aus dem Internet heruntergeladen werden muss oder unter Umständen ist eine direkte Verbindung zum Internet gar nicht vorhanden.

Die meisten Applikationen brauchen meistens trotz fertigem Image des Containers noch weitere Konfigurationsparameter. Wenn die Applikation aus mehreren Containern besteht, müssen diese unter Umständen über bestimmte Ports kommunizieren und verbunden werden, benötigen Verknüpfungen mit einer Datenbank oder sollen einen Ordnerpfad außerhalb des Containers verwenden. Über die Einbindung von Pfaden außerhalb des Containers oder in anderen Containern, bleiben die Dateien erhalten wenn der entsprechende Container gelöscht oder ersetzt wird. Um lange Kommandozeilen-Befehle zu vereinfachen bzw. zu reduzieren, kann die Erweiterung docker-compose verwendet werden. Für docker-compose erstellt man eine Textdatei mit dem Namen docker-compose.yml, die alle nötigen Konfigurationsparameter einschließlich des Containers selbst in der richtigen Formatierung enthält. Anschließend kann man mit einem Container den Container oder auch mehrere Container mit einem einfachen “docker-compose up” über die Kommandozeile starten. Dadurch lassen sich Images (Dockerfile) und die Konfiguration (docker-compose.yml) über zwei Textdateien leicht zusammenfassen, die leicht zu editieren und portabel sind. Somit lässt sich jeder Container auch einfach von einer Docker-Umgebung ohne weiteres in einer anderen Docker-Umgebung wieder herstellen oder nachstellen.

Im folgenden wird eine docker-compose.yml-Datei für einen WordPress-Blog, bestehend aus einer mySQL-Datenbank in einem Container und WordPress in einem weiteren Container, erklärt. Das Beispiel lässt sich auch in der offiziellen Dokumentation von docker-compose wiederfinden. docker-compose.yml:

version: '2'
services:
  database:   image: mysql:5.7
    volumes:
      - "./.data/db:/var/lib/mysql"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: wordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - database
    image: wordpress:latest   links:
      - database
    ports:
      - "8000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: database:3306
      WORDPRESS_DB_PASSWORD: wordpress

Dabei steht “version: ‘v2’ ” für Version 2 der docker-compose.yml-Syntax (und ist nicht unbedingt notwendig) und unter “services:” sind beide Container definiert. Für den Container database soll das Image von mySQL in der Version 5.7 verwendet

werden, während für den Container wordpress als Image die aktuell höchste verfügbare Version von WordPress verwendet werden soll. Auch sind beide Container so konfiguriert, dass sie selbstständig neugestartet werden, wenn z.B. die Docker-Umgebung neugestartet wird. Für den Container database werden außerdem die 4 aufgeführten mySQL-Umgebungsvariablen definiert (hier alle einfach mit dem Wert “wordpress”). Unter “volumes” wird ein Ordner mit dem Pfad “./.data/db” auf der Maschine der Docker-Umgebung in den Container auf den Pfad “/var/lib/mysql” verlinkt. Somit bleiben Daten die in dem Container unter diesem Pfad abgelegt werden (die Datenbankdaten) erhalten auch wenn der Container gelöscht wird und können somit auch an einen neuen Container übergeben werden. Der Container wordpress wurde durch “depends_on” vom Datenbank-Container abhängig, d.h. der WordPress-Container wird erst gestartet sobald der Container mit der mySQL-Datenbank bereits läuft. Mit diesem Container wird der Container auch verlinkt und die entsprechenden Umgebungsvariablen definiert um auf die Datenbank zugreifen zu können. Außerdem wird der öffentliche Port 8000 mit dem internen Port 80 der WordPress-Applikation verlinkt, wodurch der WordPress-Blog anschließend unter dem Port 8000 der Maschine mit Docker verfügbar wird. Nur mit dieser docker-compose-Datei können in wenigen Minuten die zwei benötigten Container gestartet werden und sind nach dem Herunterladen in kürzester Zeit (normalerweise weniger als eine Minute nach Start) verfügbar.

Dies ist Teil 2 aus einer Reihe von Blogbeiträgen zum Thema Docker/Rancher.

Teil 1 bietet einen Überblick zu Docker und Container-Umgebungen

Teil 2 erklärt die Funktionen einer Docker Registry und docker-compose

Teil 3 stellt Docker Swarm mit einer Docker Umgebung verteilt über mehrere Hosts vorhanden

Teil 4 zeigt Rancher als Orchestrierungstool für Docker (und andere Containerumgebungen)

Teil 5 enthält kurze Informationen zu den Rancher-Funktionen eines Katalogs und rancher-compose