Veelgestelde Vragen (FAQ) over de Samenwerking tussen ServBay en Docker

Wanneer je ServBay gebruikt voor lokale webontwikkeling, wil je mogelijk ook een containeromgeving opzetten met Docker. Deze FAQ behandelt veel voorkomende vragen over de samenwerking tussen ServBay en Docker op macOS, inclusief toegang vanaf Docker tot ServBay-diensten en het gebruik van ServBay als reverse proxy voor toepassingen binnen Docker-containers.

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

ServBay voegt automatisch regels toe aan het hosts-bestand van je systeem (zoals mysite.servbay.demo 127.0.0.1), waardoor je lokale ontwikkelwebsites kunt benaderen via aangepaste domeinnamen (zoals mysite.servbay.demo). Deze websites draaien feitelijk op het lokale adres 127.0.0.1 van je computer.

Door de werking van Docker wordt het hosts-bestand van de macOS-host uitgelezen, waardoor mysite.servbay.demo naar 127.0.0.1 wijst—dit leidt ertoe dat Docker naar de verkeerde (namelijk zijn eigen) service verwijst.

Belangrijkste mechanisme:

Als je in ServBay een nieuwe website aanmaakt en een domeinnaam toewijst (zoals example.servbay.demo), wordt deze automatisch naar 127.0.0.1 geleid.
Dit is de standaardmethode om gebruiksvriendelijke lokale domeinnamen te realiseren. Als je het hosts-bestand niet wijzigt, kun je enkel via adressen als http://127.0.0.1:PORT toegang krijgen, zonder aangepaste domeinnamen.

Is het uit te schakelen?

In theorie kun je handmatig de regels verwijderen die ServBay toevoegt, maar dan kun je je lokale sites niet langer via de door ServBay ingestelde domeinnaam bereiken. Dit staat haaks op het gemak dat ServBay juist wil bieden voor lokale ontwikkeling. Mocht je niet willen dat ServBay bepaalde domeinnamen beheert, maak dan in ServBay geen site aan voor dat domein.

Voor de meeste lokale ontwikkelsituaties is het automatisch beheren van het hosts-bestand door ServBay gewenst; het maakt de workflow aanzienlijk eenvoudiger.

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

Dit is een veel voorkomende behoefte en vereist een zorgvuldige aanpak om problemen te vermijden. Wanneer ServBay op je Mac een website draait als mysite.servbay.demo (die op de host vertaald wordt naar 127.0.0.1), verwijst 127.0.0.1 binnen de Docker-container echter naar de container zelf, niet naar de macOS-host.

Foute aanpak: direct host.docker.internal als URL-hostnaam gebruiken

Docker Desktop voor Mac (en Windows) biedt de DNS-naam host.docker.internal zodat containers het IP-adres van de host op kunnen lossen. Het wordt echter sterk afgeraden om deze naam direct in de URL te gebruiken om ServBay-websites te bereiken (dus bijvoorbeeld http://host.docker.internal/ in plaats van mysite.servbay.demo).

Dit komt doordat het HTTP-verzoek aan ServBay’s webserver (zoals Caddy of Nginx) nu het Host-veld heeft gevuld met host.docker.internal. De webserver in ServBay baseert zich op die header om te bepalen voor welke website het verzoek bedoeld is. Als de Host-header niet mysite.servbay.demo is, maar host.docker.internal, kan de server het verzoek niet juist routeren; ook ontstaat er bij HTTPS een SNI (Server Name Indication) fout, omdat het uitgereikte SSL-certificaat is afgegeven voor mysite.servbay.demo en niet voor host.docker.internal.

De juiste oplossing: Voeg het domein toe via extra_hosts bij het starten van de Docker-container

Zorg dat je in de /etc/hosts van de container een regel toevoegt die het gewenste domein (zoals mysite.servbay.demo) laat verwijzen naar het IP-adres van je host. Dit kan via extra_hosts in je docker-compose.yml of via --add-host in docker run, waarbij het domein naar host.docker.internal of (voorkeur) host-gateway wijst.

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 door het interne IP-adres van de host; vanaf Docker 20.10+ is dit een onderliggende alias van host.docker.internal.)

Met docker-compose.yml:

yaml

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

Na deze configuratie:

Als je applicatie binnen de container http://mysite.servbay.demo of https://mysite.servbay.demo opvraagt, lost /etc/hosts dit naar het juiste host-IP op.
Het verzoek wordt doorgestuurd naar ServBay’s webserver op de Mac.
De HTTP Host-header blijft correct en ServBay kan het verkeer correct routeren en een geldig (SSL-)certificaat aanbieden.

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

Voor databaseconnecties of andere TCP-diensten die geen SNI gebruiken, is het juist aanbevolen om host.docker.internal te gebruiken als hostnaam van de dienst.

Stappen:

Zorg dat het databasepakket (of andere dienst) in ServBay draait en verbindingen van de host toestaat (standaard ingesteld voor lokale ontwikkeling).
In de Docker-container configureer je de connectiestring of instellingen als volgt:
- Hostnaam: host.docker.internal
- Poort: Gebruik de door ServBay ingestelde poort (typisch MySQL: 3306, PostgreSQL: 5432).
- Gebruikersnaam/wachtwoord: Geef de in ServBay voor deze dienst ingestelde gegevens op.

Voorbeeld (Verbinden met ServBay's MySQL): Stel MySQL op ServBay draait op poort 3306, dan wordt in de container de connectie als volgt ingesteld:

Host: host.docker.internal
Poort: 3306
Gebruiker: your_db_user
Wachtwoord: your_db_password

Q4: Hoe zorg ik ervoor dat mijn Docker-container het SSL-certificaat (ServBay User CA) vertrouwt wanneer deze via een domeinnaam (met `extra_hosts`) een HTTPS-site in ServBay benadert?

Stel je hebt, zoals uitgelegd in Q2, met extra_hosts of --add-host het domein secure.servbay.demo naar host-gateway geleid. Als deze site een ServBay User CA SSL-certificaat gebruikt, vertrouwt de Docker-container standaard dit CA niet, waardoor SSL-handshakes zullen falen.

Locatie van het ServBay CA-bestand (op de macOS-host):

ServBay User CA rootcertificaat: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
PEM-bestand met ServBay User CA en Public CA en Mozilla rootcerts:
- ARM Macs: /Applications/ServBay/package/common/openssl/3.2/cacert.pem
- Intel Macs: /Applications/ServBay/package/common/openssl/1.1.1u/cacert.pem

Globale oplossing:

Er zijn verschillende manieren om de Docker-container het ServBay User CA te laten vertrouwen:

Methode 1: Systeembrede CA-trust tijdens build (via Dockerfile) – Ideaal als je custom images bouwt die breed CA vertrouwen vereisen.
Methode 2: Applicatie-brede trust tijdens runtime (via volume en env vars) – Handig als enkel een specifieke applicatie CA moet vertrouwen of als je het image niet wilt aanpassen.
Methode 3: Systeembrede CA-trust tijdens runtime (via volume en aangepaste startcommando’s) – Geschikt als je vertrouwen wilt toevoegen zonder image aan te passen, maar het hele container-systeem CA moet vertrouwen.

Methode 1: Systeembrede CA-trust tijdens build (Dockerfile)

Voeg bij het bouwen van je Docker-image het CA-certificaat toe aan de trusted chain.

Voorbereiding: Kopieer /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt naar de build-directory van je image.

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 # map met Dockerfile en CA-certificaat
      dockerfile: Dockerfile
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Methode 2: Applicatie-brede runtime trust (volume + env vars)

Mount het CA-certificaat als volume en stel server/app-specifieke environment variables in die naar het CA-bestand verwijzen.

docker-compose.yml voorbeeld:

yaml

version: '3.8'
services:
  myapp:
    image: some-base-image
    volumes:
      - /Applications/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
      # Voorbeeld voor Python (requests):
      # - REQUESTS_CA_BUNDLE=/etc/ssl/certs/MyCustomCA.crt
      # Voorbeeld algemeen SSL_CERT_FILE:
      # - SSL_CERT_FILE=/etc/ssl/certs/MyCustomCA.crt
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Raadpleeg de documentatie van je applicatie voor de juiste variabelen.

Methode 3: Systeembrede CA-trust tijdens runtime (volume + startcommando override)

Combineer volume-mounten van het CA-bestand met een aangepaste startopdracht die bij containerstart de certificaten toevoegt aan het systeem.

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

yaml

version: '3.8'
services:
  myapp:
    image: ubuntu:latest # of ander image met update-ca-certificates
    volumes:
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/usr/local/share/ca-certificates/ServBay-User-CA.crt:ro
    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
      "
    extra_hosts: ["secure.servbay.demo:host-gateway"]
    # Indien nodig: user: root

Let op:

Complexiteit: Het aanpassen van command/entrypoint kan complex zijn bij officiële images of images met uitgebreide opstartlogica.
Rechten: update-ca-certificates vereist vaak rootrechten.
Benodigde pakketten: Zorg dat ca-certificates aanwezig is.
Opstartvertraging: Iedere containerstart invoegen kost extra tijd.
Alpine Linux: Gebruik hier apk add --no-cache ca-certificates && update-ca-certificates.

Welke methode kiezen?

Kan je een custom image bouwen en moet CA breed vertrouwd worden, kies dan Methode 1.
Hoef je alleen een specifieke app CA te laten vertrouwen of wil je je image niet aanpassen, dan is Methode 2 eenvoudig.
Wil je geen nieuwe image bouwen en is systeembrede trust nodig, gebruik dan Methode 3.

Voor publiek CA-uitgegeven certificaten (zoals Let's Encrypt): Als je site via ServBay een publiek certificaat (zoals van Let's Encrypt via ACME) gebruikt, dan vertrouwen de meeste Docker-images standaard deze CA’s — extra handelingen zijn dan niet nodig.

Q5: Hoe wijs ik een domeinnaam toe aan een applicatie in een Docker-container en laat ik ServBay als reverse proxy fungeren?

Stel je runt een app in een Docker-container (bijv. Node.js op poort 3000 in de container), en je wilt deze via ServBay aan een mooie domeinnaam koppelen (zoals myapp.servbay.demo) en bezoeken vanaf je hostbrowser, inclusief SSL-beheer door ServBay.

Stappen:

Start je Docker-container en map de poort naar de host op 127.0.0.1: Zorg dat het servicepoort van de container gemapt wordt naar een poort op de macOS-host, en bind deze aan 127.0.0.1 om externe toegang te voorkomen.
bash
```
# Voorbeeld: Container-app draait op poort 3000, gemapt naar 127.0.0.1:3001 op de host
docker run -d -p 127.0.0.1:3001:3000 your-docker-app-image
```
1
2
Het app in de container op poort 3000 is nu bereikbaar via http://127.0.0.1:3001 op de host.
Voeg een nieuwe site toe aan ServBay en stel een reverse proxy in:
- Open het ServBay-beheerinterface.
- Klik op “Website toevoegen”.
- Domeinnaam: Geeft het gewenste domein op, bijvoorbeeld myapp.servbay.demo.
- Website type: Kies “Reverse Proxy” uit het dropdownmenu.
- IP-adres: Voer 127.0.0.1 in.
- Poort: Voer het hostpoortnummer in dat je in stap 1 gebruikte, bijvoorbeeld 3001.
- Klik op “Opslaan” of “Toevoegen”.
(Optioneel) Stel SSL in: Na het toevoegen van de site kun je in de website-instellingen SSL inschakelen. ServBay ondersteunt automatische certificaat-aanvraag via ACME (Let's Encrypt e.a.), of je kunt kiezen voor ServBay User CA of ServBay Public CA. ServBay verzorgt dan het SSL-terminatiepunt; ServBay naar de container is vaak gewoon HTTP (http://127.0.0.1:3001).
Test de toegang: Na opslaan van de ServBay-configuratie kan je de website via de browser bezoeken: http://myapp.servbay.demo of https://myapp.servbay.demo (indien SSL ingesteld). ServBay proxy’t de aanvraag door naar de Docker-container.

Stroomschema: Browser gebruiker -> https://myapp.servbay.demo -> ServBay (SSL, proxy-regels) -> http://127.0.0.1:3001 (hostpoort) -> applicatie in Docker-container.

Samenvatting

ServBay vereenvoudigt lokale webontwikkeling enorm op macOS. In combinatie met Docker:

Voor toegang van Docker-containers tot door ServBay gehoste websites, gebruik extra_hosts of --add-host zodat de domeinnaam naar host-gateway wijst, waardoor de Host header correct blijft en SNI-problemen worden voorkomen.
Voor toegang tot ServBay-databases of niet-HTTP-services vanuit Docker-containers, volstaat vaak het gebruik van host.docker.internal als serverhostnaam.
Om Docker-containers het door ServBay uitgegeven User CA SSL-certificaat te laten vertrouwen, kopieer je het CA-certificaat naar het image en werk je de trusted store bij.
Om ServBay als reverse proxy voor een Docker-applicatie te gebruiken, kies in ServBay het websitestype "Reverse proxy" en wijs naar de hostpoort die naar de container is gemapt op 127.0.0.1.

Zorg er altijd voor dat relevante ServBay-pakketten (webserver, database, enz.) én je Docker-container juist geconfigureerd en actief zijn.

Veelgestelde Vragen (FAQ) over de Samenwerking tussen ServBay en Docker ​

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

Q2: Hoe kan mijn Docker-container via de domeinnaam correct toegang krijgen tot een door ServBay beheerde website op mijn macOS-host (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 zorg ik ervoor dat mijn Docker-container het SSL-certificaat (ServBay User CA) vertrouwt wanneer deze via een domeinnaam (met extra_hosts) een HTTPS-site in ServBay benadert? ​

Methode 1: Systeembrede CA-trust tijdens build (Dockerfile) ​

Methode 2: Applicatie-brede runtime trust (volume + env vars) ​

Methode 3: Systeembrede CA-trust tijdens runtime (volume + startcommando override) ​

Q5: Hoe wijs ik een domeinnaam toe aan een applicatie in een Docker-container en laat ik ServBay als reverse proxy fungeren? ​

Samenvatting ​

Veelgestelde Vragen (FAQ) over de Samenwerking tussen ServBay en Docker

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

Q2: Hoe kan mijn Docker-container via de domeinnaam correct toegang krijgen tot een door ServBay beheerde website op mijn macOS-host (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 zorg ik ervoor dat mijn Docker-container het SSL-certificaat (ServBay User CA) vertrouwt wanneer deze via een domeinnaam (met `extra_hosts`) een HTTPS-site in ServBay benadert?

Methode 1: Systeembrede CA-trust tijdens build (Dockerfile)

Methode 2: Applicatie-brede runtime trust (volume + env vars)

Methode 3: Systeembrede CA-trust tijdens runtime (volume + startcommando override)

Q5: Hoe wijs ik een domeinnaam toe aan een applicatie in een Docker-container en laat ik ServBay als reverse proxy fungeren?

Samenvatting