Verwendung von Terraform für die Datenbankverwaltung

Einer der wichtigsten Schritte, die wir hier bei Vonage unternehmen, ist die Umwandlung in eine agile Entwicklungsorganisation, die die Prinzipien des Site Reliability Engineering (SRE) anwendet. Und das bedeutet, dass wir fast allergisch sind auf schuften.

Mühsal ist die Art von Arbeit, die in der Regel manuell, repetitiv, automatisierbar, taktisch und ohne bleibenden Wert ist und linear mit dem Wachstum einer Dienstleistung wächst.

Wir sind ständig auf der Suche nach Möglichkeiten, regelmäßige Arbeitsabläufe durch Automatisierung prozessorientierter zu gestalten.

Problem

Eine solche Klasse von Tätigkeiten, mit denen wir regelmäßig zu tun haben, sind Datenbankänderungen - Schemaänderungen, Ad-hoc-Änderungen von Datensätzen zur Behebung von Problemen, Verwaltung von Zuschüssen usw. In einer Welt ohne Automatisierung waren SREs die Gatekeeper, die diese Änderungen für verschiedene Ingenieurteams direkt an den Datenbanken vornahmen. Diese Situation warf zwei Probleme auf: Die SREs wurden zum Flaschenhals, der es den Teams nicht erlaubte, schnell genug zu arbeiten, und es gab kaum ein Audit-Protokoll über die tatsächlichen Abfragen in der Datenbank.

Um diese Probleme zu lösen, mussten wir eine Automatisierung entwickeln, die Folgendes ermöglicht

• Ingenieuren die Möglichkeit, SQL zu spezifizieren und auszuführen, das sie in Datenbanken ausführen wollten (was wir als Pushpläne bezeichnen)

• Überprüfungen der eingereichten Push-Pläne durchführen, die verhindern, dass unsichere/schädliche Änderungen durchgeführt werden

• einen Audit-Pfad über die Vorgänge in einer kanonischen Quelle der Wahrheit, vorzugsweise einem Versionskontrollsystem (VCS), zu führen

Näherung

Terraform war für uns eine ausgezeichnete Wahl, da wir es bereits in großem Umfang zur Verwaltung unserer Cloud-Infrastruktur einsetzten. Einer der oft übersehenen Aspekte von Terraform ist, dass es den Zustand hervorragend verwaltet. Mit dieser Funktionalität wollten wir es den Ingenieuren ermöglichen, die gewünschten Änderungen auf eine deklarative, idempotente Weise zu spezifizieren und die Automatisierung die schwere Arbeit erledigen zu lassen.

Ein weiteres Problem war der Zugang zu den Daten. Aus Compliance-Gründen sind die Techniker bei Vonage nicht im Besitz von Datenbankanmeldeinformationen. Wir speichern alle unsere Anmeldeinformationen verschlüsselt mit AWS SecretsManager. Obwohl unsere Techniker also keinen Zugriff auf diese Daten hatten, konnte unsere Automatisierung auf die Anmeldedaten zugreifen.

Schließlich brauchten wir einen Runner, der die von den Ingenieuren spezifizierten Push-Pläne sicher ausführt. Für die eigentlichen Prüfungen und die Ausführung der Push-Pläne haben wir uns für Python entschieden, das bei vielen unserer Tools weit verbreitet ist. Das gesamte Paket wurde auf Jenkins ausgeführt, was es uns ermöglichte, den Zugang zu Datenbankänderungen für die gesamte technische Organisation zu demokratisieren.

Code

SQL-Pushpläne

Für die eigentlichen SQL-Pushpläne haben wir uns für das gute alte YAML entschieden. Wenn jemand eine Änderung in der DB vornehmen möchte, gibt er einfach den Namen des Datenbank-Clusters und die eigentliche SQL an, die er ausführen möchte, etwa so:

---
cluster: dblocal_wdc4
sql: |
    USE config;
    ALTER TABLE mt_routing ADD COLUMN routeToRoutingGroupId VARCHAR(50) NULL DEFAULT NULL AFTER routeToTargetGroupId;

Wir haben Terraforms local-exec Funktion von Terraform, um ein Python-Skript auszuführen, das die Änderungen an der Datenbank vornehmen würde:

resource "null_resource" "db_pushplan" {
  # This will rerun the pushplan if the file contents have been changed
  triggers = {
    hash = filebase64(var.pushplan_file)
  }

  provisioner "local-exec" {
    command = "pipenv run python ${path.module}/pushplan_executor.py -d ${var.db_host} -p ${var.db_port} -f ${var.pushplan_file}"

    environment = {
      db_username = var.db_username
      db_password = var.db_password
    }
  }
}

Anmerkung: Es ist wichtig, die Anmeldeinformationen als Umgebungsvariablen an das Skript zu übergeben, um zu vermeiden, dass sie in den Protokollen oder der Bash-History auftauchen.

Python

Das Python-Skript, das wir zur Ausführung des eigentlichen Pushplans verwendet haben, tut mehr als nur die Ausführung. Zunächst führt es eine Reihe von Prüfungen durch:

• Stellt sicher, dass der im Pushplan angegebene Cluster gültig ist

• Die Verwendung des Python sqlparse Bibliothek wird geprüft, ob das angegebene SQL gültig ist.

• Enthält die SQL-Datei unzulässige Aktionen - SELECT, GRANT, SHOW - schlägt sie fehl und informiert die Benutzer schnell über den Grund/die Gründe.

• Führt die eigentlichen SQL-Anweisungen sicher aus:

  • Bei mehreren Aktualisierungen wird zwischen aufeinanderfolgenden Anweisungen eine Pause eingelegt, um die Datenbank nicht zu überlasten.

  • Wenn es ALTERs gibt, verwendet es gh-ost um die Änderungen sicher durchzuführen.

Schlussfolgerung

Es gibt noch einige Verbesserungen, die wir gerne in dieses Tool einbauen würden. Wie zum Beispiel

• Verwendung von Terraforms MySQL-Anbieter für die Verwaltung von Berechtigungen. Dieser Provider ermöglicht es Ingenieuren, verschiedene Datenbankbenutzer für verschiedene Applikationen schneller zu erstellen und zu verwenden.

• Einbindung von Flugroute in das Tool, um sicherzustellen, dass dieses auch als kanonische Quelle der Wahrheit für alle unsere Schemata dient.

• Bauen Sie einen Beförderungsmechanismus ein, der es den Ingenieuren ermöglicht, Änderungen zuerst in der Nicht-Produktionsumgebung zu testen. Wenn sie erfolgreich laufen, können die Ingenieure diese Änderungen nach Prod befördern.

Und es wird noch viele weitere geben. Allerdings haben wir jetzt eine gute Grundlage, um diese Automatisierung mit dem Basismechanismus auf alle anderen Aspekte der Datenbankverwaltung auszuweiten.