ホストOSがCentOS6上にCentOS7のdockerコンテナを稼働させた場合のsystemctlエラーに関して

Question

タイトルの通りになりますが、
さくらVPS（ホストOSがにCentOS6）上にCentOS7のdockerコンテナを稼働させhttpd+php7を起動させたいのですが
systemctlコマンド実行時に下記エラーでhttpdが開始出来ません。

[root@d51ec0a3332d /]# systemctl start httpd.service
Failed to get D-Bus connection: No such file or directory

httpd.serviceは存在している様です。。

[root@d51ec0a3332d /]# ll /usr/lib/systemd/system/httpd.service
-rw-r--r-- 1 root root 752 Aug 23 11:11 /usr/lib/systemd/system/httpd.service

過去のQAを確認して--privilegedオプションを付けて起動させ、docker exec でシェルに入ってます。

docker run --privileged -d --name httpsrv -p 8080:80 httpd_php7 /sbin/init
docker exec -it httpsrv bash

ちなみに--cap-add=SYS_ADMINオプションを使用しても同じくエラーでした。

CentOS6上にCentOS7のコンテナでdaemonを立ち上げたい場合は他にコツがあるのでしょか？

centosが必要な理由は、redhat系の経験が長いので、Debian系の管理が不安と言うのと、
OFFICIALが付いているimageがなにかと安心という点です。

この組み合わせで動作しているよって方ご教授頂ければ幸いです。
宜しくお願い致します。

追記

ホスト：CentOS7＋コンテナ：CentOS7での組み合わせでは確認出来ておりませんので、確認後レポート致します。

検証結果

AWSのEC2で検証しました。
CentOSが選択にないので、redhat-enterpriseでインスタンスを作成しdockerをバイナリーインストールして確認しました。
(ライセンス問題で通常インストールすると有料版を使えって怒られる）

ホストOS ： Red Hat Enterprise Linux Server release 7.4 (Maipo)
コンテナ ： CentOS Linux release 7.4.1708 (Core)

[root@7af92ef993ee /]# systemctl
  UNIT                                   LOAD   ACTIVE     SUB       DESCRIPTION
  proc-sys-fs-binfmt_misc.automount      loaded active     waiting   Arbitrary Executable File Formats File System Automount Point
  dev-xvda2.device                       loaded activating tentative /dev/xvda2
  -.mount                                loaded active     mounted   /

....etc

結果ホスト：CentOS7(redhar enterprise7)＋コンテナ：CentOS7の組み合わせでは何の問題もなくsystemctlコマンドは使えそうです。

Comments

[TaichiYanagiya]

ホストが CentOS 7 だと実行できるのでしょうか？

[BECK_]

なるほど実際にCentOS7の環境では試行していません。CentOS6とCentOS7でサービス管理システムがinitからSystemdに変更になったのが要因かなと思いまして。別インスタンス作成して試してみますね。

[TaichiYanagiya]

https://teratail.com/questions/92752 のコンテナイメージで試してみるとどうでしょうか？

[BECK_]

ホストがCentOS7で検証結果を追記しました。https://hub.docker.com/r/centos/systemd/のイメージはコンテナの起動時にエラーがmkdirエラーが出てダメの様です。（深堀してませんが）

Answer 1

ホスト(CentOS 6)側の kernel のバージョンが古いため、CentOS 7 コンテナを起動するために必要な機能が備わっていないためだと思います。

CentOS 6 に、elrepo リポジトリから kernel-ml をインストールした環境で、CentOS 7 コンテナを起動し、systemctl コマンドを実行することができました。

###環境
AWS EC2: CentOS Linux 6 x86_64 HVM EBS 1704_01-74e73035-3435-48d6-88e0-89cc02ad83ee-ami-23285c35.4 (ami-d4d0e2b3)
kernel: kernel-ml-4.13.4-1.el6.elrepo.x86_64 (elrepo)
docker: docker-io-1.7.1-2.el6.x86_64 (EPEL)

[root@centos6]# yum install http://www.elrepo.org/elrepo-release-6-8.el6.elrepo.noarch.rpm
[root@centos6]# yum --enablerepo=elrepo-kernel install kernel-ml
[root@centos6]# vi /boot/grub/grub.conf
    (/boot/vmlinuz-4.13.4-1.el6.elrepo.x86_64 を起動するように default= を変更)
[root@centos6]# reboot

-------- (再起動後) --------
[root@centos6]# uname -r
4.13.4-1.el6.elrepo.x86_64

[root@centos6]# rpm -q docker-io
docker-io-1.7.1-2.el6.x86_64

[root@centos6]# docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d/1.7.1
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d/1.7.1
OS/Arch (server): linux/amd64

Comments

[BECK_]

有難う御座います！
無事systemctlコマンドが使える様になりました。

Answer 2

DockerコンテナはOSとリソースを共有するため、原則はホストOSと同じバージョンでの実行が必要となります。
CentOS6でのDockerサポートも終了しているため、CentOS7で動作確認できているのであれば、CentOS7を利用することをお勧めします。

Comments

[BECK_]

有難う御座います。
ホストOSとコンテナOSの差異はdocker側で吸収されているのかと思っておりました。
開発SV、ステージングSV、本番SVのホストOSは合わせた方が良いとの事ですね。

各開発者はローカルのmacOS上のコンテナにて作業しているのですが、当ケースだとどうしても環境を合わせる事が難しいと思います。
皆様どの様に運用しておりますでしょか？

[退会済みユーザー]

仮想マシンとしての実行を間に挟む等の対応が一般的ではないかと思います。
有償製品もありますが、無償でも例えばvirtualbox+vagrant+docker等の組み合わせで対応可能です。
このあたり、仮想マシンとコンテナの違いを調べられるとよいかもしれません。

[BECK_]

有難う御座います。
dockerだけでは完全にホスト環境依存を排除出来ないのでvagrantを挟むって事なのですね。
仮想オン仮想的なイメージなので堂々巡りしている感じがしていましたが、dockerが完全仮想化ソフトでない事で合点しました。

[退会済みユーザー]

コンテナ技術は仮想マシンに比べてオーバヘッドを少なくでき、特に起動に関してはコンテナの立ち上がりはとても速いですが、その理由はすでに起動しているホストOSがあるがゆえです。

>dockerだけでは完全にホスト環境依存を排除出来ないのでvagrantを挟むって事なのですね。
先ほどの例だと仮想マシンを動作させているのはvirtualboxの方で、vagrantはそれをコマンドで制御できるようにして自動化等をやりやすくするためのツールとなります。
組み合わせると便利なので記載しましたが、vagrant自体は必須というわけではありません。

[BECK_]

レス遅くなりすみません。
virtualbox + vagrant + dockerで実際の環境作成して検証しておりました。
なるほどそれぞれの位置づけが理解出来ました。
いろいろと有難う御座いました。