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

Das Salz in der Suppe: Tests

Während Transports und Engines leicht einzurichten sind, sind Tests in Sachen Komplexität ein anderes Kaliber. Das hat zwei Gründe: Einerseits liegen Uphold selbst keine Beispiel-Tests für MySQL bei. Auf der Uphold-GitHub-Seite findet sich lediglich ein einsames Beispiel zu MongoDB (Bild 3). Wer also MySQL-Tests für Uphold braucht, fängt quasi bei Null an, denn auch aus der Community kommt keine Schützenhilfe. Andererseits ist gerade das auch nachvollziehbar: Denn was in Sachen Datenbank bei MySQL zu testen ist, weiß letztlich nur der betreibende Admin selbst. Ein Test, der sich lediglich mit MySQL verbindet und dann einen Client auf die spezifische Datenbank loslässt, ist weitestgehend nutzlos. Denn so ließe sich lediglich beweisen, dass der Docker-Container mit MySQL richtig funktioniert und automatisiert eine Datenbank mit MySQL aufsetzen kann.

Relevant ist für den Admin aber viel mehr die Information, ob im Backup, das Uphold zuvor in die Versuchsdatenbank eingespielt hat, tatsächlich sinnvolle Daten stehen. Und was "sinnvoll" ist, variiert von Fall zu Fall. Denkbar wäre das Auslesen von Tabellen in der Datenbank, um die ausgelesenen Inhalte danach auf Plausibilität zu prüfen. Mögliche Kriterien sind dabei möglicherweise die Fragen, ob es eine auffällig erhöhte Anzahl leerer Felder gibt ober ob in den einzelnen Feldern der Tabelle der Inhalt den Erwartungen entspricht. Was jene Erwartungen sind, weiß aber wieder nur der Admin. Dieser kommt bei Uphold also nicht drumherum, hochspezifische Tests für seinen Uphold-Einsatzzweck zu bauen und sie in Uphold zu integrieren.

Ein paar feste Regeln gilt es beim Verfassen von MySQL-Tests aber auch zu beachten. Wie der Rest von Uphold müssen die Tests in Ruby geschrieben sein und "Minitest" nutzen. Bei Minitest handelt es sich um ein von der "Seattle Ruby Brigade" im Netz veröffentlichtes Framework für Tests in Ruby. Ein Uphold-Test besteht also aus der Definition der Requirements der Ruby-Module (Minitest und MySQL) sowie aus dem eigentlichen Code, der am Ende einen Minitest-Test aufruft. Weil Minitest zum Einsatz kommt, mussten die Uphold-Entwickler kein eigenes System entwickeln, um über den Erfolg oder Misserfolg von Tests zu entscheiden, denn das ist bei Minitest bereits inkludiert. Letztlich fragt Uphold also nur die Ergebnisse der durchgeführten Minitests ab und entscheidet dann, ob es den Test insgesamt als erfolgreich oder fehlgeschlagen bezeichnet.

Weil Uphold-Tests normaler Ruby-Code sind, entpuppt sich die Dokumentation der Standard-Datenbank-Schnittstellen in Ruby als eine wichtige Quelle für Beispiele. Das MySQL-Tutorial für Ruby von Zetcode listet neben den wichtigsten Funktionen des "mysql"-Gems auch einige Beispiele auf [2], die sich als Basis für eigene Tests verwenden lassen.

Für alle Tests gilt, dass sie in "/etc/uphold/tests" liegen sollten, damit sie in die Definition eines Container-Verbundes eingebunden werden können.

Bild 4: Ein fertiges Yaml-File für den Test eines MySQL-Backups könnte so aussehen.

Das große Ganze: Die Definition eines Verbundes

Wenn Engine, Transport und Tests definiert sind und Uphold auch darüber hinaus grundlegend konfiguriert ist, fehlt noch ein Teil des Puzzles: Die Definition des Container-Verbundes, die diese drei Komponenten miteinander verbindet und Uphold dazu bringt, die Container zu starten, darin das Datenbank-Backup in eine frische Datenbank zu integrieren und schließlich die Tests zu starten. Die Dateien gehören nach "/etc/uphold/conf.d" und dürfen einen beliebigen Namen haben, die Dateiendung muss allerdings ".yml" sein – denn sonst findet Uphold die Dateien nicht. Die Backup-Definition liegt also auch im YAML-Format vor und kennt neben den schon erwähnten Schlüsselwörtern "engine", "transport" und "tests" noch "enabled" und "name". "enabled" akzeptiert die Werte "true" oder "false" und ermöglicht, speziell diesen Test zu aktivieren oder abzuschalten. Der Pa­rameter ist notwendig, weil Uphold grundsätzlich alle Dateien, die es mit entsprechenden Test-Definitionen findet, auswertet und umsetzt. Der Wert, den Uphold bei "enabled" annimmt, ist "true". Ist der Parameter also nicht vom Autor der Backup-Definition gesetzt, führt Uphold den Test automatisch aus.

"name" bietet dem Admin die Möglichkeit, dem Test einen beliebigen Namen zu geben; er sollte allerdings so gewählt sein, dass er einen Rückschluss auf den durchgeführten Test zulässt. "mysql-production" ist also aussagekräftiger als "test1".

Die zuvor festgelegten Definitionen für Engines, Transports und Tests lassen sich über die YAML-Notation "- Dateiname" einbinden. Heißt die Testdatei also "read-database.rb", käme hinter "tests:" eine neue Zeile mit dem Inhalt "read database", wobei dem "-" zwei Leerzeichen voranzustellen sind. Für die anderen Eigenschaften gilt dasselbe. Wer es lieber übersichtlich haben will, kann in der Backup-Definition aber auch die vollständigen Definitionen von Backup und Transports angeben (Bild 4). Lediglich die Tests lassen sich ausschließlich über Dateinamen referenzieren.

Bild 5: Uphold kommt auch mit einer eigenen API daher, über die sich Ergebnisse der Tests automatisch abfragen und die Tests selbst anstoßen lassen.

Ähnliche Artikel

comments powered by Disqus
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

Ausgabe /2023