AZURE POSTGRESQL → STACKIT POSTGRESQL FLEX · TUTORIAL
Azure PostgreSQL flexible server zu STACKIT PostgreSQL Flex
Ein Flexible Server wird zu einer STACKIT-PostgreSQL-Flex-Instanz. StackToIT schreibt die Instanz mit Flavor, Speicher, täglichem Backup, Aufbewahrung und einer Zugriffsliste aus Ihren Firewall-Regeln. Was StackToIT nicht übernimmt, benennt es: Administrator-Login, Datenbank, Zonen und, im Architekturbericht, die Server-Parameter. Diese Anleitung führt eine Demo-Umgebung von der Eingabe bis zum Restore.
Vom Azure-Server zur STACKIT-Instanz
Eine für diese Seite geschriebene Demo-Umgebung, am 4. November 2026 mit StackToIT bewertet: General-Purpose-Server, Version 15, zonenredundante Hochverfügbarkeit, nur privater Zugriff. Links zwei Blöcke der Eingabe (Datenbank- und Parameter-Block sind hier weggelassen), rechts der Ressourcenblock des STACKIT-Terraforms, das die Engine geschrieben hat; die Prüfkommentare über dem Block in der Datei sind hier weggelassen. Die Eingabeblöcke stehen in main.tf nicht direkt hintereinander; jeder steht deshalb wörtlich in einem eigenen Ausschnitt.
resource "azurerm_postgresql_flexible_server" "billing" {
name = "psql-billing-gwc"
resource_group_name = azurerm_resource_group.data.name
location = azurerm_resource_group.data.location
version = "15"
sku_name = "GP_Standard_D4s_v3"
storage_mb = 131072
administrator_login = "billingadmin"
administrator_password = var.pg_admin_password
backup_retention_days = 14
geo_redundant_backup_enabled = false
public_network_access_enabled = false
zone = "1"
high_availability {
mode = "ZoneRedundant"
standby_availability_zone = "2"
}
}resource "azurerm_postgresql_flexible_server_firewall_rule" "office" {
name = "office"
server_id = azurerm_postgresql_flexible_server.billing.id
start_ip_address = "203.0.113.10"
end_ip_address = "203.0.113.20"
}resource "stackit_postgresflex_instance" "billing" {
project_id = var.project_id
name = "psql-billing-gwc"
version = "15"
flavor_id = "4.32-replica"
storage = {
class = var.postgresflex_storage_class
size = 128
}
backup_schedule = "0 2 * * *"
network = {
acl = var.billing_allowed_cidrs
}
retention_days = 32
}Das Flavor deckt die Quellgröße ab
Die Quell-SKU GP_Standard_D4s_v3 hat 4 vCPU und 16 GiB. Der Lauf wählt 4.32-replica, das kleinste hochverfügbare Flavor im eu01-Katalog, das sie abdeckt: 4 vCPU und 32 GiB. Hochverfügbarkeit wird zu einem Replica-Flavor, das der Lauf als drei sich spiegelnde Knoten beschreibt. Wo jeder Knoten läuft und wie ein Failover abläuft, behauptet er nicht.
Backups auf STACKIT-Skala
Azure hält 14 Tage vor; der Provider akzeptiert 32 bis 90, also wird retention_days zu 32. Als Zeitplan setzt der Lauf täglich 02:00 als Vorgabe, und STACKIT dokumentiert ausschließlich tägliche Backups. Eine Point-in-Time-Wiederherstellung legt bei PostgreSQL Flex eine neue, geklonte Instanz an.
Version und Speicher werden übernommen
Laut Lauf gehört Version 15 zu den Versionen, die PostgreSQL Flex anbietet (14 bis 18). Aus 131072 MB Speicher wird size 128; die Speicherklasse ist eine Variable ohne Default, die Sie festlegen.
Firewall-Regeln werden zur ACL
Der Bereich 203.0.113.10 bis 203.0.113.20 wird in vier CIDRs im Default der ACL-Variable umgerechnet. Die Liste bestätigen Sie.
Was der Entwurf als nicht übernommen ausweist
Zeilen aus den Kommentaren in terraform/data.tf, unverändert. Sie sind die Arbeit, die nach dem Anlegen der Instanz bleibt.
# NOT CARRIED (azurerm_postgresql_flexible_server.billing): administrator_login = billingadmin, administrator_password — the administrator login is not generated: create the users with stackit_postgresflex_user (pinned provider).
# NOT CARRIED (azurerm_postgresql_flexible_server.billing): public_network_access_enabled = false — the public-network access switch has no counterpart: clients reach the STACKIT instance through its ACL (network.acl) either way.
# NOT CARRIED (azurerm_postgresql_flexible_server.billing): zone = 1, high_availability.standby_availability_zone = 2 — the availability zone and the high-availability standby zone are not generated (pinned provider).
# NOT CARRIED (azurerm_postgresql_flexible_server_database.invoices): name = invoices, charset = UTF8, collation = en_US.utf8 — create the database with stackit_postgresflex_database (pinned provider) and restore its data.
# LEDGER backup retention: 14 days → retention_days = 32 — TRANSFORMED
# LEDGER network exposure: private → instance endpoint restricted by ACL — REVIEW
# LEDGER high availability: standby / multi-node → flavor_id = "4.32-replica" (a replica flavor: three nodes that mirror each other; no STACKIT page states the zone of each node or how a failover works, so a zone failure or an automatic takeover is not claimed) — TRANSFORMEDvariable "billing_allowed_cidrs" {
type = list(string)
description = "CIDRs allowed to reach azurerm_postgresql_flexible_server.billing. Default: the address ranges of the source server's firewall rules, as CIDRs."
default = ["203.0.113.10/31", "203.0.113.12/30", "203.0.113.16/30", "203.0.113.20/32"]
}Benutzer und Datenbanken deklarieren Sie
Weder der Administrator-Login noch die Datenbank werden erzeugt. Die Kommentare nennen stackit_postgresflex_user und stackit_postgresflex_database als die zu verwendenden Ressourcen.
Aus privat wird ACL-beschränkt
Eine STACKIT-Instanz hat einen eigenen Hostnamen und eine eigene IPv4-Adresse und ist standardmäßig aus vordefinierten STACKIT-Adressbereichen erreichbar; die ACL ergänzt Ihre Bereiche. Ein privater Scope existiert als Opt-in für freigeschaltete Konten und kann sich noch ändern. Die Erreichbarkeit eines privaten Azure-Servers ändert sich daher, sofern Sie diesen Scope nicht erhalten.
Server-Parameter brauchen einen manuellen Blick
Die Demo-Umgebung setzt log_min_duration_statement auf 500. Der Entwurf enthält dafür keine Zeile; der Parameter steht nur im Architekturbericht als offene kritische Einstellung. Listen Sie Ihre Server-Parameter daher auf und prüfen Sie jeden von Hand.
Wie die Einstellungen in diesem Lauf abgebildet werden
| Azure-Einstellung | STACKIT-Entwurf | Wer handelt |
|---|---|---|
| version = 15 | version = 15 | Engine-Version gegen den Katalog bestätigen |
| sku_name GP_Standard_D4s_v3 | flavor_id 4.32-replica | Data Architect bestätigt Größe und Knotenzahl |
| storage_mb 131072 | storage size 128, Klasse aus Variable | Speicherklasse wählen |
| backup_retention_days 14 | retention_days 32, Zeitplan 0 2 * * * | Neue Aufbewahrung akzeptieren |
| geo_redundant_backup_enabled false | Nicht erzeugt; offene Einstellung | Data Architect bestätigt, dass der Backup-Ort passt |
| public_network_access_enabled false | network.acl aus der Variable | Network Architect entscheidet über den Scope |
| Firewall-Regel office | Vier CIDRs im ACL-Default | Bereiche bestätigen |
| administrator_login, Datenbank invoices | Nicht erzeugt | Benutzer und Datenbank deklarieren |
Klassen so, wie der Lauf sie entschieden hat: REPLATFORM mit Konfidenz MEDIUM für den Server. Datenbank, Regel und Parameter gehören zur Server-Einheit.
Die Schritte in der Reihenfolge
Terraform bewerten
Führen Sie stacktoit assess für den Ordner mit dem azurerm-Code aus und lesen Sie die offenen Anfragen, die der Lauf auflistet. Die Demo-Umgebung hat eine Variable ohne Wert, das Administrator-Passwort; der Lauf meldet sie und hält fest, dass sie nichts aufhält.
Die vier Pakete abarbeiten
Der Lauf gruppiert die offenen Einstellungen in vier Arbeitspakete mit je einem Verantwortlichen: Data, Identity, Network und Platform Architect. Sie enthalten den Backup-Ort, den Resource-Group-Scope und den Administrator-Login, die Exposition und die Firewall-Bereiche sowie Standby-Zone und Namen.
Benutzer und Datenbank ergänzen
Deklarieren Sie Benutzer und Datenbank wie im nächsten Abschnitt beschrieben, mit einem deklarierten Benutzer als Owner. Das Passwort jedes Benutzers erzeugt der Provider und markiert es als sensibel.
Dump und Restore
Azure dokumentiert dafür pg_dump und pg_restore, mit dem Verzeichnisformat für parallele Arbeit. pg_dump verarbeitet eine Datenbank pro Aufruf und sichert keine Rollen. Legen Sie die Rollen als Benutzer auf der neuen Instanz an, statt einen Rollen-Dump einzuspielen, und prüfen Sie danach die Berechtigungen.
Clients auf den neuen Host umstellen
Verbindungs-Strings nutzen den Hostnamen der Instanz und Port 5432; bei einem Timeout empfiehlt STACKIT, die ACL zu prüfen. Der Lauf ergänzt, dass PostgreSQL Flex Verbindungen immer mit TLS 1.3 verschlüsselt: Clients müssen TLS 1.3 beherrschen und dem neuen Serverzertifikat vertrauen.
Benutzer, Datenbank und der Umzug von Hand
Zuerst die Benutzer
Deklarieren Sie je Anwendungs-Login einen stackit_postgresflex_user mit project_id, instance_id, username und roles; das Beispiel des Providers nutzt die Rolle login. Das Passwort ist ein schreibgeschütztes, sensibles Attribut, das der Provider befüllt, und landet daher im State.
Dann die Datenbank
stackit_postgresflex_database erwartet einen Namen und einen Owner, also den username eines deklarierten Benutzers. In der Demo-Umgebung ist das die Datenbank invoices mit dem Anwendungsbenutzer als Owner.
Dump im Verzeichnisformat
Azure dokumentiert für größere Datenbanken pg_dump -Fd -j mit einer Anzahl Kerne und pg_restore -Fd -j -d in die Zieldatenbank; Fehler gehen nach errors.log und werden danach geprüft. Diese Schritte führen Sie selbst aus; StackToIT führt keinen der beiden Befehle aus.
Client-Versionen zählen
Laut Azure müssen die Werkzeuge dieselbe oder eine neuere Major-Version haben als die Server, aus denen exportiert und in die importiert wird. Mit Version 15 auf beiden Seiten taugen Werkzeuge ab Version 15.
Rollen ohne Passwörter
Auf einem Flexible Server braucht pg_dumpall -r die Option --no-role-passwords, weil die Rollen-Passwörter dort nicht lesbar sind. Ein Rollen-Dump enthält also keine Passwörter; die STACKIT-Benutzer erhalten die Passwörter, die der Provider erzeugt.
Restores erzeugen eine neue Instanz
STACKIT stellt ein Backup oder einen Zeitpunkt wieder her, indem es ihn in eine neue Instanz im selben Projekt klont. Rechnen Sie damit, dass sich nach einem Restore der Hostname für die Clients ändert.
Fragen von Datenbank-Teams
Wird das georedundante Backup übernommen?
Der Entwurf setzt keinen Backup-Ort, und der Provider hat dafür kein Attribut. Der Lauf lässt die Einstellung offen und bittet eine Person zu bestätigen, dass die STACKIT-Backups, die in der Region bleiben, genügen.
Kann ich einen Dump mit Rollen aus Azure einspielen?
Azure beschreibt, Rollen auf Flexible Servern mit pg_dumpall und der Option --no-role-passwords zu sichern. Auf STACKIT legen Sie Benutzer mit der Provider-Ressource an und setzen Berechtigungen selbst; gehen Sie nicht davon aus, dass ein eingespielter Rollen-Dump funktioniert.
Wie viel Downtime brauchen Dump und Restore?
Das hängt von Datenmenge und Änderungsrate ab, die die Quelle nicht nennt. Der Lauf sagt das in seinen Hinweisen zum Datenumzug, nennt nur die bereitgestellten 131072 MB, die nicht der Datenmenge entsprechen, und überlässt die Methode Ihnen.
Ist die Instanz wie der private Azure-Server erreichbar?
Nicht standardmäßig. Sie ist aus den Bereichen der ACL und aus vordefinierten STACKIT-Bereichen erreichbar. Legen Sie die ACL fest und klären Sie, ob Sie den privaten Scope brauchen, bevor Sie etwas anwenden.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.