Zum Inhalt springen

Aufgabe 09 - Installation einer lokalen PostgreSQL-Datenbank

Zu Zen-Modus wechseln

Aufgabe 09 - Installation einer lokalen PostgreSQL-Datenbank mit Docker

Abschnitt betitelt „Aufgabe 09 - Installation einer lokalen PostgreSQL-Datenbank mit Docker“

In dieser Übung entsteht die eigene Arbeitsumgebung: ein lokaler PostgreSQL-Server in Docker mit persistenten Daten (siehe Kapitel 5 - SQL-Grundlagen). Diese Datenbank wird in allen folgenden SQL-Übungen verwendet. Im Expertenteil werden Persistenz und Sicherheit tatsächlich überprüft.

  • Kapitel 5 - SQL-Grundlagen (Einstieg).
  • Eine Docker-Umgebung (Docker Desktop, Docker Engine oder Podman) auf dem HTL-Live-Image oder dem eigenen Betriebssystem.
  • Ein PostgreSQL-Client (psql, DBeaver, pgAdmin o. Ä.).
  • Grundlagen zum HTL-Live-Image: Übung A und Übung B.
  • Sie unterscheiden Datenbankserver und Datenbank-Client.
  • Sie konfigurieren einen Container mit Image, Port-Mapping und Volume.
  • Sie weisen die Persistenz der Daten über einen Neustart hinaus nach.
  • Sie härten den Server ab und sichern Daten mit Backup und Restore.
  • Reproduktion: Docker prüfen und einen Container starten (Teil A).
  • Reorganisation und Transfer: den Server konfigurieren und testen (Teile B und C).
  • Reflexion, Problemlösung und Urteilsbildung: Persistenz und Sicherheit nachweisen und beurteilen (Teil D).

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

  1. Zwischen HTL-Live-Image (VM) und nativem Betriebssystem entscheiden und ausreichende Rechte sicherstellen.
  2. Die Docker-Installation prüfen mit docker version und docker ps.
  1. Eine docker-compose.yml schreiben, die einen postgres-Container startet, den Port mappt (z. B. 5432:5432), ein Volume für die Daten einbindet und die Umgebungsvariablen POSTGRES_PASSWORD, POSTGRES_USER, POSTGRES_DB setzt.
  2. Den Container mit docker compose up -d starten und mit docker ps und docker logs <container> prüfen, dass er ohne kritische Fehler läuft.
  1. Mit psql oder einem GUI-Tool verbinden (Host, Port, Benutzer, Passwort, Datenbank).
  2. Folgende Befehle ausführen und die Ergebnisse notieren:
CREATE DATABASE testdb;
\c testdb
SELECT version();
CREATE TABLE test (id SERIAL PRIMARY KEY, name TEXT NOT NULL);
INSERT INTO test (name) VALUES ('First entry');
SELECT * FROM test;

Teil D - Expertenteil: Persistenz und Sicherheit nachweisen

Abschnitt betitelt „Teil D - Expertenteil: Persistenz und Sicherheit nachweisen“
  1. Persistenz beweisen: Den Container mit docker compose down stoppen und entfernen (das Volume bleibt), dann mit docker compose up -d neu starten. Prüfen, ob die Tabelle test und ihr Datensatz noch vorhanden sind. Anschließend das Experiment mit einem anonymen Container ohne Volume wiederholen und den Unterschied dokumentieren. In zwei bis drei Sätzen erklären, warum das Volume den Unterschied macht.

  2. Least Privilege: Einen zusätzlichen Datenbankbenutzer app_user anlegen, der kein Superuser ist, und ihm nur die Rechte auf testdb geben, die eine Anwendung braucht (CONNECT, Rechte auf die Tabellen). Mit app_user verbinden und nachweisen, dass ein DROP DATABASE testdb; scheitert, ein SELECT auf test aber funktioniert.

    CREATE ROLE app_user WITH LOGIN PASSWORD '...';
    GRANT CONNECT ON DATABASE testdb TO app_user;
    -- in testdb:
    GRANT SELECT, INSERT, UPDATE, DELETE ON test TO app_user;
  3. Port absichern: Das Port-Mapping so ändern, dass der Server nur lokal erreichbar ist (127.0.0.1:5432:5432 statt 5432:5432). In zwei Sätzen begründen, warum ein offen ins Netz gebundener Datenbankport gefährlich ist.

  4. Backup und Restore: Mit pg_dump ein Backup von testdb erstellen, danach eine frische Datenbank restoredb anlegen und das Backup mit psql einspielen. Nachweisen, dass die Tabelle test samt Datensatz in restoredb ankommt.

    Terminal-Fenster
    docker compose exec -T postgres pg_dump -U <user> testdb > backup_testdb.sql
    docker compose exec -T postgres psql -U <user> -c "CREATE DATABASE restoredb;"
    docker compose exec -T postgres psql -U <user> -d restoredb < backup_testdb.sql
  1. Worin unterscheidet sich ein Datenbankserver von einem Datenbank-Client?
  2. Wozu dient ein Volume, und was passiert ohne Volume nach einem Neustart?
  3. Was bedeutet das Port-Mapping 5432:5432, und was ändert 127.0.0.1:5432:5432?
  4. Warum sollte eine Anwendung nicht mit dem Superuser auf die Datenbank zugreifen?
  5. Welche zwei Schritte gehören zu einem logischen Backup und Restore mit pg_dump/psql?
  • Eine Dokumentation (Word oder PDF) mit gewählter Umgebung, docker-compose.yml, konfigurierten Einstellungen (Port, Benutzer, Datenbank, ohne Klartext-Passwort) und den aufgetretenen Problemen samt Lösung.
  • Screenshots: laufender Container in docker ps, erfolgreiche Verbindung, SELECT * FROM test;, der Persistenz-Nachweis aus Teil D sowie der fehlgeschlagene DROP DATABASE mit app_user.

HTL Villach, Schuljahr 2025-2026,
https://www.htl-villach.at