Einheit 2.5: Bereitstellung von Datenbank- und Streamingdiensten

Einführung

TaskBoard verfügt nun über Compute-, Networking- und Storage-Funktionen in Code. Die Anwendung benötigt jedoch immer noch einen Ort, um den Zustand zu speichern. Aufgaben, Boards und Benutzer gehören in einem relationalen Speicher mit TLS und automatisierten Backups. Sitzungsdaten und heiße Lese-Pfade gehören in einem In-Memory-Cache. Task-Änderungsereignisse, die der Worker-Service verbraucht, gehören in einen Stream.

Diese Einheit bereitstellt alle drei als Terraform-Ressourcen. Sie definieren die PostgreSQL-Cluster-Transaktions-speicher und die In-Memory DB-Replikatsatz (Sitzungs- und Lese-Cache), auf den TaskBoard angewiesen ist, und sehen dann das gleiche Bereitstellungs-Muster auf MongoDB, MariaDB und Kafka angewendet. Die harte Regel, die durch jedes Beispiel verläuft: IONOS-gemanagte Datenbanken laufen als einzelne schreibbare Primärdatenbank. Es gibt keine lesbaren Replikate, um Lesevorgänge zu skalieren. Sie bereitstellen eine Cluster und skalieren Lesevorgänge mit dem Cache, nicht mit der Datenbank. Jedes Beispiel markiert Anmeldedaten sensitive, sodass Verbindungsmaterialien niemals in Plan-Ausgaben oder CI-Logs landen.

1. Bereitstellung von PostgreSQL mit Terraform

PostgreSQL ist TaskBoards System der Aufzeichnungen. Die ionoscloud_pg_cluster-Ressource erstellt eine gemanagte Cluster: Sie geben die Motorversion, die Anzahl der Instanzen, die Ressourcengröße, den Speicher, die LAN-Verbindung, das Wartungsfenster und die anfänglichen Anmeldedaten an. Die Bereitstellung ist asynchron, und eine neue Cluster kann 20 bis 30 Minuten benötigen, um den Zustand AVAILABLE zu erreichen, da die Plattform für jede angeforderte Instanz frische Knoten bereitstellt.

Die Cluster bindet an ein privates LAN (die Datenbank-Ebene aus Einheit 2.2), sodass sie nie direkt mit dem Internet verbunden ist. Der Standardport ist 5432 und kann nicht konfiguriert werden.

1.1 Die pg_cluster-Ressource

Unterstützte PostgreSQL-Versionen sind 14, 15 und 16. Speichertypen sind SSD Premium, SSD und HDD. Der connections-Block bindet die Cluster an eine bestehende LAN und weist ihr eine CIDR innerhalb dieser 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 instances-Wert ist die Gesamtzahl der Node-Instanzen, nicht die Anzahl der Lese-Replikate. Der unterstützte Bereich beträgt 1 bis 5 Instanzen pro Cluster. Zusätzliche Instanzen sind Hochverfügbarkeits-Standbys und keine Endpunkte, von denen Ihre Anwendung liest. PostgreSQL unterstützt zwei Replikationsmodi: ASYNCHRONOUS (Standard) und STRICTLY_SYNCHRONOUS. Der streng synchrone Modus erfordert mindestens 3 Instanzen. Für TaskBoard bereitstellen Sie eine einzelne primäre Instanz (instances = 1) und skalieren Sie die Lesevorgänge mit In-Memory DB in Abschnitt 2.

1.2 Sicherungen, Wartung und Versionssperre

Managed PostgreSQL führt automatisierte Sicherungen mit einer Aufbewahrungsfrist von 7 Tagen durch und unterstützt eine Wiederherstellung zum bestimmten Zeitpunkt innerhalb dieses Zeitraums, aber in der v2-API-Version kann die Aufbewahrungsfrist über backup.retentionDays bei der Erstellung oder Aktualisierung von Cluster von 1 bis 365 Tagen konfiguriert werden. Beachten Sie, dass die allgemeine Backup Service keine verwalteten Datenbanken sichert, also planen Sie nicht, sie auf die Cluster-Datenbank auszurichten. Die Wiederherstellung umfasst PITR (Point-in-Time-Recovery) sowie Ihre eigenen geplanten Datenbank-Dumps, die in Modul 4 behandelt werden.

Binden Sie den postgres_version-Wert explizit, anstatt ihn schwimmen zu lassen. Major-Updates ändern das Verhalten und sind nicht etwas, das Sie durch einen Plan-Unterschied 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)"

Das maintenance_window steuert, wann die Plattform Patches anwendet. Jedes Fenster ist bis zu 4 Stunden lang. Wählen Sie einen Zeitraum mit geringem Datenverkehr, damit der HA-Failover während des Patchens außerhalb der Hauptlast liegt.

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

TaskBoard verwendet In-Memory DB für Sitzungsspeicherung und für Caching von Aufgabenlisten. Da PostgreSQL keine lesbaren Replikate hat, ist der Cache die Leseskala-Ebene und keine optionale Optimierung. Die ionoscloud_inmemorydb_replicaset-Ressource bereitstellt ein Replikatsatz, der mit Redis kompatibel ist. Der Motor ist die stabile Version 7.2 von Redis OSS und der Standardport ist 6379.

In-Memory DB bietet nun zwei Versionen von API. Die v2-API-Version (Version 2.0.0), deren primäre Ressource die Cluster ist, ist allgemein verfügbar und die empfohlene API-Version für die Produktion. Die v1-API-Version (Version 1.0.0), deren primäre Ressource die ReplicaSet ist, ist die Legacy-Implementierung und hat eine Ankündigung der Entfernung für eine bevorstehende Version; die Migration von v1 auf v2 ist kundenseitig initiiert und nicht automatisch, sodass bestehende v1-Cluster manuell auf die v2-Cluster-Ressource migriert werden müssen, bevor v1 entfernt wird. Die Terraform-Beispiele unten bereitstellen den In-Memory DB-Replikatsatz, und das Verbindungsmodell, das sie produzieren (Motor, Port, TLS, fester Verbindungslimit), ist unabhängig von der API-Version, die die Ressource unterstützt. Für neue direkte API- oder SDK-Entwicklungen sollten die v2-Cluster-Endpunkte verwendet werden.

Der Replikatsatz besteht aus einem aktiven Node und n-1 passiven Knoten. Passive Knoten bieten Failover und nicht zusätzliche Lese-Durchsatzrate aus der Perspektive des Clients, da Clients über den aktiven Endpunkt verbunden sind.

2.1 Die inmemorydb_replicaset-Ressource

Eine kritische Einschränkung: Anmeldedaten werden nur bei der Erstellung festgelegt. Sie können das Passwort nicht durch eine spätere Aktualisierung ändern, also generieren Sie es einmal und speichern Sie es an einem Ort, an dem Ihre Anwendung es lesen kann. Der Mindestspeicherplatz beträgt 10 GB pro Node. Die Standard-Verdrängungsrichtlinie ist allkeys-lru. Der Persistenzmodus ist standardmäßig auf None gesetzt; 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, aber er ist nur verschlüsselt, wenn Sie TLS auf der Instanz bei der Erstellung aktivieren; standardmäßig ist es nicht aktiviert. Sobald es aktiviert ist, ist die Zertifizierungsstelle Let's Encrypt, sodass ein Standard-System-CA-Bundle die Verbindung ohne das Versenden eines benutzerdefinierten Stammzertifikats validiert. Ihr Redis-Client verbindet sich mit aktiviertem TLS gegen den aktiven Endpunkt mit TLS.

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 vor Ort gedreht werden kann, behandeln Sie eine Rotation als Ersetzung: Stellen Sie ein neues Replikatsatz bereit, schalten Sie den Datenverkehr um und zerstören Sie dann den alten.

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

PostgreSQL und In-Memory DB decken die Bedürfnisse von TaskBoard ab, aber das Bereitstellungsmuster verallgemeinert sich. Kafka, MongoDB und MariaDB folgen alle dem gleichen Muster: eine Cluster-Ressource, ein Verbindungsblock, der an eine LAN bindet, ein Wartungsfenster und Anmeldeinformationen, alles asynchron. Nachfolgend finden Sie die Ressourcennamen und die Unterschiede, die wichtig sind, wenn Sie darauf zugreifen.

3.1 Kafka-Cluster und Themen

Der Ereignisstrom von TaskBoard (Ereignisse zur Aufgabenänderung, die vom Worker verarbeitet werden) läuft auf Kafka. Die Bereitstellung umfasst zwei Ressourcen: die Cluster und dann 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 auf diesen Versionen bleiben weiterhin aktiv, aber neue Cluster sollten die Version 4.0.0 verwenden. Ein Cluster führt 3 Broker aus, und IONOS empfiehlt (obwohl es nicht standardmäßig voreingestellt ist) einen Replikationsfaktor von 3 für Themen, der der 3-Broker-Struktur entspricht. Die Authentifizierung erfolgt über mTLS für die DatenEbene und ein Bearer-Token für die Verwaltungs-API. Die Verschlüsselung während der Übertragung ist 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 Anzahl der Partitionen ist die Obergrenze für die Parallelität der Consumer, daher sollten Sie sie für die erwartete Consumer-Verteilung dimensionieren (Modul 4 behandelt die Consumer-Skalierung). Der Replikationsfaktor von 3 entspricht der 3-Broker-Layout. Client-Zertifikate, die für mTLS ausgestellt werden, sind 365 Tage gültig, daher sollten Sie vor ihrem Ablauf eine Rotation planen.

3.2 MongoDB und MariaDB

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

MariaDB verwendet ionoscloud_mariadb_cluster. Es unterstützt nur LTS-Versionen, beginnend mit 10.6 (zum Beispiel 10.6, 10.11), der Standardport ist 3306 und die Replikation erfolgt nur 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 den zu bereitstellenden Engine:

Wählen Sie PostgreSQL oder MariaDB für relationale Transaktionsdaten, MongoDB für Dokumentendaten, In-Memory DB für Caching und Kafka für Ereignisstreams. Keiner der relationalen Engines bietet lesbare Replikate, daher ist die Antwort für die Leseskala immer der Cache. Wählen Sie PostgreSQL, MariaDB, MongoDB, Redis oder Kafka, um die richtige Engine für Ihre Anforderungen zu finden.

4. Verbindungsausgaben und die Single-Primary-Einschränkung

Eine Bereitstellung ist nur nützlich, wenn die Anwendung eine Verbindung herstellen kann. Terraform kennt den Namen und die Anmeldeinformationen von Cluster nach der Anwendung, daher sollten diese als Ausgaben exponiert werden, jede von ihnen mit sensitive markiert, damit sie nicht im Plan-Output, in CI-Protokollen oder in terraform output ohne -raw erscheinen.

4.1 Sensitive Ausgaben

Die PostgreSQL-Cluster-Instanz stellt einen stabilen DNS-Hostname bereit, zum Beispiel pg-010203.postgresql.de-fra.ionos.com, den Ihre Anwendung anstelle eines IP verwendet. Erstellen Sie die Verbindungszeichenfolge aus dem DNS-Namen von Cluster und den von Ihnen bereitgestellten Anmeldeinformationen.

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 nicht durch den Client deaktiviert werden, daher sollten Sie immer sslmode=require (oder strenger) auf der Anwendungsseite festlegen. Das TLS-Stammzertifikat für PostgreSQL ist ISRG Root X1, das in jedem modernen System-CA-Bundle enthalten ist.

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

Dies ist die Einschränkung, die naive Skalierungspläne durchbricht. Es gibt keine read_endpoint-Ausgabe, die erstellt werden kann, da es keine Lese-Replikation gibt. Die Replikationsgruppe von In-Memory DB besteht aus einem aktiven und n-1 passiven Knoten, und die passiven Knoten sind Failover-Ziele, keine Leseendpunkte. Die PostgreSQL-instances > 1-Funktion bietet Hochverfügbarkeits-Backup-Systeme, 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
}

Verbinden Sie die Anwendung so, dass jeder Schreibvorgang und jeder konsistente Lesevorgang zum Primärknoten und jeder heiße Lesevorgang über In-Memory DB mit einem Cache-Aside-Muster erfolgt. Diese Integration ist Gegenstand des Moduls 4, aber die Bereitstellungsentscheidung wird hier getroffen: ein Primärknoten, ein Cache.

API Referenz-Quick-Card

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

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 Management-APIs; mTLS für die Kafka-Daten-Ebene

Code-Lab

Ziel: Bereitstellung der Datenbankebene von TaskBoard mit Terraform: einer einzelnen primären PostgreSQL Cluster und einem In-Memory DB-Replikatsatz, dann Ausgabe ihrer Verbindungsdetails als sensible Werte.

Voraussetzungen:

• IONOS Cloud-Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform >= 1.5 mit dem ionoscloud-Anbieter
• Ein bestehendes Rechenzentrum und Datenbank-LAN aus den Einheiten 2.1 und 2.2

Schritt 1: Deklaration sensibler Variablen

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

Schritt 2: Hinzufügen der PostgreSQL Cluster (aus Abschnitt 1.1), dann Validierung:

terraform validate

Erwartete Ausgabe:

Success! The configuration is valid.

Schritt 3: Hinzufügen des In-Memory DB-Replikatsatzes (aus Abschnitt 2.1) und der sensiblen Ausgaben (aus Abschnitt 4.1). Dann Planung:

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 (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: Lesen der sensiblen Verbindungszeichenfolge (Hinweis: -raw, erforderlich, weil es sich um sensible Informationen handelt):

terraform output -raw pg_connection_string

Erwartete Ausgabe:

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

Schritt 6: Überprüfen der PostgreSQL-Verbindung über TLS von einem Host auf der Datenbank-LAN:

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

Erwartete Ausgabe:

PostgreSQL 16.x ...

Schritt 7: Überprüfen des Caches 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

Validierungs-Checkliste:

• [ ] PostgreSQL Cluster erreicht AVAILABLE und akzeptiert eine TLS-Verbindung
• [ ] In-Memory DB-Replikatsatz reagiert auf PING über TLS
• [ ] Alle Verbindungsausgaben sind als sensible markiert und erfordern -raw zum Lesen
• [ ] Kein Passwort erscheint in der Plan-Ausgabe oder den Anwendungsprotokollen

Aufräumen:

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

Häufige Fallstricke

1. Behandlung von Cluster-Instanzen als Lese-Replikate

   • Problem: Sie setzen instances = 3 auf dem PostgreSQL Cluster und versuchen, Leseanfragen an eine zweite Node zu senden, um die Primärinstanz zu entlasten. Die Verbindungen landen jedoch immer noch auf dem gleichen beschreibbaren Endpunkt, und Sie erhalten nie eine Lese-Skalierung.
   • Warum es passiert: IONOS-gemanagte Datenbanken führen eine einzelne beschreibbare Primärinstanz aus. Zusätzliche Instanzen sind Hochverfügbarkeits-Standbys, keine lesbaren Replikate, und es gibt keinen separaten Leseendpunkt.
   • Lösung: Stellen Sie eine Primärinstanz bereit und leiten Sie heiße Leseanfragen durch In-Memory DB:

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

2. Leckagen von Anmeldeinformationen durch Terraform-Ausgaben

   • Problem: Ihre CI-Protokolle drucken das Datenbankpasswort aus, weil eine Ausgabe nicht als sensibel markiert wurde und terraform apply es im Lauf ausgibt.
   • Warum es passiert: Ausgaben sind standardmäßig sichtbar. Jede Verbindungsschrift, die aus Anmeldeinformationen erstellt wird, ist Klartext, es sei denn, sie wird gekennzeichnet.
   • Lösung: Markieren Sie jede ausgabenbasierte Anmeldeinformation sensitive = true und lesen Sie nur dann, wenn erforderlich, 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 die Anwendung schlägt fehl oder die Änderung wird ignoriert.
   • Warum es passiert: In-Memory DB-Anmeldeinformationen werden nur bei der Erstellung festgelegt und können nicht später geändert werden.
   • Lösung: Behandeln Sie die Rotation als Ersetzung. Stellen Sie einen neuen Replikatsatz bereit, migrieren Sie den Datenverkehr und zerstören Sie dann den alten. Erstellen Sie das Passwort einmal bei der Erstellung:

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

Zusammenfassung

Sie können nun die gesamte Datenebene von TaskBoard als Code bereitstellen: ein einzelnes primäres PostgreSQL Cluster für Transaktionen, ein In-Memory DB-Replikaset für Sitzungen und Lese-Caching und (unter Verwendung desselben Ressourcenmusters) Kafka, MongoDB oder MariaDB, wenn ein Workload diese benötigt. Sie wissen, wie Sie jeden Cluster an ein privates LAN binden, ein Wartungsfenster festlegen, Anmeldeinformationen sicher bereitstellen und Verbindungsdetails als sensible Terraform-Ausgaben exponieren. Am wichtigsten ist, dass Sie nach dem Einzel-Primär-Modell bereitstellen: eine beschreibbare Cluster, wobei die Lese-Skalierung durch den Cache und nicht durch Replikate, die nicht existieren, gehandhabt wird.

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; Anmeldeinformationen 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 Daten-Ebene authentifiziert sich mit mTLS
• Jede Verbindungsausgabe muss als sensitive markiert werden; der Standard-SSL-Modus von PostgreSQL ist prefer und kann nicht deaktiviert werden, sodass die Anwendung sslmode=require festlegt
• Es gibt keine lesbaren Lese-Replikate auf jedem gemanagten Motor; stellen Sie einen einzelnen Primär- und Skalieren Sie die Lesevorgänge durch In-Memory DB

Wichtige Begriffe:

• Einzel-Primär-Modell: Die Bereitstellungsbeschränkung, dass gemanagte Datenbanken eine beschreibbare Cluster ohne lesbare Replikate ausführen; Lesevorgänge werden auf der Cache-Ebene skaliert.
• Replikaset (In-Memory DB): Ein aktiver Node plus n-1 passive Failover-Knoten; Clients verbinden sich über den aktiven Endpunkt.
• Wartungsfenster: Ein konfigurierbares wöchentliches Zeitfenster (bis zu 4 Stunden), in dem die Plattform Patches anwendet und möglicherweise einen HA-Failover auslöst.
• Sensible Ausgabe: Eine Terraform-Ausgabe, die als sensitive = true markiert ist, sodass sie in Plan-, Anwendungs- und CI-Protokollen verborgen ist und -raw zum Lesen erfordert.
• Replikationsfaktor (Kafka): Die Anzahl der Broker-Kopien jeder Partition; standardmäßig 3, was dem 3-Broker-Cluster entspricht.

Nächste Schritte

Weiterlernen: Einheit 2.6: Wissensprüfung - Infrastructure as Code

Verwandte Themen:

• Einheit 2.4: Speicherbereitstellung als Code
• Einheit 4.1: Datenbank- und Caching-Integration