先日サンフランシスコで開催された第1回のCoreOS Festで，CoreOSチームは，App Container Spec(appc)がGoogle，Apcera，Red Hat，VMware各社の支持を獲得したことを発表した。Googleは，CoreOSのappc実装である‘rkt’をKubernetesでサポートする。またApceraは，‘Kurma’という名のappcインプリメンテーションを新たに開発中だ。プロジェクトの運営方針も新たに設定され，従来のCoreOSによるメンテナンスに加えて，Red Hat，Google，Twitterからもメンテナが選出されることになった。
2014年12月にApp Container Spec(appc)が発表されて以来，CoreOSは，同仕様の開発を公式に推進する，たたひとつの企業だった。appcは，セキュリティと移植性，モジュール性に重点を置いたコンテナアプリケーションの開発，運用の方法を定義したものだ。仕様の定義と並行してCoreOSは，appcを実装した初のコンテナランタイムとして，rktの開発も行っていた。
セキュリティとスタック間の移植性は，アプリケーションコンテナの採用を成功させるためのコアであると，CoreOSのブログに述べられている。そして今回のCoreOS Festで，この活動をGoogleやApcera，Red Hat，VMwareといった企業が支援することが発表されたのだ。
... 企業と個人が一堂に会して，アプリケーションコンテナのための明確な仕様の確立を通じて，スタック間のセキュリティと開放性，モジュール性を確保するためのガイドラインを提供します。
4月には，Google Venturesの主導によってCoreOSに1,200万ドルの投資が行われると同時に，CoreOS用の商用KubernetesプラットフォームであるTectonicがローンチされた。Kubernetesは，アプリケーションコンテナを対象とした，Googleのオープンソースオーケストレーションシステムである。コンピュータクラスタ内でノードのスケジューリングを処理し，ワークロードをアクティブに管理する。CoreOS FestでGoogleが述べたところによると，Kubernetesプロジェクトは，appcサポートを追加するプルリクエストを受諾している。これにより，CoreOSのrkt(およびその他appc準拠のコンテナ実装)をKubernetes内で，Dockerコンテナとともに実行することが可能になる。
これはKubernetesプロジェクトにとっても，より広範なコミュニティにとっても，重要な一歩となります。コンテナ基盤に柔軟性と選択肢を加えるとともに，Kubernetes開発者に対して，優れたセキュリティ機能とパフォーマンスを新たに約束してくれるのです。
ApceraはKurmaのリリースによって，appcの活動を新たにサポートする。Kurmaは，ApceraのHybrid Cloud Operating System(HCOS)のデプロイをコンテナ化する作業から発展した，appcのオープンソース実装である。Apceraのブログには，同社の目標とappcの目標と一致していることが述べられている。
ApceraのHCOSの目標がセキュリティとポリシであることには，今後も変わりはありません。一方でKurmaは，HCOSデプロイメントの礎となって業務効率の向上を実現する，コンテナ基盤環境なのです。AppCは当社にとって価値があります。[... なぜならば，]ネットワークオントロジ，イメージの検索・検証・暗号化，あるいはアプリケーションの識別といったものは，すべて当社が力を入れている分野だからです。
CoreOSブログによると，Red Hatからもappcのメンテナとしてエンジニアが参加している。これに伴ってappcプロジェクトでは，運営方針を確立すると同時に，CoreOSとは業務上の関連がないGoogleやTwitterからも新たなコミュニティメンバを選出した。当初より仕様開発者としてCoreOSから参加するBrandon Philips，Jonathan Boulle両氏は今後もメンテナとして残る。
この新たなメンテナ構成は，各メンバが独自のユニークな視点を持つことによって，appcを本当の意味での共同作業にしてくれます。
VMwareはこの4月，appcのサポート活動として，同社の軽量LinuxオペレーティングシステムであるProject Photonでrktを提供すると発表した。これによってVMwareのvSphereおよびvCloud Airのユーザが，デプロイメント機構としてrktを利用できるようになる。CoreOSのブログには，VMwareがappcへのコミットを改めて宣言したことに加えて，同仕様の改善に向けてコミュニティと緊密に協力していることが述べられている。
InfoQは，CoreOSでプロジェクトのテクニカルリーダを務めるJonathan Boulle氏に，先日のCoreOS Festで発表された内容に関して質問した。
InfoQ: Kubernetesにrktサポートが導入されたことは，このプラットフォームに含まれるさまざまなコンテナのエコシステムがサポートされるという意味で，非常に意義のあるものです。その他のクラスタ管理フレームワーク製品，例えばMesosphereのMarathonやApache Aurora，AWSのECSなどでも，rktサポートを追加する作業は行われているのでしょうか？
Boulle: appc仕様やrktの開発に取り掛かった当初から，Apache Mesosの開発チーム – Mesosphere自身とも，コア開発の多くを行ったTwitterとも – とは，緊密なコンタクトを取っています。彼らからは，有益なインプットをたくさんもらうだけでなく，Mesos自体の中では，独自の仕様実装開発にも積極的に取り組んでくれています。Mesosのコアに機能を統合していくという，彼らのアーキテクチャモデルにもよく適合しますし，私たちが目指している，「明確に定義された標準による，相互運用可能なさまざまな実装」の好例でもあります。appcがMesosのコアに直接組み込まれたことは，Mesosプラットフォーム上で動作するすべてのフレームワーク – MesosphereのMarathon，Apache Auroraなど – にとってメリットがあるのです。
他のクラスタ管理フレームワーク提供者とも，appcやrktの統合について，積極的に議論しているところですので，今後も注目してください！
InfoQ: コンテナ化されたプラットフォームには，ストレージとネットワークが課題として残っています。appc仕様は，これらの問題の解決にはどのような貢献をするのでしょう？
Boulle: 最初に仕様を作った時には，この２つの領域については，意識的にあまり固執しないようにしていました – 特にネットワークに関しては，ほとんどすべての環境において，独自の難解な要件があるため，非常に難しい問題です。ネットワークに関して必要以上に規範的になることは避けたかったので，とても単純なレベルに留めることにしました。仕様ではランタイムに対して，アプリケーションコンテナに3層のネットワークインターフェースの提供だけを求めています。
仕様と並行して自分たちの実装開発も始めていましたので，rktのために，これらさまざまな要件に応える柔軟性を備えた，具体的なネットワークソリューションが必要になることは明らかでした。これを実現するため，私たちはコミュニティの力を借りて(たくさんの協力を得ることができました！)，プラグインベースのネットワーク機構案を開発しました。クラウドプロバイダのテクノロジから，ipvlanのようなLinuxカーネルの最新機能まで，あらゆるタイプのネットワークバックエンドとインターフェース可能な，スタンドアロンのプラグインを開発する，というのが，その基本的なアイデアです。ネットワークに関しては第一人者で，flannelプロジェクトのリーダでもあるEugeneが，このネットワーク機構を実装して，rktに組み込んでくれました。
ところが，rktのネットワーク提案が完成に近づいた頃，コミュニティからのフィードバックの中に重要な提案がありました。rkt自体の外部でネットワークを処理する，もっと汎用的に利用可能なものが望ましいのではないか，というものです。同時に私たちは，業界の他の人たちからも意見を集め始めていました。OpenShiftに携わるRed Hatのエンジニアや，GoogleでKubernetesを開発しているチームなどです。彼らもまた，自分たちのプロジェクト用に，プラグインベースのソリューションを展開することを希望していました。
ご存知のとおり私たちは，このCoreOSのオープンな共通仕様を強く支持しています。共有可能と思われるものに対する，業界のこの強い要求が，そのために何かをしたいと私たちに思わせたのです。標準仕様を共有することで，共通で相互運用の可能なリソースを活用することができれば，業界の，あるいはコンテナのエコシステムの成功のための，極めて大きな力になります。そのために私たちは，先頃，Linux上のアプリケーションコンテナ用のネットワークプラグイン仕様を定義して，CNI(Container Network Interface)と名付けました。当面はappc組織下で，GitHub上で公開することになっていますが，仕様自体はappc仕様とはまったく別のもので，対象範囲もずっと小さくなっています(appcがクロスプラットフォームを意図しているのに対して，対象をLinuxに特定していることがその一例です)。Google，Red Hat，Ciscoなどのエンジニアや，その他コミュニティのメンバと積極的に協力して，仕様の肉付けを行っています。できるだけ早く合意に達して，他のプロジェクトへの統合に着手したいと思っています。
この仕様はまだ提案書として作成を進めている段階なのですが，スタンドアロンで動作する，完全な機能を備えたプラグインが，開発中のものも含めて，すでに多数存在している点には注目してほしいと思っています。実際に私たちは，CNIプラグインを使ってrkt自体を移行する作業を実施して，すでに大きな成功を収めています。つい先日はコミュニティのメンバが，ipvlan用のプラグインを新たに開発しました。
ストレージに関しては，まだ手を付ける時間のない領域のひとつとして残っています。現時点では，大規模な分散システム – KubernetesやMesosのような – の成果を土台として，彼らの専門知識や経験を活用し，それらを仕様に反映したいと思っています。
InfoQ: コンテナは，Linuxサーバ上ではさらに主流となっていますが，その他の市場，例えばWindows サーバやIoTプラットフォームでも，受け入れられつつあるように思います。この分野においてappcあるいはrktは，影響力を発揮できるでしょうか？
Boulle: CoreOSの実装で私たちは，明確に定義された，効率的で高度に構成可能なコンポーネントの構築を重視すると同時に，可能な限りポータブルにすることにも努力を払っています。組込み機器やIoTの世界でも，コンテナを使った興味深いアプリケーションが現れるのは時間の問題です。この領域には，コミュニティからも多くの関心があります。rktとappcをARMデバイスで使用したいと考えているユーザのために，私たちは先頃，appcで認識するアーキテクチャセットにARMv7とv8を追加しました。ARMのエコシステムは歴史的にアーキテクチャ面での多様性が大きく，Linuxなどの実装とは名称が異なる部分もいくつかあります。慎重を期すために私たちは，ARMの技術者たちとも協力して，適切な用語体系を使用できるように注意を払いました。
Windowsに関しては，appcでは当初からクロスプラットフォームな仕様を意図しているので，MicrosoftあるいはWindowsコミュニティから，実装を担当してくれる人が現れればと思っています。仕様の開発においては，コアの部分を非常に汎用的なものにする一方で，OS特有の部分も同じようにサポートすることによって，アルゴリズムとポータビリティの現実的なバランスを慎重に取るよう，多くの努力を払っています。
InfoQ: appcにサポート企業が加わったという発表は，コミュニティ活動の将来を保証する上で素晴らしいことだと思います。サポート企業のリストに将来，Docker Inc.が加わることを期待していますか？
Boulle: appc仕様はオープンプロジェクトですから，すべての企業 – そしてもちろん，コミュニティの誰でも – が議論に参加して，仕様を作り上げてほしいと思っています。 仕様に積極的に関与している個人ならば誰でも，メンテナとして選出される対象になります。すでに運営方針が確立されていて，CoreOSがプロジェクトの命運を左右することはない，という点にも注目してほしいと思います。実際にメンテナの大半は，社外のメンバで構成されています。
Dockerチームのエンジニアがプロジェクトに参加するのは，心から歓迎したいと思います。最初はきっと，仕様の現在の状況と，Dockerプロジェクトにとって問題のありそうな点をフィードバックすることから始めることになるでしょう。次には現在のメンテナたちが，それら仕様上の問題解決に取り組んで，最終的には，Docker Engine自体にappcサポートを実装することになると思います。現在，いくつかのappcランタイム実装 – jetpackやkuma，rktなど – の開発中が積極的に進められているので，仕様に対する集約的な合意作業と，機能的に独立した実装作業を並列的に進行できることは実証済みです。ですから，実装を開発している他のエンジニアグループが新たに議論に加わって，この仕様をさらに明確にしてくれるならば，大歓迎したいと思っています。
私たちの目標は，コンテナがさまざまな創造的な方法で利用されていく，その成功を見届けたいと願うような人々がすべて参加するコミュニティを作り上げることです。
InfoQ: DockerのGithubリポジトリ上に開設された‘Dockerエンジンのランタイムオプションとしてのappc’というPRは，(関連するコードのPOC PR以外)あまり議論を喚起することができませんでした。この結果は意外でしたか？
Boulle: 意外だったと言っていいでしょう。コンテナのエコシステムにおける，私たちの全般的な目標に沿ったものだと強く感じていましたし，その問題を通じてオープンに活動し，総合的なソリューションとしてまとめたいと思っていましたから。PRの最初の具体化(#10776)でもっと状況を明確化することもできたと思いますし，あなたの言う問題(#10777)については，議論を誘導するための純粋な概念実証(proof-of-concept)であって，問題に取り組む意欲を示すためのコードに過ぎないということを，もっと明確化するべきだったかも知れません。残念なことにそのコードは，私たちが望んだような議論の対象ではなく，評価の対象そのものになってしまいました。最初から可能なかぎりの明確化を行わなかったことについては，その責任を受け入れなければならないと思っています。
InfoQ: コンテナに関する技術は，標準化を目指すには若過ぎるのではないかと指摘する開発者が一部にいます。この件について，何か意見はありますか？
Boulle: コンテナ技術は確かに若いですが，標準化して複数の実装が共有すべき問題は，今日すでに存在していると考えています。私たちがappc仕様で定義しようとしているのは，このようなものです。イメージのフォーマット，環境，ネーミング，ディスカバリ，バージョニング，暗号化などに関わる問題が，エンジニアグループが別々に議論して実装した結果であることは，十分に理解されています。
これらの問題で合意に達することができれば，アプリケーション開発者がひとつのappcコンテナイメージを開発するだけで，仕様に準拠したすべての場所で，一貫してアプリケーションを実行できるようになります。コンテナ標準に関して合意に達することが重要だという，主な理由のひとつがここにあります。開発者の作業を容易にすると同時に，共有フォーマット上で相互運用可能な，さまざまなツールを使用できるようになるのです。さらに，ソフトウェアを実運用する段階になれば，運用エンジニアが仕様に準拠した任意のランタイムを選択可能になると同時に，その上でアプリケーションが予測可能な動作をすることに確信を持てるようになります。
現時点では，コンテナ化されたインフラストラクチャに関するすべてを標準化しようというのは – 特にそれが初期段階である間は – 実際には非常に困難であり，おそらくは不可能です。しかしappcでは，ランタイムやネットワークを事細かく標準化するつもりはありません。仮想マシンなどの技術と比較すると，コンテナは，実装上の決定の余地がたくさんあります。このような部分について仕様では，より高いレベルのものとして抽象化しているのです。私たちはappc仕様を，今現在の状況を重視した汎用的なものに留めようと考えています。外部に接するAPIや，リソースの階層管理，ネットワーク実装といったものは，完全に範囲外なのです。
InfoQ: appcあるいはrktのv1が利用可能になる時期について，何か紹介することはありますか？
Boulle: CoreOSには“早期リリース，頻繁にリリース(release early, release often)”という思想がありますし，rktはまだ若いプロジェクトです。ですから，自信を持って実用レベルであると言えるステージに達するまでには，まだまだ多くの作業が必要だと思っています。ひとつ注意して頂きたいのは，v1.0までのrktのメジャー/マイナー番号には，その前提となっている仕様のバージョン番号に従う(どのバージョンの仕様の実装かを明確にするため)，という意図があることです。ですからrktのリリースバージョンは，開発の進捗や完成度を表しているのではありません。これはつまり，rktが1.0をいつ発表できるのかは，仕様の安定化に掛かっているということでもあるのです！
仕様自体に関しては，先日CoreOS社外からメンテナが追加任命されたことで，仕様完成に向けての総合的な体制が完成しました。これらコントリビュータが増えたことで，この2週間，作業が大幅に進捗しました。1.0到達に向けて何が必要か，という点に集中することも可能になってきています。今後このマイルストンに向けた作業は，広範なappcコミュニティのみでなく，運営事務局にいるメンテナの共同作業を基盤として実施されることになります。
CoreOSブログは最後に，新たな企業にappcコミュニティへの参加を呼びかけると同時に，個人開発者に対してもappcメールリストやGithub上の議論への参加を通じて，appcやrktの実装作業に加わることを推奨している。