第15章コンテナと実行環境

作ったものを他の環境で動かし続ける部である。コンテナで実行前提をそろえ、クラウドとCI/CDで届け、ログやメトリクスで観察する。インフラと運用で広く使う用語が中心になる。

この章では、アプリとDBを他の人の環境でも同じように起動するためのコンテナ用語を扱う。 DockerとDocker Composeを中心に、imageの作り方、service同士の接続、portやvolumeの考え方を、研修用アプリ（app serviceとdb service）の例で説明する。

container

読み：コンテナ（container）
一言で言うと：imageから起動した、実行中のアプリの単位。
くわしく：containerは、imageをもとに動き出した1つの実行環境である。同じimageから複数のcontainerを起動できる。containerの中のファイルは、containerを作り直すと消えることがある。だから消えると困るデータはvolumeに残す。「自分のPCでは動くが他の人の環境では動かない」を減らすために、実行前提をimageにまとめてcontainerで動かす。
具体例：支援ステータス機能のアプリを、app containerとdb containerの2つとして起動する。app containerがWebアプリを動かし、db containerがPostgreSQLを動かす。
つまずきやすい点：imageとcontainerを混同する。imageは設計図、containerは動いている実体である。
関連語：image（第15章）、Dockerfile（第15章）、volume（第15章）
テキスト本文での登場箇所：第15章「imageとcontainerを分けて理解する」

image

読み：イメージ（image／container image）
一言で言うと：コンテナを起動するための、読み取り専用テンプレート。
くわしく：imageは、アプリを動かすための前提（runtime、依存関係、ファイル、起動方法など）をひとまとめにした読み取り専用のテンプレートである。Dockerfileに作り方を書き、docker build でimageを作る。同じimageから何個でもcontainerを起動できる。imageにsecretを入れてはいけない。build時に決まる内容と、起動時に外から渡す内容を分けて考える。
具体例：支援ステータス機能のアプリを、docker build で1つのimageにまとめる。そのimageから、開発者それぞれが同じcontainerを起動できる。
つまずきやすい点：imageに .env やpasswordを焼き込むと、漏えいリスクになる。環境ごとに変わる値はrun時に渡す。
関連語：container（第15章）、Dockerfile（第15章）、registry（第15章）
テキスト本文での登場箇所：第15章「imageとcontainerを分けて理解する」

Dockerfile

読み：ドッカーファイル（Dockerfile）
一言で言うと：imageの作り方を1行ずつ記録するファイル。
くわしく：Dockerfileには、どのbase imageから始め、どこに作業ディレクトリを置き、依存関係をどう入れ、どのファイルをcopyし、どのcommandで起動するかを書く。単に動けばよいスクリプトではなく、後から読む人がアプリの実行環境を理解するための文書でもある。docker build はこのファイルを読んでimageを作る。base imageやcommandを選んだ理由も説明できるとよい。
具体例：支援ステータス機能のアプリ用に、FROM node:22 から始め、COPY package*.json ./ と RUN npm ci で依存関係を入れ、CMD ["npm", "start"] で起動するDockerfileを書く。
つまずきやすい点：例文を丸暗記するだけで、なぜその順番でcopyするか（依存関係installを再利用しやすくするため）を説明できないこと。
関連語：image（第15章）、build context（第15章）、base image（第15章）
テキスト本文での登場箇所：第15章「Dockerfileは、imageの作り方を記録する」

Docker

読み：ドッカー（Docker）
一言で言うと：imageを作り、containerとしてアプリを動かすための代表的なツール。
くわしく：Dockerは、Dockerfileからimageをbuildし、そのimageからcontainerをrunする一連の流れを提供するツールである。docker build でimageを作り、docker run でcontainerを起動する。複数のserviceをまとめて扱うときはDocker Composeを使う。コマンドを大量に暗記することより、imageとcontainer、build時とrun時の違いを説明できることが大切である。
具体例：支援ステータス機能のアプリを、Dockerでimage化し、app containerとして起動する。DBはDockerの公式PostgreSQL imageを使う。
つまずきやすい点：Dockerコマンドを覚えること自体を目的にしてしまう。まずはアプリの実行前提を説明できるようにする。
関連語：image（第15章）、container（第15章）、Compose（第15章）
テキスト本文での登場箇所：第15章「imageとcontainerを分けて理解する」

build

読み：ビルド（build）
一言で言うと：Dockerfileをもとに、imageを組み立てる作業。
くわしく：buildは、Dockerfileの手順に沿ってimageを作る処理である。docker build で実行する。依存関係のinstallはbuild時に行うことが多い。build時に必要なものと、container起動（run）時に必要なものは違う。DB passwordや接続先のように環境ごとに変わる値は、build時にimageへ焼き込まず、run時に渡す。何を先にcopyするとbuildのキャッシュを再利用しやすいかも、buildを設計するときの観点になる。
具体例：支援ステータス機能のアプリで package*.json を先にcopyしてから npm ci を実行し、依存関係のinstall結果をbuildで再利用しやすくする。
つまずきやすい点：build時に必要な値とrun時に必要な値を混ぜ、secretをimageに含めてしまう。
関連語：image（第15章）、Dockerfile（第15章）、build context（第15章）
テキスト本文での登場箇所：第15章「imageとcontainerを分けて理解する」

base image

読み：ベースイメージ（base image）
一言で言うと：自分のimageの土台にする、出来合いのimage。
くわしく：base imageは、Dockerfileの FROM で指定する出発点のimageである。runtimeや基本的な環境がすでに入っているので、その上に依存関係やアプリを足していく。どのbase imageを選ぶかで、imageの大きさ、含まれるツール、セキュリティ更新の状況が変わる。古すぎるbase imageは脆弱性のリスクになるので、第14章の依存関係確認とつなげて見る。
具体例：支援ステータス機能のNode.jsアプリで FROM node:22 を指定し、Node.js 22が入ったbase imageの上にアプリを載せる。
つまずきやすい点：base imageのversionを意識せず、古いものを使い続けて脆弱性を抱える。
関連語：Dockerfile（第15章）、image（第15章）、依存関係（第14章）
テキスト本文での登場箇所：第15章「Dockerfileは、imageの作り方を記録する」

build context

読み：ビルドコンテキスト（build context）
一言で言うと：imageを作るときにDockerへ渡すファイルの範囲。
くわしく：build contextは、buildの際にDockerへ送られるファイルやディレクトリの集まりである。Dockerfileで COPY . . と書いたとき、どのファイルが候補になるかに関わる。何でも入れてよいわけではなく、不要なファイルを含めるとbuildが遅くなり、imageも大きくなる。生成物や依存ディレクトリ、secretを含めると、環境差分や漏えいの原因になる。何を渡すかは .dockerignore で制御する。
具体例：支援ステータス機能のアプリをbuildするとき、node_modules や .env をbuild contextから外し、必要なソースだけをimageへ入れる。
つまずきやすい点：build contextを意識せず、.env やログまでimageに含めてしまう。
関連語：.dockerignore（第15章）、image（第15章）、build（第15章）
テキスト本文での登場箇所：第15章「build contextと.dockerignoreを意識する」

.dockerignore

読み：ドッカーイグノア（.dockerignore）
一言で言うと：build contextから除外するファイルを書くファイル。
くわしく：.dockerignore は、buildのときにimageへ渡したくないファイルやディレクトリを書くファイルである。.gitignore のDocker版だと考えると分かりやすい。.git、node_modules、.env、coverage、tmp、logsなどを除外候補にする。これによりbuildが速くなり、imageが小さくなり、secretの混入も防げる。逆に必要なファイルまで除外すると、container内でファイルが足りず起動しない原因になる。
具体例：支援ステータス機能のアプリで .dockerignore に .env を書き、実際のsecretを含む .env がimageへ入らないようにする。
つまずきやすい点：除外しすぎて必要なファイルまで消し、起動失敗の原因にする。
関連語：build context（第15章）、.gitignore（第14章）、.env.example（第5章）
テキスト本文での登場箇所：第15章「build contextと.dockerignoreを意識する」

Compose

読み：コンポーズ（Docker Compose）
一言で言うと：複数のcontainerをまとめて定義し、一度に起動する仕組み。
くわしく：Docker Composeは、appやDBなど複数のserviceを1つのファイル（Compose file）に書き、まとめて起動・停止できる仕組みである。コマンドを短くするためだけではなく、serviceどうしの関係を説明する文書にもなる。docker compose up で起動し、docker compose ps や docker compose logs で状態を確認する。各serviceのimage、port、volume、environmentをまとめて見渡せる。
具体例：支援ステータス機能のアプリを、app serviceとdb serviceとして1つのCompose fileに定義し、docker compose up で同時に起動する。
つまずきやすい点：AIが出した古いCompose記法を、公式資料や実行結果と照合せずに採用する。
関連語：service（第15章）、depends_on（第15章）、volume（第15章）
テキスト本文での登場箇所：第15章「Composeは、複数serviceの関係を記録する」

service

読み：サービス（service）
一言で言うと：Composeで定義する、1つの役割を持ったcontainerのまとまり。
くわしく：serviceは、Compose fileの中で定義する1つの構成単位である。それぞれのserviceがどのimageを使い、どのportを公開し、どのvolumeを使い、どの環境変数を持つかを書く。Composeの中ではservice名が接続先の名前として使える。たとえばDB serviceの名前が db なら、app containerからは DB_HOST=db で接続する。serviceに分けることで、アプリとDBの関係が説明しやすくなる。
具体例：支援ステータス機能で app（Webアプリ）と db（Database）の2つのserviceを定義し、app から db へservice名で接続する。
つまずきやすい点：app serviceからDBへ localhost で接続しようとする。Compose内では相手のservice名を使う。
関連語：Compose（第15章）、network（第15章）、port mapping（第15章）
テキスト本文での登場箇所：第15章「Composeは、複数serviceの関係を記録する」「service名で接続する」

network

読み：ネットワーク（network）
一言で言うと：container同士が名前で通信するための、つながりの仕組み。
くわしく：Composeで複数のserviceを起動すると、それらは同じnetworkに置かれ、service名で互いに通信できる。このため、container同士の通信（service名を使う）と、自分のPCからcontainerへの通信（host側portを使う）を分けて考える必要がある。containerの中の localhost は、そのcontainer自身を指す。app containerの中から localhost と書いても、db containerには届かない。
具体例：支援ステータス機能で、app containerはComposeのnetworkを通じて db という名前でdb containerへ接続する。ブラウザからは http://localhost:3000 でapp containerを見る。
つまずきやすい点：container内の localhost を、別のcontainerやhostと同じだと思い込む。どこから見たlocalhostかを確認する。
関連語：service（第15章）、port mapping（第15章）、host（第15章）
テキスト本文での登場箇所：第15章「service名で接続する」

host

読み：ホスト（host）
一言で言うと：containerを動かしている側の、自分のPCやサーバー本体。
くわしく：hostは、Dockerやcontainerを実行している土台のマシンである。port mappingやbind mountを考えるときは、host側とcontainer側を分けて見る。host側のportは、自分のPCのブラウザからアクセスするときの番号である（第5章のポート概念と関連する）。container側のportは、container内のアプリが待ち受ける番号である。host側のportを別のプロセスが使っていると、起動時にport競合が起きる。
具体例：支援ステータス機能で "8080:3000" と書くと、host（自分のPC）の8080番が、app container内の3000番につながる。
つまずきやすい点：host側portとcontainer側portを混同して、どこにアクセスすればよいか分からなくなる。
関連語：port mapping（第15章）、network（第15章）、bind mount（第15章）
テキスト本文での登場箇所：第15章「service名で接続する」「port mappingは、host側とcontainer側を分ける」

port mapping

読み：ポートマッピング（port mapping）
一言で言うと：host側のportとcontainer側のportをつなぐ設定。
くわしく：port mappingは、自分のPC（host）のportと、container内でアプリが待ち受けるportを対応づける設定である。Composeでは "3000:3000" のように書き、左がhost側、右がcontainer側である。"8080:3000" なら、ブラウザでは8080番にアクセスし、container内では3000番でアプリが動く。port周りで詰まったら、アプリがlistenしているport、Composeが公開しているhost port、そのhost portが他プロセスと競合していないか、見ているURLが正しいかを分けて確認する。host側portは第5章のポート概念と関連する。
具体例：支援ステータス機能のapp serviceに ports: - "${APP_PORT:-3000}:3000" と書き、ブラウザから http://localhost:3000 で確認する。
つまずきやすい点：左右どちらがhostかを取り違える。左がhost、右がcontainerである。
関連語：host（第15章）、service（第15章）、環境変数（第5章）
テキスト本文での登場箇所：第15章「port mappingは、host側とcontainer側を分ける」

volume

読み：ボリューム（volume）
一言で言うと：containerを作り直しても消えてほしくないデータを残す仕組み。
くわしく：containerの中のファイルは、containerを作り直すと消えることがある。DBのデータやアップロードファイルのように、消えると困るものはvolumeに残す。Composeでは、volumes: で名前付きのvolume（named volume）を定義し、serviceから参照する。volumeを消す操作は、データを消す操作である。「一度消してやり直したら動いた」で終わらせず、何が消え、なぜ動いたのかを説明できるようにする。
具体例：支援ステータス機能のdb serviceで db-data:/var/lib/postgresql/data を指定し、containerを作り直してもPostgreSQLのデータを残す。
つまずきやすい点：volumeを消す意味を理解せず、DBデータを失う。
関連語：bind mount（第15章）、named volume（第15章）、service（第15章）
テキスト本文での登場箇所：第15章「volumeは、消えて困るデータを残すために使う」

named volume

読み：ネームドボリューム（named volume）
一言で言うと：名前をつけてDockerに管理させる、永続データ用のvolume。
くわしく：named volumeは、db-data のように名前をつけたvolumeで、Dockerが場所を管理する。Compose fileの volumes: セクションで定義し、serviceから参照する。host上の特定パスを直接指すbind mountと違い、データの置き場所をDockerに任せられるので、DBデータの永続化に向いている。containerを作り直しても、同じnamed volumeを参照すればデータが残る。
具体例：支援ステータス機能で db-data というnamed volumeを定義し、db serviceの /var/lib/postgresql/data に割り当ててDBデータを永続化する。
つまずきやすい点：bind mountと役割を混同する。bind mountは開発中の変更反映、named volumeはデータ永続化が主な目的である。
関連語：volume（第15章）、bind mount（第15章）、service（第15章）
テキスト本文での登場箇所：第15章「Composeは、複数serviceの関係を記録する」「volumeは、消えて困るデータを残すために使う」

bind mount

読み：バインドマウント（bind mount）
一言で言うと：host上のファイルやフォルダを、container内に直接見せる仕組み。
くわしく：bind mountは、host側の特定のファイルやディレクトリを、container内へそのまま見せる仕組みである。開発中は、ソースコードをbind mountしておくと、host側で編集した変更がcontainerへすぐ反映され、開発しやすい。これはDBデータを残すためのvolumeとは目的が違う。bind mountは開発の便利さ、DB volumeはデータの永続化のために使う。本番相当では、bind mountに頼らずbuild済みimageを使うことが多い。
具体例：支援ステータス機能の開発時に、アプリのソースをbind mountして、コードを直すたびにcontainerを作り直さずに変更を反映する。
つまずきやすい点：bind mountとvolumeを同じものと考える。前者は開発用の反映、後者は永続化が主目的である。
関連語：volume（第15章）、named volume（第15章）、host（第15章）
テキスト本文での登場箇所：第15章「開発用と本番相当の違いを分ける」「volumeは、消えて困るデータを残すために使う」

environment variable

読み：環境変数（environment variable）
一言で言うと：環境ごとに変わる設定を、コンテナへ外から渡す仕組み（→第5章）。
くわしく：環境変数そのものは第5章で扱う。この章では、コンテナでどう渡すかに絞る。DB接続先、DB user、DB name、app port、ログレベルなどを、imageに焼き込まずcontainer起動時に外から渡す。Composeの environment: で指定するか、.env から読み込む。build時に必要な値とrun時に必要な値を分けることで、secretをimageへ入れてしまう危険を避けられる。
具体例：支援ステータス機能のapp serviceに DB_HOST: db や DB_PASSWORD: ${DB_PASSWORD} を渡し、環境ごとに値を変えられるようにする。
つまずきやすい点：環境ごとに変わるsecretをimageに焼き込んでしまう。run時に渡す。
関連語：環境変数（第5章）、.env.example（第15章）、build（第15章）
テキスト本文での登場箇所：第15章「環境変数と.env.exampleを分ける」

.env.example

読み：ドットエンブサンプル（.env.example）
一言で言うと：必要な変数名と安全な見本値を共有するためのファイル（→第5章）。
くわしく：詳細は第5章で扱う。この章では、コンテナの文脈での扱いに絞る。.env はローカルで便利だがGitにcommitしない。一方 .env.example は、必要な変数名と安全な例（dummy-password など）を共有するために使い、実際のsecretは入れない。第14章のsecret確認と同じく、本物のpasswordをREADME、PR本文、ログ、AI入力に含めない。
具体例：支援ステータス機能で .env.example に DB_PASSWORD=dummy-password と書き、本物のpasswordは各自の .env だけに置く。
つまずきやすい点：.env.example に実際のsecretを書いてしまう。見本値だけにする。
関連語：.env.example（第5章）、environment variable（第15章）、.dockerignore（第15章）
テキスト本文での登場箇所：第15章「環境変数と.env.exampleを分ける」

depends_on

読み：ディペンズオン（depends_on）
一言で言うと：Composeでservice間の起動順の依存を表す設定。
くわしく：depends_on は、Composeであるserviceが別のserviceに依存することを示す設定である。ただし、depends_on: - db と書くだけでは起動の順番を制御するだけで、DBが接続を受け付ける準備まで終わったことは保証しない。DB processが起動しても、まだ接続を受けられないことがある。「起動したこと」と「使える状態であること」は別である。確実に待ちたい場合は、healthcheckと条件付きの depends_on を組み合わせる。
具体例：支援ステータス機能でapp serviceに depends_on: - db を書いてdbを先に起動させつつ、DBが使えるかはログやhealthcheckで確認する。
つまずきやすい点：depends_on だけでDBが利用可能だと思い込む。ログやhealthcheckで状態を見る。
関連語：healthcheck（第15章）、service（第15章）、Compose（第15章）
テキスト本文での登場箇所：第15章「depends_onは、起動順と利用可能状態を分けて考える」

healthcheck

読み：ヘルスチェック（healthcheck）
一言で言うと：serviceが本当に使える状態かを判定する仕組み。
くわしく：healthcheckは、containerが起動しただけでなく、実際にリクエストを受けられる状態（healthy）かどうかを判定する仕組みである。Composeでは、healthcheckと条件付きの depends_on を組み合わせて、依存先がhealthyになってからserviceを起動する構成も取れる。研修では細かい記法を暗記しなくてよい。大切なのは、「起動した」ことと「使える状態である」ことを分けて確認する考え方である。
具体例：支援ステータス機能で、db serviceにhealthcheckを設定し、DBがhealthyになってからapp serviceを起動するようにする。
つまずきやすい点：起動済み（running）とhealthy（使える）を同じものと考える。両者は別である。
関連語：depends_on（第15章）、service（第15章）、Compose（第15章）
テキスト本文での登場箇所：第15章「depends_onは、起動順と利用可能状態を分けて考える」

registry

読み：レジストリ（registry）
一言で言うと：imageやパッケージを保管し、配布する場所。
くわしく：registryは、imageや依存パッケージを置いて共有するための保管場所である。base imageはpublicなimage registryから取得することが多い。本番相当では、自分でbuildしたimageをregistryに置き、そこから各環境で取得して動かす（registry image）。依存関係も、外部のpackage registryからアプリへ入る。registryから何を取り込むかは、第14章の依存関係やsecretの観点ともつながる。
具体例：支援ステータス機能のapp imageをregistryに置き、staging環境やproduction環境はlocal buildではなくregistry imageを使う、と環境差分の表に書く。
つまずきやすい点：localでbuildしたimageと、registryから取得するimageの違いを意識しないこと。
関連語：image（第15章）、base image（第15章）、依存関係（第14章）
テキスト本文での登場箇所：第14章「情報が渡る場所を線で見る」、第15章「local、staging、productionの差分を書く」

Twelve-Factor App

読み：トゥエルブファクターアップ（The Twelve-Factor App）
一言で言うと：環境差分を設定として外出しするなど、運用しやすいアプリの作り方をまとめた原則集。
くわしく：設定を環境変数で渡す、依存関係を明示する、ログを標準出力へ流す、といった項目を挙げ、同じコードを別環境で安全に動かせるようにする考え方である。コンテナやクラウドで「手元では動くが本番で動かない」を減らすときの土台になる。すべてを厳密に守る必要はないが、環境差分の扱い方の基準として役立つ。
具体例：支援ステータス機能を手元・staging・本番で動かすとき、接続先やsecretをコードに書かず環境変数で渡せば、同じimageを環境ごとに使い回せる。
つまずきやすい点：原則名を覚えることが目的ではない。設定を環境変数で外出しする、という実際の扱いに落とすことが大事である。
関連語：環境変数（第5章）、.env.example（第5章）、secret（第14章）
テキスト本文での登場箇所：第15章「開発用と本番相当の違いを分ける」

第15章 コンテナと実行環境