先月末リリースし, 近日中に社内にお披露目予定のDoX正式版(DoXは, DockerでオレオレVPSを作った話で軽く触れている, Dockerを使った社内向けのステージング環境のことです)で使わざるを得なかった, Dockerのバッドノウハウについてメモしておきます.

恐らくあの辺りのコードについては, 数カ月後DoXにまた手を加えようとした時に｢...なんでこんな事してるんだ...?｣と頭を悩ませると思うので, 忘れないようにQiita:Teamに書いておいたのを, ブログに転載することにします.

Dockerの使い方としても, かなりバッドノウハウ感がある状況で起きる, ある特定事例を解決するためのバッドノウハウなので, 恐らくこんな所で詰まる人はいないと思うのですが... まあ, 悩みぬいた記念にこうやって晒しておくことにします.

問題

｢システムコンテナ内でrebootすると, 再起動はするものの, runlevelがunknownになって, 各種プロセスが立ち上がらない｣

前振り

DoXでは, Dockerのコンテナをまるで1つのサーバのように扱う(複数のプロセスが立ち上がる)｢システムコンテナ｣と, Dockerが想定している｢1コンテナ = 1プロセス｣のように動かす｢アプリコンテナ｣という, 2つのコンテナを扱うことができます.

今現在社内に提供しているDoXのベータ版では, システムコンテナしか対応していませんが, DoX正式版ではDockerHubなどから取得したイメージをアプリコンテナとして立ち上げることが出来ます.

これによって, 例えばDockerHubからElasticsearchのイメージを取得してから起動すれば, すぐさまElasticsearchを試す環境が出来上がる, なんてことが出来ます.

今回バッドノウハウを使わざるを得なかったのは, そのアプリコンテナではなく, システムコンテナで生じたある問題を解決する為でした.

症状

システムコンテナは, イメージを起動する際の起動コマンドを/sbin/initにして, そこから各種プロセス(例えばsshdとか, httpdとか...)を立ち上げることで実現しています.

ここまではいいのですが, 問題はそのシステムコンテナの中でrebootをしようとした場合です.

システムコンテナの中でrebootを叩くと, 各種プロセスが正常に落ちていくのですが, /sbin/initが再度立ち上がったタイミングで処理が止まってしまいます.

docker execコマンドでコンテナの中に侵入し, runlevelコマンドでランレベルを確認すると, なんとunknownという値が... そこから手動で, /sbin/init 3のように, ランレベルを指定(この場合は3)してあげると, 各種プロセスが立ち上がるのですが, これではうっかりコンテナ内でrebootコマンドを実行してしまうと, ユーザがそのコンテナに接続する術がなくなってしまいます(SSHで接続出来ないので).

幸い, docker stopしてからdocker startした場合や, docker restartで再起動した場合は正常に立ち上がるので, これらのコマンドを内部的に利用してコンテナを操作しているDoXのWebアプリケーション経由で, 例えばコンテナを再起動するなどすれば, 再びコンテナ内に各種プロセスが立ち上がりコンテナを利用出来るようになるのですが, これは非常に面倒です.

解決策という名のバッドノウハウ

解決策という名のバッドノウハウは,

コンテナ起動時に--add-cap=SYS_BOOTを与える
コンテナ起動時に--restart=alwaysを与える

...でした. このオプションを与えると, Dockerのシステムコンテナがどのように動いていくか, 具体的に説明していきましょう.

まず, --add-capというオプションは, コンテナに対して特権を与えるオプションです(こちらの記事が詳しいです: (ヽ´ω`) < Dockerで--cap-addオプションを試す).

このオプションで, SYS_BOOTという権限をコンテナに与えると, コンテナ内でrebootを実行した際, 何故かコンテナそのものが停止します. ちなみにその詳細な理由はまだ調べられていません...

これが｢再起動｣であれば問題は解決だったのですが, 残念ながら｢コンテナの停止｣であり, 各種プロセスが立ち上がらないのはこれまでと同じです.

ここで登場するのが, --restartオプション. これはDockerのコンテナが異常停止した際に再起動するかどうかを指定することが出来るオプションです. 今回のように--restart=alwaysにすると, コンテナが停止した場合, 即座に/何度もコンテナを起動してくれます(docker stopなど, 正しい手段でコンテナを停止した場合はその限りではありません).

...もうおわかりですね?

--cap-add=SYS_BOOTでreboot実行時にコンテナを停止させる
この停止はdocker stopなどの正しい手段ではないので, Dockerは即座にコンテナを起動(恐らく, docker start)する
この際のコンテナは正常な起動なので, ランレベルは3になり, 各種プロセスが正しく立ち上がる

...どうです, バッドノウハウ感がたまらないでしょう? 個人的には, まるで｢バッドノウハウのお手本｣のような, なんかもうそういう感じのどうしようもない感じで非常に辛かったです(原因調査と, このバッドノウハウの発見だけで1日潰れましたし).

えー, というわけで, こういうバッドノウハウなどにも支えられつつ, DoX正式版は(恐らく)無事完成したので, 恐らく近日中に社内の各事業部に向けて提供することが出来ると思います.

調査

この症状について, チームで詳しく調べてみたところ, DoXベータ版と正式版でコンテナを動かすためのエンジンが異なるらしく(ベータ版はlxc, 正式版はlibcontainer), libcontaierで正常にrebootできなかったイメージをlxc上でrebootした所, 問題なく各種プロセスが立ち上がる形で再起動出来たとの事でした.

エンジンをlxcに変更する, という手もあるとはいえ, そうしてしまうとデバッグに便利な, Dockerコンテナ内に接続することが出来るdocker execコマンドが使えなくなってしまうというデメリットもあり, 今回はこのバッドノウハウを使いながら, libcontainerを使おうという方針になりました.