RDS PostgreSQL erstellen und verbinden

Einführung

Eine Bestellanwendung benötigt eine relationale Datenbank, um Kundenbestellungen zu speichern. In diesem Lab erstellst du mit Amazon RDS eine private PostgreSQL-Datenbank, verbindest einen standardmäßigen SQL-Client und richtest die Anwendung auf den neuen Endpunkt aus.

Du solltest VPC-Subnetze, Sicherheitsgruppen und Anwendungsverbindungen aus den vorigen VPC- und EC2-Kursen verstehen. Netzwerk, Anwendung und konfigurierte AWS CLI sind vorbereitet. Ein persönliches AWS-Konto ist nicht nötig. Am Ende entfernst du die Datenbank.

Bezug zu Zertifizierungen

Dieses Lab bietet grundlegende praktische Übungen zu folgenden Prüfungsthemen.

Cloud Practitioner (CLF-C02) · Aufgabe 3.4: Amazon RDS als verwalteten relationalen Datenbankdienst erkennen.
Solutions Architect – Associate (SAA-C03) · Aufgabe 3.3: Datenbank-Engines und Datenbankverbindungen von Anwendungen verstehen.

Die Anwendungsdatenbank erstellen

In diesem Schritt erstellst du eine private PostgreSQL-Instanz im vorbereiteten Datenbanknetzwerk.

Amazon RDS verwaltet relationale Datenbankinstanzen. PostgreSQL ist die Engine, die Tabellen speichert und SQL ausführt. Die AWS CLI verwaltet die RDS-Ressource; ein SQL-Client verbindet sich mit der Engine, um Daten zu bearbeiten. Eine RDS-Instanz zu erstellen und eine Tabelle abzufragen sind unterschiedliche Vorgänge.

Die AWS Management Console hilft beim Erkunden von Diensten und Prüfen von Ressourcen. Die CLI eignet sich für präzise Abfragen, wiederholbare Vorgänge und Automatisierung, ihre Syntax erfordert jedoch Übung. Dieser Kurs nutzt das vorbereitete Terminal und AWS View. AWS View zeigt Lab-Ressourcen und Anwendungsergebnisse und ist von der AWS Management Console getrennt.

Wechsle in den Arbeitsbereich und lade die bereitgestellten Verbindungseinstellungen:

cd /home/labex/project
source database.env

DB_SECURITY_GROUP_ID bezeichnet die vorbereiteten Netzwerkzugriffsregeln der Datenbank. PGSERVICEFILE und PGPASSFILE zeigen dem PostgreSQL-Client, wo sich die üblichen Verbindungs- und Passwortdateien befinden. Halte Passwortdateien privat; ihr Inhalt muss nicht angezeigt werden.

Prüfe die vorbereitete DB-Subnetzgruppe:

aws rds \
  describe-db-subnet-groups \
  --db-subnet-group-name orders-subnets \
  --query 'DBSubnetGroups[].{Name:DBSubnetGroupName,VPC:VpcId,Subnets:Subnets[].SubnetIdentifier}'

Eine DB-Subnetzgruppe benennt die VPC-Subnetze, in denen RDS platziert werden kann. Diese Gruppe enthält private Datenbanksubnetze in zwei Availability Zones. Zwei Subnetze aktivieren allein noch keine Multi-AZ-Bereitstellung.

Erstelle die Instanz:

aws rds \
  create-db-instance \
  --db-instance-identifier orders-db \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --engine-version 16.15 \
  --allocated-storage 20 \
  --master-username orders_admin \
  --master-user-password "$(cat db-password.txt)" \
  --db-name orders \
  --db-subnet-group-name orders-subnets \
  --vpc-security-group-ids "$DB_SECURITY_GROUP_ID" \
  --no-publicly-accessible \
  --backup-retention-period 0 \
  --query 'DBInstance.{Identifier:DBInstanceIdentifier,Status:DBInstanceStatus,Engine:Engine}'

Die Instanzkennung orders-db benennt die RDS-Ressource; der Datenbankname orders benennt die PostgreSQL-Datenbank darin. db.t3.micro wählt eine Instanzklasse und 20 fordert Speicher in GiB an. Privater Zugriff hält die Anwendungsverbindungen im vorbereiteten Netzwerk. Für diese kurze Übung ist die Aufbewahrung automatischer Backups deaktiviert; ein späteres Lab behandelt einen manuellen Snapshot.

$(cat db-password.txt) liefert das vorbereitete Datenbankpasswort, ohne es auszugeben. Füge keine Passwörter in Notizen oder Screenshots ein.

Warte auf Verfügbarkeit und prüfe den Verbindungsendpunkt:

aws rds \
  wait db-instance-available \
  --db-instance-identifier orders-db

aws rds \
  describe-db-instances \
  --db-instance-identifier orders-db \
  --query 'DBInstances[0].{Identifier:DBInstanceIdentifier,Database:DBName,Status:DBInstanceStatus,Endpoint:Endpoint}'

Erwartet werden die Datenbank orders, der Status available und PostgreSQL-Port 5432. Der Endpunkt ist die Adresse, mit der Clients diese Instanz auswählen. AWS View sollte orders-db nun als Primärdatenbank anzeigen. Eine Bestelltabelle existiert noch nicht.

SQL-Client und Anwendung verbinden

In diesem Schritt testest du die Engine und richtest die Anwendung auf ihren Endpunkt aus.

psql ist der standardmäßige PostgreSQL-Client für die Befehlszeile. Der vorbereitete Dienst orders-db enthält die Verbindungsdetails der erstellten Instanz. Ein Dienstname ist ein praktischer Eintrag in der Clientkonfiguration und keine AWS-Ressource.

Eine private PostgreSQL-Verbindung braucht einen erreichbaren Endpunkt und erlaubten Port

Konzeptdiagramm: Eine private PostgreSQL-Verbindung braucht einen erreichbaren Endpunkt und erlaubten Port.

Frage die Engine ab:

psql \
  "service=orders-db" \
  --command 'SELECT current_database(), current_user;'

Erwartet werden die Datenbank orders und der Benutzer orders_admin. Dieses Ergebnis stammt aus einer Datenbankverbindung und nicht aus RDS-Ressourcenmetadaten. RDS verwaltet den Datenbankhost; Anwendungen nutzen das Datenbankprotokoll und keinen SSH-Zugriff auf diesen Host.

Lies den Endpunkt aus RDS aus. --query wählt ein Feld, --output text erzeugt einen einfachen Wert und $(...) der Shell speichert ihn in DB_ENDPOINT:

DB_ENDPOINT=$(aws rds \
  describe-db-instances \
  --db-instance-identifier orders-db \
  --query 'DBInstances[0].Endpoint.Address' \
  --output text)

Prüfe die bereitgestellte Anwendungskonfiguration:

cat app-config.json

read_host wählt die Datenbank für Abfragen, write_host für Änderungen. Zunächst sollen beide die Primärinstanz verwenden. password_file verweist auf eine private Datei, statt das Passwort in dieses JSON-Dokument einzubetten.

Setze beide Hostfelder mit dem JSON-Werkzeug jq. Schreibe eine neue Datei und ersetze die Konfiguration erst, wenn die Bearbeitung gelungen ist:

jq \
  --arg host "$DB_ENDPOINT" \
  '.read_host = $host | .write_host = $host' \
  app-config.json > app-config.new
mv app-config.new app-config.json

Teste die Anwendungsverbindung:

curl \
  --silent \
  --show-error \
  --fail \
  http://127.0.0.1:8080/application/connection

Erwartet werden database gleich orders, user gleich orders_admin und read_only gleich false. Die Primärinstanz erlaubt Schreibzugriffe, dieses Lab stellt aber nur die Verbindung her. Die Bestellliste in AWS View bleibt ohne Bestelltabelle nicht verfügbar; du erstellst sie im nächsten Lab. PostgreSQL-Primärverbindung in AWS View

Das Beispiel zeigt die Anwendung verbunden mit der Primärdatenbank orders und den nativen RDS-Endpunkt. Die Bestelltabelle existiert noch nicht. Deine Ressourcenkennungen können abweichen.

AWS Console: RDS

Beispiel der offiziellen Console: Endpoint und Port unter Connectivity & security entsprechen Endpoint.Address und Endpoint.Port der CLI. Das Beispiel zeigt MySQL mit 3306; dieses Lab nutzt PostgreSQL mit 5432 und den Endpunkt Ihrer eigenen Abfrage. Übernehmen Sie weder Beispielhostname noch Port. Arbeiten Sie in Terminal und AWS View ohne AWS-Anmeldung weiter.

Source: AWS RDS guide.

Die Datenbankinstanz entfernen

In diesem Schritt entfernst du die kurzlebige Datenbank und erhältst die vorbereitete Anwendung und das Netzwerk.

Lösche deine Instanz ohne abschließenden Snapshot:

aws rds \
  delete-db-instance \
  --db-instance-identifier orders-db \
  --skip-final-snapshot \
  --query 'DBInstance.DBInstanceIdentifier'

--skip-final-snapshot verwirft die Übungsdatenbank, ohne eine Wiederherstellungskopie zu speichern. Entscheide bei wichtigen Daten vor dem Löschen, wie du ein Backup erhältst.

Warte auf die Löschung und prüfe den Bestand:

aws rds \
  wait db-instance-deleted \
  --db-instance-identifier orders-db

aws rds \
  describe-db-instances \
  --query 'DBInstances[].DBInstanceIdentifier'

Erwartet wird []. AWS View sollte keine Datenbank mehr anzeigen. Hinter dem alten Anwendungsendpunkt läuft keine Datenbank mehr; ein Verbindungsfehler nach der Löschung ist daher erwartbar. Erhalte die bereitgestellte Subnetzgruppe, die Sicherheitsgruppen und Anwendungsdateien.

Zusammenfassung

Du hast eine private RDS-PostgreSQL-Instanz erstellt, ihre Ressourcenkennung vom Datenbanknamen unterschieden und den Endpunkt geprüft. Du hast die Engine mit psql abgefragt und eine Anwendung mit derselben Primärinstanz verbunden. Abschließend hast du die Instanz gelöscht und das vorbereitete Netzwerk erhalten.

Das nächste Lab erstellt eine Bestelltabelle und verwendet SQL zum Speichern und Abfragen von Kundenbestellungen.