Veelgestelde Vragen: Samenwerking tussen ServBay en Docker (FAQ)

Wanneer je ServBay gebruikt voor lokale webontwikkeling, is het vaak wenselijk dit te combineren met Docker voor een containergebaseerde omgeving. Deze FAQ beantwoordt de meest voorkomende vragen over de samenwerking tussen ServBay en Docker op macOS en Windows, waaronder toegang tot ServBay-services vanuit Docker en het gebruik van ServBay als reverse proxy voor applicaties in Docker-containers.

Q1: Waarom wijzigt ServBay het `hosts`-bestand van mijn systeem? Kan ik dit verhinderen?

ServBay voegt automatisch regels toe aan het hosts-bestand van je systeem (zoals mysite.servbay.demo 127.0.0.1), waardoor je lokale websites kunt openen via een eigen domeinnaam (zoals mysite.servbay.demo). In werkelijkheid draait deze site op het lokale adres 127.0.0.1 van je computer.

Door Docker’s werking worden hosts-bestanden vanaf het hoofdsysteem (macOS of Windows) gelezen binnen containers, waardoor mysite.servbay.demo naar 127.0.0.1 verwijst en Docker pogingen doet om het verkeerde (het eigen container-)service te benaderen.

Belangrijkste mechanisme:

Wanneer je een nieuwe website aanmaakt in ServBay en een domeinnaam opgeeft (zoals example.servbay.demo), verwijst ServBay deze automatisch naar 127.0.0.1.
Dit is standaard voor prettige lokale domeinnaamtoegang. Zonder aanpassing van het hosts-bestand kun je sites enkel bereiken via een adres als http://127.0.0.1:PORT, en niet via een eigen domein.

Kan ik dit voorkomen?

In theorie kun je handmatig de door ServBay toegevoegde regels verwijderen, maar dan kun je je lokale website niet meer onder de gekozen domeinnaam bereiken. Dit ondermijnt het gebruiksgemak dat ServBay wil bieden. Het beheren van lokale domeinen via het hosts-bestand is namelijk een van de kernfuncties van ServBay. Wil je niet dat ServBay een specifiek domein in het hosts-bestand zet, maak dan voor die naam geen site aan in ServBay.

Voor de meeste lokale ontwikkelscenario’s is het automatisch beheer van het hosts-bestand juist wenselijk en vereenvoudigt het de workflow.

Q2: Hoe kan mijn Docker-container via een domeinnaam een door ServBay beheerde website op de host bereiken (zoals `mysite.servbay.demo`)?

Dit is een vaak voorkomende vraag, die aandacht vereist voor correcte configuratie. Wanneer ServBay een website host met domeinnaam (zoals mysite.servbay.demo), wordt deze op de host naar 127.0.0.1 verwezen. Binnen een Docker-container verwijst 127.0.0.1 echter naar de container zelf, niet naar de host.

Verkeerde aanpak: direct host.docker.internal als hostnaam gebruiken in je URL naar ServBay

Hoewel Docker Desktop voor Mac (en Windows) het speciale DNS-adres host.docker.internal biedt om vanuit een container de host-IP te vinden, Wordt sterk afgeraden dit direct als URL-hostnaam te gebruiken bij het benaderen van ServBay-sites (zoals http://host.docker.internal/ en verwachten dat je zo mysite.servbay.demo bereikt).

Dit komt omdat de HTTP-aanvraag dan het Host-header veld waarde host.docker.internal krijgt. ServBay’s webserver (zoals Caddy of Nginx) bepaalt met deze Host header over welke site je hem benadert. Als die header host.docker.internal is en niet mysite.servbay.demo, kan de server het verzoek niet correct routeren naar je site, of in het geval van HTTPS zelfs een SNI (Server Name Indication) fout veroorzaken omdat het SSL-certificaat alleen geldig is voor mysite.servbay.demo, niet voor host.docker.internal.

Correcte oplossing: Voeg extra_hosts toe bij het starten van je container

Om ervoor te zorgen dat je applicatie binnen de container de originele domeinnaam (zoals mysite.servbay.demo) gebruikt en de juiste Host header meestuurt, moet je in /etc/hosts van de container een regel toevoegen, die de domeinnaam naar het hostsysteem verwijst — met extra_hosts (in docker-compose.yml) of --add-host (via docker run), naar host.docker.internal of beter nog host-gateway.

Met docker run:
bash
```
docker run --add-host=mysite.servbay.demo:host-gateway ... your_image
```
1
(host-gateway is een speciale waarde die Docker vervangt voor het interne adres van de host; dit is vanaf Docker 20.10+ een diepere alias voor host.docker.internal).

Met docker-compose.yml:

yaml

version: '3.8' # of nieuwer
services:
  myapp:
    image: your_image
    extra_hosts:
      - "mysite.servbay.demo:host-gateway" # of "mysite.servbay.demo:host.docker.internal"
    # ... overige configuratie

Na configuratie geldt binnen de container:

Wanneer je applicatie nu http://mysite.servbay.demo of https://mysite.servbay.demo benadert, zal /etc/hosts deze naar het IP-adres van je macOS-host omleiden.
Het verzoek bereikt de ServBay-webserver op je host.
De HTTP Host header heeft de juiste waarde (mysite.servbay.demo), waardoor ServBay correct routert en het juiste SSL-certificaat aanbiedt (indien HTTPS).

Q3: Hoe verbindt mijn Docker-container met door ServBay beheerde databases (zoals MySQL, PostgreSQL) of andere niet-HTTP diensten?

Bij het verbinden met databases en andere TCP-diensten die niet afhankelijk zijn van domeinnamen/SNI, is het gebruik van host.docker.internal als hostnaam aanbevolen en werkt prima.

Stappen:

Zorg dat het betreffende ServBay-databasepakket (of andere dienst) actief is en op de host openstaat voor verbindingen (standaard staan ze dit lokaal meestal toe).
Stel in je Docker-container bij databaseverbinding (of dienst):
- Hostnaam (Hostname/Server): Gebruik host.docker.internal.
- Poort (Port): Gebruik de poort die ServBay voor jouw databasepakket heeft geconfigureerd (bv. MySQL standaard 3306, PostgreSQL standaard 5432).
- Gebruikersnaam/Wachtwoord: Wat je in ServBay voor de database hebt ingesteld.

Voorbeeld (verbinden met ServBay beheerde MySQL): Stel MySQL draait op ServBay’s standaardpoort 3306. Je configuratie/connection string binnen de container is dan:

Host: host.docker.internal
Poort: 3306
User: your_db_user
Pass: your_db_password

Q4: Hoe kan mijn Docker-container CA-certificaten van ServBay User CA vertrouwen bij HTTPS-toegang middels domeinnaam (via `extra_hosts`)?

Stel je hebt zoals bij Q2 extra_hosts of --add-host gebruikt om secure.servbay.demo naar host-gateway te verwijzen. Indien deze site een SSL-certificaat van ServBay User CA gebruikt, vertrouwt een Docker-container deze CA standaard niet, wat aanleiding geeft tot SSL-handshake fouten.

ServBay CA-bestandspad:

ServBay User CA rootcertificaat:
- macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
- Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt
PEM-bestand met ServBay User CA + Public CA + 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

Op te lossen op één van de volgende manieren:

Methode 1: Vertrouwd maken op systeemniveau bij builden (via Dockerfile) — Aanbevolen als je image aanpasbaar is en universeel CA-vertrouwen vereist.
Methode 2: Vertrouwd maken op applicatieniveau bij runtime (via volumes en env-var) — Voor specifieke app-vertrouwen of als je image niet wilt wijzigen.
Methode 3: Vertrouwd maken op systeemniveau bij runtime (via volumes en custom startcommand) — Handig als je geen custom image wilt bouwen en wel systeembreed CA-vertrouwen wilt.

Methode 1: Vertrouwd maken bij builden (Dockerfile)

Je voegt het CA-certificaat toe aan de vertrouwensdatabase tijdens het bouwen van je image.

Zorg dat je het CA-bestand hebt: Kopieer ServBay User CA’s rootcertificaat naar de build-directory (naast je Dockerfile):
- macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
- Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt

Dockerfile-voorbeeld (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-voorbeeld (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:

yaml

# docker-compose.yml
version: '3.8'
services:
  myapp:
    build:
      context: ./app_service # Directory bevat Dockerfile + ServBay-Private-CA-ECC-Root.crt
      dockerfile: Dockerfile
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Methode 2: Vertrouwd maken op applicatieniveau (volume + env-var)

Je mount het certificaat in de container en configureert de app om het te gebruiken via een env-var.

docker-compose.yml voorbeeld:

yaml

version: '3.8'
services:
  myapp:
    image: some-base-image
    volumes:
      # Voorbeeld pad op macOS
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
      # Voorbeeld pad op Windows (pas naar OS aan)
      # - C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
    environment:
      # Voorbeeld voor Node.js:
      - NODE_EXTRA_CA_CERTS=/etc/ssl/certs/MyCustomCA.crt
      # Voor Python (requests):
      # - REQUESTS_CA_BUNDLE=/etc/ssl/certs/MyCustomCA.crt
      # Algemeen:
      # - SSL_CERT_FILE=/etc/ssl/certs/MyCustomCA.crt
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Raadpleeg de documentatie van je app voor de juiste omgevingsvariabelen.

Methode 3: Vertrouwd maken op systeemniveau bij runtime (volume + custom startcommand)

Je combineert een volumemount met een aangepaste startcommand die bij het opstarten de CA-database updatet. Hiermee hoef je geen custom image te bouwen, maar dit maakt je startprocedure wel wat ingewikkelder.

docker-compose.yml-voorbeeld (Debian/Ubuntu-image):

yaml

version: '3.8'
services:
  myapp:
    image: ubuntu:latest # Of andere image met update-ca-certificates
    volumes:
      # Mount direct op de locatie waar trusted CA's verwacht worden
      # Voorbeeld macOS-path
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/usr/local/share/ca-certificates/ServBay-User-CA.crt:ro
      # Voorbeeld Windows-path (naar OS aanpassen)
      # - C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt:/usr/local/share/ca-certificates/ServBay-User-CA.crt:ro
    # Vervang command om bij start CA's bij te werken en daarna app te starten
    # Let op: meestal heb je root nodig voor update-ca-certificates
    command: >
      sh -c "
        echo 'CA-certificaten worden bijgewerkt...' &&
        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-certificaten zijn bijgewerkt.'
        else
          echo 'update-ca-certificates niet gevonden, CA-update overgeslagen.'
        fi &&
        echo 'Applicatie starten...' &&
        exec your_original_application_command_here # Vervang door je eigen CMD/applicatie-startcommand
      "
    extra_hosts: ["secure.servbay.demo:host-gateway"]
    # Indien nodig, tijdelijk user op root zetten:
    # user: root # Of eigen entrypoint-script voor rechtenbeheer

Let op:

Complexiteit: Je start/entrypoint wordt geavanceerder, zeker bij complexe images.
Rechten: Vaak is root toegang nodig voor update-ca-certificates, anders kun je deze stappen niet uitvoeren.
Package-afhankelijkheid: Zorg dat de container ca-certificates en update-ca-certificates bevat; in het script wordt dit via apt-get geïnstalleerd.
Startup-tijd: Elke start voert deze stappen uit (klein beetje extra starttijd).
Alpine Linux: Gebruik daar: apk add --no-cache ca-certificates && update-ca-certificates.

Welke methode te kiezen?

Kun je bouwen en customizen? Methode 1 is dan het best.
Wil je je image niet aanpassen en enkel specifieke apps laten vertrouwen? Methode 2 is handig.
Wil je geen image bouwen en het op container-niveau doen, zonder veel installatie? Dan is Methode 3 geschikt.

Bij publieke CA-certificaten (zoals Let's Encrypt): Als je site in ServBay via ACME (zoals Let's Encrypt) een publiek certificaat ontvangt, zijn deze doorgaans out-of-the-box vertrouwd in Docker-images en zijn extra stappen niet nodig.

Q5: Hoe wijs ik een domeinnaam toe aan een Docker-applicatie en stel ik reverse proxy in via ServBay?

Stel je runt een app in een Docker-container (bijvoorbeeld een Node.js-service op poort 3000), en je wilt deze bereikbaar maken via een elegant(e) domein (zoals myapp.servbay.demo) vanaf je host-browser, waarbij ServBay het SSL-certificaatbeheer regelt.

Stappen:

Start je Docker-container en koppel de poort aan host’s 127.0.0.1: Koppel de app-poort in de container aan een poort op het host-systeem (macOS of Windows), gebonden aan 127.0.0.1 zodat deze enkel lokaal benaderbaar is en niet direct extern.
bash
```
# App draait op poort 3000 in container, gemapt naar host’s 127.0.0.1:3001
docker run -d -p 127.0.0.1:3001:3000 your-docker-app-image
```
1
2
In dit voorbeeld is je app nu via http://127.0.0.1:3001 op je host beschikbaar.
Voeg een site toe in ServBay en stel reverse proxy in:
- Open de ServBay-beheersinterface.
- Klik op “Website toevoegen”.
- Domeinnaam: Voer hier het gewenste domein in (zoals myapp.servbay.demo).
- Website type: Kies “Reverse Proxy”.
- IP-adres: Vul 127.0.0.1 in.
- Poort: Vul de host-poort uit stap 1 in, bijvoorbeeld 3001.
- Klik op “Opslaan” of “Toevoegen”.
(Optioneel) Stel SSL in: Na het toevoegen kun je in de site-instellingen SSL inschakelen. ServBay ondersteunt ACME-gebaseerde certificaten (zoals Let's Encrypt), of ServBay User/Publieke CA. ServBay regelt SSL-terminatie, en het verkeer naar je Docker-app blijft gewoon HTTP (http://127.0.0.1:3001) vanuit ServBay.
Test je toegang: Nu kun je via je browser naar http://myapp.servbay.demo of https://myapp.servbay.demo (met SSL) gaan. ServBay proxy't het verkeer door naar je Docker-applicatie.

Verbindingsstroom: Browser gebruiker -> https://myapp.servbay.demo -> ServBay (SSL termination, reverse proxy lookup) -> http://127.0.0.1:3001 (hostpoort) -> app binnen Docker-container.

Samenvatting

ServBay vereenvoudigt lokale webontwikkeling op macOS en Windows aanzienlijk. In samenwerking met Docker:

Wil je een ServBay-hosted website vanuit Docker bespreken, gebruik dan extra_hosts of --add-host om de domeinnaam naar host-gateway te koppelen; zo komt je Host header juist door en voorkom je SNI-problemen.
Wil je een ServBay-hosted database of niet-HTTP service benaderen vanuit Docker, gebruik dan het hostadres host.docker.internal.
Wil je ServBay User CA-certificaten vertrouwen in de Docker-container, voeg het CA-certificaat toe aan je image of mount het en update het vertrouwde CA-bestand.
Wil je ServBay als reverse proxy inzetten voor je Docker-applicatie, voeg in ServBay een site toe van type “Reverse Proxy” die verwijst naar een hostpoort op 127.0.0.1.

Controleer altijd dat zowel de benodigde ServBay software (webserver, database, etc.) als je Docker-container correct zijn ingesteld en actief zijn.

Veelgestelde Vragen: Samenwerking tussen ServBay en Docker (FAQ) ​

Q1: Waarom wijzigt ServBay het hosts-bestand van mijn systeem? Kan ik dit verhinderen? ​

Q2: Hoe kan mijn Docker-container via een domeinnaam een door ServBay beheerde website op de host bereiken (zoals mysite.servbay.demo)? ​

Q3: Hoe verbindt mijn Docker-container met door ServBay beheerde databases (zoals MySQL, PostgreSQL) of andere niet-HTTP diensten? ​

Q4: Hoe kan mijn Docker-container CA-certificaten van ServBay User CA vertrouwen bij HTTPS-toegang middels domeinnaam (via extra_hosts)? ​

Methode 1: Vertrouwd maken bij builden (Dockerfile) ​

Methode 2: Vertrouwd maken op applicatieniveau (volume + env-var) ​

Methode 3: Vertrouwd maken op systeemniveau bij runtime (volume + custom startcommand) ​

Q5: Hoe wijs ik een domeinnaam toe aan een Docker-applicatie en stel ik reverse proxy in via ServBay? ​

Samenvatting ​

Veelgestelde Vragen: Samenwerking tussen ServBay en Docker (FAQ)

Q1: Waarom wijzigt ServBay het `hosts`-bestand van mijn systeem? Kan ik dit verhinderen?

Q2: Hoe kan mijn Docker-container via een domeinnaam een door ServBay beheerde website op de host bereiken (zoals `mysite.servbay.demo`)?

Q3: Hoe verbindt mijn Docker-container met door ServBay beheerde databases (zoals MySQL, PostgreSQL) of andere niet-HTTP diensten?

Q4: Hoe kan mijn Docker-container CA-certificaten van ServBay User CA vertrouwen bij HTTPS-toegang middels domeinnaam (via `extra_hosts`)?

Methode 1: Vertrouwd maken bij builden (Dockerfile)

Methode 2: Vertrouwd maken op applicatieniveau (volume + env-var)

Methode 3: Vertrouwd maken op systeemniveau bij runtime (volume + custom startcommand)

Q5: Hoe wijs ik een domeinnaam toe aan een Docker-applicatie en stel ik reverse proxy in via ServBay?

Samenvatting