Googleは，JenkinsとPackerを使ってGoogle Compute EngineVMのカスタムイメージのビルドを自動化するリファレンス実装を，Kubernetesベースのオープンソースで開発した。継続的デリバリのビルドパイプラインへのイメージ生成過程の追加と，VMインストールの信頼性向上と時間削減を可能にするアーティファクト生成という，２つの実現方法を実証することが，開発の主な目的だ。
Google Cloud Platformブログでは，クラウドにデプロイされるアプリケーションの多くが，仮想マシン(VM)インスタンスの特殊なプロビジョニングを必要としている事実が指摘されている。このタイプのプロビジョニングの例として挙げられているのが，オペレーティングシステムのコンフィギュレーション，言語ランタイムのインストール，インスタンスへのリモートログイン管理などだ。プロビジョニングへのアプローチ方法はさまざまだ。それぞれのVMにSSHで接続して独自コマンドを実行する従来型の手法もあれば，VM初期化プロセスのブートストラップでPuppetやChef，あるいはAnsibleといったプロビジョニングを利用するという，より現代的な“自動システム管理”的手法もある。前者のプロセスがマニュアル操作によるエラーを起こしやすい(‘スノーフレーク’サーバを生み出すことも少なくない)一方で，後者のプロセスではインストールの長時間化や，ソフトウェアパッケージリポジトリの信頼性が影響を及ぼす可能性がある。
起動時のインスタンスプロビジョニングに代わる方法が，HashcorpのPackerなどのツールを利用したカスタムVMベースイメージの生成だ。このプロセスは，VMインスタンスのワンタイム(繰り返しは可能)のプロビジョニングと，そこから任意の数のVMをオンデマンドに初期化できる‘スナップショット’インスタンス生成で構成されている。これによってVMインストール時のインスタンスのプロビジョニングを回避すると同時に，信頼性の向上とブート時間の短縮が可能になる。
Google Cloud Platformチームは今回，ソリューションの技術資料とリファレンス実装をリリースすることによって，JenkinsやPacker，Kubernetesといったオープンソース技術を使ったGCE(Google Compute Engine)経由のイメージビルド自動化に関して，その詳細を説明したことになる。今回のリファレンス実装は，GCEあるいはDockerベースのアプリケーションの継続的ビルドを行うためのテンプレートとして利用することもできる。共通のプロジェクトでビルドしたイメージを，組織内の他のプロジェクトで共有することも可能だ。自動化されたこのイメージビルドプロセスについてGoogle Cloud Platformブログでは，最終的には組織の継続的インテグレーション(CI)プロセスに統合することも可能だ，と提案している。
InfoQでは，Google Cloud PlatformのソリューションアーキテクトであるEvan Brown氏に，イメージの自動ビルドに関する技術資料とリファレンス実装についていくつか質問した。
InfoQ: 他のベンダがSaaSのサービスとしてのみ提供しているコンテナ/クラウドの継続的デリバリパイプラインを，完全なオープンソースとして提供しているのは，あなた方以外にありません。これにはどのような考えがあったのでしょうか？
Brown: この方法を決めた時，私たちには２つの目標がありました。そのひとつは，カスタムイメージのビルドは，クラウドでは古くからあった話題であるということです。今回のソリューションで私たちはカスタムイメージ - 特に不変(immutable)イメージ - に対処したいと思っていました。コンテナが非常に普及したとは言え，VMもまだまだ重要です。不変イメージ生成の自動化という，この価値ある作業を行う上で，ユーザをいかに支援できるか，そして，Google Compute EngineのVMだけでなく，Dockerコンテナでも利用できるようにするには，どうすればよいのか？ もうひとつの目標は，実装内容を概念的に語るだけでなく，ユーザが概念を理解するために使用することのできる，機能的な，オープンソースのリファレンスを提供することでした。
InfoQ: RIではJenkinsやHashicorpのPackerなど，オープンソースのツールを使っていますが，これは社内用に開発していたから，という理由ではなく，今回の成果を活用するための意識的な決断だったのでしょうか？
Brown: JenkinsとPackerを使用すると決定したのは，理由があってのことです。そもそもこれが実現できたのは，数ヶ月前にGoogle社員が行ったPackerへのコントリビューションや，Jenkins用のいくつかのオープンソースプラグインに対するGoogleのコントリビューションがあったからなのです。私たちはユーザが利用し，愛しているプロジェクトにコントリビュートしています。不変イメージの自動化のような新たな問題に対するユニークな取り組みを行う上で，それらのいくつかを利用できるというのは，本当にエキサイティングなことです。
InfoQ: パイプラインは今のところKubernetesへのデプロイ専用ですが，Goole Cloud Platformで動作する他のプラットフォーム，例えばMesosフレームワークなどをサポートしたいと思いますか？
Brown: GitHubにある実装は，KubernetesとGoogle Container Engineで動くように設計されていますが，コア機能を提供している３つのDockerイメージについては，DockerさえあればMesosでも動作します。Container Engineを選んだのは，Kubernetesクラスタを約3分で動作させられる上に，廃棄するのも簡単にできるからです。つまり，このサンプルを立ち上げて試用した上でそれを廃棄するのに，30分足らずでよいということです。そして翌日には，自分たちの環境に合わせた微調整をしたクラスタを立ち上げて，いろいろ試してみることができるのです。
システムのデザインも，Kubernetesで実行するのに向いています。3つのレイヤ – SSL終端プロキシ(ngix)，Jenkinsリーダ/UI，Jenkinsビルドエージェント – があるので，それらをDockerコンテナに置き換えるのは簡単です。Kubernetesは単純に，それらのデプロイと管理を行えばよいのです。Jenkins用KubernetesプラグインではCarlos Sanchezがエキサイティングな開発をしていますので，使い勝手のよい，素晴らしいものになると思います。
InfoQ: InfoQの読者がこのプロジェクトにコントリビュートしたい場合は，どのような方法で関与するのが一番よいのでしょう？
Brown: コントリビュータは大歓迎です！コントリビューションにはコード提供やドキュメントの改善があります。まずはGitHubのリポジトリをフォークして，プルリクエストを送信してください。コントリビューションやフィードバックが140文字以内に収まるなら，Twitterでevandbrownに送る方法もあります。
InfoQ: お時間を頂いてありがとうございました。その他，InfoQ読者に伝えたいことは何かありますか？
Brown: 質問をありがとうございました！私たちの発表したこのソリューションと実装は，PackerやJenkins，Kubernetes，Docker，それから数々の，数々のすばらしいJenkinsプラグインなど，多くの優れたオープンソースプロジェクトを組み合わせたものです。読者の皆さんにはそれを強く言いたいですね。改良のアイデアがある，あるいはコードや資料のコントリビューションを考えているのでしたら，ぜひ支援をお願いします。
Googleの自動イメージビルドのリファレンス実装に関する詳細は，Google Cloud PlatformブログあるいはGithubリポジトリにある。