PHPアプリケーションのコンテナイメージを作成する際、ビルドに必要なツール（Composer、各種コンパイラなど）をすべて含めてしまうと、イメージが肥大化し、セキュリティリスクも増大します。

この課題を解決するのが、コンテナビルドの効率を最大化する技術、マルチステージビルドです。

マルチステージビルドとは？

マルチステージビルドとは、一つのDockerfile内で複数のFROM命令（ステージ）を定義し、最終的なイメージにデプロイに必要なファイルだけをコピーする手法です。

役割分担

1. ビルドステージ (Build Stage):
   • 目的: アプリケーションのビルドと依存関係の解決。
   • 使用イメージ: 大きなイメージ（例: composer:latest、php:8.3-fpmなど）。
   • 作業: Composerによる依存パッケージのインストール、フロントエンドアセットのコンパイル、テストの実行などを行います。
   • 特徴: このステージは最終的なデプロイには使用されません。
2. 最終ステージ (Final Stage):
   • 目的: アプリケーションの実行環境の構築。
   • 使用イメージ: 軽量なイメージ（例: php:8.3-fpm-alpine、distrolessなど）。
   • 作業: ビルドステージで生成された成果物（例: vendorディレクトリ、コンパイル済みバイナリ、PHPコード）のみをコピーします。

メリット

• イメージサイズの劇的な削減: ビルドツールやキャッシュ、開発用の依存関係が最終イメージから完全に除外されます。
• セキュリティ向上: 最終イメージが最小限の構成になるため、攻撃対象となる領域が縮小します。
• ビルド時間の短縮: 軽量なイメージを使用することで、プル時間が短くなります。

PHPアプリケーションでのマルチステージビルド

PHPアプリケーションの典型的なマルチステージビルドは、Composerによる依存関係の解決を分離することに焦点を当てます。

Dockerfile

以下のDockerfileは、Composerで依存関係を解決するステージと、それを使ってアプリケーションを実行する最小限のステージに分離しています。

# =============================================
# ステージ1：build_stage（依存関係の解決）
# =============================================
FROM composer:latest AS build_stage 
WORKDIR /app 
# 先に依存関係ファイルだけをコピー（キャッシュ効率化のため）
COPY composer.json composer.lock ./ 
# 本番環境用に最適化してインストール 
# --no-dev: 開発用パッケージを除外
# --optimize-autoloader: オートローダーを最適化して高速化 
RUN composer install \
--no-dev \
--no-interaction \
--optimize-autoloader 
# =============================================
# ステージ2：final_stage（最小限の実行環境）
# =============================================
# 軽量なAlpine LinuxベースのPHP-FPMイメージを使用
FROM php:8.3-fpm-alpine AS final_stage 
# セキュリティ：実行用の非特権ユーザーを作成
RUN adduser -D appuser
USER appuser
WORKDIR /var/www/html
# ステージ1からvendorディレクトリのみをコピー
# --chown で所有権を同時に変更するのがポイント
COPY --from=build_stage --chown=appuser:appuser /app/vendor ./vendor
# アプリケーションのソースコードをコピー
COPY --chown=appuser:appuser . .
 
# PHP-FPMを起動 
EXPOSE 9000
CMD ["php-fpm"]

実行手順

1. プロジェクトルートに配置: 上記のDockerfileをプロジェクトのルートディレクトリに配置します。
2. docker buildを実行: 通常通りdocker buildコマンドを実行するだけです。Dockerエンジンが自動的にマルチステージビルドを処理します。

docker build -t my-php-app:prod .

PHPでのポイント

1. composer_stageの利用: Composerをインストールする手間を省くため、公式のcomposerイメージをビルダーとして使うのが最も効率的です。
2. --no-dev: 開発時のみ必要なパッケージ（テストフレームワークなど）は最終イメージに含めないようにします。
3. USER nonroot: セキュリティのため、最終ステージでは必ずroot権限を放棄し、非特権ユーザーでアプリケーションを実行するように設定しましょう。（これにより、低ポート番号の使用には制約が生じますが、セキュリティが大幅に向上します）
4. COPY --fromの活用: この命令が全てです。Composerの巨大なキャッシュやビルドツール群を最終イメージから排除し、必要なvendorディレクトリだけをクリーンにコピーします。

マルチステージビルドは、軽量で安全なPHPコンテナイメージを作成するための必須技術です。ぜひあなたのプロジェクトに導入してください。

コンテナ技術は現代のアプリケーション開発・運用に欠かせないものとなりましたが、コンテナを運用する上で「セキュリティ」と「イメージサイズ」は常に大きな課題として立ちはだかります。

あなたのコンテナイメージは本当に安全で、そして最小限に保たれていますか？

多くの開発者は、手軽さからコンテナをroot（管理者）権限で実行し、また開発やデバッグに不要なOSパッケージをそのまま含めてしまいがちです。

これが、セキュリティリスクの増大と、イメージサイズの肥大化を招く原因となります。

この記事では、この課題を解決するための Unprivileged（非特権ユーザー実行）とDistroless（ディストロレス）イメージについて、その概念から実践的な使い方、そして運用上の注意点までを解説します。

そもそも「Unprivileged」と「Distroless」とは何か？

1. Unprivileged (非特権ユーザー実行) とは？

Unprivileged実行とは、「最小特権の原則」をコンテナで実践することです。

• 定義
  コンテナ内のメインプロセスをrootユーザー（UID 0）ではなく、一般ユーザー（非特権ユーザー）として実行すること。
• メリット
  コンテナが何らかの理由で侵害されたり、エスケープ（コンテナの外側にあるホストOSへの侵入）が試みられたりした場合でも、プロセスが持つ権限が最小限に抑えられます。
  これにより、ホストシステムへの影響範囲を劇的に制限できます。
• 実現方法
  Dockerfile内でUSER命令を使用して、コンテナの実行ユーザーを切り替えます。

2. Distroless (ディストロレス) イメージとは？

Distrolessイメージとは、セキュリティとサイズを極限まで追求したベースイメージです。

• 定義
  OSディストリビューション（Linux）の要素、具体的にはbash、apt、lsといった一般的なシェルやパッケージ管理ツールを意図的に含めない、アプリケーション実行に必要な最小限のランタイムとライブラリのみで構成されたコンテナイメージです。
• 「通常のイメージ」との違い
  通常のイメージ（例: ubuntu:latest）には多くの汎用ツールが含まれていますが、Distrolessイメージにはそれらが一切含まれていません。デバッグツールさえないため、その名（Distro-less = ディストリビューションがない）が示す通り、極めて軽量です。

Unprivileged & Distroless を組み合わせるメリット

この二つのアプローチを組み合わせることで、コンテナの運用は次のレベルに引き上げられます。

1. 圧倒的なセキュリティ向上

• 攻撃対象領域の削減
  Distroless化により、イメージに含まれるバイナリやライブラリの数が最小限になります。
  その結果、既知の脆弱性（CVE）を持つ可能性のあるパッケージが激減し、攻撃対象となる領域を大幅に縮小します。
• 権限昇格リスクの低減
  Unprivileged実行により、仮にコンテナに侵入されても、攻撃者がホストシステムでroot権限を得るのが極めて困難になります。

2. イメージサイズの劇的な削減

• 不要なOSレイヤーやツールがないため、イメージサイズは通常のベースイメージに比べて数百MB単位で削減されることがあるらしい
• これにより、レジストリへのプッシュ/プル時間が短縮され、デプロイ時間の高速化、そしてストレージコストの削減につながります。

3. ビルド時間の短縮と効率化

ベースイメージが小さくなることで、CI/CDパイプラインでのダウンロード時間が短縮され、コンテナのビルドプロセス全体が効率化されます。

Unprivileged & Distroless なコンテナの使い方

Unprivileged & Distrolessを実現する最も一般的な方法は、マルチステージビルドを利用することです。

1. Distroless イメージの基本構造

1. Build Stage
   開発に必要なコンパイラ、パッケージマネージャなどを含む通常のイメージ（例: golang:latest, node:latest）を使い、アプリケーションのビルドや依存関係のインストールを行います。
2. Final Stage
   Distrolessイメージをベースとし、Build Stageで生成された最終的なバイナリや必要なランタイムファイルだけをコピーします。

2. Unprivileged実行の設定

Distrolessイメージの多く（例: gcr.io/distroless/...）は、セキュリティのため、デフォルトで非rootユーザー（例: nonroot）が設定されています。

もしご自身でベースイメージから構築する場合、Dockerfileに以下のコマンドを追加してユーザーを切り替えます。

# ユーザーを作成し、パーミッションを設定
RUN adduser --disabled-password --gecos "" appuser

# 実行ユーザーを一般ユーザーに切り替える
USER appuser

運用上の注意点：非特権ユーザーとポート番号の壁

UnprivilegedコンテナをECS（または任意のLinuxホスト）で運用する際、セキュリティの恩恵と引き換えに、ある実用上の課題に直面します。

1. ポート1024未満のバインドはroot権限が必要

Linux OSのセキュリティ原則により、Webサーバーなどで一般的に使われるポート番号1024未満（ウェルノウンポート、例: HTTPの80、HTTPSの443）にバインドするには、root権限（特権）が必要です。

あなたがECSでUnprivilegedかつDistrolessなNginxイメージを使った際、Nginxがデフォルトで80番ポートを使おうとすると、権限がないため「Permission Denied」といったエラーが発生し、コンテナの起動に失敗してしまいます。

2. ECS/Fargate環境での具体的な解決策

この問題を解決しつつ、Unprivilegedのセキュリティメリットを維持するには、以下の方法が最も推奨されます。

1. アプリケーション側のポート変更:Webサーバー（Nginxなど）の設定ファイルを変更し、1024番以上のポート（例: 8080、8081）で待ち受けるように設定を変更します。
2. ロードバランサー (ALB) でのポートマッピング:
   • ECS（Fargate）のタスク定義で、コンテナが使用するポートを8080などに設定します。
   • Application Load Balancer (ALB) を利用し、ALBは外部からのアクセスを80番（標準HTTP）で受けます。
   • ALBは、内部のECSタスクグループに対しては8080番でルーティングします。

これにより、コンテナ内部は非特権ユーザーで安全に運用され、外部ユーザーはポート番号を意識することなくWebサイトにアクセスできるようになります。

次世代コンテナの標準へ

UnprivilegedとDistrolessの組み合わせは、コンテナのセキュリティ基準とデプロイ効率を大きく引き上げる、次世代コンテナの標準パターンです。

• Distroless: 攻撃対象領域とイメージサイズを最小化。
• Unprivileged: 権限昇格リスクを最小化。

特にECSなどの本番環境で運用する際は、ポート1024未満の制限に注意を払い、ロードバランサーを活用して安全かつ効率的な構成を構築しましょう。

あなたのプロジェクトも、今日からこの強力なセキュリティパターンに移行してみませんか？

しかし、ローカルのDocker Compose環境では問題なく動作しても、AWSのECS Fargateのような本番環境にデプロイしようとすると、いくつかの疑問に直面します。

• 「NginxとPHP-FPMコンテナはどう連携させるのがベスト？」
• 「fastcgi_pass ってローカルと設定を変える必要ある？」
• 「InertiaでビルドしたReactのJS/CSSファイルは、結局どのコンテナに置くのが正解？」

この記事では、fastcgi_pass の基本から、ECS Fargateでの最適なコンテナ構成、そしてInertia/Reactプロジェクト特有の「静的ファイルの配置場所」問題までを、順を追って解説します。

fastcgi_pass とは？

NginxとPHP-FPMの「橋渡し」

まず基本のおさらいです。Nginxは高性能なWebサーバーですが、それ自体はPHPコードを実行できません。
一方、PHP-FPMはPHPコードを実行することに特化したプロセス（サーバー）です。

Nginxがクライアント（ブラウザ）から .php ファイルへのリクエストを受け取ったとき、そのリクエストをPHP-FPMに処理してもらう必要があります。

このとき、Nginxの設定ファイル（nginx.conf）で、「どのPHP-FPMに処理を依頼するか」の宛先を指定するのが fastcgi_pass ディレクティブです。

location ~ \.php$ {
    # ...
    # ↓ この一行が「橋渡し」の指定
    fastcgi_pass php-fpm-server:9000; 
}

ローカル開発 (Docker Compose) での構成

ローカル開発では、「1コンテナ1責務」の原則に従い、NginxとPHP-FPMを別々のコンテナとして docker-compose.yml で定義するのが一般的です。

# docker-compose.yml (抜粋)
version: '3'
services:
  # Nginxコンテナ
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./laravel-project:/var/www/html

  # PHP-FPMコンテナ
  php:
    build: . # PHP-FPMとLaravelコードを含むDockerfile
    volumes:
      - ./laravel-project:/var/www/html

この構成では、NginxコンテナとPHPコンテナは 別々のネットワーク空間 に存在します。Docker Composeが提供する内部ネットワークを介して、サービス名で通信します。

したがって、NginxコンテナからPHPコンテナへは、php というサービス名（ホスト名）を使ってアクセスします。

# nginx.conf (Docker Compose用)
location ~ \.php$ {
    # ...
    # 'php' サービス（コンテナ）の 9000番ポートに転送
    fastcgi_pass php:9000;
}

（※ このTCP/IP通信によるパフォーマンスやセキュリティの懸念は、コンテナ間通信がDockerの内部ネットワークに限定されていれば、実用上ほとんど問題になりません。）

【1タスク2コンテナ】本番 (ECS Fargate) での構成：

さて、本題のECS Fargateです。
ECSでは、docker-compose.yml に相当するものとして「タスク定義 (Task Definition)」を使います。

ここで重要なキーポイントは、「1つのタスク定義の中で、NginxコンテナとPHP-FPMコンテナの2つを定義する」ことです。

これら2つのコンテナは、1セットで「Webアプリケーションサーバー」として機能します。

ECS Fargateでのfastcgi_passはどうなる？

ECSの同一タスク内で実行されるコンテナは、同じネットワーク空間（ネットワークモード awsvpc）を共有します。

これは、Nginxコンテナから見ると、PHP-FPMコンテナが「他人」ではなく、「自分自身（localhost）」として見えることを意味します。

したがって、ECS Fargate用のNginxイメージに含める nginx.conf の設定は、以下のようになります。

# nginx.conf (ECS Fargate用)
location ~ \.php$ {
    # ...
    # サービス名ではなく、localhost (127.0.0.1) を指定する
    fastcgi_pass 127.0.0.1:9000;
}

タスク定義のイメージ

タスク定義では、以下のように設定します。

• コンテナ-A: php-fpm-container
  • イメージ: （Laravelコードを含むPHP-FPMイメージ）
  • ポートマッピング: なし (外部に公開する必要はないため)
• コンテナ-B: nginx-container
  • イメージ: （設定済みのnginx.confと静的ファイルを含むNginxイメージ）
  • ポートマッピング: 80:80 (ALBからのトラフィックを受け取るため)

ALB（ロードバランサー）からのトラフィックはNginxコンテナが受け取り、必要に応じて localhost:9000 を介してPHP-FPMコンテナに処理を渡します。

Inertia/Reactのビルドファイルはどこに置く？

ここで、Inertia/React構成特有の問題に直面します。

「InertiaはLaravel（PHP）がビューを配信する仕組みだから、npm run build で生成された public/build フォルダは、PHP-FPMコンテナにだけ置けば良いのでは？」

これはよくある誤解ですが、パフォーマンスと責務分離の観点から、ビルドした静的ファイル（JS/CSS）はNginxコンテナに配置するのが正解です。

この理由を理解するために、Inertiaのページが読み込まれる2段階のフローを見てみましょう。

ステップ1: HTMLシェルのリクエスト (PHP-FPMが処理)

1. ブラウザが https://example.com/dashboard にアクセスします。
2. ALB → Nginxコンテナがリクエストを受け取ります。
3. NginxはこれがPHPのリクエストだと判断し、fastcgi_pass 127.0.0.1:9000 を使ってPHP-FPMコンテナに転送します。
4. PHP (Laravel) が起動し、Inertiaは app.blade.php をレンダリングしようとします。
5. このとき、PHPは public/build/manifest.json を読み取り、HTMLに含めるべきJS/CSSのファイル名を特定します。
6. PHPは以下のようなHTMLの「ガワ」を生成し、Nginx経由でブラウザに返します。

   <html>
   <head>
       <script src="/build/assets/app.12345.js" defer></script>
       <link rel="stylesheet" href="/build/assets/app.67890.css">
   </head>
   <body>
       <div id="app" data-page="..."></div>
   </body>
   </html>
   

ステップ2: 静的アセット(JS/CSS)のリクエスト (Nginxが処理)

1. ブラウザは、ステップ1で受け取ったHTMLを解析します。
2. 「/build/assets/app.12345.js と /build/assets/app.67890.css が必要だ」と判断し、ブラウザは別途2回のリクエストをサーバーに送信します。
3. このリクエストは、もはやPHPとは全く関係ありません。
4. ALB → Nginxコンテナがこの2つのリクエストを受け取ります。
5. Nginxは「自分の管理下（public フォルダ）にそのファイルがあるか？」を探します。
6. Nginxコンテナに public/build/ 以下の実体ファイルが存在するため、NginxはPHP-FPMを起動することなく、それらの静的ファイルを超高速でブラウザに直接返します。

もし、NginxコンテナにJS/CSSファイルがなければ、このリクエストもPHP-FPMに転送されてしまい、「JSファイルを取得するためだけにLaravelを起動する」という深刻なパフォーマンスボトルネックが発生します。

CI/CDでのベストプラクティス

上記2ステップから、CI/CDパイプラインでDockerイメージをビルドする際は、以下の構成が最適です。

1. npm run build を実行し、public/build ディレクトリを生成します。
2. PHP-FPMイメージのビルド:
   • Laravelのコード（app/, routes/ など）をコピーします。
   • ステップ1のために public/build/manifest.json をコピーします。（リンク生成に必要）
3. Nginxイメージのビルド:
   • nginx.conf をコピーします。
   • ステップ2のために public フォルダ全体（index.php と、public/build 以下の 全てのJS/CSSファイル を含む）をコピーします。（静的アセットの配信用）

結論

manifest.json はPHP-FPMコンテナに、JS/CSSの実体ファイルはNginxコンテナに必要です。

両方のイメージに public フォルダ（または public/build）全体をコピーするのが、最もシンプルで確実な方法です。

まとめ

ECS Fargateで Laravel + Inertia + React 構成を動かすための要点をまとめます。

1. 構成: 「1タスク2コンテナ（Nginx + PHP-FPM）」構成を採用します。
2. fastcgi_pass: NginxからPHP-FPMへの通信は、同一タスク内のため fastcgi_pass 127.0.0.1:9000; を指定します。
3. 静的ファイル: ビルドしたJS/CSSは、パフォーマンス最適化のためNginxコンテナに配置し、Nginxから直接配信させます。
4. manifest.json: HTMLシェル生成のため、PHP-FPMコンテナにも manifest.json が必要です。

この構成により、PHP-FPMは動的処理に専念し、Nginxは静的ファイルの高速配信に専念するという、「1コンテナ1責務」のメリットを最大限に活かした、スケーラブルな本番環境を構築できます。

個人開発で使用している以下スタックで画像を保存できない問題がおきた。

• Laravel10
• MinIO(S3の代わり)
• Intervention IMage 3

調査

Intervention IMage

Intervention IMage がVersion2 → Version3 で大きく変わったこともあり、使用法を疑ったが、何ら問題はなかった。

debug等の値を見て見たが、問題なし。。。

    /**
     * 画像をリサイズする.
     *
     * @param \Illuminate\Http\UploadedFile $file
     * @return \Intervention\Image\Interfaces\ImageInterface
     */
    public function resize(UploadedFile $file): ImageInterface
    {
        return $this->ImageManager
            ->read($file)
            ->resize(Media::BLOG_IMAGE_WIDTH, Media::BLOG_IMAGE_HEIGHT);
    }


    /**
     * 画像をS3にPutする.
     *
     * @param string $path
     * @param \Illuminate\Http\UploadedFile $file
     * @return bool
     */
    public function putForS3(string $path, UploadedFile $file): bool
    {
        $convertFile = $this->ImageManger->resize($file)->toPng();
        return $this->diskS3->put($path, $convertFile);
    }

minio への通信

ローカル環境をDockerを用いて開発していることもあり、ローカルネットワークが怪しいと何故か閃いた。

以下のコマンドを用いてネットワークを見たところ、同じネットワーク内に存在していたのでコンテナ間の通信は担保されている様子でした。

docker network ls
docker network inspect

ただし、 minio に向けた curl コマンドが返ってこないことが分かった。

原因

調査を進めていくと、サービス名に対してエンドポイントを指定しないといけないことが分かった。

minio:
    image: quay.io/minio/minio:RELEASE.2023-01-18T04-36-38Z
    container_name: 'discovery-gem_minio'

今回はminioとして登録していたので、 .env のエンドぽいとの指定が以下の様に設定する必要がありました。

AWS_ENDPOINT=http:{docker-compose.ymlで指定したport}//minio

たったこれだけのために頭を悩ましたのは悔しすぎる。

本業とは別に取り組んでいた個人開発でマネタイズができず、サービスを終了させてしまったのでここで供養させてください。

RIP My Service…

作ったもの

HP 兼 予約サイト 兼 ECサイトなるシステムを開発しました。

僕が沖縄県出身ということもあり、沖縄の個人経営を営んでいる小さな企業さんを相手に営業の肩代わりをすることを目的にシステムを開発しました。

というのも沖縄県は観光地として有名でありながらもHPすら持たず、地元の口コミのみで経営を行っているお店が多々ある状態でした。

せっかくの観光地でありながらお客様を呼び込めないのはかなりもったいないという思いから作った次第でございます。

技術構成

マネタイズポイント

物販購入

沖縄ならではの商品が展開されるEC機能を開発しました。

1商品当たり個別に x％ の手数料をいただく契約になります。

予約

美容院やレジャー施設の予約を受け付ける機能を開発しました。

こちらもEC同様に1予約あたり、x円の手数料 or オプション契約 のどちらかを契約する想定でした。

売り方

沖縄出身ではあるものの都内で勤務しているということもあり現地での営業活動ができないという状況でした。
そのため、現地で営業活動を行ってもらうために地元の友だちに「俺はこれから月100万円稼ぐシステムを開発するから営業をしてくれ」と大きく誇張した言い分を持って営業活動をしてもらいました。

その友人は面白そうだからという理由で快く引き受けてくれ、以下のマーケティング手法で営業を行ってもらいました。

• SNS
  • Instagram
  • Twitter
• ブログ

先に結論から入るのですが、期間としては6ヶ月間行ってもらい、皆さんの想像通り契約は1件も入らなかったです。

なぜ売れなかったのか

知名度

これは誰しもが考えることだと思うのですが 認知されていないサービスにお金を払う ことは避けたいはずです。

尚更、登記もしていない個人が開発したシステムに対して自分の命であるお金を注ぐことはあり得ないです。

考えられる手法としては以下の手法が取れるはずです。

• 正しい営業をする
• 受託等で知名度を得る
• その他のサービスで知名度を得る（知名度が無いことによる無限ループが発生する…）

お客様が安心してこのサービスにはお金を投資できると胸を張って言えるようなシステムを構築するのは難しいですね。。。

効果を得られるか不安

知名度がないという理由にも近しいですが、当システムを使用することで利益を得られることに対する不安を拭い去る事はできませんでした。

なぜなら契約が1件もないということは実績が無いということですからお客様からすると不安しかありません。

世の中のスタートアップはどうやって利益を得ているんですか？？

県民性

こちらは確固たるデータがある訳ではないんですが、ハードに仕事をしないという県民性を見誤っていた可能性がある事を感じています。

沖縄は「のんかーな性格（のんきな性格）」と呼ばれる人が多い印象です。

事実として僕の知っている沖縄の経営者では食べていける分を稼げて楽しい毎日を送ることが大切という人が多いです。（4人だけしか知りませんが…）

そういった考えを持っている人に対して業務を効率化して売上を伸ばしましょうなんて言っても「忙しくなるなら現状のままで」といった答えが返ってくるに決まっています。

そのあたりをしっかりと調査する or ターゲットを先に見つける事が大切かなぁという印象です。

反省

僕はゴミを作ってしましました。

誰にも使われないシステムなんてゴミです。ただのゴミクズです。

今回は僕一人と頭の悪い友人の時間だけが溶けただけで済んで本当に良かったです。（実際には5万ほど運用費としてお金を使いました。）

仮に起業という形でサービスを開発していた場合は廃業に大きく近づいていたので、個人開発の一環でここまでの勉強ができたのは僕の才能かもしれません。笑

まだまだ作りたいものはあるので引き続き頑張っていきたいですねぇ〜

表題の通り、Docker+Laravel+React+Viteで環境構築後にnpm run dev で画面が真っ白になってしまった。

docker --version
Docker version 20.10.6, build 370c289

php artisan --version
[22-Jul-2023 14:05:32 Asia/Tokyo] Xdebug: [Step Debug] Could not connect to debugging client. Tried: host.docker.internal:9000 (through xdebug.client_host/xdebug.client_port).
Laravel Framework 10.15.0

npm list --depth=0
data@ /data
+-- @headlessui/react@1.7.15
+-- @inertiajs/react@1.0.9
+-- @tailwindcss/forms@0.5.4
+-- @vitejs/plugin-react@3.1.0
+-- autoprefixer@10.4.14
+-- axios@1.4.0
+-- laravel-vite-plugin@0.7.8
+-- postcss@8.4.27
+-- react-dom@18.2.0
+-- react@18.2.0
+-- tailwindcss@

エラー文言

デベロッパーツール＞Console

GET http://127.0.0.1:5173/@vite/client net::ERR_CONNECTION_REFUSED
localhost/:25     GET http://127.0.0.1:5173/resources/js/app.jsx net::ERR_CONNECTION_REFUSED
localhost/:25     GET http://127.0.0.1:5173/resources/js/Pages/Welcome.jsx net::ERR_CONNECTION_REFUSED
localhost/:20     GET http://127.0.0.1:5173/@react-refresh net::ERR_CONNECTION_REFUSED

portがおかしい

ConsoleのリクエストURLからportがおかしいことに気づく。

Dockerのnginxで指定していたportは8080:80にしていたのだが、http://127.0.0.1:5173となっている。

うーん。なぜだ。

解決方法

Laravel,Reactを導入しているコンテナの設定が漏れている気がしてきた。

Dockerにてアプリケーションコンテナにportをしてみると解決できた。

docker-compose.ymlに以下を追記。

app:
    build: ./docker/php
    volumes:
      - ./src:/data
    ports:
    - 5173:5173  ←vite用port開通

そして、viteがホストを参照するようにするため、package.jsonに以下を追記。

"scripts": {
        "dev": "vite --host",   ←--hostを追記
        "build": "vite build"
    },

これで解決できた−