Skip to main content

第42章：FROM（ベース選びの考え方）🏗️

1) FROMって結局なに？🍞➡️🥪​

Dockerfileの FROM は「このイメージを土台にして作ります」の宣言だよ📣 土台を変えると、同じアプリでも👇がガラッと変わる😳

  • 起動できる/できない（互換性）⚠️
  • イメージサイズ（重い/軽い）🐘🐇
  • 依存ライブラリの入れやすさ（ビルドのラクさ）🧰
  • セキュリティの面倒さ（更新・脆弱性）🛡️
  • デバッグのしやすさ（シェルある？）🕵️‍♂️

2) まず結論：初心者が最初に選ぶならコレ👍✨​

迷ったら、まずは 公式の Node イメージの“標準（Debian系）” を土台にすると事故りにくいよ😄 公式側でも「迷ってるならコレ」扱いの位置づけになってる💡 (GitHub)

おすすめのスタート例👇

  • 開発・学習でまず安定を取りたい：node:24（標準）✅
  • 少し軽くしたい（でも安定寄り）：node:24-slim（ただし罠あり）⚖️
  • 最小サイズ重視：node:24-alpine（ただし互換性の罠あり）🪶⚠️

ここで “24” にしている理由：本日時点で Node v24 が Active LTS（本番向け推奨ゾーン）だからだよ📌 (nodejs.org)

3) 「Nodeのバージョン」をどう決める？🔢🤔​

まず FROM node:XX の XX（Nodeのメジャーバージョン） を決めよう🧠

✅ 基本ルール​

  • 本番想定なら Active LTS / Maintenance LTS を使う（Node公式の推奨） (nodejs.org)
  • node 公式イメージも、“サポート中の Node バージョン”を追う方針 (GitHub)

2026-02-08 時点の目安（Node公式の表）​

  • v24：Active LTS ✅
  • v22 / v20：Maintenance LTS ✅
  • v25：Current（実験寄り）⚠️ (nodejs.org)

なので学習カリキュラム的にも、基本は v24（Active LTS） を推しにするのが自然だよ😊 (nodejs.org)

4) 「OSの種類（派生）」をどう決める？🧱🐧​

同じ node:24 でも、後ろにいろいろ付くよね👇

  • node:24（標準）
  • node:24-slim
  • node:24-alpine
  • node:24-bookworm / node:24-trixie …など

4-1) 標準（Debian系）＝最初の安心枠🧸​

公式では標準タグが「迷うならこれ」枠で、よく使う Debian パッケージが多めに入っててラクだよ🧰 (GitHub) 学習・開発ではこれが本当に強い💪😄

4-2) slim＝軽いけど、困った時に困る😇​

slim は「Node を動かす最小構成」寄りで、標準に入ってる“よくある便利パッケージ”が無いよ📦 そして公式も「よほど理由がないなら標準推奨」って明言してる⚠️ (GitHub)

slim を選ぶのは、だいたい👇みたいなとき：

  • 会社やCIで「サイズ制限が厳しい」🐇
  • “必要なものだけ自分で入れる” をちゃんと設計できる🧑‍🔧

4-3) alpine＝超軽いけど、互換性の地雷あり💣​

alpine はめちゃ軽い（ベースが小さい）🪶 ただし glibc じゃなくて musl libc を使うから、ネイティブ系が絡むと詰まることがあるよ😵 (GitHub)

さらに「process.dlopen で必要な共有ライブラリが無い」みたいな問題もあり得て、 Alpine のバージョンによって libc6-compat や gcompat を入れる話が公式に書かれてる📌 (GitHub)

なので結論：

  • 初学者の序盤は alpine を“最初の選択”にしないのが安全😊
  • サイズが最優先になったタイミングで、目的を持って選ぶのが◎

4-4) Debianの世代名（bullseye/bookworm/trixie）って何？📚​

Node公式イメージは Debian を土台にしたタグがあり、世代があるよ👇

  • bullseye = Debian 11
  • bookworm = Debian 12
  • trixie = Debian 13 (GitHub)

基本は「指定がなければメンテ側が移行する」こともあるので、固定したいなら bookworm まで書くのが分かりやすい👍

5) もう一段上：Distroless（上級寄り）🧊🛡️​

「本番の最終イメージを極限まで小さく・安全寄りに」なら distroless という考え方があるよ😎 distroless は パッケージマネージャやシェル等を入れないので、余計なものが無くて小さい🧼 (GitHub)

ただし注意⚠️

  • シェルが無いので、Dockerfile の書き方（exec形式）も気を付ける必要あり🕳️ (GitHub)
  • デバッグが難しい（だから :debug タグが用意されてたりする）🕵️‍♂️ (GitHub)

Node向けには gcr.io/distroless/nodejs24-debian12 みたいに LTS向けタグがあるよ📌 (GitHub) （この教材の流れだと、最終章付近で「本番最終形」として触るのが気持ちいい😄）

6) タグ固定の考え方：latest は避けよう🙅‍♂️​

FROM node:latest みたいなのは、いつの間にか中身が変わって壊れやすい😇

✅ 安定の順番（おすすめ）​

  1. node:24（メジャー固定。ほどよく追従）🙂
  2. node:24-bookworm（OS世代も固定）🙂🙂
  3. node:24.13.0-bookworm（より固定、更新管理は自分）🧑‍🔧

🔒 ガチ固定：digest（ハッシュ）で固定​

Docker公式も「タグは変わり得るが digest は不変」って説明してるよ📌 (Docker Documentation) 本番の“完全再現”やサプライチェーン対策だと digest 固定が強い💪

7) ハンズオン：ベースを変えて「差」を体感しよう🎮✨​

この章はまだ COPY や RUN を深くやってない段階でも大丈夫👌 「Nodeが動く土台」を変えるだけの超ミニ実験をするよ😄

7-1) まずは “そのまま run” で比較（いちばん簡単）🏃‍♂️​

PowerShell でもOKだよ🪟✨

docker run --rm node:24 node -p "process.version"
docker run --rm node:24-slim node -p "process.version"
docker run --rm node:24-alpine node -p "process.version"

次にサイズを見る👀

docker image ls node

「alpine が軽い！」「slim も軽い！」「標準はちょい重い！」みたいな感触が掴めれば勝ち🏆✨

7-2) Dockerfile で FROM を差し替える実験🧪​

適当なフォルダを作って、Dockerfile を3つ作るよ📁

Dockerfile.default​

FROM node:24
CMD ["node", "-p", "process.version"]

Dockerfile.slim​

FROM node:24-slim
CMD ["node", "-p", "process.version"]

Dockerfile.alpine​

FROM node:24-alpine
CMD ["node", "-p", "process.version"]

ビルドして実行👇

docker build -f Dockerfile.default -t from-lab:default .
docker build -f Dockerfile.slim    -t from-lab:slim .
docker build -f Dockerfile.alpine  -t from-lab:alpine .

docker run --rm from-lab:default
docker run --rm from-lab:slim
docker run --rm from-lab:alpine

最後にサイズ比較👇

docker image ls from-lab

これで「FROM を変えると何が変わるか」が体で入るよ😄✨

8) ベース選びの“判断早見表”📌✨​

迷ったらこの表でOK🙆‍♂️

  • 学習/開発（まず動かす・デバッグしやすい） 👉 node:24 ✅

    • “よくあるパッケージ多め”でラク (GitHub)

  • 少し軽く（でも Debian 系で安定） 👉 node:24-slim ⚖️

    • ただし “入ってないもの”が増える。公式も標準推し (GitHub)

  • 最小サイズ優先 👉 node:24-alpine 🪶

    • musl/glibc 差でハマる可能性あり (GitHub)

  • 本番最終形をガチで小さく安全寄り 👉 distroless 🧊🛡️

    • シェル無し等の制約あり (GitHub)

9) AI活用（Copilot / Codex 等）🤖✨​

この章でAIにやらせると強いのは「判断」と「理由の言語化」だよ🧠

プロンプト例（そのまま貼ってOK）📋​

  • 「Node API + Prisma + sharp を使う予定。node:24 / slim / alpine のどれが安全？理由と注意点を3つ」
  • 「今の Dockerfile の FROM を node:24-slim に変えたら起きがちな失敗を、症状→原因→対策で表にして」
  • 「“タグ固定の戦略”を、個人開発向けに：安全・手間・更新頻度のバランスで提案して」

10) よくある落とし穴（先に知って勝つ😄）🪤​

  • slim にして「curl ない！git ない！」みたいな“便利不足”で詰まる😇 (GitHub)
  • alpine にしてネイティブ依存で詰む（musl 由来）😵 (GitHub)
  • latest を使って、ある日突然 CI が壊れる💥（タグは変わり得る） (Docker Documentation)
  • “完全再現したい”のにタグ固定しかしてなくて、微妙にズレる😇（digest は不変） (Docker Documentation)

11) ミニ問題（理解チェック✅）​

  1. node:24-alpine が軽い理由を一言で言うと？🪶
  2. slim を選ぶ時に、先に疑うべき「無いもの」は何？（例：◯◯が無い）🧰
  3. 本番で node:25（Current）を避けたくなる理由は？🔢
  4. digest 固定が強いのはなぜ？🔒 (Docker Documentation)

12) まとめ🏁🎉​

  • FROM は「土台」だから、互換性・サイズ・安全・デバッグ全部に効く🏗️
  • まずは node:24（Active LTS） で安定させるのが強い✅ (nodejs.org)
  • 軽量化は slim → alpine の順で“目的を持って”やるのが安全⚖️🪶 (GitHub)
  • 本番の完全再現や安全性を上げたいなら digest 固定も視野🔒 (Docker Documentation)
  • distroless は強いけど、使いどころは後半の“本番最終形”が気持ちいい🧊🛡️ (GitHub)

次の第43章（WORKDIR）に行くと、Dockerfile が一気に「迷子にならない書き方」になってくるよ🧭✨