Baruch Sadogursky氏に聞く- Dockerコンテナのライフサイクル管理における課題

JFrogデベロッパアドボケートのBaruch Sadogursky氏は，DevOps Days Kiel last Mayを含むいくつかのカンファレンスで講演し，開発から運用までのDockerイメージの管理とフロー追跡に関する課題を取り上げながら，JFrogの提案するソリューションを紹介している。

InfoQでは，Dockerコンテナのライフサイクル管理における課題についての理解を深めるべく，Sadogursky氏に話を聞いた。

InfoQ: たくさんの開発チームがビルドアーティファクトとしてDockerイメージを採用して，そのデプロイメントパイプラインを通じて提供していますが，この現状についてどう思いますか？

Baruch Sadogursky: 最近のDockerには大きな関心を持っています。かつてスタックを使用していたものを，今度はDockerのプロモーションパイプラインで実現しようとしている人たちがいますが，必ずしもうまくいっていません。Dockerを採用するというアーキテクチャ上の判断がかえって事態を難しくしている部分もありますし，Dockerの最大のメリットのいくつかが，同時に間違いを起こしやすくしているからです。

InfoQ: そういったことを実践している人たちは，イメージを運用システムに展開していると思いますが，実際には単に，VMベースの運用インスタンス手っ取り早く簡単なレプリカとして使用しているだけではないのでしょうか？

Sadogursky: Dockerを実運用で使用しているチームの数よりも，単なる“遊び”の対象であったり，概念実証(PoC)を行なっていたり，あるいは開発環境として使っているチームの数の方がはるかに多いのは事実です。理由のひとつは，抽象化された不明確なレイヤがひとつ加わることによって，運用レベルでは許容できないような不確実性が増えることにあると思います。

InfoQ: アーティファクトとして(依存性の管理が可能な)Dockerfile + (WARファイルなどの)アプリケーションバイナリではなく，Dockerイメージの使用を提唱している理由を簡単に説明して頂けますか？

Sadogursky: 見解の全体はこちらのブログ記事で述べていますが，少しだけ説明すると，Dockerfileからのイメージ生成では，複数回実行した場合にまったく同じ成果物が得られるという保証がないからです。その理由としては，Dockerfileの本質として，ほとんどのコマンドがさまざまな依存物を取り込んでいる上に，その大部分が安定バージョンを使用していないことがあげられます。

InfoQ: では，あなたの意見として，Dockerfileにどのような情報が必要で，どのような情報は取り除くべきだと思いますか？

Sadogursky: すべての依存対象について，できる限りバージョンを固定することですね。一部の参照についてはapt-getでバージョン番号を指定するなどの方法で可能ですが，それができないものもあります(例えばUbuntuのベースイメージでは，同じバージョンのセキュリティアップデートを集めています)。ですが，まずは試すことです。

InfoQ: パイプライン経由でDockerイメージをプロモートする上で，課題となるのは何でしょう？

Sadogursky: 現在のDockerレジストリのほとんどが採用している配布モデルは，イメージをプルして，パイプラインの次のステップとして新たなレジストリ(あるいはリポジトリ)のタグを更新して，それをプッシュバックする，というものです。くだらないと思いませんか？

InfoQ: 現在のDockerレジストリ(Dockerや競合他社のもの)の状況について，どう思いますか？それぞれにどのような違いがあるのでしょうか？

Sadogursky: とても幅の広い質問ですね。レジストリを比較するメトリックはたくさんありますが，最も意味が深いのは，パイプラインの他の部分にツールを追加する必要があるかどうか，という点です。Dockerはコンテナ技術で，コンテナには何かが含まれています。この“何か”の部分をコンテナイメージと同じアーティファクトリポジトリ上で管理できれば，イメージを構築したビルドと，コンテナ内で何らのものを作成したビルドとの間をトレースするためのメタデータが確立できるからです。

InfoQ: ソースコードとアプリケーションそれぞれの各バージョン，さらにDockerイメージのバージョンとの間のトレーサビリティを確立する上で，依存性管理の煩わしさを避けるにはどうすればよいのでしょう？

Sadogursky: “一度ビルドすれば，変更せずに配布可能なバイナリ”がこの問題も解決してくれます。依存関係管理システムを運用すれば，バイナリ生成時のソースのトレーサビリティも同時に確立します。運用システムに関しても同じです。

InfoQ: セキュリティの観点から，提供するDockerイメージが脆弱性を持っていないことを保証するためには，何をすればよいと思いますか？

Sadogursky: 特に変わったことではありません。セキュリティスキャナを使用する必要があります。Dockerコンテナのスキャンだけでなく，イメージ内部や，イメージ内のアーティファクトにも使用することが大切です。いずれも実行時には，コンテナのセキュリティ上の脆弱性に関わってきます。

InfoQ: Dockerイメージベースのプロモーションパイプラインは，チームが不変のイントラストラクチャ(immutable infrastructure)を実現する上で有効なものでしょうか？このような“ビルド・アンド・フォーゲット”アプローチを(パッチ適用や依存性管理といった観点から)インフラストラクチャに対してサポートするためには，他にどのようなパズルのピースが必要なのでしょう？

Sadogursky: Dockerイメージベースのアプローチは，不変のインフラストラクチャそのものです。不変のイメージを作るというアイデアは，不変のインフラストラクチャという方法論に他なりません。優れたCIパイプラインが用意できれば，すべてのソース変更がCIビルドとプロモーションを起動し，結果として新しいDockerコンテナのセットが作成される – これはまさに，不変のインフラストラクチャの理想の姿です。

InfoQ: ChefやPuppetといった構成管理ツールは，このようなシナリオに適しているでしょうか？

Sadogursky: 10億ドル級の質問ですね。答えられるのが誰なのか，私には分かりません。変更可能なインフラストラクチャソフトウェアが，不変のインフラストラクチャの世界においてどのように自身を再発明するのか，非常に興味があります。もしかしたらChef Habitatは，その方向への第一歩かも知れません。注目しています。