FAQ zur Zusammenarbeit von ServBay und Docker

Wenn Sie ServBay für die lokale Webentwicklung nutzen, möchten Sie möglicherweise Docker für containerisierte Umgebungen einsetzen. Dieses FAQ beantwortet häufig auftretende Fragen zur gemeinsamen Nutzung von ServBay und Docker unter macOS und Windows. Es behandelt, wie Sie aus Docker auf ServBay-Dienste zugreifen und ServBay als Reverse Proxy für Anwendungen im Docker-Container nutzen.

Q1: Warum verändert ServBay meine `hosts`-Datei im System? Kann ich das verhindern?

ServBay trägt Einträge in Ihre System-hosts-Datei ein (z.B. mysite.servbay.demo 127.0.0.1), sodass Sie lokale Websites unter individuellen Hostnamen wie mysite.servbay.demo aufrufen können. Diese Websites laufen tatsächlich auf Ihrer lokalen Adresse 127.0.0.1.

Da Docker die hosts-Datei Ihres Betriebssystems (macOS oder Windows) ausliest, wird mysite.servbay.demo auf 127.0.0.1 aufgelöst und Docker versucht, auf seinen eigenen Container zuzugreifen, anstatt auf die ServBay-Websites.

Grundprinzip:

Wenn Sie in ServBay eine neue Website mit einem Domainnamen (wie example.servbay.demo) anlegen, wird die Domain automatisch auf 127.0.0.1 gesetzt.
Dies ist die übliche Methode, um lokale Domains erreichbar zu machen. Ohne Änderungen an der hosts-Datei können Sie nur über http://127.0.0.1:PORT zugreifen – nicht über den gewählten Hostnamen.

Kann man das verhindern?

Im Prinzip können Sie die von ServBay gesetzten Einträge manuell entfernen, dadurch ist Ihr lokales Angebot aber nur noch unter der IP erreichbar und nicht über Domains. Das würde den Zweck von ServBay – die komfortable lokale Entwicklung – untergraben. Wenn Sie nicht möchten, dass ServBay bestimmte Domain-Einträge verwaltet, legen Sie diese Websites am besten gar nicht erst in ServBay an.

Für die meisten Entwicklungsszenarien ist die automatische Verwaltung der hosts-Datei durch ServBay ausdrücklich gewünscht und macht die Arbeit deutlich leichter.

Q2: Wie kann mein Docker-Container per Domain korrekt auf Websites auf meinem Host zugreifen, die von ServBay verwaltet werden (z.B. `mysite.servbay.demo`)?

Dies ist ein typischer Anwendungsfall, der korrekt konfiguriert werden muss. Wenn ServBay eine Website wie mysite.servbay.demo auf Ihrem macOS- oder Windows-Host bereitstellt (aufgelöst nach 127.0.0.1), verweist 127.0.0.1 im Docker-Container aber auf den Container selbst — nicht auf Ihr lokales System.

Falscher Ansatz: Einfach den Hostnamen host.docker.internal als URL im Container verwenden

Sowohl Docker Desktop für Mac als auch Windows stellen das spezielle DNS host.docker.internal bereit, um den Host aus dem Container zu erreichen. Es wird jedoch dringend abgeraten, dies in der URL zu verwenden, um ServBay-Websites zu erreichen (z.B. durch Aufruf von http://host.docker.internal/ in der Erwartung, dass dies auf mysite.servbay.demo verweist).

Denn dann lautet im HTTP-Request das Host-Header host.docker.internal. ServBay-Webserver (wie Caddy oder Nginx) nutzen dieses Header für die Zuordnung zum korrekten Ziel. Ist der Wert aber host.docker.internal statt mysite.servbay.demo, kann keine korrekte Zuordnung erfolgen und im Fall von HTTPS entstehen SNI-Fehler (Server Name Indication), weil das SSL-Zertifikat für mysite.servbay.demo und nicht für host.docker.internal ausgestellt ist.

Richtiges Vorgehen: Domain im Container per extra_hosts hinzufügen

Damit Applikationen im Container die originale Domain (z.B. mysite.servbay.demo) und das korrekte Host-Header nutzen, sollten Sie der /etc/hosts-Datei des Containers einen Eintrag hinzufügen, der die Domain auf die IP des Hosts auflöst. Das geht via extra_hosts im docker-compose.yml oder mit --add-host bei docker run – und als Adresse nutzen Sie entweder host.docker.internal oder besser host-gateway.

Mit docker run:
bash
```
docker run --add-host=mysite.servbay.demo:host-gateway ... your_image
```
1
(host-gateway ist ein Docker-spezifischer Platzhalter, der zur internen Host-IP aufgelöst wird. Ab Docker Version 20.10+ wird es typischerweise als tieferer Alias für host.docker.internal verwendet.)

Mit docker-compose.yml:

yaml

version: '3.8' # oder höher
services:
  myapp:
    image: your_image
    extra_hosts:
      - "mysite.servbay.demo:host-gateway" # alternativ "mysite.servbay.demo:host.docker.internal"
    # ... weitere Konfiguration

Nach der Konfiguration gilt:

Der Container löst http://mysite.servbay.demo oder https://mysite.servbay.demo via /etc/hosts korrekt zur Host-IP auf.
Die Anfrage wird an den ServBay-Webserver auf dem Host weitergeleitet.
Das HTTP-Header Host enthält den korrekten Wert mysite.servbay.demo, wodurch ServBay Websites richtig zuordnet und das richtige SSL-Zertifikat liefert (bei HTTPS).

Q3: Wie kann mein Docker-Container auf Datenbanken (wie MySQL oder PostgreSQL) oder andere Nicht-HTTP-Services zugreifen, die von ServBay bereitgestellt werden?

Anders als bei webbasiertem Zugriff wird hier keine Domain benötigt und SNI ist irrelevant. Für Datenbanken oder andere TCP-Dienste ist die Verwendung von host.docker.internal als Servername empfohlen und funktioniert zuverlässig.

Vorgehen:

Stellen Sie sicher, dass das gewünschte Datenbankpaket (oder ein anderer Dienst) in ServBay läuft und für lokale Zugriffe konfiguriert ist (Standardkonfiguration genügt meist für lokale Entwicklung).
Im Docker-Container konfigurieren Sie die Verbindung zu:
- Hostname/Server: host.docker.internal
- Port: Der in ServBay konfigurierte Port (z.B. für MySQL 3306, für PostgreSQL 5432)
- Benutzer/Passwort: Die von Ihnen in ServBay hinterlegten Zugangsdaten

Beispiel (MySQL-Verbindung): Wenn ServBay MySQL auf Port 3306 bereitstellt, sieht die Verbindung im Container so aus:

Host: host.docker.internal
Port: 3306
Benutzer: your_db_user
Passwort: your_db_password

Q4: Wie vertraut mein Docker-Container den von ServBay User CA ausgestellten SSL-Zertifikaten beim Zugriff auf HTTPS-Websites (über Domain und `extra_hosts`)?

Sie haben, wie unter Q2 empfohlen, die Domain (z.B. secure.servbay.demo) im Container per extra_hosts/--add-host eingerichtet. Falls diese Website ein ServBay User CA-Zertifikat nutzt, vertraut Ihr Container diesem CA standardmäßig nicht – und SSL-Handshake schlägt fehl.

Pfad zu ServBay CA-Datei:

ServBay User CA Root-Zertifikat:
- macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
- Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt
PEM mit ServBay User CA, Public CA und Mozilla Roots:
- macOS (ARM): /Applications/ServBay/package/common/openssl/3.2/cacert.pem
- macOS (Intel): /Applications/ServBay/package/common/openssl/1.1.1u/cacert.pem
- Windows: C:\ServBay\package\common\openssl\3.3\cacert.pem

Lösungsansätze:

Es gibt verschiedene Möglichkeiten, damit Ihr Container dem ServBay User CA-Zertifikat vertraut:

Variante 1: Systemweiter Vertrauenseintrag beim Build (Dockerfile) – Geeignet, wenn ein eigenes Image gebaut und CA global benötigt wird.
Variante 2: Anwendungsbasiertes Trust beim Start (Mount & Umgebungsvariable) – Praktisch, wenn nur eine App dem Zertifikat vertrauen soll und Sie das Basissystem nicht ändern wollen.
Variante 3: Systemweiter Trust beim Start (Mount & angepasster Startbefehl im Container) – Wenn Sie keine Images bauen und trotzdem systemweiten Trust benötigen.

Variante 1: Buildzeit-Systemtrust (Dockerfile)

Der CA Trust wird beim Image-Build direkt im lokalen Zertifikatespeicher des Containers registriert.

CA-Datei vorbereiten: Kopieren Sie die ServBay User CA Root-Datei in Ihr Buildverzeichnis (z.B. neben das Dockerfile):
- macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
- Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt

Dockerfile für Debian/Ubuntu:

dockerfile

# Dockerfile
FROM ubuntu:latest
COPY ServBay-Private-CA-ECC-Root.crt /usr/local/share/ca-certificates/ServBay-User-CA.crt
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && \
    update-ca-certificates && \
    rm -rf /var/lib/apt/lists/*

Dockerfile für Alpine:

dockerfile

# Dockerfile
FROM alpine:latest
COPY ServBay-Private-CA-ECC-Root.crt /usr/local/share/ca-certificates/ServBay-User-CA.crt
RUN apk add --no-cache ca-certificates && update-ca-certificates

docker-compose Build-Beispiel:

yaml

# docker-compose.yml
version: '3.8'
services:
  myapp:
    build:
      context: ./app_service # Verzeichnis mit Dockerfile und CA-Datei
      dockerfile: Dockerfile
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Variante 2: Trust für einzelne Anwendungen zur Laufzeit (Volume Mount & ENV)

Die CA-Datei wird ins Image gemountet; die Anwendung erhält den Trust über eine Umgebungsvariable.

docker-compose Beispiel:

yaml

version: '3.8'
services:
  myapp:
    image: some-base-image
    volumes:
      # Beispiel macOS-Path
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
      # Beispiel Windows-Path (ggf. anpassen)
      # - C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
    environment:
      # Beispiel für Node.js:
      - NODE_EXTRA_CA_CERTS=/etc/ssl/certs/MyCustomCA.crt
      # Beispiel für Python (requests):
      # - REQUESTS_CA_BUNDLE=/etc/ssl/certs/MyCustomCA.crt
      # Beispiel für generische SSL_CERT_FILE:
      # - SSL_CERT_FILE=/etc/ssl/certs/MyCustomCA.crt
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Die genaue Umgebungsvariable hängt von der jeweiligen Anwendung ab.

Variante 3: Systemweiter Trust zur Laufzeit (Volume Mount & custom Start-Command)

Hier wird die CA-Datei in das Container-System gemountet und ein Startbefehl ausgeführt, der den Trust im Container aktiviert. Ein Image-Build ist nicht nötig, allerdings ist der Startbefehl komplexer.

docker-compose Beispiel (Debian/Ubuntu-Basis):

yaml

version: '3.8'
services:
  myapp:
    image: ubuntu:latest # oder ein anderes Image mit update-ca-certificates
    volumes:
      # CA-Datei ins Systemverzeichnis mounten
      # macOS Beispiel-Pfad
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/usr/local/share/ca-certificates/ServBay-User-CA.crt:ro
      # Windows Beispiel-Pfad (ggf. anpassen)
      # - C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt:/usr/local/share/ca-certificates/ServBay-User-CA.crt:ro
    # Command überschreiben, um bei Start Trust zu setzen und App zu starten
    # root oder passende Rechte für update-ca-certificates erforderlich!
    command: >
      sh -c "
        echo 'Attempting to update CA certificates...' &&
        if command -v update-ca-certificates > /dev/null; then
          if [ ! -f /usr/bin/update-ca-certificates ]; then apt-get update && apt-get install -y --no-install-recommends ca-certificates; fi &&
          update-ca-certificates &&
          echo 'CA certificates updated.'
        else
          echo 'update-ca-certificates command not found, skipping CA update.'
        fi &&
        echo 'Starting application...' &&
        exec your_original_application_command_here # Ersetzen mit dem App-Startbefehl
      "
    extra_hosts: ["secure.servbay.demo:host-gateway"]
    # Falls root-Rechte für das Command nötig sind, eventuell user: root setzen oder Zulassung per entrypoint.

Hinweise:

Komplexität: Das Command/Entrypoint muss ggf. angepasst werden, falls komplexe Logik im Image vorhanden ist.
Rechte: update-ca-certificates benötigt in der Regel root-Rechte.
Abhängigkeiten: Das Image braucht das Paket ca-certificates und das Kommando update-ca-certificates (bei Bedarf installiert das Skript dies automatisch).
Startzeit: Der Zertifikat-Update-Prozess verlängert den Start.
Alpine Linux: Hier genügt: apk add --no-cache ca-certificates && update-ca-certificates.

Welche Methode wählen?

Wenn Sie ein custom Image bauen und CA systemweit benötigen: Variante 1 ist die beste Wahl.
Wenn Sie das Image nicht ändern und nur einzelne Apps vertrauen sollen, ist Variante 2 komfortabel.
Wenn Sie kein Image bauen wollen und systemweiten Trust wünschen, ist Variante 3 das Mittel der Wahl.

Für Zertifikate von öffentlichen CAs (z.B. Let's Encrypt): Wenn Ihr ServBay-Website-Zertifikat von einer öffentlichen CA (über ACME, z.B. Let's Encrypt) stammt, sind diese in Grund-Images meist schon vertraut – hier muss nichts weiter getan werden.

Q5: Wie kann ich ServBay nutzen, um einer Anwendung im Docker-Container eine Domain zuzuweisen und als Reverse Proxy zu fungieren?

Angenommen, Sie betreiben im Container eine Applikation (z.B. einen Node.js-Service auf Port 3000). Sie möchten ihm eine eigene Domain (z.B. myapp.servbay.demo) zuweisen und via ServBay von außen (z.B. aus dem lokalen Browser) zugreifen – mit ServBay als SSL-Proxy.

Schrittfolge:

Container starten und Port auf 127.0.0.1 am Host mappen: Das Container-Service sollte den App-Port lokal am Host binden (auf 127.0.0.1) – so bleibt er nur lokal erreichbar, kein Zugang aus dem Netzwerk.
bash
```
# Beispiel: Container-App läuft auf Port 3000, Host-Mapping auf 127.0.0.1:3001
docker run -d -p 127.0.0.1:3001:3000 your-docker-app-image
```
1
2
Nun ist die App im Container via http://127.0.0.1:3001 am Host erreichbar.
In ServBay neuen Website-Eintrag als Reverse Proxy anlegen:
- ServBay-Admin öffnen.
- „Website hinzufügen“ wählen.
- Domain: Beispielsweise myapp.servbay.demo.
- Website-Typ: Wählen Sie im Dropdown „Reverse Proxy“.
- IP-Adresse: Rechts ins Feld 127.0.0.1 eingeben.
- Port: Den bei Schritt 1 gemappten Port, also z.B. 3001.
- Speichern/Übernehmen.
(Optional) SSL aktivieren: Nach der Einrichtung kann SSL für die Website aktiviert werden. ServBay bezieht automatisch ein Zertifikat von z.B. Let's Encrypt (ACME) oder Sie wählen ein ServBay CA (User/Public CA). ServBay kümmert sich um SSL-Terminierung; die Verbindung zum Docker-Container bleibt typischerweise unverschlüsselt (http://127.0.0.1:3001).
Testen: Nach dem Speichern ist die Website über http://myapp.servbay.demo bzw. https://myapp.servbay.demo (bei SSL) erreichbar. ServBay leitet die Anfrage als Reverse Proxy in den Container weiter.

Ablauf: Browser des Nutzers -> https://myapp.servbay.demo -> ServBay (SSL, Proxyregel) -> http://127.0.0.1:3001 (lokaler Host-Port) -> App im Docker-Container.

Zusammenfassung

ServBay vereinfacht die lokale Webentwicklung unter macOS und Windows erheblich. Bei Kombination mit Docker beachten Sie:

Für den Zugriff auf ServBay-Websites aus Docker: Domain per extra_hosts oder --add-host auf host-gateway mappen, damit das Header korrekt ist und SNI vermieden wird.
Für den Zugriff auf ServBay-Datenbanken oder andere TCP-Services: Als Host einfach host.docker.internal verwenden – das funktioniert problemlos.
Falls Ihr Container ServBay User CA signierte SSL-Zertifikate akzeptieren soll: CA ins Image kopieren und Trust aktualisieren.
Um ServBay als Reverse Proxy für Container-Anwendungen zu nutzen: In ServBay Website-Typ „Reverse Proxy“ wählen und auf den gemappten Host-Port verweisen.

Achten Sie stets darauf, dass alle benötigten ServBay-Pakete (Webserver, Datenbanken etc.) und Ihre Docker-Container korrekt konfiguriert und gestartet sind.

FAQ zur Zusammenarbeit von ServBay und Docker ​

Q1: Warum verändert ServBay meine hosts-Datei im System? Kann ich das verhindern? ​

Q2: Wie kann mein Docker-Container per Domain korrekt auf Websites auf meinem Host zugreifen, die von ServBay verwaltet werden (z.B. mysite.servbay.demo)? ​

Q3: Wie kann mein Docker-Container auf Datenbanken (wie MySQL oder PostgreSQL) oder andere Nicht-HTTP-Services zugreifen, die von ServBay bereitgestellt werden? ​

Q4: Wie vertraut mein Docker-Container den von ServBay User CA ausgestellten SSL-Zertifikaten beim Zugriff auf HTTPS-Websites (über Domain und extra_hosts)? ​

Variante 1: Buildzeit-Systemtrust (Dockerfile) ​

Variante 2: Trust für einzelne Anwendungen zur Laufzeit (Volume Mount & ENV) ​

Variante 3: Systemweiter Trust zur Laufzeit (Volume Mount & custom Start-Command) ​

Q5: Wie kann ich ServBay nutzen, um einer Anwendung im Docker-Container eine Domain zuzuweisen und als Reverse Proxy zu fungieren? ​

Zusammenfassung ​

FAQ zur Zusammenarbeit von ServBay und Docker

Q1: Warum verändert ServBay meine `hosts`-Datei im System? Kann ich das verhindern?

Q2: Wie kann mein Docker-Container per Domain korrekt auf Websites auf meinem Host zugreifen, die von ServBay verwaltet werden (z.B. `mysite.servbay.demo`)?

Q3: Wie kann mein Docker-Container auf Datenbanken (wie MySQL oder PostgreSQL) oder andere Nicht-HTTP-Services zugreifen, die von ServBay bereitgestellt werden?

Q4: Wie vertraut mein Docker-Container den von ServBay User CA ausgestellten SSL-Zertifikaten beim Zugriff auf HTTPS-Websites (über Domain und `extra_hosts`)?

Variante 1: Buildzeit-Systemtrust (Dockerfile)

Variante 2: Trust für einzelne Anwendungen zur Laufzeit (Volume Mount & ENV)

Variante 3: Systemweiter Trust zur Laufzeit (Volume Mount & custom Start-Command)

Q5: Wie kann ich ServBay nutzen, um einer Anwendung im Docker-Container eine Domain zuzuweisen und als Reverse Proxy zu fungieren?

Zusammenfassung