回答編集履歴
4
全ホストで同じバージョンに揃える解決策について言及した。
answer
CHANGED
|
@@ -30,4 +30,5 @@
|
|
|
30
30
|
その認識で正しいです。しかしそれが問題になる場合はほとんどないと思います。(カーネルの差異に依存するアプリケーションが全く無いとは言い切れませんが…)
|
|
31
31
|
問題にならない分野でdockerが採用されているということになると思います。
|
|
32
32
|
|
|
33
|
-
そのような差を気にするアプリケーションを使うのであればスーパーバイザー型のより純粋な仮想化を採用すべきだと思います。
|
|
33
|
+
そのような差を気にするアプリケーションを使うのであればスーパーバイザー型のより純粋な仮想化を採用すべきだと思います。
|
|
34
|
+
または、開発機と本番機すべてでホストのディストリビューションとバージョンを揃えておくというのも実用的な解決策だと思います。
|
3
表現修正。
answer
CHANGED
|
@@ -30,4 +30,4 @@
|
|
|
30
30
|
その認識で正しいです。しかしそれが問題になる場合はほとんどないと思います。(カーネルの差異に依存するアプリケーションが全く無いとは言い切れませんが…)
|
|
31
31
|
問題にならない分野でdockerが採用されているということになると思います。
|
|
32
32
|
|
|
33
|
-
そのような差を気にするアプリケーションであればスーパーバイザー型のより純粋な仮想化を採用すべきだと思います。
|
|
33
|
+
そのような差を気にするアプリケーションを使うのであればスーパーバイザー型のより純粋な仮想化を採用すべきだと思います。
|
2
コメントを受けて追記。
answer
CHANGED
|
@@ -6,4 +6,28 @@
|
|
|
6
6
|
「/etc/*-release」というファイルはディストリビューションのファイルシステム上の１ファイルでありカーネルではありません。
|
|
7
7
|
|
|
8
8
|
質問にあるUbuntu上にCentOSが入ったdockerコンテナがある状態は、カーネルはUbuntuのものを使いファイルシステムのコマンド等はコンテナ内のCentOSが使われている状態ということになります。
|
|
9
|
-
言い替えると、「Dockerでホストと異なるOSをゲストで動かせる」というのは正しくはDockerでホストと異なるディストリビューション(カーネルを除く部分)をゲストで動かせるということです。
|
|
9
|
+
言い替えると、「Dockerでホストと異なるOSをゲストで動かせる」というのは正しくはDockerでホストと異なるディストリビューション(カーネルを除く部分)をゲストで動かせるということです。
|
|
10
|
+
|
|
11
|
+
#※コメントを受けて追記
|
|
12
|
+
|
|
13
|
+
細かいところまで回答出来るかあやしいのですが回答します。
|
|
14
|
+
|
|
15
|
+
> 初回にダウンロードしているイメージは各ディストリビューションを再現するためのファイル群（？）だと思うのですがどのように再現しているのでしょうか。
|
|
16
|
+
> これらの情報を深く調べるにはどのようなキーワードで調べればよいでしょうか。
|
|
17
|
+
|
|
18
|
+
ネット検索して↓を見つけました。
|
|
19
|
+
|
|
20
|
+
[ベースイメージの作成 — Docker-docs-ja 1.9.0b ドキュメント](https://docs.docker.jp/engine/articles/baseimages.html)
|
|
21
|
+
|
|
22
|
+
> また、ディストリビューションごとにkernelも違うという事はありますでしょうか？
|
|
23
|
+
|
|
24
|
+
> その任意コードに関する部分はコンテナ型では再現されないという理解であってますでしょうか？
|
|
25
|
+
> 例えばコンテナ内で開発後に本番環境に移行するとしてもディストリビューションごとのLinux kernelの違いがあった場合吸収できないと思います。
|
|
26
|
+
> よってコンテナを開発環境やテスト環境として利用するのは問題がある気がしています。
|
|
27
|
+
|
|
28
|
+
> コンテナのイメージを配布して何処でもすぐに同じ環境が作れるという謳い文句もありますがホスト側のLinux kernelに強く依存しているので場合によっては問題がある気がします。
|
|
29
|
+
|
|
30
|
+
その認識で正しいです。しかしそれが問題になる場合はほとんどないと思います。(カーネルの差異に依存するアプリケーションが全く無いとは言い切れませんが…)
|
|
31
|
+
問題にならない分野でdockerが採用されているということになると思います。
|
|
32
|
+
|
|
33
|
+
そのような差を気にするアプリケーションであればスーパーバイザー型のより純粋な仮想化を採用すべきだと思います。
|
1
表現修正。
answer
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
UbuntuやCentOSなどのLinuxディストリビューションは、カーネル呼ばれるコア部分に加えてファイルシステムに基本コマンドや追加のアプリケーションソフトをひとまとめのパッケージとして配布されていて、これ全体を広いほうの意味で「OS」と呼んでいます。
|
|
4
4
|
|
|
5
5
|
一方で、dockerの説明での「OS」とはカーネルだけのことを言っています。上記Linuxディストリビューションの説明で言うと、カーネルを「OS」と呼び、それ以外の基本コマンドや追加アプリケーションは含みません。
|
|
6
|
-
「/etc/*-release」というファイルはディストリビューションのファイルシステムでありカーネルではありません。
|
|
6
|
+
「/etc/*-release」というファイルはディストリビューションのファイルシステム上の１ファイルでありカーネルではありません。
|
|
7
7
|
|
|
8
8
|
質問にあるUbuntu上にCentOSが入ったdockerコンテナがある状態は、カーネルはUbuntuのものを使いファイルシステムのコマンド等はコンテナ内のCentOSが使われている状態ということになります。
|
|
9
9
|
言い替えると、「Dockerでホストと異なるOSをゲストで動かせる」というのは正しくはDockerでホストと異なるディストリビューション(カーネルを除く部分)をゲストで動かせるということです。
|