Skip to main content

第02章：完成形のイメージ図を作る🗺️✨

この章は「手を動かす前に、頭の中の地図を完成させる章」だよ😊🧠 ここができると、あとでリバースプロキシを入れても迷子になりにくい✨

🎯 目的（この章でできるようになること）​

  • 「入口は1個（80/443）」「中に複数アプリ」が一発で説明できるようになる🚪➡️🏠
  • “外（ブラウザ）” と “中（Dockerネットワーク）” を分けて考えられるようになる🌍🧱
  • URL・ルール・行き先を、図に落として整理できるようになる📝✨

🧠 まずは完成形の“結論”を1枚にする（超重要）​

完成形はこう👇

  • ブラウザは 80/443（HTTP/HTTPS）だけ見てる🌐
  • その入口に リバースプロキシが立ってる🚥
  • リバプロが、ホスト名（サブドメイン）やパスで、裏側のアプリに振り分ける🎯

🗺️ 図（外から見た図）：「入口は1個」だけ覚える🚪✨​

あなたのブラウザ
   |
   |  http(s)://app1.localhost
   |  http(s)://app2.localhost
   |  http(s)://api.localhost
   v
┌─────────────────────────┐
│  Reverse Proxy（入口）   │  : 80 / 443 だけ公開
└─────────────────────────┘
      |            |            |
      v            v            v
   app1         app2          api
（フロント） （管理画面）   （API）

ポイントはこれだけ🥳 「ブラウザが見るのは入口だけ」→「入口が中へ案内する」🚦➡️🏠

.localhost はローカル用途で扱いやすい“特殊用途”として整理されてるので、例として使うのに相性がいいよ🏷️✨（このあと章6で深掘りするやつ） (IETF Datatracker)

🐳 図（Dockerの中の図）：「中は名前でつながる」感覚を作る🌐​

Docker Compose で動かすと、コンテナ同士は同じネットワーク内でサービス名（≒名前）で見つけ合える感じになるよ👀✨ （Compose はデフォルトでネットワークを作って、その中でサービス名で到達できる、という整理） (Docker Documentation)

（Dockerの中 / Composeネットワーク内）

┌──────────────────────────────────────┐
│  proxy（リバースプロキシ）           │
│   - 入口: 80/443                      │
│   - 行き先: app1 / app2 / api          │
└───────────────┬───────────┬──────────┘
                │           │
                v           v
        ┌────────────┐  ┌────────────┐
        │ app1        │  │ app2        │
        │ (Vite等)    │  │ (管理画面)  │
        └─────┬──────┘  └─────┬──────┘
              │               │
              v               v
            ┌────────────────────┐
            │ api（Node/TS API） │
            └────────────────────┘

※ ここでは「proxy が app1:3000 に流す」みたいな発想でOK

✅ 手順（“図を作る手順”）— 5分でできるテンプレ📝✨​

ここからは「設計っぽいことを、難しい言葉なしで」やるよ😌🌱 順番どおりに埋めるだけでOK！

① URL一覧（ユーザーが触る入口）を3つ書く🌐​

例：

  • app1.localhost（メイン画面）🖥️
  • app2.localhost（管理画面）🔧
  • api.localhost（API）🧪

② “中のアプリ一覧”を3つ書く（サービス名の予定）🐳​

例：

  • app1（フロント）
  • app2（別フロント / 管理UI）
  • api（Node/TS API）

ここでのコツは、URL名とサービス名を近づけること😺 （あとで混乱しない✨）

③ ルールを書く（どれで振り分ける？）🎯​

  • ルールA：ホスト名で分ける（app1.localhost → app1）🏷️
  • ルールB：パスで分ける（localhost/app1 → app1）📁

この章では「完成イメージ図」なので、どっちでもOK。 ただし “完成形” がイメージしやすいのは ホスト名方式だよ（本番っぽさが出る）😊✨

④ “公開ポート”と“内部ポート”を分けて書く🔌​

  • 公開するのは proxy の 80/443だけ🚪
  • app1/app2/api は 外に出さない（中だけでOK）🫥

この「外に出す/出さない」を分けるのが、設計の最初の第一歩🥚➡️🐣

⑤ 最後に、図を清書する🧼✨​

  • 外の図：URL → proxy → アプリ
  • 中の図：proxy →（Composeネットワーク）→ サービス名で到達

この2枚が揃うと、次章以降が一気に楽になるよ🚀

😇 よくあるミス（今のうちに回避！）​

  • ミス1：入口が増える前提で考える → localhost:3000 とかを増やしていくと、最後に必ず混乱する😵‍💫 完成形は “入口1個” が基本方針ね🚪✨

  • ミス2：外のポートと中のポートをごちゃ混ぜにする → 「ブラウザが叩くポート」と「コンテナ同士のポート」は別世界🌍🏠 Composeはネットワークの中でサービス名で見つけられる、って発想が大事だよ (Docker Documentation)

  • ミス3：名前がバラバラで迷子になる → front / frontend / web が混ざると地獄👻 “命名ルール” は後でやるけど、今は 近い名前に寄せるだけでOK😊

🤖 AIに聞く例（コピペで使えるプロンプト集）​

AIは「図を作る」「抜けを見つける」が超得意だよ🧠✨ （Copilot/Codex系にそのまま投げてOK）

1) 完成形の図を、漏れなく作ってもらう

ローカル開発で「入口1個（80/443）＋複数アプリ」を作りたい。
URLは app1.localhost / app2.localhost / api.localhost。
Reverse Proxy を入口に置き、ホスト名で振り分ける前提で、
外から見た図とDocker内の図（proxy→各サービス）をASCIIで描いて。
また、外に公開すべきポートと、内部だけで良いポートを区別して。

2) 自分の図の“ツッコミどころ”を探してもらう

以下が私の完成形イメージ図です。矛盾や不足、混乱ポイントを指摘して、改善案を3つください。
（ここに自分の図を貼る）

3) 「ホスト名方式 vs パス方式」どっちが良いか相談

ローカルで複数アプリを共存させたい。ホスト名方式（app1.localhost）とパス方式（/app1）の
メリット/デメリットを、開発時のCORS・Cookie・WebSocket（HMR）観点で超やさしく説明して。
最後におすすめの選び方を結論で。

🧪 ミニ課題（10〜15分）— “自分のプロジェクト版”を作ろう🎒✨​

次の穴埋めを埋めて、外の図と中の図を手書きでもテキストでも作ってみてね✍️😊

穴埋めテンプレ

  • 入口URL：_____ / _____ / _____
  • 入口（proxy）が受けるポート：_____
  • 中のサービス名：_____ / _____ / _____
  • 振り分けルール：ホスト名 or パス（どっち？）→ _____
  • 外に公開するのは proxy 以外に必要？ → Yes / No（理由も一言）💡

できたら合格ライン🎉

  • 「入口は1個」って言い切れる
  • 「中はサービス名でつながる」って言い切れる (Docker Documentation)
  • URL→proxy→アプリが、矢印で説明できる

✅ 次章へのつながり（ちょい予告）👀✨​

この章の図が完成したら、次は「振り分けの3大パターン（ポート/パス/サブドメイン）」に入るよ🧠🔀 ここまでの“完成形の地図”があると、比較が一気にラクになる🥳