スペシャリストから学ぶコンテナ技術 第 1 回

林「そうです。運用チームから本番だけ落ちる (問題が発生する) んですけど、といった問い合わせが開発チームに来るみたいなことっていままでの経験でなかったですか ?」

原田「よくありましたね (笑) 開発でもステージングでも再現しなくて、結局、本番環境に入らせてもらったり、細かいログもらったりで、トラブルシューティングした結果、『え、ランタイムのバージョン違ってますね・・・』とか。」

林「そうなんですよね。このようなことが起こるとデプロイのライフサイクルを信用できなくなって、アプリケーションをデプロイする上での心理的な障壁が大きくなってしまいます。本当はどんどんデプロイして、フィードバックをもらって、修正して、すぐにまたデプロイを繰り返すといったフィードバックループを回したいにも関わらず、なかなかデプロイができないといった事態が発生しかねません。」

林「この、時間の経過により各環境に差異が発生するみたいなことを解決するために、どんな方法がありますかね ?」

原田「例えば、構成管理ツール・サービスを使って、環境差分が発生しないようする。万が一発生した場合でも、すぐに気付く仕組みを作る とかですか ?」

林「はい、それも有効な方法の 1 つだと思います。今回は深くは触れないですが、Ansible といったソフトウェアを導入されているお客様も多いと思います。別な選択肢として、『コンテナ』を利用するという方法もあります。」

原田「お、いよいよコンテナの登場ですね。」

原田「なるほど。シンプル イズ ベストなアイデアですね。『環境間のバージョン差異で問題が発生するならそのまま全部運べばいいよね』というのは。でも、『設定値』はパッケージングしていないんですね、これはどういう理由なのでしょうか ?」

林「いいポイントですね。もちろん、設定値を含めてパッケージングすることは可能です。ただ、実務上、設定値を含めることはあまりありません。というのは、設定値は、環境ごとに設定すべき値が変わることがほとんどですよね。例えば、開発、ステージング、本番環境はまったく同じアプリケーションコードを使用しますが、異なる設定値を使用することで、環境ごとに接続先のデータベースを変えたり、出力するログの粒度を変えたりします。つまり、設定値は環境差分があることが当たり前なので、コンテナの中には入れません。」

林「逆に、設定値を無理にパッケージング (コンテナ化) してしまうと、コンテナを各環境に運ぶたび、つまりデプロイするたび、パッケージを紐解いて、中身を確認して、設定値を環境に合わせて変えて、もう一度パッケージングして、コンテナを起動するといったことにもなりかねません。」

原田「なるほど、よく分かりました。では、この設定値はどうやってコンテナで起動するアプリケーションに反映させるのでしょうか ?」

林「お、かなり具体的な質問ですね。原田さん、もしかすると、今、コンテナと言いつつも、頭の中では Docker コンテナのことを想像されていらっしゃいませんか ? 事実上、Docker もしくは Docker コンテナのことを単に『コンテナ』と呼ぶことも多いのですが、せっかくの機会なので、この部分についてもお話したいと思います。」

原田「はい、ぜひ。コンテナと Docker の違いについては普段あまり意識することはないので、言われて見れば気になる・・・という読者の方もいらっしゃると思います。」

林「コンテナ技術は、ホスト OS からアプリケーションの動作環境・プロセスを隔離するための技術 (アイソレーション技術) のことで、そのコンテナ技術により隔離した環境・プロセスをコンテナといいます。このプロセスの隔離は、Linux の場合は cgroup や namespace といった Kernel の機能で実現しています。この部分の詳細については中々イメージが湧かないと思うので、実際にデモをお見せしながら、別途説明したいと思います。ですので、ここでは、コンテナ技術はホスト OS 上で動くプロセスの隔離技術だとなんとなく覚えていただければと思います。」

林「このコンテナ技術の実装は古くからあり、例えば、Solaris Containers (2005 年) や LXC (2008 年) などが有名です。広義だと、chroot もそうですね。」

原田「なるほど、確かに、chroot もファイルシステムの隔離なので、隔離技術の 1 つですね。」

林「 Docker もこのコンテナ技術を実装するソフトウェアの 1 つであり、Docer により隔離された環境のことを Docker コンテナといます。そして、この Docker は、事実上、コンテナ技術実装のデファクトスタンダードとなっており、コンテナと言えば Docker (もしくは Docker コンテナ) のことを表していることがほとんどです。」

林「もちろん Solaris Containers や LXC といった Docker 以前からあるコンテナ実装ソフトウェア、もしくは、rkt といった Docker 以後に登場したコンテナ実装ソフトウェアを利用されているお客様はいらっしゃると思いますが、おそらくほとんどの読者の方は Docker について改めて知りたいと思われているかなと思います。ですので、これ以降は コンテナ = Docker という前提でお話をさせていただければと思います。」

原田「ここで 1 つ疑問が。コンテナ技術とその実装方法は、Docker 以前からあることが分かりました。でも、開発者の間でコンテナが流行り初めたのは、Docker が登場 (2013 年 3 月) してからだと思います。ということは、Docker 以前のコンテナ実装ソフトウェアと Docker は、何か決定的な違いがあると思うのですが、具体的に何が違うのでしょうか ?」

林「これもいい質問ですね。ただ、この説明をするには、Docker 自身についてもう少し深く掘り下げる必要があるので、まずはその部分について説明させてください。」

原田「はい、分かりました。今までは、『コンテナとはなにか ? コンテナのメリットは ?』というコンテナ全般についての話だったかと思います。ここからは『Docker』の話になるかと思いますので、ここで一旦まとめさせていただいて、Docker については次号以降で詳しくお話を聞かせてください。」

林「はい、よろしくお願いします。」

アプリケーションには 4 つの構成要素 (アプリケーションコード、ランタイム、ライブラリなどの依存物、設定値) があります。この中で、デプロイの際に、各環境間で同一なものを利用するのはアプリケーションコードのみで、それ以外の要素は各環境にあらかじめセットアップされたものを利用するというデプロイフローを採用している場合、時間の経過とともに、意図せず各環境のランタイムのバージョンが異なってしまう、つまり、環境差分が発生することがあります。その結果、本番環境だけアプリケーションが動かないといった問題が発生することがあります。

そのようなことが起きると、デプロイのライフサイクルを信用できなくなり、プロダクトの価値向上のためにフィードバックループを高速に回すことができなくなってしまいます。

その環境差分をなくすための手段の1つとして、アプリケーションの構成要素のうち、アプリケーションコード、ランタイム、ライブラリなどの依存物をパッケージングして、隔離された環境で実行するコンテナならびにコンテナ技術について紹介しました。

次回以降では、コンテナ実装のソフトウェアとしてデファクトスタンダードになっている Docker について、掘り下げていきたいと思います。