Einheit 2.5: Bereitstellung von Datenbank- und Streaming-Diensten

Einführung

TaskBoard verfügt nun über Compute, Networking und Storage in Code. Die Anwendung benötigt weiterhin einen Ort, um den Zustand zu speichern. Aufgaben, Boards und Benutzer gehören in einen relationalen Speicher mit TLS und automatisierten Backups. Sitzungsdaten und heiße Lesezugriffe gehören in einen In-Memory-Cache. Ereignisdaten zu Aufgabenänderungen, die der Worker-Dienst verarbeitet, gehören in einen Stream.

Diese Einheit provisioniert alle drei Komponenten als Terraform-Ressourcen. Sie definieren den PostgreSQL-Cluster (transaktionaler Speicher) und die In-Memory DB Replica Set (Sitzungs- und Lese-Cache), von denen TaskBoard abhängt, und sehen anschließend das gleiche Provisionierungs-Muster für MongoDB, MariaDB und Kafka angewendet. Die strenge Regel, die durch alle Beispiele zieht: Die relationalen Engines (PostgreSQL, MariaDB) laufen als eine einzelne schreibbare Primärinstanz, ohne lesbare Replikate, um Lesezugriffe zu skalieren; nur MongoDB Enterprise kann lesbare Sekundärinstanzen hinzufügen. Sie provisionieren einen Cluster und skalieren Lesezugriffe über den Cache, nicht über die Datenbank. Jedes Beispiel kennzeichnet Zugangsdaten mit sensitive, damit Verbindungsinformationen niemals in der Plan-Ausgabe oder in CI-Protokollen landen.

1. Bereitstellung von PostgreSQL mit Terraform

PostgreSQL ist das zentrale System für die Datenspeicherung von TaskBoard. Die ionoscloud_pg_cluster-Ressource erstellt einen verwalteten Cluster: Sie geben die Engine-Version, die Anzahl der Instanzen, die Ressourcen-Größe, den Speicher, die LAN-Verbindung, das Wartungsfenster und die anfänglichen Zugangsdaten an. Die Bereitstellung erfolgt asynchron, und ein neuer Cluster kann 20 bis 30 Minuten benötigen, um den Status AVAILABLE zu erreichen, da die Plattform für jede angeforderte Instanz neue Knoten bereitstellt.

Der Cluster wird an ein privates LAN angeschlossen (die Datenbankebene aus Einheit 2.2), sodass er niemals direkt dem Internet ausgesetzt ist. Der Standardport ist 5432 und kann nicht konfiguriert werden.

1.1 Die pg_cluster-Ressource

Die unterstützten PostgreSQL-Versionen sind 14, 15 und 16. Die verfügbaren Speichertypen sind SSD Premium, SSD und HDD. Der connections-Block bindet den Cluster an ein bestehendes LAN und weist ihm eine CIDR innerhalb dieses LAN zu.

resource "ionoscloud_pg_cluster" "taskboard" {
  postgres_version = "16"
  instances        = 1
  cores            = 4
  ram              = 8192
  storage_size     = 50
  storage_type     = "SSD Premium"
  location         = ionoscloud_datacenter.taskboard.location
  display_name     = "taskboard-pg"

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.db.id
    cidr          = "10.20.30.4/24"
  }

  maintenance_window {
    day_of_the_week = "Sunday"
    time            = "03:00:00"
  }

  credentials {
    username = "taskboard_admin"
    password = var.pg_admin_password
  }

  synchronization_mode = "ASYNCHRONOUS"
}

Der Wert instances ist die Gesamtanzahl der Knoten, nicht die Anzahl der Replikate für Lesezugriffe. Der unterstützte Bereich liegt bei 1 bis 5 Instanzen pro Cluster. Zusätzliche Instanzen sind HA-Standbys, keine Endpunkte, von denen Ihre Anwendung liest. PostgreSQL unterstützt zwei Replikationsmodi: ASYNCHRONOUS (Standard) und STRICTLY_SYNCHRONOUS. Der strikt synchrone Modus erfordert mindestens 3 Instanzen. Für TaskBoard provisionieren Sie eine einzelne Primärinstanz (instances = 1) und skalieren Lesezugriffe mit In-Memory DB in Abschnitt 2.

1.2 Backups, Wartung und Versionsfixierung

Managed PostgreSQL verwaltet standardmäßig automatisierte Backups mit einer Aufbewahrungsdauer von 7 Tagen und unterstützt die Wiederherstellung zu einem bestimmten Zeitpunkt innerhalb dieses Zeitfensters. Bei der v2 API ist die Aufbewahrungsdauer jedoch bei der Erstellung oder Aktualisierung des Clusters über backup.retentionDays von 1 bis 365 Tage konfigurierbar. Beachten Sie, dass der allgemeine Backup Service verwaltete Datenbanken nicht sichert. Planen Sie daher nicht, ihn auf den Cluster zu zeigen. Die Wiederherstellung umfasst PITR sowie eigene geplante Dump-Dateien, die in Modul 4 behandelt werden.

Fixieren Sie postgres_version explizit, anstatt es schwimmen zu lassen. Major-Updates ändern das Verhalten und sind keine Änderung, die Sie durch einen Plan-Diff stillschweigend auslösen möchten.

variable "pg_admin_password" {
  type      = string
  sensitive = true
}

# Pass at apply time or via TF_VAR_pg_admin_password, never hardcode:
#   terraform apply -var="pg_admin_password=$(openssl rand -base64 24)"

maintenance_window steuert, wann die Plattform Patches anwendet. Jedes Zeitfenster dauert höchstens 4 Stunden. Wählen Sie einen Zeitraum mit geringem Datenverkehr, damit ein HA-Failover während des Patchings außerhalb der Spitzenzeiten stattfindet.

2. Bereitstellung von In-Memory DB für Caching

TaskBoard verwendet In-Memory DB für die Sitzungsspeicherung und zum Caching von Aufgabenlisten. Da PostgreSQL keine lesbaren Replikate besitzt, ist der Cache die Skalierungsschicht für Lesezugriffe und keine optionale Optimierung. Die Ressource ionoscloud_inmemorydb_replicaset provisioniert einen Redis-kompatiblen Replikatsatz. Die Engine ist Redis OSS stabile Version 7.2 und der Standardport ist 6379.

In-Memory DB stellt nun zwei API-Versionen bereit. Die v2-API (Version 2.0.0), deren primäre Ressource die Cluster ist, ist GA und die empfohlene API für den Produktivbetrieb. Die v1-API (Version 1.0.0), deren primäre Ressource die ReplicaSet ist, ist die Legacy-Implementierung und hat eine für eine kommende Version angekündigte Rückstellung; die Migration von v1 auf v2 wird vom Kunden initiiert, ist nicht automatisch, daher müssen bestehende v1-Cluster manuell auf die v2-Ressource Cluster migriert werden, bevor v1 entfernt wird. Die Terraform-Beispiele unten provisionieren den In-Memory DB Replikatsatz, und das von ihnen erzeugte Verbindungsmodell (Engine, Port, TLS, fester Verbindungshöchstwert) ist unabhängig davon gleich, welche API-Version die Ressource unterstützt. Für neue direkte API- oder SDK-Entwicklung sind die v2-Endpunkte Cluster zu verwenden.

Der Replikatsatz besteht aus einem aktiven Knoten und n-1 passiven Knoten. Passive Knoten bieten Failover, aber keine zusätzliche Lesebandbreite aus Sicht des Clients, da Clients über den aktiven Endpunkt verbinden.

2.1 Die inmemorydb_replicaset Ressource

Eine wichtige Einschränkung: Zugangsdaten werden nur bei der Erstellung festgelegt. Das Passwort kann nicht durch ein späteres Update geändert werden, daher einmal generieren und an einem Ort speichern, von dem Ihre Anwendung es lesen kann. Der Mindestspeicher beträgt 10 GB pro Knoten. Die Standard-Eviction-Richtlinie ist allkeys-lru. Der Persistenzmodus ist standardmäßig None; die API akzeptiert None, AOF, RDB und RDB_AOF.

resource "ionoscloud_inmemorydb_replicaset" "taskboard_cache" {
  display_name    = "taskboard-cache"
  location        = ionoscloud_datacenter.taskboard.location
  version         = "7.2"
  replicas        = 2
  persistence_mode = "RDB"
  eviction_policy  = "allkeys-lru"

  resources {
    cores = 2
    ram   = 4
  }

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.db.id
    cidr          = "10.20.30.5/24"
  }

  credentials {
    username = "default"
    plain_text_password = var.cache_password
  }

  maintenance_window {
    day_of_the_week = "Sunday"
    time            = "04:00:00"
  }
}

2.2 TLS für die Cache-Verbindung

Der Cache-Endpunkt unterstützt TLS, wird jedoch nur verschlüsselt, wenn Sie TLS bei der Erstellung der Instanz aktivieren. Standardmäßig ist diese Funktion nicht aktiviert. Nach der Aktivierung ist die Zertifizierungsstelle Let's Encrypt, sodass ein Standard-System-CA-Bundle die Verbindung validiert, ohne dass Sie eine benutzerdefinierte Stammzertifizierung bereitstellen müssen. Ihr Redis-Client verbindet sich mit aktiviertem TLS mit dem aktiven Endpunkt:

import redis

# host comes from the Terraform output (Section 4); password set at creation
r = redis.Redis(
    host=cache_host,
    port=6379,
    username="default",
    password=cache_password,
    ssl=True,
    ssl_cert_reqs="required",
)
r.set("session:abc123", "user-42", ex=3600)

Da das Passwort nicht an Ort und Stelle rotiert werden kann, ist eine Rotation als Ersetzung zu behandeln: eine neue Replikatsmenge bereitstellen, den Verkehr umleiten und anschließend die alte Replikatsmenge entfernen.

3. Bereitstellung von Kafka, MongoDB und MariaDB (gleiches Muster)

PostgreSQL und In-Memory DB decken die Anforderungen von TaskBoard ab, aber das Bereitstellungsmuster lässt sich verallgemeinern. Kafka, MongoDB und MariaDB folgen alle dem gleichen Aufbau: ein Cluster-Ressource, ein Verbindungsblock, der an ein LAN gebunden ist, ein Wartungsfenster und Zugangsdaten, alles asynchron. Nachfolgend sind die Ressourcennamen und die Unterschiede aufgeführt, die relevant werden, wenn Sie diese Dienste nutzen.

3.1 Kafka-Cluster und -Themen

Der Event-Stream von TaskBoard (Aufgabenänderungs-Events, die vom Worker verarbeitet werden) läuft auf Kafka. Die Bereitstellung umfasst zwei Ressourcen: den Cluster und eine Ressource pro Thema. Die unterstützte Kafka-Version ist 4.0.0. Die Versionen 3.9.0 und 3.9.1 sind veraltet; bestehende Cluster mit diesen Versionen laufen weiter, aber neue Cluster sollten Version 4.0.0 verwenden. Ein Cluster betreibt 3 Broker, und IONOS CLOUD empfiehlt (setzt jedoch nicht standardmäßig ein) einen Replikationsfaktor von 3 für Themen, was der 3-Broker-Struktur entspricht. Die Authentifizierung erfolgt über mTLS für die Daten-Ebene und ein Bearer-Token für die Management-API. Die Verschlüsselung während der Übertragung erfolgt über TLS.

resource "ionoscloud_kafka_cluster" "events" {
  name    = "taskboard-events"
  version = "4.0.0"
  size    = "S"
  location = ionoscloud_datacenter.taskboard.location

  connections {
    datacenter_id   = ionoscloud_datacenter.taskboard.id
    lan_id          = ionoscloud_lan.app.id
    broker_addresses = ["10.20.20.10/24", "10.20.20.11/24", "10.20.20.12/24"]
  }
}

resource "ionoscloud_kafka_cluster_topic" "task_changes" {
  cluster_id          = ionoscloud_kafka_cluster.events.id
  location            = ionoscloud_kafka_cluster.events.location
  name                = "task-changes"
  number_of_partitions = 6
  replication_factor   = 3
  retention_time       = 604800000
}

Die Partitionenanzahl ist die Obergrenze für die Parallelität der Consumer, daher sollte sie auf den erwarteten Consumer-Fan-out dimensioniert werden (Modul 4 behandelt das Skalieren von Consumern). Der Replikationsfaktor von 3 entspricht dem Broker-Layout mit 3 Brokern. Für mTLS ausgestellte Client-Zertifikate sind 365 Tage gültig, daher sollte die Rotation vor Ablauf der Gültigkeit geplant werden.

3.2 MongoDB und MariaDB

MongoDB verwendet ionoscloud_mongo_cluster. Unterstützte Versionen sind 6.0 und 7.0. Die Verbindungszeichenfolge folgt dem Format mongodb+srv://m-<id>.mongodb.<region>.ionos.com, sodass Ihr Treiber einen SRV-Eintrag erhält, anstatt einer einfachen Hostliste.

MariaDB verwendet ionoscloud_mariadb_cluster. Es werden ausschließlich LTS-Versionen unterstützt, beginnend mit 10.6 (zum Beispiel 10.6, 10.11), der Standardport ist 3306, und die Replikation erfolgt ausschließlich asynchron. Die Zertifizierungsstelle ist Let's Encrypt.

resource "ionoscloud_mariadb_cluster" "reporting" {
  mariadb_version = "10.11"
  instances       = 1
  cores           = 2
  ram             = 4
  storage_size    = 20
  display_name    = "taskboard-reporting"
  location        = ionoscloud_datacenter.taskboard.location

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.db.id
    cidr          = "10.20.30.6/24"
  }

  maintenance_window {
    day_of_the_week = "Sunday"
    time            = "05:00:00"
  }

  credentials {
    username = "reporting_admin"
    password = var.maria_password
  }
}

Die Entscheidungstabelle für die Auswahl der zu provisionierenden Engine:

Wählen Sie PostgreSQL oder MariaDB für relationale transaktionale Daten, MongoDB für Dokumentendaten, In-Memory DB für Caching und Kafka für Ereignisströme. Keine der relationalen Engines bietet lesbare Replikate, daher ist die Antwort auf das Skalieren von Lesezugriffen stets der Cache.

4. Verbindungsoutputs und die Single-Primary-Beschränkung

Provisionierung ist nur dann nützlich, wenn die Anwendung sich verbinden kann. Terraform kennt nach dem Apply den DNS-Namen des Clusters sowie die Zugangsdaten. Daher sollten diese als Outputs bereitgestellt werden, wobei jeder einzelne als sensitive markiert ist, damit sie nicht in der Plan-Ausgabe, in CI-Logs oder in terraform output ohne -raw erscheinen.

4.1 Sensible Outputs

Der PostgreSQL-Cluster stellt einen stabilen DNS-Hostnamen bereit, beispielsweise pg-010203.postgresql.de-fra.ionos.com, den Ihre Anwendung anstelle einer IP verwendet. Erstellen Sie die Verbindungszeichenfolge aus dem DNS-Namen des Clusters sowie den von Ihnen bereitgestellten Zugangsdaten.

output "pg_connection_string" {
  value     = "postgresql://${ionoscloud_pg_cluster.taskboard.credentials[0].username}@${ionoscloud_pg_cluster.taskboard.dns_name}:5432/postgres?sslmode=require"
  sensitive = true
}

output "cache_host" {
  value     = ionoscloud_inmemorydb_replicaset.taskboard_cache.dns_name
  sensitive = true
}

output "kafka_broker_addresses" {
  value     = ionoscloud_kafka_cluster.events.connections[0].broker_addresses
  sensitive = true
}

Der Standard-SSL-Modus für PostgreSQL ist prefer und kann vom Client nicht deaktiviert werden. Daher muss auf der Anwendungseite immer sslmode=require (oder strenger) gesetzt werden. Das TLS-Wurzelzertifikat für PostgreSQL ist ISRG Root X1, das in jedem modernen System-CA-Bundle enthalten ist.

4.2 Warum es keine Lese-Replikate gibt, auf die verwiesen werden kann

Dies ist die Einschränkung, die naive Skalierungspläne zunichte macht. Es gibt keine read_endpoint-Ausgabe, die erstellt werden kann, da es keine Lese-Replikate gibt. Der Replikatsatz von In-Memory DB besteht aus einem aktiven und n-1 passiven Knoten, wobei die passiven Knoten Übernahmemodule sind, keine Lese-Endpunkte. PostgreSQL instances > 1 bietet HA-Standbys, keine Abfrageziele.

# WRONG: there is no separate read endpoint to expose
# output "pg_read_endpoint" { value = ... }  # does not exist

# RIGHT: reads scale through the cache, writes go to the single primary
output "pg_primary_dns" {
  value     = ionoscloud_pg_cluster.taskboard.dns_name
  sensitive = true
}

Verdrahten Sie die Anwendung so, dass jede Schreib- und jede konsistente Leseoperation an die Primärinstanz gerichtet wird und jede heiße Leseoperation über In-Memory DB mit einem Cache-aside-Muster abgewickelt wird. Diese Integration ist Gegenstand von Modul 4, aber die Bereitstellungsentscheidung wird hier getroffen: eine Primärinstanz, ein Cache.

API-Referenz Schnellkarte

Wichtige API-Endpunkte für die Bereitstellung von Datenbanken und Streaming:

Basis-URL (Cloud DBaaS): https://api.ionos.com/databases/postgresql In-Memory DB / Kafka: regionsspezifische Hosts (zum Beispiel https://in-memory-db.de-fra.ionos.com) Authentifizierung: Authorization: Bearer <token> für Verwaltungs-APIs; mTLS für die Kafka-Datenebene

Code Lab

Ziel: Deployment der Datenbankebene von TaskBoard mit Terraform: ein PostgreSQL-Cluster mit einer einzelnen Primärinstanz und ein Replikat-Set für In-Memory DB, anschließend Ausgabe ihrer Verbindungsdaten als sensible Werte.

Voraussetzungen:

• IONOS CLOUD Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform >= 1.5 mit dem ionoscloud Provider
• Ein vorhandenes Datacenter und ein Datenbank-LAN aus den Einheiten 2.1 und 2.2

Schritt 1: Sensible Variablen deklarieren

variable "pg_admin_password" {
  type      = string
  sensitive = true
}
variable "cache_password" {
  type      = string
  sensitive = true
}

Schritt 2: PostgreSQL-Cluster hinzufügen (aus Abschnitt 1.1), dann Validierung durchführen:

terraform validate

Erwartete Ausgabe:

Success! The configuration is valid.

Schritt 3: Den In-Memory DB-Replikat-Satz hinzufügen (aus Abschnitt 2.1) sowie die sensiblen Ausgaben (aus Abschnitt 4.1). Anschließend den Plan erstellen:

terraform plan \
  -var="pg_admin_password=$(openssl rand -base64 24)" \
  -var="cache_password=$(openssl rand -base64 24)"

Erwartete Ausgabe:

Plan: 2 to add, 0 to change, 0 to destroy.
Changes to Outputs:
  + cache_host           = (sensitive value)
  + pg_connection_string = (sensitive value)

Schritt 4: Anwenden (Die Bereitstellung ist asynchron und kann 20 bis 30 Minuten für PostgreSQL dauern):

terraform apply -auto-approve \
  -var="pg_admin_password=$PG_PW" \
  -var="cache_password=$CACHE_PW"

Erwartete Ausgabe:

ionoscloud_pg_cluster.taskboard: Creation complete after 24m12s
ionoscloud_inmemorydb_replicaset.taskboard_cache: Creation complete after 6m41s
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Schritt 5: Die sensible Verbindungszeichenfolge lesen (Hinweis: -raw, erforderlich, da sie sensibel ist):

terraform output -raw pg_connection_string

Erwartete Ausgabe:

postgresql://taskboard_admin@pg-010203.postgresql.de-fra.ionos.com:5432/postgres?sslmode=require

Schritt 6: Verifizieren Sie die PostgreSQL-Verbindung über TLS von einem Host im Datenbank-LAN:

psql "$(terraform output -raw pg_connection_string)" -c "SELECT version();"

Erwartete Ausgabe:

PostgreSQL 16.x ...

Schritt 7: Cache überprüfen mit einem schnellen Set/Get über TLS:

redis-cli -h "$(terraform output -raw cache_host)" -p 6379 \
  --tls --user default -a "$CACHE_PW" PING

Erwartete Ausgabe:

PONG

Prüfliste:

• [ ] Der PostgreSQL-Cluster hat AVAILABLE erreicht und akzeptiert eine TLS-Verbindung
• [ ] Der Replikatsatz der In-Memory DB antwortet auf PING über TLS
• [ ] Alle Verbindungsoutputs sind als sensibel markiert und erfordern -raw zum Lesen
• [ ] Kein Passwort erscheint in der Plan-Ausgabe oder in den Apply-Protokollen

Aufräumen:

terraform destroy -auto-approve \
  -var="pg_admin_password=$PG_PW" \
  -var="cache_password=$CACHE_PW"

Häufige Fehler

1. Behandlung von Cluster-Instanzen als Lese-Replikate

   • Problem: Sie setzen instances = 3 auf dem PostgreSQL-Cluster und versuchen, Leseabfragen an einen zweiten Knoten zu senden, um den primären Knoten zu entlasten. Alle Verbindungen landen jedoch weiterhin am selben schreibbaren Endpunkt, und Sie erreichen keine Skalierung der Lesezugriffe.
   • Ursache: Von IONOS CLOUD verwaltete Datenbanken betreiben einen einzelnen schreibbaren primären Knoten. Zusätzliche Instanzen sind HA-Standbys, keine lesbaren Replikate, und es gibt keinen separaten Lese-Endpunkt.
   • Lösung: Bereitstellen Sie einen primären Knoten und leiten Sie häufige Lesezugriffe über In-Memory DB:

   resource "ionoscloud_pg_cluster" "taskboard" {
     instances = 1   # single primary; cache handles read scaling
   }
   

2. Leckende Zugangsdaten über Terraform-Ausgaben

   • Problem: Ihre CI-Protokolle geben das Datenbankpasswort aus, da eine Ausgabe nicht als sensibel markiert wurde und terraform apply sie in der Ausführung wiedergibt.
   • Warum es passiert: Ausgaben sind standardmäßig sichtbar. Jede Verbindungszeichenfolge, die aus Zugangsdaten erstellt wird, ist Klartext, sofern sie nicht als sensibel markiert ist.
   • Lösung: Markieren Sie jede Ausgabe, die Zugangsdaten enthält, als sensitive = true und lesen Sie sie nur bei Bedarf mit -raw.

   output "pg_connection_string" {
     value     = local.pg_conn
     sensitive = true
   }
   

3. Versuch, das In-Memory DB-Passwort später zu ändern

   • Problem: Sie führen ein Update aus, um das Cache-Passwort zu rotieren, und der Apply-Vorgang schlägt fehl oder die Änderung wird ignoriert.
   • Ursache: Die Zugangsdaten für In-Memory DB werden nur bei der Erstellung festgelegt und können danach nicht geändert werden.
   • Lösung: Behandeln Sie die Rotation als Ersetzung. Erstellen Sie einen neuen Replikat-Satz, migrieren Sie den Datenverkehr und zerstören Sie anschließend den alten Satz. Erzeugen Sie das Passwort einmalig bei der Erstellung:

   credentials {
     username            = "default"
     plain_text_password = var.cache_password  # set once, immutable
   }
   

Zusammenfassung

Sie können nun die gesamte Datenschicht von TaskBoard als Code bereitstellen: einen PostgreSQL-Cluster mit einer einzelnen Primärinstanz für Transaktionen, eine Replikatsammlung der In-Memory DB für Sitzungen und Lese-Caching sowie (unter Verwendung desselben Ressourcenmusters) Kafka, MongoDB oder MariaDB, wenn eine Workload sie benötigt. Sie wissen, wie Sie jeden Cluster einem privaten LAN zuweisen, ein Wartungsfenster festlegen, Anmeldedaten sicher bereitstellen und Verbindungsdetails als sensible Terraform-Ausgaben bereitstellen. Am wichtigsten ist, dass Sie um das Single-Primary-Modell herum bereitstellen: ein schreibbarer Cluster, wobei die Skalierung der Lesezugriffe über den Cache erfolgt; die relationalen Engines bieten keine Lese-Replikate (MongoDB Enterprise kann dies, aber die Datenschicht von TaskBoard ist relational).

Wichtige Punkte:

• ionoscloud_pg_cluster stellt PostgreSQL (Versionen 14, 15, 16; Port 5432) bereit; instances sind HA-Knoten, keine Lese-Replikate, und der Bereich liegt zwischen 1 und 5
• ionoscloud_inmemorydb_replicaset stellt Redis 7.2 auf Port 6379 bereit; die Anmeldedaten werden nur bei der Erstellung festgelegt und können nicht vor Ort geändert werden
• ionoscloud_kafka_cluster plus ionoscloud_kafka_cluster_topic stellen Kafka 4.0.0 mit 3 Brokern und Replikationsfaktor 3 bereit; die Datenebene authentifiziert sich mit mTLS
• Jede Verbindungs-Ausgabe muss als sensitive markiert werden; der Standard-SSL-Modus von PostgreSQL ist prefer und kann nicht deaktiviert werden, daher setzt die Anwendung sslmode=require
• Die relationalen Engines (PostgreSQL, MariaDB) stellen keine lesbaren Lese-Replikate bereit; MongoDB Enterprise unterstützt bis zu fünf lesbare Sekundärinstanzen. Für die relationale Datenschicht von TaskBoard stellen Sie eine einzelne Primärinstanz bereit und skalieren Lesezugriffe über die In-Memory DB

Wichtige Begriffe:

• Single-Primary-Modell: Die Bereitstellungsbeschränkung, wonach die relationalen Engines einen schreibbaren Cluster ohne lesbare Replikate betreiben; Lesezugriffe skalieren auf der Cache-Ebene. (MongoDB Enterprise ist die Ausnahme: Es kann bis zu fünf lesbare Sekundärinstanzen hinzufügen.)
• Replikatsammlung (In-Memory DB): Ein aktiver Knoten plus n-1 passive Failover-Knoten; Clients verbinden sich über den aktiven Endpunkt.
• Wartungsfenster: Ein konfigurierbarer wöchentlicher Zeitrahmen (bis zu 4 Stunden), in dem die Plattform Patches anwendet und HA-Failover auslösen kann.
• Sensible Ausgabe: Eine Terraform-Ausgabe, die als sensitive = true markiert ist, sodass sie in Plan-, Apply- und CI-Protokollen verborgen wird und -raw zum Lesen erfordert.
• Replikationsfaktor (Kafka): Die Anzahl der Broker-Kopien jeder Partition; Standardwert ist 3, passend zum 3-Broker-Cluster.

Nächste Schritte

Weiter lernen: Einheit 2.6: Wissensprüfung - Infrastructure as Code

Verwandte Themen:

• Einheit 2.4: Storage Provisioning as Code
• Einheit 4.1: Datenbank- und Caching-Integration