Gut vorbereitet

Uphold bringt die nötigen "Dockerfiles" bereits mit, die es braucht, um für seine Tests die benötigten Container zu starten. Das sind grundsätzlich drei Stück: In einem Container läuft die grafische Oberfläche von Uphold, über die der Admin später auch Zugriff auf ein einfaches Webinterface erhält – dort sieht er über entsprechende Icons, ob ein Test-Lauf

erfolgreich war (grün), ob ein Fehler aufgetreten ist (rot/orange) oder ob der Test aus spezifischen Gründen gar nicht durchgeführt werden konnte (blau) (Bild 2). Der zweite Container beherbergt die Testkomponenten von Uphold, also jenen Teil, der zuvor definierte Tests gegen die Datenbank fährt, in der Uphold vorher automatisch das Back­­up eingespielt hat. Container 3 ent­hält neben der Datenbank alle weiteren Uphold-Komponenten, insbesondere den Controller, der mit dem "tester"-Container redet und dort die Durchführung der Tests anstößt.

In Sachen Benutzerfreundlichkeit haben die Uphold-Entwickler mitgedacht: Der Admin hinterlegt lediglich die Uphold-Konfiguration auf dem Zielsystem und startet danach über die Docker-eigenen Werkzeuge den "uphold-ui"-Container mit der grafischen Uphold-Oberfläche. Über die internen Docker-Werkzeuge zum Starten von Containern stößt jener Uphold-Container dann den Bau und Start der beiden anderen Docker-Container an. Für den Admin fällt effektiv also nur ein Befehl an, den er auf der Kommandozeile eingeben muss, um die Uphold-Tests in Gang zu setzen.

Bild 2: Per Webinterface stellt Uphold auf Wunsch Resultate der Tests auch grafisch dar.

 Die meiste Arbeit: Uphold konfigurieren

Damit dieser Automatismus ruckelfrei funktioniert, steht allerdings zuerst die Aufgabe an, Uphold zu konfigurieren. Uphold setzt im Wesentlichen auf Konfigurationsdateien und kommt ohne Programme daher, die das Einrichten der Lösung erleichtern. Hier ist in Sachen Komfort bei der Benutzung also noch Platz nach oben. Gleich mehrere Konfigurationsdateien sind nötig:

- "/etc/uphold/uphold.yml" ist die zentrale Uphold-Konfigurationsdatei, in der alle grundlegenden Einstellungen hinterlegt sind. Das sind gar nicht so viele, wie man vermuten würde: Insgesamt acht Parameter stehen den Admin zur Verfügung, um das Uphold-Verhalten zu steuern.

- "/etc/uphold/conf.d/" kann als Ordner beliebig viele Konfigurationsdateien im YAML-Format (Endung .yml) enthalten. Jede dieser Dateien enthält eine fertige Konfiguration für ein Uphold-Gespann aus drei Containern. Während die zuvor erwähnte "uphold.yml" also das Verhalten von Uphold selbst bestimmt, hin­terlegt der Admin in den Dateien im "conf.d"-Ordner die Konfiguration für Test-Cluster aus drei Containern. Dazu gehören der genutzte Datenbank-Typ ("engine"), die genutzte Methode, um an das zu testende Datenbank-Backup heranzukommen ("transport"), sowie die Tests.

- "/etc/uphold/engines/", "/etc/uphold/transports/" und "/etc/uphold/tests/" liefern quasi den Unterbau für die Angaben in "/etc/uphold/conf.d/". Damit sich etwa in der Konfigurationsdatei für ein Container-Gespann Tests festlegen lassen, sind diese in einzelnen YAML-Dateien in "/etc/uphold/tests/" zu definieren. Gleiches gilt für die Transport-Methode und die unterstützten Datenbanken. Uphold kommt ab Werk mit MySQL, PostgreSQL und MongoDB zurecht; die später in den Containern laufenden Datenbanken lassen sich über die "Engine"-Dateien also konfigurieren.

Die Inhalte von "uphold.yml" werden dem Admin kaum Kopfzerbrechen bereiten, denn hier gibt es kaum etwas zu konfigurieren. Das folgende Beispiel lässt sich problemlos übernehmen:

log_level: DEBUG

config_path: /etc/uphold

docker_log_path: /var/log/uphold

docker_url: unix:///var/run/docker.sock

docker_container: forward3d/uphold-tester

docker_tag: latest

docker_mounts: - /var/db-backups

Lediglich den Wert von "docker_mounts" sollten Admins je nach lokaler Vorgabe anpassen: Das hier genannte Verzeichnis hängt Uphold beim Start der Container später automatisch in deren Dateisystem ein. Das ist dann notwendig, wenn die Datenbank-Backups, die Uphold verifizieren soll, auf dem Uphold-Host-System bereits vorliegen. Alternativ dazu bietet Uphold die Möglichkeit, Backups per S3-Protokoll im laufenden Betrieb nachzuladen. In  diesem Fall entfällt der Parameter "docker_mounts" in "uphold.yml" ersatzlos und der Admin legt später einen eigenen "transport" für diesen Zweck an. Der Wert hinter "log_level" lässt sich übrigens auch auf "INFO", "WARN" oder "ERR" setzen – er legt fest, welche Meldungen Uphold in seine Logdatei schreibt und welche es ohne Anzeige verwirft. "DEBUG" bedeutet, dass Uphold sämtliche generierten Meldungen in das Uphold-Log schreibt.