twitter icon   twitter icon   rss icon

Linux.com Japan

Home ニュース Linux.com Exclusive CoreOS CTO Brandon Philips: コンテナは次世代のパッケージ マネージャー

CoreOS CTO Brandon Philips: コンテナは次世代のパッケージ マネージャー

原文は 2016 年 3 月 22 日に掲載されました。

brandon-philips-coreOS

CoreOS を設立した時、Brandon Philips と Alex Polvi は Linux オペレーティング システムを分散システム向けに根本的に再設計することにしました。

彼らはまず、サーバー基盤全体で改善の余地がある領域を探しました。そして分散システムのハードルの 1 つ、ライフサイクル管理も含むアプリケーションの展開・配置に狙いを定めました。また、伝統的にパッケージ マネージャーの仕事とされてきた、ディスク上の全ファイルのライフサイクル管理が本当に難しいということに気づきました。

「パッケージ管理は、それらを保管・管理するディストリビューションの保守担当者以外にとっては一般的でなく、ある意味失敗してきました。」と Philips は言います。「社内アプリケーションを .deb  や .rpm で作る組織はあまり見られません。もしそのような組織があるとしたら彼らはとても洗練されており、それはある意味挑戦だと言えるでしょう。」

彼らはまた、再現可能性、アトミック ロールバック、アップデートなどの特性を持った、パッケージ管理の強化された分散システム向けオペレーティング システムを作る方法を考えました。

彼らの努力の結果が、クラスターのために特別に設計された、オープン ソースで Linux ベースのオペレーティング システム、CoreOS です。そこにはコンテナ内でアプリケーションを管理するツールも含まれています。しかし、分散システムのために Linux のパッケージ管理を再設計しようという目標はまだ実現できていません。これは一部、コンテナ テクノロジーの標準が確立されていないことにも原因があります。

 

Docker 上に構築

彼らが CoreOS Linux のプロトタイプ作りを始めたとき、CoreOS Linux の基本的な要件はただ 1 つ、コンテナだけでした。もちろんコンテナは Linux の世界では新しいものではありませんが、当時は市場で誤解されていました。コンテナの重要性に対する認識は不十分でした。

Philips と Polvi は、CoreOS 製品化の最終段階に近づいた時、Docker を知りました。Docker はオープン ソース プロジェクトであるため、CoreOS チームが分散システムに思い描いていたことにとても上手く適合しました。最初の CoreOS リリースには 2 つのコンポーネントが付属していました。分散システムの etcd と Docker ランタイムの runC です。また、CoreOS の Web サイトによると、CoreOS の主たる構成要素は、アプリケーションとコードが実行される Docker コンテナ エンジンです。

 

Docker からの分裂

Docker と CoreOS はある意味持ちつ持たれつの関係でした。CoreOS 方は最小主義であり、常にコンテナとアプリケーションの展開・配置に必要な Linux ディストリビューションのアップデートを適用しました。しかし、Docker 方が大きく膨張しはじめ、スコープも拡張しはじめると、かなりの違いが生じてきました。

「私たちは Docker 周りに非常にたくさんの製品を作り上げました。しかし、私たちには Docker オープン ソース プロジェクトで影響力を行使したいと思ったことがいくつもありました。」と Philips は言います。たとえば、Philips は、Docker がデーモン プロセスとして動作しており、他のプロセスの実行に影響を及ぼす可能性があることを懸念しました。また、暗黙の DNS 名なしで、署名検証や標準的でオープンなイメージ フォーマットに取り組みたかったと言っています。

しかしながら、さまざまな理由で私たちが望んでいた変更は Docker に組み込まれることはありませんでした。そこで、CoreOS チームは、コンテナ ランタイムが行うべきことに関して、彼らのビジョンにより合致した rkt (ロケットと発音する) プロジェクトを立ち上げることにしました。また、アプリケーションをコンテナ内で実行する方法を定義する AppC という仕様も作成しました。

CoreOS Web サイトには、「私たちは Docker が導いたコンテナの元々の前提をまだ信じており、これに取り組んでいます。それと同時に、プロダクション適用レベルのコンテナに入れたいものをいくつか整理し、修正しています。」と書かれています。CoreOS がコンテナの設計で重要だと信じている特性は、構成可能性、セキュリティ、イメージの配布、オープンなフォーマットです。

 

オープン ソース ソリューション

CoreOS チームは孤立してはいません。Red Hat や Google といった他のユーザーも同じゴールを目指しています。そこで、2015 年 12 月、CoreOS を含む 40 以上の企業・組織が、コンテナのイメージ フォーマットやランタイムなどのオープンな業界標準を作り、AppC を含む既存の仕様と調和させるという意図を持ちLinux Foundation 管轄下に Open Container Initiative (OCI) を立ち上げました。これまで OCI は プロセスが Linux コンテナ内で動作することの意味に重点を置いてきたと Philips は言います。

「Linux のコンテナはさまざまな個別のテクノロジーでできており、コンテナというものを標準化しようとするのは野心的な目標です」と Philips は言います。「AppC で成し遂げたかったことのすべてを成し遂げ、実際のイメージ フォーマットを完成させるにはまだまだ時間がかかります。」

OCI はイメージ フォーマットに取り組み始めたばかりで、コンテナのネーミングや暗号化キーによるイメージへの署名など、他の基本的なことはまだ議論していません。そして、彼の話によると、一部の OCI メンバーはこれらは OCI のスコープ外であると思っているため、OCI が取り組むことはないかもしれません。

今のところ同プロジェクトは、オープン コンテナ仕様、および、Docker から提供されたコンテナ ランタイム runC の開発に集中してきました。しかし、コンテナ周辺でスタックのテクノロジー層が成熟するにつれ、プロジェクトのスコープは技術革新と加速が必要とされる他の分野に拡張するかもしれません。

一方で、新しい共通のコンテナ テクノロジー一式の作成と採用促進をめざして昨年 7 月に設立された Cloud Native Computing Foundation (CNCF) が、OCI のテクノロジー開発の方向に合わない仕事を引き受けるかもしれません。

「OCI の役員会が、これらのことはスコープ外だとか、技術的な解決方法が見つからないと言う場合は、それらを CNCF に持っていきます」と Philips はいいます。

 

コンテナは次世代のパッケージ マネージャー

Philips と彼のチームは、コンテナにおけるネーミング、イメージ フォーマット、署名といった問題に懸念を抱いています。なぜなら Philips は、自分たちがこれらに責任があると思っているからです。「私たちが正しく行えば、コンテナは Linux パッケージ管理の次の進化のステップとなるでしょう」と彼は言います。

つづいて Philips は、パッケージ管理のおかげで Linux は過去 15 年間成功を収めてきたと言いました。「それ (名前がついているもの) をインストールして」と言える便利さや、それを魔法のように自分のコンピューターに導入できる便利さが素晴らしい、と彼は言います。


Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!