コンテナとは何か

はじめに

Dockerをはじめとするコンテナ技術を利用して開発を行う人は少なくないと思います。
普段意識せずに使用しているコンテナ、これらはどのように定義や実装をされているのでしょうか。
本記事では、コンテナとは何かを

1. 公式ドキュメントなどの定義
2. Linuxカーネル
3. 実際のプロセスの観察

の 3 つの観点から確認します。
事前にこちらを読んでおくと事前知識として少しだけに役立つかもしれません。

https://zenn.dev/ka_kan/articles/9554371342d8a6

コンテナとは

まずはコンテナという言葉を、仕様書や公式ドキュメントなどから整理します。

OCI Runtime Specによるコンテナ定義

OCI Runtime Specificationの用語集では、コンテナ（container）を定義しています。
日本語では、プロセスを実行するための環境であり、隔離とリソース制限を設定できるもの。と訳すことができます。

Red HatによるLinuxコンテナの解説

Red Hatの「What is a Linux container?」では、Linux コンテナを「1つ以上のプロセスの集合であり、システムの残りから隔離されている」「それらを動かすために必要なファイルは、専用のイメージから提供される」ものと説明しています

Dockerによるコンテナの定義

Dockerのページではコンテナのことを「コンテナとは、コードとその依存関係をパッケージ化したソフトウェアの標準単位であり、アプリケーションが異なるコンピューティング環境間で迅速かつ確実に動作することを可能にします。Dockerコンテナイメージは、アプリケーションの実行に必要なすべて（コード、ランタイム、システムツール、システムライブラリ、設定）を含む軽量で独立した実行可能ソフトウェアパッケージです。」
のような説明をしています。

また、Docker docsでは「コンテナはアプリケーションの各コンポーネントごとに隔離されたプロセスです。」と定義されています。
下記のような記述がありました。

• 自己完結型：各コンテナは動作に必要な全てを備えており、ホストマシンに事前インストールされた依存関係に依存しません。
• 隔離型：コンテナは隔離された状態で実行されるため、ホストや他のコンテナへの影響が最小限に抑えられ、アプリケーションのセキュリティが向上します。
• 独立型：各コンテナは個別に管理されます。1つのコンテナを削除しても他のコンテナには影響しません。
• ポータブル性：コンテナはどこでも実行可能！開発マシンで動作するコンテナは、データセンターやクラウド環境でも全く同じ動作をします。

上記の情報からコンテナとは

ここまでの一次情報をまとめると、コンテナにはだいたい次のような共通したイメージがあります。

• コンテナはプロセスを実行するための環境である。
• その環境は隔離されており（他のプロセスやシステムから分離されている）、リソース制限をかけられる（CPU・メモリなど）。

ということがわかります。

Linuxではコンテナをどう表現しているか

コンテナはUNIX系、Linuxで使用されることがしばしばあります。
これらを調べてみると、namespaceやcgroupsに辿り着きました。

namespace

Linuxのnamespaceのmanページには、下記の記述がありました。（日本語訳）

名前空間の用途の 1 つは、コンテナを実装することです。

cgroups

また、cgroupsのmanページですが、ubuntuのドキュメントにて

制御グループ（cgroups）は、システムリソースの管理と分割を可能にする強力なLinuxカーネル機能です。その中核として、cgroupsはユーザーがプロセスの集合に対してハードウェアリソース（CPU、メモリ、ディスクI/O、ネットワーク帯域幅など）の使用量を割り当て、優先順位付けし、制限することを可能にします。この機能は、systemdやコンテナ化といった技術の基盤を提供し、現代のUbuntuシステムの安定性とセキュリティにとって不可欠です。

という記述があり、コンテナ化について記述があります。

Linuxのコンテナとは

namespaceによってプロセス一覧、マウントポイント、ホスト名、ネットワークなどを分け、cgroupsによってCPU、メモリなどを制限することで、コンテナという概念を実現しています。
※Linuxにはコンテナという専用の機能はありませが、namespaceやcgroupsなど複数の機能を組み合わせることで、コンテナと呼ばれるような隔離・制限された実行環境を作っています。

実験：コンテナの実体を/procから確かめる

今回は、コンテナ内で動いているものがLinuxからはプロセスとして見えていることを確認します。
Dockerを使用して確認します。

Dockerの確認

# Docker が動いているか確認
docker version

# Linux VM 上でコンテナが動いていることを確認
docker run --rm alpine:3.20 uname -a
# 例: Linux d0d4f9b0f4aa 6.x.x ... のような出力になればOK

実際に確認

docker run -it --rm \
  --name host-view \
  --pid=host --uts=host --net=host \
  --privileged \
  alpine:3.20 sh

--pid=hostを指定することで、このコンテナはホストと同じPID名前空間を共有します。
そのため、別ターミナルで起動したtestコンテナ内のプロセスも、host-viewコンテナからは「ホストプロセス」としてpsや/proc経由で確認できます。

######コンテナ内
# VM内のカーネルバージョン
uname -a 
ps -o pid,ppid,cmd | head
echo "host-view のPID: $$"

別ターミナルからコンテナを起動

docker run -d --name test alpine:3.20 sleep infinity
docker ps
docker inspect -f '{{.State.Pid}}' test
# 例: 12345

hostで確認

PID_TEST=12345   # 別ターミナルで出てきた数字に置き換え

ps -o pid,ppid,comm | grep "$PID_TEST"
ls -l "/proc/$PID_TEST"

上記より、sleepを実行しているプロセスであることが確認できます。

まとめ

公式ドキュメントから、コンテナは隔離とリソース制限を備えたプロセス実行環境と整理できました。
Linuxでは、namespaceとcgroupsを中心とした複数の機能の組み合わせで、この環境を実現しています。
実際に /procを確認すると、コンテナ内の処理は最終的にLinuxのプロセスとして表現されていることがわかりました。
また、今回の実験からコンテナ内で動いているものの実体はLinuxのプロセスであり、namespace や cgroups によって「隔離・制限されたプロセス（の集合）」として扱われていることがわかりました。
学習の補助になれば幸いです。

参考

OCI Runtime Specificationの用語集
Red Hatの「What is a Linux container?」
cgroupsのmanページ
ubuntuのドキュメント