ServBay と Docker 連携 FAQ

ローカルWeb開発でServBayを利用する際、Dockerによるコンテナ環境と組み合わせて使いたい場面があるでしょう。本FAQでは、macOSとWindows環境でServBayとDockerを併用する場合によくある質問とその対処法をまとめています。DockerからServBayサービスへのアクセスや、ServBayによるDockerコンテナ内アプリのリバースプロキシ設定も解説します。

Q1: ServBayはなぜシステムのhostsファイルを書き換えるのですか？それを止められますか？

ServBayは、システムのhostsファイルにエントリ（例: mysite.servbay.demo 127.0.0.1）を追加することで独自のローカルドメイン（例: mysite.servbay.demo）を使ってローカル開発サイトへアクセスできるようにしています。これらのサイトは実際にはあなたのPCの127.0.0.1で動作しています。

しかしDockerの仕組みにより、ホスト（macOSやWindows）のhostsファイルがコンテナにも反映され、mysite.servbay.demoが127.0.0.1に解決され、結果としてDockerコンテナ自身へのアクセスになってしまいます。

仕組みのポイント：

• ServBayで新しいサイトを作り、ドメイン（example.servbay.demoなど）を指定すると、そのドメインが自動的に127.0.0.1へ向けられます。
• カスタムドメインでローカルサイトへアクセスするためにはhostsファイルを修正することが一般的です。hostsファイルを変更しない場合は、http://127.0.0.1:PORTのような形式でしかアクセスできません。

止めることは可能ですか？

理論上、ServBayが追加したエントリを手動で消すことは可能ですが、その場合ServBayが設定した独自ドメイン経由でローカルサイトにアクセスできなくなり、ServBayの便利なローカル開発体験が損なわれます。ServBayの主要機能の1つは、ローカルサイトの作成・アクセスを簡素化することです。特定ドメインの管理をServBayに任せたくない場合は、ServBayでそのドメインのサイトを作成しないことを推奨します。

ほとんどのローカル開発パターンでは、ServBayによる自動hosts管理が期待される動作であり、設定を非常に簡単にしてくれます。

Q2: Dockerコンテナから、ServBayの管理するウェブサイト（例: mysite.servbay.demo）へドメイン名で正しくアクセスする方法は？

このニーズは非常に多いですが、正しく設定しないとトラブルにつながります。ServBayがホスト（macOSやWindows）上で稼働しているサイト（例: mysite.servbay.demo、これはホストでは127.0.0.1）にアクセスしたい場合、Dockerコンテナ内の127.0.0.1は「コンテナ自身」を指すため、ホストのサイトへは届きません。

NG例：URLのホスト名として直接host.docker.internalを用いてServBayサイトにアクセスする

Docker Desktop for Mac/Windowsでは、host.docker.internalという特殊なDNS名でコンテナ→ホストのIP解決をサポートしていますが、この名前で直接URLアクセス（例: http://host.docker.internal/→mysite.servbay.demoを期待）することは推奨されません。

この理由は、アクセス時にHTTPリクエストヘッダのHostフィールドがhost.docker.internalになってしまうためです。ServBayのWebサーバ（CaddyやNginx）はこのHostヘッダで訪問サイトを判定しています。Hostがhost.docker.internalだと目的のサイトへ正しくルーティングできず、HTTPSの場合はSNI（Server Name Indication）のエラーの元となります。これは提供されるSSL証明書がmysite.servbay.demo向けであり、host.docker.internalには一致しないためです。

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

Dockerコンテナ内のアプリで本来のドメイン（mysite.servbay.demoなど）を用い、Hostヘッダを正しく送りたい場合は、コンテナの/etc/hostsに該当ドメインをホストのIPへ向けるよう登録します。これはextra_hosts（docker-compose.yml）や--add-host（docker run）で行い、IPにはhost.docker.internalまたは推奨されるhost-gatewayを指定します。

• docker runの場合:

  docker run --add-host=mysite.servbay.demo:host-gateway ... your_image

  （host-gatewayは特別な値で、Dockerがホストの内部IPへ自動変換するものです。Docker 20.10以降ではhost.docker.internalの低レイヤ別名です。）

• docker-compose.ymlの場合:

  version: '3.8' # 以降のバージョンも可
  services:
    myapp:
      image: your_image
      extra_hosts:
        - "mysite.servbay.demo:host-gateway" # または "mysite.servbay.demo:host.docker.internal"
      # ... その他設定

この設定後、Dockerコンテナ内で：

1. アプリがhttp://mysite.servbay.demoまたはhttps://mysite.servbay.demoにアクセスしようとすると、コンテナの/etc/hostsに従いmacOSホストのIPへ向かう
2. リクエストはホスト側で已稼働のServBayウェブサーバへ送信される
3. HTTPのHostヘッダがmysite.servbay.demoとなり、ServBayは正しくサイト判定・SSL証明書（HTTPS使用時）提供が可能になる

Q3: Dockerコンテナから、ServBay管理のデータベース（MySQL・PostgreSQLなど）やHTTP以外のサービスに接続する方法は？

ドメインベースのWebサービスとは異なり、データベースやSNI不要のTCPサービスへの接続はhost.docker.internalをホスト名として使うのが推奨かつ有効です。

手順：

1. ServBay内でデータベースソフト（またはサービス）が起動済みであることを確認し、ホストからの接続が許可されているか確認（通常ローカル開発ではデフォルトでOK）。

2. Dockerコンテナ内でデータベース接続設定：

   • ホスト名（Hostname/Server）： host.docker.internalを指定
   • ポート（Port）： ServBayで該当サービスに割り当てたポート（MySQL標準3306、PostgreSQL標準5432など）
   • ユーザー名／パスワード： ServBay側で設定した認証情報を利用

   例：ServBay管理のMySQLへ接続する場合 ServBayのMySQLがデフォルトの3306ポートで稼働している場合、Dockerコンテナ内アプリでは

   • ホスト: host.docker.internal
   • ポート: 3306
   • ユーザー: your_db_user
   • パスワード: your_db_password などの接続情報を設定してください。

Q4: Dockerコンテナが、ドメイン名（extra_hosts利用）経由でServBay上のHTTPSサイト（ServBay User CA証明書使用）にアクセスする際、コンテナにCA信頼情報を認識させるには？

Q2の手順通り、extra_hostsや--add-hostでsecure.servbay.demoをhost-gatewayへ向けているとします。このときsecure.servbay.demoのSSL証明書がServBay User CAによるものである場合、Dockerコンテナは通常このCAを「信頼されない」と判定してSSL接続に失敗します。

ServBay CA関連ファイルのパス：

• 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
• ServBay User CA＋Public CA＋Mozilla CAを含むPEMファイル:
  • 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

解決策の概要：

DockerコンテナにServBay User CAを信頼させるには主に下記3つの方法があります。

1. 方法1：システムレベル信頼（Dockerfileでビルド時追加）
   CAを全システムで信頼したい場合やカスタムイメージを構築できる場合にお勧め。

2. 方法2：アプリケーションレベル信頼（ボリュームマウント＋環境変数）
   特定アプリだけCAを信頼させたいか、イメージを変更したくない場合に。

3. 方法3：システムレベル信頼（ボリュームマウント＋カスタム起動コマンド）
   イメージのビルド無しですべてのシステムでCA信頼を有効にしたい場合。

方法1：Dockerfileでシステムレベル信頼を構築時に

Dockerイメージビルド時にCA証明書を信頼ストアへ追加。

• CAファイルを準備： ServBay User CAルート証明書をDockerビルドコンテキスト（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でビルド:

  # docker-compose.yml
  version: '3.8'
  services:
    myapp:
      build:
        context: ./app_service # DockerfileやServBay-Private-CA-ECC-Root.crtのあるディレクトリ
        dockerfile: Dockerfile
      extra_hosts: ["secure.servbay.demo:host-gateway"]

方法2：ボリュームマウントと環境変数によるアプリレベル信頼

CA証明書ファイルをコンテナにマウントし、アプリケーションで環境変数などにより利用。

• docker-compose.yml例:

  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：ボリューム＋カスタム起動コマンドでシステム全体で信頼

ボリュームで証明書をマウントした後、起動コマンドでシステムのCAストアを更新します。イメージのビルド不要ですが、起動手順がやや複雑です。

• docker-compose.yml例（Debian/Ubuntu系）:

  version: '3.8'
  services:
    myapp:
      image: ubuntu:latest # 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
      # 起動時にCA更新＋アプリ起動コマンド
      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ユーザーでupdate-ca-certificatesを実行する必要がある場合はuser: rootで一時切替も検討

  注意事項:
  • 複雑さ: 起動コマンドやentrypointの変更は公式イメージ利用時などは手順が煩雑になることも。
  • 権限: update-ca-certificatesは通常root権限が必要です。デフォルト非root起動の場合は要権限変更。
  • パッケージ依存: イメージ内にca-certificatesやupdate-ca-certificatesが必要。サンプルは不在時自動インストール（aptベースの場合）。
  • 起動時間: 起動毎に処理するため起動が遅くなる場合があります。
  • Alpine Linuxの場合: コマンドはapk add --no-cache ca-certificates && update-ca-certificates。

どの方法が最適？

• カスタムイメージビルド可能でグローバル信頼を目的とするなら方法1が最適
• イメージを変更せず特定アプリのみ信頼させたい場合は方法2
• システム全体に信頼、イメージ変更はしたくない場合は方法3が良い選択です

Let's EncryptなどパブリックCAの場合： ServBayのウェブサイトがACME（Let's Encrypt等）パブリックCA証明書の場合、多くの公式Dockerイメージは標準でこれらCAを信頼済みのため追加作業は不要です。

Q5: Dockerコンテナ内アプリにServBayで独自ドメインを設定し、リバースプロキシするには？

Dockerコンテナ内で（例：Node.jsサービス3000番ポート）アプリを稼働させ、ServBayで好きなドメイン（例: myapp.servbay.demo）を割り振り、ホスト側からアクセス＋SSLによるセキュアな公開を行う手順です。

手順：

1. Dockerコンテナでアプリ稼働、ポートをホスト127.0.0.1にマッピング：
   ポートの公開はホストローカルのみ（127.0.0.1バインド）として、外部公開を防ぎます

   # 例：コンテナ内3000番ポートをホスト127.0.0.1:3001へマッピング
   docker run -d -p 127.0.0.1:3001:3000 your-docker-app-image

   この例では、コンテナアプリは3000でListen、ホストのhttp://127.0.0.1:3001からアクセス可能。

2. ServBayで新規サイト（リバースプロキシ）を追加：

   • ServBay管理画面を開く
   • 「ウェブサイト追加」をクリック
   • ドメイン名: 例：myapp.servbay.demoを指定
   • サイトタイプ: ドロップダウンで**「リバースプロキシ」**を選択
   • IPアドレス: サイト設定入力欄に127.0.0.1を入力
   • ポート: 手順1で割り当てたホスト側ポート（例：3001）を入力
   • 「保存」または「追加」をクリック

3. （任意）SSL設定： サイト追加後、SSL有効化設定が可能です。ServBayはACME（Let's Encryptなど）パブリックCAによる証明書取得も可能、またServBay User CAやPublic CAも選択できます。SSL終端はServBay側が担当し、ServBay→Dockerコンテナの経路は通常HTTP（例：http://127.0.0.1:3001）でOKです。

4. 動作確認： ServBayの設定が保存されたら、ブラウザでhttp://myapp.servbay.demoやhttps://myapp.servbay.demo（SSL設定時）にアクセスください。ServBayがDockerコンテナのアプリへプロキシします。

動作フロー： ブラウザ → https://myapp.servbay.demo → ServBay（SSL終端・リバースプロキシ） → http://127.0.0.1:3001（ホストローカルポート） → Dockerコンテナ内アプリ

まとめ

ServBayはmacOS・WindowsでのローカルWeb開発を大幅に効率化します。Dockerと連携する際のポイントは：

• DockerコンテナからServBay管理のウェブサイトへアクセスする際は、extra_hostsまたは--add-hostでサイトのドメイン名をhost-gatewayに向けることで、Hostヘッダを正しく伝達しSNI等の問題を回避できます。
• DockerコンテナからServBay管理のデータベースやHTTP以外のサービスへアクセスする際は、host.docker.internalをホスト名指定するだけで簡単に接続できます。
• ServBay User CAによるSSL証明書をDockerコンテナに信頼させる場合は、CA証明書コピー＆信頼ストアの更新が必要です。
• Dockerコンテナ内アプリをServBayでリバースプロキシする場合は、「リバースプロキシ」サイトタイプ設定で、ホスト127.0.0.1の公開ポートを指定してください。

ServBayの各種サービス（ウェブサーバ・データベース等）およびDockerコンテナの設定・稼働状況を常に確認して正しい連携を心がけましょう。