コンテナ Docker/Podmanの用語集（31語）

.gitignoreと似た書式で、1行に1パターンを書く。node_modulesや.gitなど不要なものを除外することでビルドが速くなり、.envなどの秘密情報を誤ってイメージに含めてしまう事故も防げる。

同じbridgeに参加したコンテナ同士はIPアドレスで通信できるが、コンテナ名による名前解決の機能が限定的という弱点がある。実務ではユーザ定義ネットワークを別途作るのが定石とされる。

イメージのビルドからレジストリでの共有、コンテナの起動管理までを一つのコマンド体系で提供する。常駐するデーモンが本体で、dockerコマンドはその窓口にあたる。コンテナ技術の代名詞的な存在になっている。

compose.yamlにservicesとしてコンテナの構成を宣言的に書き、docker compose upでまとめて起動する。長いdocker runコマンドを何度も打つ代わりに、設定ファイルを読み書きする運用に置き換える。

FROM（ベース）・COPY（ファイル配置）・RUN（コマンド実行）などの命令を並べ、docker build でイメージを生成する。各命令が1つのレイヤになる。

FROMで元イメージを指定し、RUNやCOPYで加工手順を並べ、docker buildでイメージ化する。環境構築がコードとして残るため、同じ環境を誰でも再現できる。1命令ごとにレイヤが作られる仕組みも合わせて押さえたい。

docker コマンド（クライアント）からの指示を受け、イメージ管理やコンテナ起動を担う。Podman はこの常駐プロセスを必要としない設計。

プロセスが生きていることと、アプリが正常に応答できることは別物だ。healthcheckで定期的にチェックコマンドを実行し、失敗が続くとunhealthyと判定される。depends_onのcondition指定と組み合わせて起動順序の制御にも使う。

latestという名前のタグに何度でも別の中身を上書きpushできてしまうため、取得するたびに中身が変わっている可能性がある。本番運用では具体的なバージョン番号のタグを使うのが安全とされる。

RHEL系で標準的に使われる。コマンドはほぼ docker と同じで、常駐デーモンなしに一般ユーザ権限（rootless）でコンテナを動かしやすい。

常駐デーモンなしで動き、root権限のない一般ユーザーでも実行しやすい設計が特徴。dockerとほぼ同じサブコマンドが使え、別名設定だけで移行できる場面も多い。RedHat系ディストリビューションで標準的に採用される。

コンテナを作るための設計図にあたる。複数のレイヤが積み重なって構成され、レジストリで配布される。料理でいうレシピに相当する。

イメージから起動した実体がコンテナで、設計図と実物の関係に近い。docker pullでレジストリから取得し、同じイメージからは何個でも同一環境のコンテナを作れる。Dockerfileを書けば自作もできる。

タグ名は同じまま中身だけ上書きされることがあるが、ダイジェストは中身そのものから一意に定まるため、pullするイメージの中身を厳密に固定したいときに使う識別子になる。

アプリと必要なファイルをホストから隔離して動かす軽量な実行単位。1つのイメージから複数のコンテナを起動でき、消しても元のイメージは残る。

ホストOSのカーネルを共有しながらプロセスを隔離するため、仮想マシンより起動が速く消費リソースも少ない。「自分のPCでは動くのに」問題を防ぎ、開発環境の配布や本番デプロイの単位として広く使われる。

使うイメージ・公開ポート・ボリューム・環境変数などをまとめて1つの名前で定義したもの。webやdbのように役割ごとにサービスを分け、Compose上ではこの名前がそのままコンテナ間のホスト名としても使われる。

イメージ名にコロンで続けて指定する。省略すると latest が使われる。同じイメージの異なるバージョンを使い分けるための目印。

ホストで編集したソースコードが即座にコンテナ内へ反映されるため、開発中のコード共有によく使われる。保存先の管理をDockerに任せるボリュームと違い、ホスト側のパスを自分で指定して結びつける点が異なる。

docker run の -p ホスト:コンテナ で指定する。例: -p 8080:80 ならホスト8080番への通信がコンテナ80番へ転送される。

コンテナを消してもデータを残したいときに使う。-v でコンテナ内のパスに対応づけ、別のコンテナと共有することもできる。

コンテナ内への書き込みは本体を消すと失われるため、データベースの中身などはボリュームに置く。Docker側が管理する領域で、ホストの任意フォルダを直接つなぐバインドマウントとは管理のされ方が異なる。

前段のステージでコンパイラなどの道具を使ってビルドを行い、最終ステージではCOPY --from=で成果物だけを取り込む。ビルド専用の道具は最終イメージに残らないため、容量が小さく攻撃対象も減る。

既定のbridgeと異なり、参加したコンテナ同士はコンテナ名（または--nameの値）をそのままホスト名として使い、IPアドレスを意識せずに接続できる。Docker Composeもプロジェクトごとにこれを自動生成している。

万一コンテナから抜け出されてもホストのroot権限を奪われにくく、安全性が高い。Podmanが標準で対応し、Dockerにもルートレスモードがある。1024未満のポート使用など一部機能に制限が出る点は把握しておく。

Dockerfile の各命令ごとに作られる読み取り専用の層。共通レイヤは使い回されるため、保存容量やビルド時間を節約できる。

Dockerfileの命令ごとに層が作られ、変更のない層はキャッシュとして再利用される。共通部分を複数のイメージで共有できるため、容量と取得時間の節約になる。ビルドが速い・遅いの原因は層の切り方にあることが多い。

Docker Hub が代表例。docker pull で取得し、docker push で登録する。社内専用のプライベートレジストリも構築できる。

docker pullで取得し、docker pushで公開する、イメージ版の共有倉庫。公式イメージの配布元であると同時に、社内専用のプライベートレジストリを立てることもある。Gitのリモートリポジトリに相当する役割を担う。

python:slimのように開発ツールやドキュメントを削ったslim系、Alpine Linuxを土台にしたalpine系が代表例。容量は小さくなるが、alpine系は標準Cライブラリがmuslのため一部パッケージで互換性の問題が出ることがある。

on-failureは失敗時のみ、alwaysは常に、unless-stoppedは明示停止以外の場合に再起動する。落ちたコンテナを人手を介さず立て直すための基本設定になる。