Aufgabe 11 - Dokploy, Domain und Zertifikat

Aufgabe 11 - Dokploy, Domain und Zertifikat

Worum geht es?

Sie schließen die Kette, die dieses Kapitel verspricht: Aus einem git push wird eine öffentlich erreichbare Anwendung unter Ihrem eigenen Namen, mit gültigem Zertifikat (siehe Kapitel Auslieferung mit Containern). Am Ende dieser Übung ist Ihr Jahresprojekt zum ersten Mal etwas, das man jemandem zeigen kann, indem man ihm eine Adresse sagt.

Was Sie dafür brauchen

• Kapitel Auslieferung mit Containern, Abschnitte Reverse Proxy und TLS bis Produktion und Vorschau trennen.
• Ihren gehärteten Server aus Aufgabe 08 und die Compose-Beschreibung aus Aufgabe 10.
• Eine eigene Domain oder einen Namen bei einem Dienst wie DuckDNS oder sslip.io.

Welche Kompetenzen Sie erwerben und zeigen

• Sie erklären den Weg einer Anfrage von der Domain über TLS bis zum Container an jeder Station.
• Sie legen DNS-Einträge an und prüfen sie mit dig und curl.
• Sie liefern Ihr Projekt über Dokploy aus, sichern die Oberfläche ab und trennen Produktion von Vorschau.

Pädagogische Einordnung

• Reproduktion: DNS-Einträge anlegen und die Installation nach Anleitung durchführen (Teil A).
• Reorganisation und Transfer: das eigene Projekt ausliefern und jede Station einzeln prüfen (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: den Weg einer Anfrage erklären und Umgebungen trennen (Teil C).

Let’s Encrypt hat ein Gedächtnis

Fehlgeschlagene Zertifikatsanfragen sind pro Stunde und pro Woche begrenzt. Prüfen Sie vor jedem Versuch mit dig +short, ob der Name auf Ihren Server zeigt, und verwenden Sie zum Ausprobieren die Staging-Umgebung. Wer in einer Schleife neu deployt, sperrt sich selbst aus.

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Namen und Deployment-Oberfläche

1. Legen Sie die DNS-Einträge für Ihr Projekt an. Vier Namen bereiten Sie gleich vor, auch wenn Sie zunächst nur einen brauchen: den Hauptnamen für die Anwendung, api. für den Webservice, cms. für den Inhaltsbereich und dokploy. für die Deployment-Oberfläche.

2. Notieren Sie zu jedem Eintrag vier Angaben: Typ (A, AAAA oder CNAME), Name, Ziel und TTL.

3. Prüfen Sie jeden Namen mit dig +short <name>. Notieren Sie die Antworten und vergleichen Sie sie mit der IP-Adresse aus docs/betrieb.md.

4. Erklären Sie in drei bis vier Sätzen, was die TTL bewirkt. Beschreiben Sie dabei, in welcher Reihenfolge Sie bei einem geplanten Umzug vorgehen würden: TTL herabsetzen, umstellen, TTL wieder heraufsetzen.

5. Laden Sie das Installationsskript von Dokploy herunter und lesen Sie es, bevor Sie es ausführen:

   curl -sSL https://dokploy.com/install.sh -o install.sh
   less install.sh
   sudo sh install.sh

   Notieren Sie in drei bis vier Sätzen, welche drei Bestandteile das Skript einrichtet, und begründen Sie, warum der Zwischenschritt mit less auf einem gerade gehärteten Server keine Förmlichkeit ist.

6. Legen Sie das Administratorkonto sofort nach der Installation an. Erklären Sie in zwei Sätzen, wovor die Eile schützt.

7. Hängen Sie die Oberfläche an den Unternamen dokploy. mit eigenem Zertifikat und schließen Sie den direkten Port in der Firewall. Weisen Sie beides nach: den Aufruf über den Namen und die Prüfung des Ports von einem zweiten Rechner aus.

8. Tragen Sie den Eingriff mit Datum, Befehlen und Ergebnis in docs/betrieb.md ein.

Teil B - Das Projekt ausliefern

1. Verbinden Sie Ihr Repository, wählen Sie den Produktionsbranch und Ihr Dockerfile als Bauart.

2. Tragen Sie alle Umgebungsvariablen aus .env.example mit echten Werten ein. Prüfen Sie danach mit git grep, dass keiner dieser Werte im Repository steht.

3. Legen Sie PostgreSQL als eigenen Dienst mit Volume und geplanter Sicherung an. Notieren Sie, wie die Verbindungszeichenfolge in die Umgebung der Anwendung gelangt.

4. Lösen Sie das erste Deployment aus und lesen Sie die Build-Ausgabe mit. Notieren Sie jeden Fehler, der dabei auftrat, und was Sie dagegen getan haben. Beim ersten Mal geht selten alles durch, und genau diese Liste ist der Ertrag der Übung.

5. Prüfen Sie die Auslieferung mit curl -vI https://<ihr-name>. Notieren Sie vier Angaben: ob eine Antwort kommt, welches Zertifikat gezeigt wird, wer es ausgestellt hat und wie lange es gilt.

6. Prüfen Sie die Umleitung mit curl -vI http://<ihr-name>. Notieren Sie den Statuscode und den Location-Header.

7. Hinterlegen Sie den Webhook im Repository. Ändern Sie eine sichtbare Kleinigkeit, pushen Sie, und messen Sie die Zeit vom Push bis zur sichtbaren Änderung im Browser. Notieren Sie die Dauer.

Teil C - Die Kette erklären und die Umgebungen trennen

1. Zeichnen Sie den Weg einer Anfrage für Ihr Projekt als Sequenzdiagramm, mit Ihren Namen und Ihren Ports. Die vier Beteiligten sind Browser, DNS, Traefik und Container. Legen Sie das Diagramm in docs/architektur.md ab.

2. Beschreiben Sie zu jeder der vier Stationen in zwei bis drei Sätzen, wie sie ausfällt und woran Sie den Ausfall erkennen. Diese Beschreibung ist Ihre Landkarte für Aufgabe 12.

3. Erklären Sie in fünf bis sechs Sätzen den Ablauf der Zertifikatsausstellung als Besitzprüfung. Beantworten Sie dabei drei Fragen: Was stellt Let’s Encrypt, was hinterlegt Traefik, und was ruft Let’s Encrypt danach ab? Nennen Sie am Ende die beiden Voraussetzungen, die daraus folgen, und den Befehl, mit dem Sie jede davon prüfen.

4. Richten Sie eine Vorschauumgebung unter test. mit Ihrem Arbeitsbranch ein. Sie bekommt eigene Umgebungsvariablen und eine eigene Datenbank.

5. Weisen Sie die Trennung nach. Legen Sie in der Vorschau einen Datensatz an und zeigen Sie, dass er in der Produktion nicht auftaucht. Notieren Sie, wie Sie das geprüft haben.

6. Beurteilen Sie in vier bis fünf Sätzen, was eine Vorschauumgebung wert ist, die auf der Produktionsdatenbank arbeitet. Nennen Sie zwei Fehler, die dadurch überhaupt erst möglich werden.

7. Schreiben Sie einen Eintrag in docs/entscheidungen.md zur Deployment-Strategie, mit den vier Abschnitten Entscheidung, Alternativen, Begründung und Folgen. Als Alternativen kommen das Deployment von Hand und eine fremde Cloud in Frage.

Wissenscheck

1. Welche zwei Aufgaben erfüllt ein Reverse Proxy, und warum sprechen die Container dahinter nur einfaches HTTP?
2. Wie erkennt Traefik einen neuen Container, und worin unterscheidet sich das von nginx?
3. Was bewirkt die TTL eines DNS-Eintrags, und was tut man vor einem geplanten Umzug?
4. Welche zwei Voraussetzungen müssen erfüllt sein, damit Let’s Encrypt ein Zertifikat ausstellt?
5. Warum leitet man Port 80 dauerhaft auf HTTPS um, und was tut zusätzlich der Header Strict-Transport-Security?
6. Warum wird ein Installationsskript aus dem Netz erst gelesen und dann ausgeführt?
7. Warum braucht eine Vorschauumgebung eine eigene Datenbank?

Abgabe

Die Anwendung ist unter der eigenen Domain mit gültigem Zertifikat erreichbar, HTTP leitet auf HTTPS um, und ein Push auf den Produktionsbranch löst ein Deployment aus. Das Sequenzdiagramm mit den vier Ausfallbeschreibungen liegt in docs/architektur.md, der Eintrag zur Deployment-Strategie in docs/entscheidungen.md, Installation und Absicherung in docs/betrieb.md. Die DNS-Tabelle, die curl-Ausgaben, die Fehlerliste aus dem ersten Deployment und der Trennungsnachweis stehen in protokoll.md.