'Datenbanken' lautet der Schwerpunkt der Dezember-Ausgabe des IT-Administrator. Darin werfen wir einen Blick auf den Firewall-Schutz und das ... (mehr)

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.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019