Engines für die Datenbanken

Die folgenden drei Schritte sind etwas aufwendiger: Hier legt der Admin quasi den Grundstein für den Betrieb eines Uphold-Verbundes, indem er eine Engine, einen Transport für die Backups in die Docker-Container und die gewünschten Tests definiert. Den Anfang machen die Engines: Wie bereits erwähnt steht neben MySQL und PostgreSQL auch MongoDB zur Verfügung. Uphold nutzt für die Festlegung auf eine Datenbank das Schlüsselwort "type", das entsprechend die Werte "mysql", "postgresql" und "mongodb" haben kann. Weil die Definitionen von Engines ebenfalls im YAML-Format vorliegen, steht in der ersten Zeile der Engine-Definition das Schlüsselwort "engine".

Neben "type" steht noch das "settings"-Keyword zur Verfügung: Dieses legt die relevante Konfiguration für den zuvor defi­nierten "type" fest. Dabei gibt es eine Besonderheit: Das für den Datenbank-Container zu nutzende Docker-Abbild wählt Uphold auf Grundlage der "type"-Konfiguration aus. Für einen MySQL-Container würde Uphold also ein anderes Container-Image nutzen als für PostgreSQL. Die Schlüsselwörter "docker_image" und "docker_tag" geben dem Admin die Möglichkeit, hier auch ein eigenes, selbst vorbe­reitetes Docker-Image zu nutzen. Ein vollständiges, auf MySQL basiertes Beispiel für eine Engine-Definition ist dieses:

engine:

    type: mysql

    settings:

       database: your_database_name

       docker_image: mariadb

       docker_tag: 5.5.42

       port: 3306

       sql_file: MySQL.sql

"database" legt der Admin nach eigenem Gutdünken fest. "sql_file" sollte sich auf den Namen der Datei mit dem Backup innerhalb des Containers beziehen. In "uphold.yml" legt der Artikel etwa fest, dass Docker "/var/db-backups" des Host-Systems in den Container durchschleift – heißt das Backup der Datenbank nun "mysql.tar" und liegt in diesem Ordner, so lautet die passende Angabe für "sql_file" "/var/db-backups/mysql.tar".

Bild 3: Das Beispiel zeigt einen MongoDB-Test auf Minitest-Basis. Beispiele für MySQL liegen Uphold leider nicht bei; hier ist Handarbeit angesagt.

Transports als Zwischenschritte

Als "Transport" bezeichnet Uphold einen Zwischenschritt bei der Verarbeitung von Backups: Das Transport-Modul ist verantwortlich dafür, eine Backup-Datei so vorzubereiten, dass die laufende Datenbank des Datenbank-Containers sie im Anschluss sofort nutzen kann. Teil der Vorbereitung kann dabei durchaus auch sein, die Backup-Datei erstmal herunterzuladen. Zu diesem Zweck unterstützt Uphold das Amazon-S3-Protokoll: Wer von seiner Datenbank Backups automatisch mit Hilfe eines externen Backup-Programms zieht, kann diese – je nach genutztem Werkzeug – automatisch auch in den Amazon-S3-Objektspeicher hochladen lassen. Uphold wiederum kann, wenn es mit den Login-Daten für den S3-Zugang gewappnet ist, diese Dateien direkt aus dem S3-Speicher laden. Das folgende Beispiel beschreibt einen Transport für S3:

transport:

    type: s3

    settings:

       region: eu-central-1

       access_key_id:

AKIAIOSFODNN7EXAMPLE

       secret_access_key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

       bucket: db-backups

       path: backups/mysql

       filename: mysql-{date}.tar

       date_format: '%Y-%m-%d'

       date_offset: 0

Dieses Beispiel sucht im Ordner "backups/mysql" nach einer Datei mit dem Namen "mysql-Jahr-Monat-Tag.tar". "{date}" ist ein Platzhalter, den Uphold von sich aus in das Format übersetzt, das in "date_format" angegeben ist. Am 03.10. wäre der Dateiname also "mysql-2016-10-03.tar". Wer seine Backups nicht aus S3 bezieht, nutzt alternativ einen "local"-Transport:

transport:

    type: local

    settings:

       path: /var/db-backups

       filename: mysql-{date}.tar

       date_format: '%Y-%m-%d'

       date_offset: 0

Der Transport führt zum selben Effekt wie das vormals beschriebene S3-Beispiel, allerdings greift Uphold hier direkt über den beschriebenen Pfad auf die Datei zu.