WEBリクエスト（80や443ポート）がWEBサーバーに来たときに、どうしてEC2インスタンスの中にあるDockerのアプリケーションを表示、実行できるのかわからなかったので調べた。
結論、Dockerデーモンがdocker-compose.ymlに書かれているマッピングを元に振り分けているようだ。

ステップ

ステップ1: リクエストの到着

ドメイン名解決: ユーザーがブラウザにURLを入力すると、DNSがドメイン名をIPアドレスに解決します。このIPアドレスは、あなたのEC2インスタンスに割り当てられています。

EC2へのリクエスト: リクエストはインターネットを介してこのIPアドレス（あなたのEC2インスタンス）に送信されます。

ステップ2: EC2インスタンスとWebサーバー

ポートリスニング: EC2インスタンス上で動作しているWebサーバー（例えばNginxやApache）は、80番ポート（HTTP）や443番ポート（HTTPS）でリクエストを待ち受けています。

リクエストの受信: Webサーバーはリクエストを受け取り、設定ファイル（例えばNginxの設定ファイル）に基づいて、そのリクエストをどのように処理するかを決定します。

ステップ3: Dockerコンテナへの転送

docker-compose.ymlとポートマッピング: docker-compose.ymlファイルで定義されたポートマッピングにより、外部からのリクエストがDockerコンテナの特定のポートに転送されるように設定されています。例えば、ports: - "80:8000"の設定は、EC2インスタンスの80番ポートからのリクエストを、Dockerコンテナの8000番ポートにマッピングします。

転送ルールの適用: Webサーバーは、リクエストを受け取ると、docker-compose.ymlで設定されたマッピングに従って、リクエストを内部のDockerコンテナに転送します。このプロセスは、Webサーバーの設定（リバースプロキシの設定など）とdocker-compose.ymlのポートマッピングの組み合わせによって実現されます。

ステップ4: コンテナ内の処理

コンテナ内でのリクエスト処理: Dockerコンテナ内のアプリケーション（この場合、8000番ポートでリッスンしているアプリケーション）はリクエストを受け取り、適切なレスポンスを生成します。

レスポンスの送信: 生成されたレスポンスは、同じ経路を逆にたどってユーザーのブラウザに送り返されます。

例によってchatGPTにレストランに例えてもらった

ステップ1: リクエストの到着 - レストランへの道案内

ドメイン名解決: 顧客（ユーザー）がレストランの住所（URL）を知りたいとき、彼らは案内板（DNS）に問い合わせます。案内板はレストランの住所を具体的な場所（IPアドレス）に変換し、顧客はその場所へ向かいます。

EC2へのリクエスト: 顧客がその場所（EC2インスタンス）に到着します。この場所はあなたが経営するレストランコンプレックスで、様々なレストラン（コンテナ）があります。

ステップ2: EC2インスタンスとWebサーバー - レセプションでの案内

ポートリスニング: レセプション（Webサーバー）は、入り口（80番ポートや443番ポート）で顧客を待ち受けています。

リクエストの受信: レセプションは顧客からの要望（リクエスト）を受け取り、彼らが何を求めているかを理解し、どのレストラン（コンテナ）に案内するかを決定します。

ステップ3: Dockerコンテナへの転送 - レストランへの案内

docker-compose.ymlとポートマッピング: 各レストラン（コンテナ）は特定の入り口（ポート）を持っています。たとえば、日本食レストランは入り口A（80番ポート）から入りますが、中華料理レストランは入り口B（8000番ポート）を使用します。

転送ルールの適用: レセプションは、顧客を適切なレストランへと案内します。これは、レセプションの指示（Webサーバーの設定）とレストランの入り口（ポートマッピング）に基づきます。

ステップ4: コンテナ内の処理 - レストランでのサービス

コンテナ内でのリクエスト処理: 顧客がレストラン（Dockerコンテナ）に到着すると、ウェイター（アプリケーション）が注文を受け、彼らのために料理（レスポンス）を準備します。

レスポンスの送信: 顧客は注文した料理を受け取り、満足してレストランを後にします。