Übersicht: Veröffentlichung einfach erklärt¶

Ziel¶

Diese Seite erklärt die wichtigsten Begriffe rund um die Veröffentlichung einer Webapp.

Sie ist bewusst einfach geschrieben und richtet sich an Personen, die noch nicht genau wissen, was Domain, DNS, Port, Nginx, Reverse Proxy, HTTPS oder Certbot bedeuten.

Am Ende soll klar sein:

was beim Aufruf einer Website technisch passiert,
warum mehrere Bausteine nötig sind,
welche Rolle Docker, Nginx und Certbot spielen,
warum eine App nicht einfach direkt öffentlich laufen sollte,
wie die einzelnen Dateien in diesem Kapitel zusammenhängen.

Das Gesamtbild¶

Wenn jemand eine Website im Browser öffnet, passiert vereinfacht Folgendes:

Browser
↓
Domain
↓
DNS
↓
öffentliche Server-IP
↓
Server
↓
Nginx Reverse Proxy
↓
lokaler Docker-Port
↓
Docker-Container
↓
App oder Dokumentation

Beispiel:

https://immohai.ohaisoft.com
↓
DNS findet die Server-IP 46.225.28.194
↓
Anfrage kommt auf dem Server an
↓
Nginx erkennt: diese Anfrage gehört zu Immohai
↓
Nginx leitet intern weiter auf 127.0.0.1:8200
↓
Docker-Container immohai-web antwortet
↓
Browser zeigt die App an

Ein einfaches Bild¶

Man kann sich den Server wie ein Gebäude vorstellen.

Internet = Straße
Domain = Adresse des Gebäudes
DNS = Telefonbuch / Navigationssystem
Server = Gebäude
Nginx = Empfang / Pförtner
Docker-Container = einzelne Büros im Gebäude
Ports = Türen zu den Büros
HTTPS = verschlossener, sicherer Briefumschlag
Certbot = Dienst, der den Sicherheitsschlüssel besorgt und erneuert

Der Browser kommt an die Adresse.

Nginx sitzt am Eingang und entscheidet:

Diese Anfrage ist für die App.
Diese Anfrage ist für die Dokumentation.
Diese Anfrage ist für das Playbook.

Dann leitet Nginx die Anfrage intern an den richtigen Dienst weiter.

Warum braucht man überhaupt mehrere Bausteine?¶

Eine Webapp braucht nicht nur Code.

Damit sie sauber öffentlich erreichbar ist, braucht sie mehrere technische Ebenen:

Ebene	Aufgabe
Domain	lesbarer Name für Menschen
DNS	verbindet Domain mit Server-IP
Server	Maschine, auf der die Dienste laufen
Docker	startet App und Dokumentation in Containern
Port	technischer Eingang zu einem Dienst
Nginx	verteilt öffentliche Anfragen an interne Dienste
HTTPS	verschlüsselt die Verbindung
Certbot	erstellt und erneuert HTTPS-Zertifikate
Firewall	erlaubt oder blockiert Netzwerkzugriffe

Ohne diese Bausteine kann eine App zwar lokal laufen, ist aber nicht sauber, sicher und dauerhaft öffentlich erreichbar.

Grundbegriffe¶

Server¶

Ein Server ist ein Computer, der dauerhaft im Internet erreichbar ist.

Auf dem Server laufen zum Beispiel:

Webapp
Dokumentation
Datenbank
Docker
Nginx
Certbot

Im Praxisbeispiel läuft der Server bei Hetzner Cloud.

Servername: ubuntu-4gb-nbg1-1
Benutzer: fober
Öffentliche IPv4: 46.225.28.194

Öffentliche IP-Adresse¶

Eine IP-Adresse ist die technische Adresse eines Servers im Netzwerk.

Beispiel:

46.225.28.194

Menschen merken sich solche Zahlen schlecht. Deshalb verwendet man Domains.

Domain¶

Eine Domain ist ein lesbarer Name für eine Website.

Beispiel:

ohaisoft.com

Subdomains sind Unteradressen dieser Domain.

Beispiele:

playbook.ohaisoft.com
immohai.ohaisoft.com
docs.immohai.ohaisoft.com

Eine Hauptdomain kann also mehrere Dienste enthalten.

DNS¶

DNS bedeutet Domain Name System.

DNS ist vereinfacht das Telefonbuch des Internets.

Es übersetzt:

immohai.ohaisoft.com

zu:

46.225.28.194

Ohne DNS müsste man die Website direkt über die IP-Adresse aufrufen.

A-Record¶

Ein A-Record ist ein DNS-Eintrag.

Er sagt:

Diese Domain zeigt auf diese IPv4-Adresse.

Beispiel:

immohai.ohaisoft.com → 46.225.28.194

Im Praxisbeispiel zeigen mehrere Subdomains auf dieselbe Server-IP:

playbook.ohaisoft.com       → 46.225.28.194
immohai.ohaisoft.com        → 46.225.28.194
docs.immohai.ohaisoft.com   → 46.225.28.194

Welche App am Ende angezeigt wird, entscheidet später Nginx.

Port¶

Ein Port ist ein technischer Eingang zu einem Dienst.

Ein Server hat eine IP-Adresse, aber auf dieser IP können viele Dienste laufen.

Ports unterscheiden diese Dienste.

Beispiele:

Port	Bedeutung
`22`	SSH-Zugang zum Server
`80`	HTTP
`443`	HTTPS
`8100`	Developer Playbook lokal
`8200`	Immohai App lokal
`8201`	Immohai Dokumentation lokal

HTTP¶

HTTP ist das normale, unverschlüsselte Web-Protokoll.

Beispiel:

http://immohai.ohaisoft.com

HTTP ist technisch einfach, aber nicht verschlüsselt.

Für öffentliche Websites sollte HTTP nur noch als Weiterleitung auf HTTPS verwendet werden.

HTTPS¶

HTTPS ist die verschlüsselte Variante von HTTP.

Beispiel:

https://immohai.ohaisoft.com

HTTPS sorgt dafür, dass die Verbindung zwischen Browser und Server verschlüsselt ist.

Das ist wichtig, weil:

Daten nicht einfach mitgelesen werden können,
Browser keine Sicherheitswarnung anzeigen,
Nutzer der Seite eher vertrauen,
moderne Webstandards HTTPS erwarten.

Zertifikat¶

Ein HTTPS-Zertifikat bestätigt, dass eine Domain zu einem bestimmten Server gehört.

Der Browser prüft dieses Zertifikat.

Wenn es passt, zeigt der Browser eine sichere Verbindung an.

Wenn es fehlt oder falsch ist, erscheint eine Warnung.

Wichtig:

Zertifikate und private Schlüssel dürfen niemals in Git gespeichert oder öffentlich geteilt werden.

Let's Encrypt¶

Let's Encrypt ist eine Zertifizierungsstelle.

Sie stellt kostenlose HTTPS-Zertifikate aus.

Das ist für kleine und professionelle Projekte sehr praktisch, weil keine teuren Zertifikate gekauft werden müssen.

Certbot¶

Certbot ist ein Programm auf dem Server.

Certbot macht drei wichtige Dinge:

Es fragt bei Let's Encrypt ein HTTPS-Zertifikat an.
Es trägt das Zertifikat in die Nginx-Konfiguration ein.
Es kümmert sich um die automatische Erneuerung.

Ohne Certbot müsste man Zertifikate manuell erstellen, installieren und erneuern.

Das wäre fehleranfällig.

Nginx¶

Nginx ist ein Webserver.

In diesem Playbook wird Nginx hauptsächlich als Reverse Proxy verwendet.

Nginx nimmt öffentliche Anfragen auf Port 80 und 443 entgegen.

Danach leitet Nginx die Anfrage intern an den passenden Docker-Dienst weiter.

Beispiel:

playbook.ohaisoft.com       → 127.0.0.1:8100
immohai.ohaisoft.com        → 127.0.0.1:8200
docs.immohai.ohaisoft.com   → 127.0.0.1:8201

Reverse Proxy¶

Ein Reverse Proxy ist ein Vermittler vor den eigentlichen Anwendungen.

Der Browser spricht nicht direkt mit dem Docker-Container.

Der Browser spricht mit Nginx.

Nginx entscheidet dann:

Welche Domain wurde aufgerufen?
Welcher lokale Dienst gehört dazu?
An welchen Port muss ich intern weiterleiten?

Beispiel:

Browser ruft auf:
https://docs.immohai.ohaisoft.com

Nginx leitet weiter an:
http://127.0.0.1:8201

Der Nutzer sieht davon nichts. Für ihn bleibt die URL:

https://docs.immohai.ohaisoft.com

Docker¶

Docker startet Anwendungen in Containern.

Ein Container ist eine isolierte Umgebung für einen Dienst.

Beispiele:

developer-playbook-docs
immohai-web
immohai-docs

Jeder Container kann eigene Dateien, eigene Konfiguration und eigene Ports haben.

Docker Compose¶

Docker Compose beschreibt mehrere Docker-Dienste in einer Datei.

Diese Datei heißt:

docker-compose.yml

Beispiel:

services:
  docs:
    image: squidfunk/mkdocs-material:latest
    container_name: developer-playbook-docs
    ports:
      - "127.0.0.1:8100:8000"

Das bedeutet:

Der Container läuft intern auf Port 8000.
Auf dem Server ist er lokal unter 127.0.0.1:8100 erreichbar.

Lokaler Port¶

Ein lokaler Port ist nur auf dem Server selbst erreichbar.

Beispiel:

127.0.0.1:8200

127.0.0.1 bedeutet:

nur dieser Server selbst

Das ist gewollt.

Die App soll nicht direkt öffentlich erreichbar sein.

Öffentlich erreichbar ist nur Nginx.

Warum nicht Docker direkt öffentlich machen?¶

Man könnte einen Docker-Container direkt auf Port 80 veröffentlichen.

Beispiel:

ports:
  - "80:80"

Das ist für einfache Tests möglich, aber für das Playbook nicht empfohlen.

Nachteile:

Nur ein Container kann Port 80 verwenden.
Mehrere Apps auf demselben Server werden schwierig.
HTTPS-Verwaltung wird unübersichtlich.
Nginx kann Port 80 nicht verwenden.
Die Struktur ist schlechter wartbar.

Besser:

ports:
  - "127.0.0.1:8200:80"

Dann ist der Container nur lokal erreichbar und Nginx übernimmt die öffentliche Weiterleitung.

UFW / Firewall¶

Eine Firewall regelt, welche Verbindungen zum Server erlaubt sind.

Für dieses Setup werden typischerweise erlaubt:

OpenSSH
Nginx Full

Das bedeutet:

Regel	Zweck
`OpenSSH`	SSH-Zugang zum Server
`Nginx Full`	HTTP und HTTPS für Websites

Prüfen:

sudo ufw status verbose

curl¶

curl ist ein Kommandozeilenwerkzeug zum Testen von URLs.

Beispiel:

curl -I https://immohai.ohaisoft.com

-I fragt nur die HTTP-Kopfzeilen ab.

Das ist praktisch, um schnell zu prüfen, ob eine Website erreichbar ist.

Typische erfolgreiche Antworten:

HTTP/2 200
HTTP/1.1 200 OK

Eine Weiterleitung auf HTTPS sieht zum Beispiel so aus:

301 Moved Permanently

Wie alles zusammenspielt¶

Beispiel: Immohai App¶

Nutzer öffnet:
https://immohai.ohaisoft.com

DNS sagt:
immohai.ohaisoft.com → 46.225.28.194

Anfrage kommt auf dem Server an:
46.225.28.194

Nginx erkennt:
server_name immohai.ohaisoft.com

Nginx leitet weiter:
proxy_pass http://127.0.0.1:8200

Docker-Container antwortet:
immohai-web

Browser zeigt:
Immohai App

Beispiel: Immohai Dokumentation¶

Nutzer öffnet:
https://docs.immohai.ohaisoft.com

DNS sagt:
docs.immohai.ohaisoft.com → 46.225.28.194

Nginx erkennt:
server_name docs.immohai.ohaisoft.com

Nginx leitet weiter:
proxy_pass http://127.0.0.1:8201

Docker-Container antwortet:
immohai-docs

Browser zeigt:
Immohai Dokumentation

Beispiel: Developer Playbook¶

Nutzer öffnet:
https://playbook.ohaisoft.com

DNS sagt:
playbook.ohaisoft.com → 46.225.28.194

Nginx erkennt:
server_name playbook.ohaisoft.com

Nginx leitet weiter:
proxy_pass http://127.0.0.1:8100

Docker-Container antwortet:
developer-playbook-docs

Browser zeigt:
Developer Playbook

Aktueller Stand im Praxisbeispiel¶

Dienst	Öffentliche URL	Lokaler Port	Container
Developer Playbook	`https://playbook.ohaisoft.com`	`127.0.0.1:8100`	`developer-playbook-docs`
Immohai App	`https://immohai.ohaisoft.com`	`127.0.0.1:8200`	`immohai-web`
Immohai Dokumentation	`https://docs.immohai.ohaisoft.com`	`127.0.0.1:8201`	`immohai-docs`

Welche Datei erklärt was?¶

Datei	Thema
`01-domain-und-dns.md`	Domain kaufen, Subdomains anlegen, DNS prüfen
`02-port-strategie.md`	lokale Docker-Ports und Portbereiche
`03-nginx-reverse-proxy.md`	Nginx installieren und Domains an lokale Dienste weiterleiten
`04-https-mit-certbot.md`	HTTPS-Zertifikate mit Certbot einrichten
`05-app-und-doku-veroeffentlichen.md`	vollständiger Prüfablauf für App und Dokumentation
`06-veroeffentlichung-checkliste.md`	wiederverwendbare Abschlusscheckliste

Reihenfolge für die Veröffentlichung¶

1. Domain festlegen
2. DNS-Einträge setzen
3. DNS prüfen
4. Docker-Ports lokal binden
5. Container lokal testen
6. Nginx Reverse Proxy einrichten
7. HTTP öffentlich testen
8. Certbot ausführen
9. HTTPS testen
10. automatische Zertifikatserneuerung testen
11. Browser-Test durchführen
12. Dokumentation aktualisieren

Häufige Missverständnisse¶

Ist DNS das gleiche wie Nginx?¶

Nein.

DNS sagt nur:

Welche IP-Adresse gehört zu dieser Domain?

Nginx sagt:

Welcher lokale Dienst gehört zu dieser Domain?

Ist HTTPS das gleiche wie Certbot?¶

Nein.

HTTPS ist die verschlüsselte Verbindung.

Certbot ist das Werkzeug, das die dafür nötigen Zertifikate erstellt und erneuert.

Ist Nginx die App?¶

Nein.

Nginx ist nur der Vermittler.

Die eigentliche App läuft im Docker-Container.

Ist Docker öffentlich erreichbar?¶

In diesem Setup nicht direkt.

Docker läuft lokal auf dem Server.

Öffentlich erreichbar ist Nginx.

Warum braucht jede Subdomain eine Nginx-Konfiguration?¶

Weil Nginx wissen muss, wohin es die Anfrage weiterleiten soll.

Beispiel:

playbook.ohaisoft.com       → 127.0.0.1:8100
immohai.ohaisoft.com        → 127.0.0.1:8200
docs.immohai.ohaisoft.com   → 127.0.0.1:8201

Warum muss Certbot nach Nginx kommen?¶

Certbot mit Nginx-Plugin liest und verändert die Nginx-Konfiguration.

Deshalb muss Nginx vorher grundsätzlich funktionieren.

Die typische Reihenfolge ist:

DNS prüfen
↓
Nginx HTTP einrichten
↓
HTTP testen
↓
Certbot ausführen
↓
HTTPS testen

Merksatz¶

Domain und DNS bringen die Anfrage zum Server.

Nginx verteilt die Anfrage auf dem Server an den richtigen lokalen Dienst.

Docker betreibt die App oder Dokumentation.

Certbot sorgt dafür, dass die Verbindung über HTTPS sicher ist.