ServBayとDockerの連携FAQ

macOS上でローカルWeb開発を行う際、ServBayとDockerのコンテナ環境を組み合わせて使いたいケースが多くあります。本FAQでは、とくにmacOS環境でServBayとDockerを同時利用する際によく生じる質問や、主要な注意点について解説します。主にコンテナからServBayの各種サービスへのアクセス方法や、Dockerコンテナ内のアプリをServBay経由で公開するリバースプロキシ設定についても扱います。

Q1: ServBayはなぜ私のシステムの`hosts`ファイルを変更するのですか？変更を防ぐことはできますか？

ServBayでは、システムのhostsファイルにエントリー（例：mysite.servbay.demo 127.0.0.1）を追加することで、mysite.servbay.demoのようなカスタムローカルドメインでローカル開発環境へアクセスできる仕組みを提供しています。これらのWebサイトは実際にはお使いのMac本体（127.0.0.1）上で稼働しています。

しかし、Dockerの動作仕様により、コンテナはmacOSホストのhostsファイルを元に自身の/etc/hostsを生成します。その結果、mysite.servbay.demoが127.0.0.1として解決されてしまい、Dockerコンテナが自分自身を参照してしまいます。

主要な仕組み:

ServBayで新しいサイトを作成し、例えばexample.servbay.demoのようなドメイン名を指定すると、自動的に127.0.0.1へ向けるように割り当てます。
これは快適なローカル環境のために標準的な方法です。もしhostsファイルを変更しなければ、http://127.0.0.1:PORTのようなアドレスでしかアクセスできず、独自ドメインでのアクセスはできません。

変更を防ぐことはできる？

理論上、ServBayによって追加されたエントリーを手動で削除することは可能です。しかし、その場合はServBayが設定したドメイン経由でローカルサイトへアクセスできなくなるため、ServBayの利便性が損なわれます。ServBayの主な特徴は、サイト作成とアクセスの簡易化にあります。特定のドメインのhostsエントリー管理をServBayにさせたくない場合、そのドメインでのWebサイト作成自体を避けるのがよいでしょう。

多くのローカル開発環境では、ServBayによるhostsファイル自動管理こそが推奨される機能となっています。

Q2: DockerコンテナからServBayがmacOSホスト上で管理しているWebサイト（例：`mysite.servbay.demo`）へ、正しくドメイン経由でアクセスするには？

頻繁にある要件ですが、安易にはまるトラブルも多いです。ServBay上で稼働するWebサイト（例：mysite.servbay.demoがmacOSホスト上の127.0.0.1で解決される）に対し、Dockerコンテナからも同じドメイン名でアクセスさせたい場合、まず127.0.0.1が指す先に注意する必要があります。コンテナ内の127.0.0.1は「自身（コンテナ）」を指し、ホストのことではありません。

間違った方法：URLのホスト名に直接host.docker.internalを使ってServBayサイトへアクセスする

たしかにDocker Desktop for Mac（およびWindows）はhost.docker.internalという特別な名前でコンテナ→ホストの通信ができますが、この名前をServBayサイトURLのホスト名に直接使うのは非推奨です（たとえば、http://host.docker.internal/でmysite.servbay.demoを期待する）。
なぜなら、この場合HTTPリクエストのHostヘッダーがhost.docker.internalとなってしまい、ServBayのWebサーバー（CaddyやNginx）はそのHost値をもとにどのサイトかを判断するため、正しくルーティングできなくなります。HTTPS通信の場合はSNI（Server Name Indication）エラーの原因となり、例えばSSL証明書がmysite.servbay.demo用に発行されているとき、host.docker.internalでアクセスすると証明書名ミスマッチとなります。

正しい解決法：Docker起動時にextra_hostsを追加する

Dockerコンテナ内アプリからServBayの「本来のドメイン名」（例：mysite.servbay.demo）を使い、正しいHostヘッダーを送信させるには、コンテナの/etc/hostsにそのドメイン→ホストIPを追加します。これはdocker-compose.ymlのextra_hostsや、docker runの--add-hostで対応できます。値はhost.docker.internalでも良いですが、より推奨されるのはhost-gatewayです。

docker runの場合:
bash
```
docker run --add-host=mysite.servbay.demo:host-gateway ... your_image
```
1
（host-gatewayはDockerがホスト内部IPへ自動解決してくれる特別な値です。Docker 20.10以降で利用可能です。）

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"
    # ... そのほかの設定

上記設定後、Dockerコンテナ内では：

http://mysite.servbay.demoあるいはhttps://mysite.servbay.demoにアクセスしようとすると、/etc/hostsによってmacOSホストIPへ名前解決されます。
リクエストはホスト側のServBay Webサーバーに到達します。
HTTPのHostヘッダーは正しいドメイン名を保持し、ServBayは正しくルーティングとSSL証明書の付与（HTTPS時）を行います。

Q3: Dockerコンテナから、ServBayで管理しているデータベース（MySQLやPostgreSQL等）やHTTP以外のサービスへはどう接続すれば良いですか？

Webサービスのようなドメイン名ベースでのアクセスと異なり、データベース接続やSNIを用いないTCPサービスであれば、host.docker.internalをサーバー名として使うのがおすすめで有効です。

手順:

ServBay側で対象データベースやサービスが起動していることを確認します（基本的なローカル開発ではデフォルト設定で問題ありません）。
Dockerコンテナ内での接続設定では：
- ホスト名（サーバー名）: host.docker.internal
- ポート番号: ServBayでそのパッケージが使うポート（例：MySQLなら3306、PostgreSQLなら5432）
- ユーザー名・パスワード: ServBayで設定した情報
例：ServBayのMySQLへ接続するケース ServBayでMySQLがデフォルトで3306番ポート稼働の場合：
- ホスト: host.docker.internal
- ポート: 3306
- ユーザー: your_db_user
- パスワード: your_db_password

Q4: Dockerコンテナから（`extra_hosts`でドメイン解決する設定のもと）ServBay管理のHTTPSサイト（ServBay User CA証明書発行）へアクセスする際、コンテナにこのCAを信頼させるには？

Q2の設定通り、secure.servbay.demoをhost-gatewayへ向けた上で、そのサイトがServBay User CA発行のSSL証明書を用いている場合、DockerコンテナはデフォルトでそのCAを信頼していないため、SSLエラーとなります。

ServBay CAファイルのパス（macOSホスト上）:

ServBay User CAルート証明書: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
User CA, Public CA, Mozillaルート証明書をまとめたPEM:
- ARM Mac: /Applications/ServBay/package/common/openssl/3.2/cacert.pem
- Intel Mac: /Applications/ServBay/package/common/openssl/1.1.1u/cacert.pem

代表的な解決策：

DockerコンテナがServBay User CAを信頼できるようにする主な方法は次の3つです：

方法1: イメージビルド時のシステム全体信頼（Dockerfile）
→ 複数アプリでCAが必要、独自イメージを作れる場合におすすめ。
方法2: 起動時にアプリ単体で信頼（ボリュームマウントと環境変数）
→ 特定アプリのみCA信頼で済む場合や公式イメージ加工せず使いたい場合に有効。
方法3: 起動時にシステム全体で信頼（ボリュームマウント＋起動コマンドカスタム）
→ イメージビルドせず、起動都度システムにCAを登録したい場合向け。

方法1: ビルド時・システム全体信頼（Dockerfile利用）

Dockerイメージビルド時にCAを組み込み、システムで信頼します。

CAファイル準備: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crtをDockerfileと同じビルドディレクトリへコピー。

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/*

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

Composeビルド例:

yaml

# docker-compose.yml
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:
      - /Applications/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: 起動時・システム全体信頼（マウント＋カスタムコマンド）

CAを起動時にボリュームで組み込み、システムごと信頼ストアを更新するパターン。イメージビルド不要ですがコマンドはやや複雑。

（Debian/Ubuntu系イメージ例）docker-compose.yml:

yaml

version: '3.8'
services:
  myapp:
    image: ubuntu:latest # or 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 # ここを本来のCMDや起動コマンドへ置換
      "
    extra_hosts: ["secure.servbay.demo:host-gateway"]
    # 必要に応じて root 権限で実行
    # user: root

注意点:

複雑性: コマンドやエントリポイント置き換えにより、公式イメージなどでは独自の工夫が必要な場合があります。
権限: update-ca-certificatesは一般にroot権限が必要です。非rootユーザーなら権限昇格が必要となるケースも。
パッケージ依存: コンテナイメージにca-certificatesパッケージとupdate-ca-certificatesコマンドが必要です。apt系の場合は上述のコマンドで自動インストールもしています。
起動遅延: コンテナ毎起動時にチェックやコマンド実行が発生します。
Alpine: Alpineイメージはapk add --no-cache ca-certificates && update-ca-certificatesの形になります。

どの方法を選ぶ？

独自イメージ準備ができ、全体的なCA信頼が必要なら方法1がベスト。
イメージをいじりたくない、または特定アプリだけCA信頼で十分なら方法2。
システムとしてCA信頼(イメージビルド不要)が必要なら方法3。

Let’s Encrypt等、公開CA使用の場合は？ ServBayサイトがACME経由の公開CA証明書（Let’s Encryptなど）を使う場合、多くの公式Dockerイメージは公開CAをデフォルトで信頼しているため追加作業は通常不要です。

Q5: Dockerコンテナ内のアプリへ独自ドメイン経由でServBayリバースプロキシ（SSL含む）を設定するには？

たとえばDockerコンテナ内でNode.jsアプリを3000番ポートで動かし、myapp.servbay.demoのようなドメイン名でローカル開発したい、かつSSL証明書管理もServBay側に任せたいケースです。

やるべき手順:

Dockerコンテナでアプリを起動し、127.0.0.1へポートマッピング コンテナ内でアプリが（例：3000番で）リッスンしている場合、コンテナ起動時に必ず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を入力
- ポート: 手順1のマッピング先（例：3001）を入力
- 「保存」または「追加」をクリック
（任意）SSLの有効化 登録したサイトの設定からSSLを有効にできます。ServBayはACME経由でLet’s Encryptなどの公開CA証明書発行も可能ですし、ServBay User CAやPublic CAも選択できます。SSL終端処理はServBayで行われ、ServBay→Dockerは通常HTTP（http://127.0.0.1:3001）で通信します。
ブラウザからの動作確認 上記設定後、http://myapp.servbay.demoまたはSSL有効時はhttps://myapp.servbay.demoへブラウザでアクセスできるようになります。ServBayがリクエストをDockerコンテナ内アプリへ仲介します。

リクエストの流れイメージ：
ユーザーのブラウザ
　↓
https://myapp.servbay.demo
　↓
ServBay（SSL処理＋プロキシ判定）
　↓
http://127.0.0.1:3001（ホスト経由）
　↓
Dockerコンテナ内アプリ

まとめ

ServBayはmacOSにおけるローカルWeb開発を大幅にシンプルにします。Docker連携時には：

DockerコンテナからServBay管理サイトへアクセスするには、extra_hostsや--add-hostでドメイン名をhost-gatewayに割り当て、正しいHostヘッダーとSNI問題の回避を実現します。
DockerコンテナからServBay管理DBや非HTTPサービスに接続するには、host.docker.internalをサーバー名指定すれば簡単便利です。
ServBay User CAのSSL証明書をDockerコンテナで信頼させたい場合は、CAファイルをイメージに組み込み、信頼ストアを更新しましょう。
DockerアプリをServBayリバースプロキシで公開したい場合は、「リバースプロキシ」タイプのウェブサイトで、Dockerが127.0.0.1にバインドしたポートをServBayから参照します。

常に、ServBay側の該当パッケージ（Webサーバーやデータベース）およびDockerコンテナが起動・設定済みであることを忘れずに開発を進めてください。

ServBayとDockerの連携FAQ ​

Q1: ServBayはなぜ私のシステムのhostsファイルを変更するのですか？変更を防ぐことはできますか？ ​

Q2: DockerコンテナからServBayがmacOSホスト上で管理しているWebサイト（例：mysite.servbay.demo）へ、正しくドメイン経由でアクセスするには？ ​

Q3: Dockerコンテナから、ServBayで管理しているデータベース（MySQLやPostgreSQL等）やHTTP以外のサービスへはどう接続すれば良いですか？ ​

Q4: Dockerコンテナから（extra_hostsでドメイン解決する設定のもと）ServBay管理のHTTPSサイト（ServBay User CA証明書発行）へアクセスする際、コンテナにこのCAを信頼させるには？ ​

方法1: ビルド時・システム全体信頼（Dockerfile利用） ​

方法2: 起動時・アプリレベルの信頼（ボリュームマウント＋環境変数） ​

方法3: 起動時・システム全体信頼（マウント＋カスタムコマンド） ​

Q5: Dockerコンテナ内のアプリへ独自ドメイン経由でServBayリバースプロキシ（SSL含む）を設定するには？ ​

まとめ ​

ServBayとDockerの連携FAQ

Q1: ServBayはなぜ私のシステムの`hosts`ファイルを変更するのですか？変更を防ぐことはできますか？

Q2: DockerコンテナからServBayがmacOSホスト上で管理しているWebサイト（例：`mysite.servbay.demo`）へ、正しくドメイン経由でアクセスするには？

Q3: Dockerコンテナから、ServBayで管理しているデータベース（MySQLやPostgreSQL等）やHTTP以外のサービスへはどう接続すれば良いですか？

Q4: Dockerコンテナから（`extra_hosts`でドメイン解決する設定のもと）ServBay管理のHTTPSサイト（ServBay User CA証明書発行）へアクセスする際、コンテナにこのCAを信頼させるには？

方法1: ビルド時・システム全体信頼（Dockerfile利用）

方法2: 起動時・アプリレベルの信頼（ボリュームマウント＋環境変数）

方法3: 起動時・システム全体信頼（マウント＋カスタムコマンド）

Q5: Dockerコンテナ内のアプリへ独自ドメイン経由でServBayリバースプロキシ（SSL含む）を設定するには？

まとめ