質問

画像引用元
https://www.ydc.co.jp/column/0002/20171004.html

コンテナ型仮想化のDockerでホストと異なるOSをゲストで動かせるのはなぜですか？

ハイパーバイザ型は物理マシンを仮想的に再現するのでゲストに任意のOSをインストールして任意のOSを動かすことが出来るのは理解できます。
しかし、コンテナ型はホストOSをゲストと共有しているのでゲストにOSをインストールする事が出来ないはずです。

しかし、コンテナ型であるDockerを実際に試してみると以下のようにホスト型とは異なるOSが動いているように見えます。（ホストはUbuntuです）

$ docker run -it centos
[root@444c52a9d7ea /]# cat /etc/redhat-release 
CentOS Linux release 8.3.2011

これはどのような状態なのでしょうか？
コンテナ型はホストOSをゲストと共有しているという理解がそもそも間違っているのでしょうか。
docker pull（またはdocker run時に自動で）イメージをダウンロードしていますがこのイメージにOSの全てが入っているのでしょうか？
そうだとしても200MB程度なので本当のOSイメージにしては小さすぎる気もします。
例えばUbuntu server 20.04のisoを公式からダウンロードすると935 MB程度です。

コンテナ型についての情報を調べてもゲストに任意のOSをインストール出来ないような書き方の記事しか出てこないので不思議でしょうがないです。

gentaro

2021/02/05 13:37

まぁ既に書いてある回答がほぼ全てですが「ホスト型とは異なるOS」が本当に動かせるなら、Linux上のDockerでWindowsコンテナが動くはずです。（当然そんなことはできない）

行動規範の内容に同意します

回答5件

ベストアンサー

どの範囲までを「OS」というのかというあたりの話が、dockerの説明といわゆるLinuxディストリビューションでの説明とで違っていて(どちらが間違っているというのではなく「OS」の範囲を狭義にとるか広義にとるかの違いです)、その区別を付けて理解する必要があると思います。

UbuntuやCentOSなどのLinuxディストリビューションは、カーネル呼ばれるコア部分に加えてファイルシステムに基本コマンドや追加のアプリケーションソフトをひとまとめのパッケージとして配布されていて、これ全体を広いほうの意味で「OS」と呼んでいます。

一方で、dockerの説明での「OS」とはカーネルだけのことを言っています。上記Linuxディストリビューションの説明で言うと、カーネルを「OS」と呼び、それ以外の基本コマンドや追加アプリケーションは含みません。
「/etc/*-release」というファイルはディストリビューションのファイルシステム上の１ファイルでありカーネルではありません。

質問にあるUbuntu上にCentOSが入ったdockerコンテナがある状態は、カーネルはUbuntuのものを使いファイルシステムのコマンド等はコンテナ内のCentOSが使われている状態ということになります。
言い替えると、「Dockerでホストと異なるOSをゲストで動かせる」というのは正しくはDockerでホストと異なるディストリビューション(カーネルを除く部分)をゲストで動かせるということです。

#※コメントを受けて追記

細かいところまで回答出来るかあやしいのですが回答します。

初回にダウンロードしているイメージは各ディストリビューションを再現するためのファイル群（？）だと思うのですがどのように再現しているのでしょうか。
これらの情報を深く調べるにはどのようなキーワードで調べればよいでしょうか。

ネット検索して↓を見つけました。

ベースイメージの作成 — Docker-docs-ja 1.9.0b ドキュメント

また、ディストリビューションごとにkernelも違うという事はありますでしょうか？

その任意コードに関する部分はコンテナ型では再現されないという理解であってますでしょうか？
例えばコンテナ内で開発後に本番環境に移行するとしてもディストリビューションごとのLinux kernelの違いがあった場合吸収できないと思います。
よってコンテナを開発環境やテスト環境として利用するのは問題がある気がしています。

コンテナのイメージを配布して何処でもすぐに同じ環境が作れるという謳い文句もありますがホスト側のLinux kernelに強く依存しているので場合によっては問題がある気がします。

その認識で正しいです。しかしそれが問題になる場合はほとんどないと思います。(カーネルの差異に依存するアプリケーションが全く無いとは言い切れませんが…)
問題にならない分野でdockerが採用されているということになると思います。

そのような差を気にするアプリケーションを使うのであればスーパーバイザー型のより純粋な仮想化を採用すべきだと思います。
または、開発機と本番機すべてでホストのディストリビューションとバージョンを揃えておくというのも実用的な解決策だと思います。

投稿2021/02/05 13:14

編集2021/02/05 14:48

hidezzz

総合スコア1248

daiki002

2021/02/05 13:44

回答ありがとうございます。おっしゃるとおりOSの概念をまず理解して切り分けて考える必要がありました。初回にダウンロードしているイメージは各ディストリビューションを再現するためのファイル群（？）だと思うのですがどのように再現しているのでしょうか。これらの情報を深く調べるにはどのようなキーワードで調べればよいでしょうか。また、ディストリビューションごとにkernelも違うという事はありますでしょうか？例えばLinux kernelはこちらのリポジトリにある物が大本だと思いますが、各ディストリビューションごとにフォークされて任意のコードが入っている事もある気がします。（確認をとってないので推測です） https://github.com/torvalds/linux その任意コードに関する部分はコンテナ型では再現されないという理解であってますでしょうか？例えばコンテナ内で開発後に本番環境に移行するとしてもディストリビューションごとのLinux kernelの違いがあった場合吸収できないと思います。よってコンテナを開発環境やテスト環境として利用するのは問題がある気がしています。コンテナのイメージを配布して何処でもすぐに同じ環境が作れるという謳い文句もありますがホスト側のLinux kernelに強く依存しているので場合によっては問題がある気がします。

daiki002

2021/02/06 14:44

追記ありがとうございます！やはり場合によっては問題がある事もあるようなので使い分けが大事になりそうですね。例えばカーネルに近い低いレイヤの事をする場合はハイパーバイザ型を利用するなどを意識したいと思います。

行動規範の内容に同意します

Linux はブートしたとき、カーネル・ライブラリ・バイナリ等、ファイルシステムから読み込みます。つまりファイルが揃っていれば Linux 環境を構築できるわけです。

Docker は、今動いているカーネルに、docker イメージ内に含まれるファイル (ライブラリ・バイナリ等) を組み合わせることで動きます。

下記、ubuntu:18.04 のファイルのイメージを見てましたが、bin/、etc/、lib/ 等が揃っています。

$ docker pull ubuntu:18.04
$ docker save ubuntu:18.04 >x.tar
$ tar xvf x.tar
$ tar tvf 1a65221217b8d235120af78508e2d20cd15c7e446cb855c780dcd4a1d1099eeb/layer.tar|less
drwxr-xr-x 0/0               0 2021-01-18 21:03 bin/
-rwxr-xr-x 0/0         1113504 2019-06-06 22:28 bin/bash
-rwxr-xr-x 0/0           34888 2019-07-04 12:35 bin/bunzip2
(略)
drwxr-xr-x 0/0               0 2018-04-24 08:34 boot/
drwxr-xr-x 0/0               0 2021-01-18 21:03 dev/
drwxr-xr-x 0/0               0 2021-01-18 21:03 etc/
-rw------- 0/0               0 2021-01-18 21:02 etc/.pwd.lock
-rw-r--r-- 0/0            3028 2021-01-18 21:02 etc/adduser.conf
(略)
drwxr-xr-x 0/0               0 2021-01-18 21:03 lib/x86_64-linux-gnu/
-rwxr-xr-x 0/0          179152 2020-12-07 16:38 lib/x86_64-linux-gnu/ld-2.27.so
lrwxrwxrwx 0/0               0 2020-12-07 16:38 lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 -> ld-2.27.so

なので、今動いているカーネルと、Ubuntu:18.04 として動くために必要なファイルが揃っているので、例えば CentOS 上でも Ubuntu:18.04 が動きます。

ですので、動いている kernel が古くて、docker イメージが期待するシステムコールが実装されていなかったりすると動かないらしいです。
(私は動かない具体的な事例を知らないので、らしいと表現しておきます)

投稿2021/02/05 18:48

68user

総合スコア2022

daiki002

2021/02/06 14:46

ご回答ありがとうございます。イメージについての情報ありがとうございます！色々なイメージを展開してみて中身を確認したり簡単なイメージを自分で1から作って理解を深めていこうと思います！

行動規範の内容に同意します

しかし、コンテナ型であるDockerを実際に試してみると以下のようにホスト型とは異なるOSが動いているように見えます。

いえ、両方とも共通のLinuxカーネルで動いています。

投稿2021/02/05 13:04

maisumakun

総合スコア146018

daiki002

2021/02/05 13:47

回答ありがとうございます。 Linuxカーネルを共有して各ディストリビューションをコンテナ内で再現しているだけのようですね。

行動規範の内容に同意します

コンテナ上で動くOSは、ホストOSと同じカーネルのOSだけです。
コンテナ内の各プロセス自体は、本当はホストOSのプロセスです。

しかし、プロセスから見える周りの状況は、別のOSのファイルシステムやネットワークなので、そのプロセスはその別のOSの中で動いていると誤解しています。

ちょうど、バーチャルリアリティーがもっと進化して、視覚聴覚だけじゃなくて全ての感覚をバーチャルにしたら、本当にその仮想環境にいるのと区別が付かないというのと似ています。

投稿2021/02/05 12:51

otn

総合スコア85901

daiki002

2021/02/05 13:57

回答ありがとうございます。頂いた回答を読んで考えていると何が違えばLinux OS(ディストリビューション)が違うと言えるのかの概念があいまいになってきました。難しいですね。

otn

2021/02/05 15:11

そうですね。ホストOSでpsするとコンテナプロセスも見えるけど、コンテナ内でpsしてもOSに必須のカーネルプロセスが見えない。という一方、シェルやデーモンなどのプログラムファイルはもちろん、libcを初めとするライブラリもゲストOSの物だし。まあ、それらはホストOSのファイルでもあるわけですが。

行動規範の内容に同意します

コンテナでOSが動いていると表現することもできますが、実際には、systemd や init をコンテナで動かしている感じです。

◆前提の説明
Linux環境ではすべてのプロセスは親子関係がありツリー構造になります（プロセスツリーといいます）。
プロセスツリーの一番上にあるのは、最初に起動されたプロセスで systemd や init という名前です。
（pstree コマンドで可視化可能なので確認してみてください）

◆Linuxディストリビューション Dockerパッケージについて
CentOS などの Dockerパッケージは systemd や init を含んだファイルシステム全体をコンテナ化していて、Docker は systemd や init を起動します。

systemd や init は設定ファイルに従って、OSの初期化や、各種デーモンプロセスの起動を行います。
その結果、コンテナ内で Linux ディストリビューションの環境が再現されています。

text
1process | process | process   ←これらは systemd が起動している
2--------------------------- 
3      systemd(init)             ←Dockerはこれを起動
4---------------------------
5          Docker
6---------------------------
7   Host Kernel | Driver
8---------------------------
9       Host Hardware
10---------------------------