FAQ: Najczęstsze pytania dotyczące współpracy ServBay i Docker

Podczas lokalnego tworzenia stron WWW w ServBay możesz chcieć używać środowiska kontenerowego Docker. Ten FAQ wyjaśnia typowe zagadnienia przy równoczesnym korzystaniu z ServBay i Docker zarówno na macOS, jak i Windows, w tym dostęp do usług ServBay z Docker oraz konfigurację reverse proxy ServBay dla aplikacji w Docker.

Q1: Dlaczego ServBay modyfikuje mój systemowy plik `hosts`? Czy mogę to zablokować?

ServBay dodaje wpisy do pliku hosts (np. mysite.servbay.demo 127.0.0.1), aby umożliwić dostęp do lokalnych stron przez wybraną domenę (np. mysite.servbay.demo). Strony te są faktycznie uruchomione na adresie 127.0.0.1 na Twoim komputerze.

Jednak ze względu na mechanizm Dockera, plik hosts z systemu (macOS lub Windows) jest odczytywany także przez Docker, co sprawia, że domena mysite.servbay.demo rozwiązuje się do 127.0.0.1 – czyli wskazuje nie na komputer, ale kontener Dockera. To skutkuje błędnym dostępem do usługi.

Jak to działa:

Tworząc nową stronę w ServBay z wybraną domeną (np. example.servbay.demo), ServBay automatycznie kieruje tę domenę na adres 127.0.0.1.
Takie dodanie wpisu do pliku hosts to standardowa praktyka umożliwiająca lokalne, przyjazne domeny. Bez modyfikacji pliku hosts możesz korzystać tylko z adresu typu http://127.0.0.1:PORT, nie przez dedykowaną domenę.

Czy można to zablokować?

Teoretycznie możesz ręcznie usunąć wpisy dodane przez ServBay, ale uniemożliwi to dostęp do stron przez skonfigurowaną domenę – co jest sprzeczne z ideą wygodnego developmentu w ServBay. Automatyczne zarządzanie wpisami hosts to jedna z podstawowych funkcji ServBay, upraszczająca proces tworzenia i uruchamiania stron lokalnych. Jeśli nie chcesz, by ServBay zarządzał wpisem dla danej domeny – nie twórz dla niej strony w ServBay.

Dla większości zastosowań do developmentu lokalnego automatyczne zarządzanie plikiem hosts przez ServBay jest oczekiwane i znacznie upraszcza całość pracy.

Q2: Jak mój kontener Docker może prawidłowo uzyskać dostęp do strony ServBay na hoście, przez domenę (np. `mysite.servbay.demo`)?

To częsty problem wymagający odpowiedniej konfiguracji. Strona ServBay na Twoim komputerze (np. mysite.servbay.demo rozwiązywana do 127.0.0.1) siedzi na hoście. W kontenerze Docker, 127.0.0.1 wskazuje na wnętrze kontenera, a nie na komputer.

Błędne rozwiązanie: Użycie host.docker.internal jako hosta w adresie URL do strony w ServBay

Choć Docker Desktop dla Mac (i Windows) zapewnia specjalne DNS o nazwie host.docker.internal, który w kontenerze wskazuje na IP maszyny, nie należy używać go bezpośrednio w adresie URL do strony ServBay (np. odwiedzić http://host.docker.internal/ i oczekiwać, że to będzie mysite.servbay.demo).

Po takiej próbie, nagłówek HTTP Host jest ustawiany na host.docker.internal. Serwer WWW ServBay (np. Caddy lub Nginx) korzysta z nagłówka Host do wybierania odpowiedniej strony. Jeśli Host to host.docker.internal zamiast mysite.servbay.demo, żądanie nie zostanie właściwie obsłużone, lub – jeśli korzystasz z HTTPS – pojawi się błąd SNI (Server Name Indication), bo certyfikat SSL jest wystawiony dla mysite.servbay.demo, nie dla host.docker.internal.

Poprawne rozwiązanie: dodanie wpisu do hosts za pomocą extra_hosts

Aby aplikacje w kontenerze mogły korzystać z oryginalnej domeny ServBay (mysite.servbay.demo) i poprawnie wysyłać nagłówek Host, należy dodać wpis do pliku hosts w kontenerze, kierujący domenę na IP hosta. Najłatwiej zrobić to przez extra_hosts (w docker-compose.yml) lub --add-host (przy docker run), kierując domenę np. na host-gateway.

Używając docker run:
bash
```
docker run --add-host=mysite.servbay.demo:host-gateway ... your_image
```
1
(host-gateway to specjalna wartość – Docker zastąpi ją na właściwe wewnętrzne IP hosta. Od Docker 20.10+ jest to preferowane wobec samego host.docker.internal.)

Używając docker-compose.yml:

yaml

version: '3.8' # lub nowsza
services:
  myapp:
    image: your_image
    extra_hosts:
      - "mysite.servbay.demo:host-gateway" # lub "mysite.servbay.demo:host.docker.internal"
    # ... inne ustawienia

Po takiej konfiguracji, w kontenerze Docker:

Aplikacja odwiedzająca http://mysite.servbay.demo lub https://mysite.servbay.demo uzyska wpis w hosts rozwiązywany na IP komputera.
Zapytanie trafi do serwera WWW ServBay uruchomionego na hoście.
Nagłówek HTTP Host będzie poprawny (mysite.servbay.demo), co umożliwi ServBay poprawne przeprowadzenie routing'u oraz obsłużenie właściwego certyfikatu SSL (przy HTTPS).

Q3: Jak kontener Docker może połączyć się z bazą danych (np. MySQL, PostgreSQL) lub inną usługą TCP zarządzaną przez ServBay?

Inaczej niż w przypadku stron WWW – do baz danych czy innych usług TCP bez SNI rekomendowane jest użycie host.docker.internal jako nazwy hosta.

Kroki:

Upewnij się, że usługa bazodanowa czy inna jest uruchomiona w ServBay i akceptuje lokalne połączenia (w zwykłych ustawieniach wystarczy domyślna konfiguracja).
W swoim kontenerze Docker podczas konfiguracji połączenia:
- Host/Serwer: użyj host.docker.internal
- Port: ten, który dla danego serwisu (np. MySQL domyślnie to 3306, PostgreSQL – 5432).
- Użytkownik/Hasło: skonfiguruj zgodnie z tym, jak utworzono w ServBay.

Przykład (dla MySQL w ServBay): Gdy MySQL działa na domyślnym porcie 3306 – w aplikacji w kontenerze użyj:

Host: host.docker.internal
Port: 3306
Użytkownik: your_db_user
Hasło: your_db_password

Q4: Jak sprawić, by kontener Docker ufał CA wystawionej przez ServBay (ServBay User CA) dla domen HTTPS z konfiguracją extra_hosts?

Jeśli zgodnie z instrukcją z Q2 przypisałeś domenę przez extra_hosts lub --add-host (np. secure.servbay.demo:host-gateway) i ServBay wystawił certyfikat SSL przez ServBay User CA, to domyślnie Twoje obraz Dockera nie ufa tej CA – skutkuje to błędem przy połączeniu SSL.

Ścieżki do plików CA ServBay:

Root certyfikat ServBay User CA:
- macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
- Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt
PEM z ServBay User CA, Public CA i Mozilla Root CA:
- 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

Przegląd rozwiązań:

Są trzy główne sposoby, by kontener Docker uznał zaufanie dla ServBay User CA:

Metoda 1: Systemowe globalne zaufanie podczas budowy obrazu (Dockerfile) – polecane, gdy możesz zbudować własny obraz i chcesz, by całość systemu ufała CA.
Metoda 2: Zaufanie na poziomie aplikacji (mount volumów + zmienne środowiskowe) – gdy chcesz, by tylko aplikacja uznawała CA, bez zmiany obrazu.
Metoda 3: Globalne zaufanie podczas startu kontenera (mount volumów + custom command) – gdy nie chcesz budować obrazu, ale CA ma być zaakceptowana przez cały system kontenera.

Metoda 1: Systemowe dodanie CA przy budowie obrazu (Dockerfile)

Polega na dodaniu certyfikatu CA do zaufanych certyfikatów systemowych już podczas budowy obrazu Dockera.

Przygotuj certyfikat CA: Skopiuj ServBay-Private-CA-ECC-Root.crt do katalogu z Dockerfile.

Przykładowy Dockerfile (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/*

Przykładowy Dockerfile (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

Budowa w Docker Compose:

yaml

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

Metoda 2: Zaufanie aplikacyjne przez volumy i zmienne środowiskowe

Polega na podłączeniu pliku CA jako volum i skonfigurowaniu aplikacji przez odpowiednią zmienną środowiskową.

Przykład w docker-compose.yml:

yaml

version: '3.8'
services:
  myapp:
    image: some-base-image
    volumes:
      # dla macOS
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
      # dla Windows (dostosuj ścieżki)
      # - C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
    environment:
      # dla Node.js:
      - NODE_EXTRA_CA_CERTS=/etc/ssl/certs/MyCustomCA.crt
      # dla Python requests:
      # - REQUESTS_CA_BUNDLE=/etc/ssl/certs/MyCustomCA.crt
      # ogólne:
      # - SSL_CERT_FILE=/etc/ssl/certs/MyCustomCA.crt
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Zapoznaj się z dokumentacją swojej aplikacji, jaka zmienna środowiskowa jest właściwa.

Metoda 3: Systemowe zaufanie CA podczas uruchamiania kontenera

W tej opcji podłączasz CA jako volum i uruchamiasz polecenia aktualizujące certyfikaty systemowe przy starcie kontenera.

Przykład w docker-compose.yml (Debian/Ubuntu):

yaml

version: '3.8'
services:
  myapp:
    image: ubuntu:latest # lub inny obraz z update-ca-certificates
    volumes:
      # podłącz CA do odpowiedniego folderu
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/usr/local/share/ca-certificates/ServBay-User-CA.crt:ro
      # Windows
      # - C:\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"]
    # Jeśli konieczne, uruchom kontener jako root dla update-ca-certificates
    # user: root

Uwagi:

Stopień komplikacji: Modyfikacja polecenia startowego może być trudna w oficjalnych lub rozbudowanych obrazach.
Uprawnienia: update-ca-certificates wymaga zazwyczaj uprawnień root.
Zależności: Musi istnieć pakiet ca-certificates i narzędzie update-ca-certificates – skrypt instaluje je wg potrzeb (dla systemów oparte na apt).
Czas startu: Każde uruchomienie kontenera wydłuża się od kroków aktualizacji certyfikatów.
W przypadku Alpine: użyj polecenia apk add --no-cache ca-certificates && update-ca-certificates.

Którą metodę wybrać?

Jeśli możesz budować obraz Docker i chcesz globalnego zaufania – wybierz Metodę 1.
Jeśli chcesz tylko, by aplikacja ufała CA i bez budowy obrazu – wygodnie jest użyć Metody 2.
Jeśli potrzebujesz globalnego zaufania, ale nie chcesz budować obrazu – świetnie sprawdza się Metoda 3.

Certyfikaty publiczne (np. Let's Encrypt): Gdy ServBay korzysta z publicznych CA (np. Let's Encrypt przez ACME), większość obrazów Docker domyślnie je już uznaje, więc żadna dodatkowa akcja nie jest potrzebna.

Q5: Jak ustawić domenę i reverse proxy w ServBay dla aplikacji uruchomionej w kontenerze Docker?

Załóżmy, że masz aplikację w kontenerze Docker (np. Node.js listen na porcie 3000) i chcesz, by była dostępna pod przyjazną domeną (np. myapp.servbay.demo) z hosta, a obsługą SSL zarządzał ServBay.

Kroki:

Uruchom kontener Docker, mapując port na hosta 127.0.0.1: Dopilnuj, by Docker wystawił port aplikacji do hosta, wiążąc go z adresem 127.0.0.1 – dzięki temu będzie dostępny tylko lokalnie.
bash
```
# przykład: aplikacja w kontenerze nasłuchuje na porcie 3000, hostować na 127.0.0.1:3001
docker run -d -p 127.0.0.1:3001:3000 your-docker-app-image
```
1
2
Po tym możesz wejść na aplikację przez http://127.0.0.1:3001.
Dodaj nową stronę w ServBay jako reverse proxy:
- Otwórz panel ServBay.
- Kliknij „Dodaj stronę”.
- Domena: wpisz wybraną domenę, np. myapp.servbay.demo.
- Typ strony: wybierz „Reverse Proxy”.
- IP: wpisz 127.0.0.1.
- Port: użyj portu z kroku 1 (np. 3001).
- Zapisz konfigurację.
(opcjonalnie) Ustaw SSL: Po dodaniu strony możesz aktywować SSL – ServBay pozwala automatycznie uzyskać certyfikat Let's Encrypt lub skonfigurować certyfikaw lokalne (ServBay User CA/Public CA). ServBay obsłuży zakończenie SSL, a komunikacja z kontenerem Docker pozostaje jako zwykłe HTTP (http://127.0.0.1:3001).
Przetestuj dostęp: Po zapisaniu konfiguracji odwiedź z przeglądarki: http://myapp.servbay.demo lub https://myapp.servbay.demo (jeśli jest SSL). ServBay przekaże żądanie do aplikacji w kontenerze Docker.

Schemat działania: Przeglądarka użytkownika -> https://myapp.servbay.demo -> ServBay (SSL, reverse proxy) -> http://127.0.0.1:3001 (port hosta) -> aplikacja w kontenerze Docker.

Podsumowanie

ServBay bardzo upraszcza lokalny development WWW na macOS i Windows. W połączeniu z Docker:

Aby uzyskać dostęp do strony ServBay z Docker – skonfiguruj wpis hosts przez extra_hosts lub --add-host, by domena wskazywała na host-gateway, dzięki czemu nagłówek Host będzie poprawny i unikniesz problemów z SNI.
Aby połączyć się z bazą danych lub inną usługą ServBay z Docker – użyj host.docker.internal jako hosta.
Aby kontener Docker zaufał certyfikatom ServBay User CA – skopiuj CA do obrazu i zaktualizuj store zaufanych certyfikatów.
Aby reverse proxy ServBay kierowało żądania do aplikacji w Docker – dodaj jako stronę typu „Reverse Proxy” i wskaż port hosta z mapowaniem z kontenera.

Pamiętaj o uruchomieniu niezbędnych usług w ServBay (serwer WWW, bazy danych) oraz o poprawnej konfiguracji i działaniu kontenerów Docker.

FAQ: Najczęstsze pytania dotyczące współpracy ServBay i Docker ​

Q1: Dlaczego ServBay modyfikuje mój systemowy plik hosts? Czy mogę to zablokować? ​

Q2: Jak mój kontener Docker może prawidłowo uzyskać dostęp do strony ServBay na hoście, przez domenę (np. mysite.servbay.demo)? ​

Q3: Jak kontener Docker może połączyć się z bazą danych (np. MySQL, PostgreSQL) lub inną usługą TCP zarządzaną przez ServBay? ​

Q4: Jak sprawić, by kontener Docker ufał CA wystawionej przez ServBay (ServBay User CA) dla domen HTTPS z konfiguracją extra_hosts? ​

Metoda 1: Systemowe dodanie CA przy budowie obrazu (Dockerfile) ​

Metoda 2: Zaufanie aplikacyjne przez volumy i zmienne środowiskowe ​

Metoda 3: Systemowe zaufanie CA podczas uruchamiania kontenera ​

Q5: Jak ustawić domenę i reverse proxy w ServBay dla aplikacji uruchomionej w kontenerze Docker? ​

Podsumowanie ​

FAQ: Najczęstsze pytania dotyczące współpracy ServBay i Docker

Q1: Dlaczego ServBay modyfikuje mój systemowy plik `hosts`? Czy mogę to zablokować?

Q2: Jak mój kontener Docker może prawidłowo uzyskać dostęp do strony ServBay na hoście, przez domenę (np. `mysite.servbay.demo`)?

Q3: Jak kontener Docker może połączyć się z bazą danych (np. MySQL, PostgreSQL) lub inną usługą TCP zarządzaną przez ServBay?

Q4: Jak sprawić, by kontener Docker ufał CA wystawionej przez ServBay (ServBay User CA) dla domen HTTPS z konfiguracją extra_hosts?

Metoda 1: Systemowe dodanie CA przy budowie obrazu (Dockerfile)

Metoda 2: Zaufanie aplikacyjne przez volumy i zmienne środowiskowe

Metoda 3: Systemowe zaufanie CA podczas uruchamiania kontenera

Q5: Jak ustawić domenę i reverse proxy w ServBay dla aplikacji uruchomionej w kontenerze Docker?

Podsumowanie