Часто задаваемые вопросы по совместной работе ServBay и Docker

При локальной веб-разработке с помощью ServBay вы можете захотеть интегрировать Docker для создания контейнеризированной среды. Эта FAQ-статья отвечает на распространённые вопросы о взаимодействии ServBay и Docker на macOS и Windows, включая доступ к сервисам ServBay из Docker и настройку обратного прокси-сервера ServBay для приложений внутри контейнера.

Q1: Почему ServBay изменяет файл `hosts` в моей системе? Могу ли я это запретить?

ServBay добавляет записи в системный файл hosts (например, mysite.servbay.demo 127.0.0.1), чтобы вы могли обращаться к локальным сайтам через удобные доменные имена вроде mysite.servbay.demo. Фактически эти сайты работают на вашем компьютере по адресу 127.0.0.1.

Но так как Docker копирует hosts-файл из хост-системы (macOS или Windows) внутрь контейнера, домен mysite.servbay.demo внутри контейнера будет также указывать на 127.0.0.1 и контейнер обратится к себе, а не к сайту на хосте.

Основной механизм:

При создании нового сайта в ServBay с доменным именем (например, example.servbay.demo), ServBay автоматически направляет это имя на 127.0.0.1.
Это стандартный способ обеспечить доступ к сайту по локальному доменному имени. Если не менять файл hosts, вы сможете зайти только по адресу вида http://127.0.0.1:PORT, а не по красивому доменному имени.

Можно ли запретить?

Теоретически вы можете вручную удалить записи, добавленные ServBay, но тогда нельзя будет зайти на локальный сайт по доменному имени, что противоречит основной задумке — упростить локальную разработку. Автоматическое управление hosts-файлом — одно из ключевых преимуществ ServBay. Если вы не хотите, чтобы ServBay управлял записями для конкретных имён, просто не создавайте такие сайты в интерфейсе ServBay.

В большинстве случаев автоматическое управление hosts — ожидаемое поведение, оно сильно облегчает разработку.

Q2: Как контейнер Docker может корректно получить доступ к сайтам ServBay на хосте по доменному имени (`mysite.servbay.demo`)?

Это частая задача, решать которую нужно правильно. Сайт под управлением ServBay на вашем компьютере (mysite.servbay.demo, указывает на 127.0.0.1) будет доступен только из хоста. Для контейнера 127.0.0.1 — это сам контейнер.

Неправильный способ: использовать host.docker.internal как домен в URL

Хотя Docker Desktop для macOS и Windows предоставляет специмя DNS host.docker.internal для обращения из контейнера к хосту, настоятельно не рекомендуется использовать это имя непосредственно как host в URL (например, ожидать, что http://host.docker.internal/ отдаст содержимое mysite.servbay.demo).

Причина: при таком запросе в HTTP-заголовке Host будет значение host.docker.internal. Веб-сервер (Caddy или Nginx) полагается на заголовок Host для маршрутизации запроса — и если он не совпадает с именем сайта (mysite.servbay.demo), сервер не сможет корректно отдать сайт или выдаст ошибку SNI при HTTPS, потому что сертификат настроен на mysite.servbay.demo, а не на host.docker.internal.

Правильное решение: добавить запись через extra_hosts

Чтобы приложения внутри контейнера отправляли запросы именно на доменное имя ServBay с правильным заголовком Host, нужно добавить запись в /etc/hosts контейнера с указанием домена и IP адреса хоста (через extra_hosts или --add-host, указывая host-gateway).

docker run:
bash
```
docker run --add-host=mysite.servbay.demo:host-gateway ... your_image
```
1
(host-gateway — специальное значение, Docker подменит его на IP хоста. В Docker 20.10+ это надёжнее, чем просто host.docker.internal.)

docker-compose.yml:

yaml

version: '3.8' # или выше
services:
  myapp:
    image: your_image
    extra_hosts:
      - "mysite.servbay.demo:host-gateway" # или "mysite.servbay.demo:host.docker.internal"
    # ... другие настройки

После настройки:

При обращении по http://mysite.servbay.demo или https://mysite.servbay.demo внутри контейнера, домен будет резолвиться в IP хоста.
Запрос дойдёт до веб-сервера на хосте.
В заголовке Host будет нужное имя сайта, что обеспечит правильную маршрутизацию и подбор SSL-сертификата.

Q3: Как контейнер Docker может подключиться к базе данных под управлением ServBay (MySQL, PostgreSQL и др.) или другому не-HTTP сервису?

В отличие от веб-сервисов с доменами, для подключения к базе данных или другим TCP-сервисам без SNI рекомендуется и работает использовать host.docker.internal как имя сервера.

Шаги:

Проверьте, что нужный пакет базы данных ServBay запущен и настроен на разрешение локальных подключений (обычно по умолчанию).
В контейнере Docker для подключения укажите:
- Host: host.docker.internal
- Порт: порт, который использует база в ServBay (например, MySQL — 3306, PostgreSQL — 5432)
- Имя пользователя/пароль: используйте данные из настроек базы ServBay.

Пример (MySQL): Если MySQL работает на хосте на порту 3306, строка подключения из контейнера будет:

Host: host.docker.internal
Port: 3306
User: your_db_user
Password: your_db_password

Q4: Как сделать так, чтобы контейнер Docker доверял CA ServBay при доступе к HTTPS-сайтам с пользовательским сертификатом ServBay User CA?

Если по совету из Q2 вы добавили запись secure.servbay.demo в контейнер через extra_hosts/--add-host, и если этот сайт использует кастомный сертификат, выданный ServBay User CA, то контейнер по умолчанию не доверяет такому CA — и при HTTPS будет ошибка SSL.

Пути к CA ServBay:

Корневой сертификат 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-файл с ServBay User CA, Public CA и Mozilla:
- 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

Решения:

Есть три способа дать контейнеру доверие к ServBay CA:

Способ 1: Системное доверие при сборке образа (Dockerfile) — подходит для полностью контролируемых образов.
Способ 2: Доверие на уровне приложения (монтирование и переменные окружения) — если нужен доверие только одному приложению.
Способ 3: Системное доверие в рантайме (монтирование + запуск update-ca-certificates) — если образ стандартный, но серьезных изменений не требуется.

Способ 1: Доверие CA через Dockerfile при сборке образа

CA-файл копируется в Dockerfile в системное хранилище сертификатов.

Поместите CA-файл в каталог сборки: Перенесите файл CA рядом с Dockerfile.
- macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
- Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt

Dockerfile для Debian/Ubuntu:

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 для Alpine:

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.yml для сборки:

yaml

version: '3.8'
services:
  myapp:
    build:
      context: ./app_service # содержит Dockerfile и сертификат CA
      dockerfile: Dockerfile
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Способ 2: Доверие на уровне приложения (монтирование + переменная окружения)

CA монтируется в контейнер, а приложение настраивается на его использование (например, переменная окружения).

docker-compose.yml:

yaml

version: '3.8'
services:
  myapp:
    image: some-base-image
    volumes:
      # Пример для macOS
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
      # Пример для Windows (путь скорректируйте под ОС)
      # - C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
    environment:
      # Для Node.js:
      - NODE_EXTRA_CA_CERTS=/etc/ssl/certs/MyCustomCA.crt
      # Для Python (requests):
      # - REQUESTS_CA_BUNDLE=/etc/ssl/certs/MyCustomCA.crt
      # Для универсального SSL_CERT_FILE:
      # - SSL_CERT_FILE=/etc/ssl/certs/MyCustomCA.crt
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Найдите нужную переменную в документации вашего приложения.

Способ 3: Системное доверие через монтирование + update-ca-certificates

CA-файл монтируется напрямую, а при запуске контейнера выполняется команда для обновления хранилища CA.

docker-compose.yml для Debian/Ubuntu:

yaml

version: '3.8'
services:
  myapp:
    image: ubuntu:latest # нужен пакет ca-certificates и команда update-ca-certificates
    volumes:
      # Монтирование CA-файла
      # macOS
      - /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 'Обновление CA сертификатов...' &&
        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 сертификаты обновлены.'
        else
          echo 'Команда update-ca-certificates не найдена, пропускаем.'
        fi &&
        echo 'Запуск приложения...' &&
        exec your_original_application_command_here # замените на команду запуска приложения
      "
    extra_hosts: ["secure.servbay.demo:host-gateway"]
    # user: root # если нужен root для update-ca-certificates

Важные замечания:

Сложность: Сложные entrypoint и команду может быть сложно правильно вставить, если образ стандартный.
Права пользователя: Обычно update-ca-certificates требует root.
Пакет: В образе должны быть ca-certificates и update-ca-certificates.
Время запуска контейнера: На запуск добавится время.
Alpine Linux: Вместо apt используйте apk.

Какой способ выбрать?

Если можете собирать свой образ и нужно доверие CA “на весь контейнер”, — выбирайте Способ 1.
Если нужен доверие только одному приложению и не хотите менять образ, — используйте Способ 2.
Если менять образ нельзя, но нужно системное доверие, — Способ 3.

Сертификаты публичных CA (например Let's Encrypt): Если сайт ServBay использует сертификат публичного CA через ACME (например, Let's Encrypt), то большинство базовых Docker-образов доверяют этим CA по умолчанию, никаких дополнительных действий не нужно.

Q5: Как настроить домен и обратный прокси ServBay для приложения, запущенного в контейнере Docker?

Если вы запускаете приложение в Docker (например, Node.js на порту 3000 в контейнере) и хотите получить к нему доступ через красивый домен (myapp.servbay.demo) с поддержкой SSL — ServBay поможет сделать это.

Инструкция:

Запустите контейнер, пробросив нужный порт только на 127.0.0.1 хоста: Контейнер должен пробрасывать порт на хост только для локального доступа, чтобы ограничить внешний доступ.
bash
```
# Пример: приложение слушает порт 3000 внутри контейнера, а на хосте открывается 127.0.0.1:3001
docker run -d -p 127.0.0.1:3001:3000 your-docker-app-image
```
1
2
Теперь приложение можно проверить через http://127.0.0.1:3001.
Добавьте сайт в ServBay с типом "Обратный прокси":
- Откройте интерфейс ServBay.
- Нажмите "Добавить сайт".
- Домен: Укажите желаемый домен, например myapp.servbay.demo.
- Тип сайта: Выберите "Обратный прокси".
- IP-адрес: Введите 127.0.0.1.
- Порт: Введите порт, на который проброшено приложение из контейнера (например, 3001).
- Сохраните настройки.
(Опционально) включите SSL: После добавления сайта откройте его настройки и активируйте SSL. ServBay может автоматически получить сертификат Let's Encrypt (или другой публичный CA через ACME), либо вы можете настроить сертификат ServBay User CA или ServBay Public CA. SSL будет завершаться на уровне ServBay, между ServBay и приложением в контейнере соединение останется обычным HTTP.
Проверьте доступность: Открыв сайт в браузере по http://myapp.servbay.demo или https://myapp.servbay.demo (если активирован SSL), вы увидите приложение, работающее в контейнере.

Схема работы: Браузер пользователя -> https://myapp.servbay.demo -> ServBay (SSL, прокси) -> http://127.0.0.1:3001 на хосте -> приложение внутри Docker.

Итоги

ServBay значительно облегчает локальную веб-разработку на macOS и Windows. При совместной работе с Docker:

Для доступа контейнера к сайтам ServBay используйте extra_hosts или --add-host, чтобы домен указывал на host-gateway и заголовок Host был правильным, без SNI-ошибок.
Для доступа контейнера к базам данных ServBay и другим не-HTTP сервисам — используйте host.docker.internal как Host.
Чтобы контейнер доверял SSL-сертификатам от ServBay User CA, скопируйте CA в контейнер и обновите хранилище сертификатов.
Чтобы использовать обратный прокси ServBay для приложения в контейнере, при создании сайта в ServBay выберите тип "Обратный прокси" и укажите порт контейнера, проброшенный на 127.0.0.1 хоста.

Обязательно проверьте, что все нужные пакеты и сервисы в ServBay и ваши контейнеры запущены и корректно настроены.

Часто задаваемые вопросы по совместной работе ServBay и Docker ​

Q1: Почему ServBay изменяет файл hosts в моей системе? Могу ли я это запретить? ​

Q2: Как контейнер Docker может корректно получить доступ к сайтам ServBay на хосте по доменному имени (mysite.servbay.demo)? ​

Q3: Как контейнер Docker может подключиться к базе данных под управлением ServBay (MySQL, PostgreSQL и др.) или другому не-HTTP сервису? ​

Q4: Как сделать так, чтобы контейнер Docker доверял CA ServBay при доступе к HTTPS-сайтам с пользовательским сертификатом ServBay User CA? ​

Способ 1: Доверие CA через Dockerfile при сборке образа ​

Способ 2: Доверие на уровне приложения (монтирование + переменная окружения) ​

Способ 3: Системное доверие через монтирование + update-ca-certificates ​

Q5: Как настроить домен и обратный прокси ServBay для приложения, запущенного в контейнере Docker? ​

Итоги ​

Часто задаваемые вопросы по совместной работе ServBay и Docker

Q1: Почему ServBay изменяет файл `hosts` в моей системе? Могу ли я это запретить?

Q2: Как контейнер Docker может корректно получить доступ к сайтам ServBay на хосте по доменному имени (`mysite.servbay.demo`)?

Q3: Как контейнер Docker может подключиться к базе данных под управлением ServBay (MySQL, PostgreSQL и др.) или другому не-HTTP сервису?

Q4: Как сделать так, чтобы контейнер Docker доверял CA ServBay при доступе к HTTPS-сайтам с пользовательским сертификатом ServBay User CA?

Способ 1: Доверие CA через Dockerfile при сборке образа

Способ 2: Доверие на уровне приложения (монтирование + переменная окружения)

Способ 3: Системное доверие через монтирование + update-ca-certificates

Q5: Как настроить домен и обратный прокси ServBay для приложения, запущенного в контейнере Docker?

Итоги