Containers | SEO-LPO.net

Google Kubernetesがバージョンアップ: 複数のクラスター、ゾーン、クラウドにまたがるなどプロダクション対応を強化

A warm glow highlights the ship's wheel on board the sailing yacht "Sincerity" as sunset approaches.

Googleが、同社のオープンソースのコンテナオーケストレーションサービスKubernetesのニューバージョンバージョン1.3を発表した。

1.3は、プロダクション（本番稼働）におけるコンテナを管理するための、よりスケーラブルでロバストなシステムをユーザーに提供することに焦点が当てられている。また、今度のKubernetesは、CoreOSのrktやOpen Container Initiative (OCI)、Container Network Interface(CNI)などが提起している新しい規格もサポートしている。

GoogleのプロマネAparna Sinhaが、今日（米国時間7/6）の発表声明でこう書いている: “ユーザーが自分たちのプロダクションのデプロイをスケールしていくに伴い、サービスを複数のクラスターやゾーン、あるいはクラウドの境界にまたがって利用したい、という声が大きくなっている。また、ステートフルなサービスなど、もっと多くのワークロードをコンテナ化したい、という要望もある。今回のリリースでは、これら二つの問題への対応にとくに力を入れた。また、新しいデベロッパーやエンタープライズがより容易にKubernetesを利用でき、彼らが大小さまざまなスケールで分散システムを管理できるよう心がけた”。

今回のアップデートでユーザーは、複数のクラスターから成るサービスをセットアップでき、しかもそれらは複数のクラウドからホストされていてもよい。Googleによると、これによってハイブリッドでマルチクラウドなシナリオにも対応でき、停電などの事故にも強い高可用性のクラスターを作れるようになる。

ニューバージョンのKubernetesは、データベースのようなステートフルなアプリケーションをコンテナで動かしたい、という多くのデベロッパーの要望にも応えている。関連して、オートスケーリングのサポートも改良され、“これからの顧客はクラスターのサイズを気にする必要がなく、デベロッパーは、クラスター自身が需要の変化に対応できる、と期待してよい”、とGoogleは言っている。

Dockerのランタイムに対する代替的なコンテナランタイムとしてrtkのサポートが加わったことは、それほど意外ではない。GoogleはKubernetesが、拡張性のあるオープンなプラットホームであることを望んでおり、コンテナへのニーズも多様であることを知っている。Dockerの、自由でプラッガブルな性質はもともとKubernetesにも合っているが、それにもかかわらず、あえてユーザーに、自分の好きなパーツの利用を許そう、というのだ。

Kubernetes 1.3はGoogleの、このところ人気が盛り上がっているContainer Engineサービスにも展開される。これは基本的には、Googleのクラウドプラットホーム上の完全な管理を伴うKubernetesサービスだ。Googleによると、Container Engineのユーザーは90日ごとに倍増しており、また今回のKubernetesのニューバージョンにより、ユーザーはひとつのクラスタでこれまでの倍のノード（最大2000まで）動かせる。そしてサービスは、複数の可用性ゾーンにまたがって利用できる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Dockerがコンテナ化されたソフトウェアのためのマーケットプレースを立ち上げ…それは目下の急成長市場

v5qcdypiuxteaes1f7gnlbntzqrqzn7y9abztaxoq8q

Dockerが今日（米国時間6/21）、シアトルで行われた同社のデベロッパーカンファレンスで、Docker化された検証済みで信頼できるソフトウェアのマーケットプレースDocker Storeの、非公開ベータを発表した。

これは一種のセルフサービス型のポータルで、Dockerのエコシステムを構成するパートナーたちが自分たちのソフトウェアをDockerイメージで公開し配布する（有料or無料）。そしてユーザーはそれらのアプリケーションを、容易にデプロイできる。

Dockerはすでに、コンテナの（コンテナ化したソフトウェアの）レジストリを（主にデベロッパー向けに）提供しているが、今度のDocker Storeはエンタープライズのニーズに対応する。同社によればこのストアはエンタープライズに、“コンプライアンスを満たし商用サポートを伴うソフトウェアを、信頼性のある、検証済みのパブリッシャーから、Dockerイメージとして提供する”。有料のソフトウェアもあれば、無料のものもある。有料の場合は当然ながらお店（Docker Store）がマージンを取る。ただしそれらの詳細は、現時点では不明だ。

公開の過程はコンテナイメージのクォリティーに焦点が置かれ、すべてのコンテンツをDockerが検証し、企業のコンプライアンスのためにライセンス情報も含める。

同社は今日の発表声明で述べている: “ここ二年ほどで、Docker化されたコンテンツの利用と作成が急増している。コンテンツに対するこのような需要と、企業内におけるDockerの利用の拡大に伴い、当然ながら、セキュリティとコンプライアンスのニーズも高まっている”。

Dockerによると、最近の2年間でコンテナ化されたアプリケーションは3000%増加して46万種に達し、Docker Hubとイメージリポジトリからとり出されたイメージの数（ダウンロード数）は40億を超えている。マーケットプレースの開設によってパブリッシャーたちは、同社の継続的に成長している顧客ベースにアクセスできる。

Docker Storeはまだ非公開ベータだが、おそらくパートナーのパブリッシャーたちをもっと増やしてから一般公開されるのだろう。現在のパートナーには、Chef, New Relic, Citrix, Splunk, Nginxなどがいる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

DockerがコンテナのオーケストレーションをDocker Engineに統合、単独サービスを不要に

Dockerが今週シアトルで行ったデベロッパーカンファレンスは、事前にチケットが売り切れてしまう盛況だったが、そこでは同社のメインの製品であるDocker Engineに新しい大きな要素が加わった。これまで同社は、コンテナの構築、それらのデプロイ、オーケストレーションなど、主な工程を分割して提供していたが、今回はDocker Engineの中にコンテナのオーケストレーション機能を組み込んだ。

同社はまた、そのツールをMicrosoftのAzureやAmazonのAWSの上で、より容易にデプロイできるようにした。

DockerのCOO Scott John Johnstonによると、これらはすべて、コンテナをもっと使いやすくし、またCEOのBen Golubが今日（米国時間6/20）のキーノートで強調したように、コンテナのオーケストレーションを民主化するための努力の一環だ。コンテナのオーケストレーションは、KubernetesやMesosなど、そのためのフレームワークがすでにいろいろあるにも関わらず、依然としてデベロッパーにとって大きな痛点だ。

今回Dockerがやったことは、昨年11月にベータを終えたクラスタリングサービスDocker Swarmと、オーケストレーションサービスComposeの、Engine本体中への統合だ。これからは、デベロッパーが”Swarmモード”をonにすると、Dockerエンジンの自己治癒型でお互い同士を発見できるクラスターが作られる。Swarmモードにはオーバレイネットワークのサポートが含まれ、それにより自動的サービス発見とロードバランシングのツールが利用できる。また新たに提供されるService Deployment APIにより、デベロッパーはこれから使うサービスや画像、ポートなどを宣言できる。

Johnstonによると、Dockerの既存のSwarmとComposeツールには何も変更がない。それはユーザーの既存のデプロイを壊したくないからであり、また、サードパーティのツールと併用できるという約束に、違反したくないからだ。同社によると今回の統合化によって“Dockerプラットホームを軸とする構築の機会がさらに拡大され”、またそのプラグイン方式のアーキテクチャにより、今後はネットワーキング、ストレージ、ログ取り、パートナーのモニタリングなど、これらのネイティブなオーケストレーション機能を利用する多方面の進化が期待できる。

しかしそれと同時に、彼によれば、これらの新しい機能を使いたいと思っているデベロッパーとシスアドミンの両方が、すでに使い慣れている同じDockerコマンドラインを使えるし、アプリケーションをテストしデプロイするために必要なインフラストラクチャをより容易に構成稼働できる。“分散コンピューティングは難しいが、シスアドミンは分散アプリケーションを管理するために学校へ戻るわけにもいかない”、とJohnstonは語る。“これを構築することによって、ノードが複数ある場合にも、必要なことをすべてオーケストレーションツールがやってくれる”。

またDockerの主張によれば、そのシステムは、外部のインフラストラクチャに依存する特定のエラー発生箇所を持つことがない。セキュリティ機能をSwarmモードにも拡張したため、すべてのノードがTLSとDockerのCryptographic Node Identityを使って通信し、アドミンがやることは、ワークロードを信頼できるノードへディスパッチするだけだ。

これらの新しい機能をすべて揃えたDocker 1.12は今、リリース候補（リリースキャンディデート）を利用できる。一般公開は、7月を予定している。その後さらに徹底的なテストを重ねて、Swarmモードなどの新しい機能が商用製品として提供されるのは、今年の後半だ。

DockerをAWSやAzureで使う

これらの新しい機能と並行してDockerは今日、Docker for AWSとDocker for Azureを発表した。これにより、Docker Engineをこれら両プラットホームで容易にデプロイできるようになる。Johnstoneは語る、“最近の弊社の拡大した市場には、これまで自分たちが選んで使ってきたインフラストラクチャの上でそのまま、Dockerを使いたい、というユーザーが少なからずおられる”。そこでたとえばDocker for AWSは、AWS自身のインフラサービス（AWS Autoscaling, Elastic Load Balancer, Elastic Block Storeなど)とタイトに統合され、Azureエディションは同様に、Microsoftのクラウドサービスと統合化されている。

ここにGoogleのCloud Platformが抜けていることについてJohnstonは、まず市場の圧倒的多数派に対応した、という。Google Cloudのユーザーは、まだ少数派だ。しかし、複数のクラウドを使いたいというエンタープライズも少なくないので、今後のDocker製品のスケーリングと拡張においては、GoogleやRackspaceなどもサポートしていきたい、と彼は述べる。

さらにまた、Docker for OS X(近未来のDocker for macOS?)とDocke for Windowsが非公開ベータを終えて今では公開ベータが提供されている。いずれもDocker体験としては同じだが、AWSやAzureの場合と同様、これらのプラットホーム向けに特別にチューニングされているバージョンだ。

ただしDocker for AWSとDocker for Azureの方は、当面、非公開ベータでのみ提供される。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

LinuxとWindows、両方のコンテナ管理を引き受けるContainerXがベータを終了、無料プランもあり

コンテナ管理プラットホームを選ぼうとすると、昨今は選択肢が多くて迷ってしまう。でも、LinuxとWindowsの両方をサポートしてて、マルチテナントで、導入したらすぐに使えるようなソリューションとなると、候補はそれほど多くない。

今日（米国時間6/16）ベータを終了したContainerXは、DockerとWindows Containersの両方をサポートし、またプライベートとパブリックの両方のクラウドで使える。ただしWindowsの方は、Windows Server 2016がまだプレビューの段階なので、サポートは実験的だ。

ContainerXのCEOで協同ファウンダーのKiran Kamityによると、ベータ期間中に同社に接近してきた企業の1/3以上は、レガシーの.NETアプリケーションをコンテナ化したいために同社のプロダクトに関心を示している。さらに別の1/3は、マルチテナントのサポートに関心があり、残りは、ターンキーのコンテナ管理サービスを探していた。

コンテナに関してKamityがWindowsに関心を持つのは当然だ。彼の最初のスタートアップRingCubeは、Dockerが話題になる前からコンテナをWindowsに持ち込んでいた。RingCubeはその後、 Citrixに買収された。

unnamed-15.png
unnamed-16.png
unnamed-17.png

View Slideshow

Previous Next Exit

Kamityによると、コンテナ管理のソリューションは賭に参加している企業がとても多い。Windowsのサポートは、そんな競争の中でContainerXが自己を差別化する方法のひとつだ。もうひとつの同社の特長は、一部のチームメンバーがVMware出身であることもあって、VMwareのツールとしっかり統合されていること。それに、ContainerXのエラスチックなクラスターとコンテナプールも魅力だ。コンテナ管理サービスは必要に応じてのスケールアップ/ダウンを自動的に行うものが多いが、ContainerXの実装は複数のユーザーを効果的に隔離するので、障害からの立ち直りがはやい、という。

ContainerXの初期のサービスプロバイダークライアントのひとつであるAdvantage24は、東京で複数のデータセンターを運用している。そこの社長で協同ファウンダーのTerry Warrenはこう述べる: “今あるコンテナ管理プラットホームをほとんどすべて、ほぼ8か月かけて評価し、調査したが、最終的にContainer Xに決めたのは、Container Poolsのようなマルチテナント機能があること、ベアメタルのプラットホームを本格的にサポートしていること、そしてターンキーのユーザー体験が、完全なコンテナ管理ソリューションを求めているエンタープライズとサービスプロバイダーの両方にとって理想的だからだ”。

ベータを終えたContainerXには、三本柱の料金体系がある。無料のユーザーには最大100までのロジカルコアをサポート、ゴールドプランは中小企業向けの年額25000ドルのサービス、そして75000ドルからの大企業とサービスプロバイダー向けプランには、チャージバック（払い戻し）などの特典がある。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

コンテナ管理のWeaveworksにGV（元Google Ventures）がシリーズBで$15Mを投資、オープンソースと商用サービスの併立へ

コンテナ管理ツールのWeaveworksが今日（米国時間5/11）、GV（元Google Ventures）がリードするシリーズBのラウンドで1500万ドルを調達したことを発表した。同社へのシリーズAで500万ドルを投資したAccelが、このラウンドにも参加した。同社の調達総額は、これで2000万ドルになる。

Weaveworksは、デベロッパー(dev)とエンタープライズのオペレーション(ops)の両方にとって最新のホットな技術であるコンテナを、管理しモニタしセキュリティを図るための一連のオープンソースのツールを作っている。しかし今回得られた資金は、オープンソースのプロダクトよりも構造性の明確なシステムを求める企業のために、商用製品を作っていくことに充てられる。

CEOのAlexis Richardsonは、今回の資金調達を発表するブログ記事で、“次のステップは統合化された商用製品の提供だ”、と述べている。同社にはクラウドサービスを提供していく計画もあり、それはまだベータの段階だ。

データセンターの進化史における最初の原生動物は、モノリシックな（一枚岩的な）アプリケーションだ。単一の巨大なアプリケーションを作り、それをセットアップしていく。アップグレードは大作業になるので、本当に必要になってからでないと、できなかった。

しかし今日では、デベロッパーはもっと迅速にアップデートしたいし、ユーザーは、変化の激しい市場の中でもっとも最新のツールを使って企業競争に勝ちたい。コンテナはアプリケーションを、複数のマイクロサービスの集まりへと分割する方法を提供する。それらは迅速にデリバリでき、自分の仕事が終わったらメモリから消えていく。

今の企業は、何百何千という大量のコンテナをデリバリし、そのそれぞれが、特定の時間にローンチしてディスクリートなタスクを実行しなければならない。大量のコンテナに関して、それらがすべて正しく行われるためには、ソフトウェアのコーディネーション努力がたいへんな仕事になるが、でも今日までは、デベロッパーとオペレーション（合わせてDevOps）たちは、自作のツールを適当に寄せ集めてそのプロセスを管理していた。

まだコンテナがアーリーアダプターのものだった時代には、そんな大変な仕事を誰もがやっていたが、でも技術がメインストリームに乗って市場の大きな部分を捕まえていくためには、企業が簡単に買えて簡単に使える出来合いのツールセットがあって、それらを既存のシステム管理体制に容易に組み込めないといけない。

そういう仕事をやってくれるのが、Weaveworksだ。同社はコンテナとそのまわりに存在する大量の可動部品のすべてを管理する方法を提供し、ユーザーが作ったコンテナのエコシステムを視覚化する。そしてそのエコシステムのライフサイクルに付き合いながら、複雑な仕事を単純化するためのお手伝いを提供する。

Weaveworks以外にもコンテナ管理を代行するサービスはあるが、同社はその業界のリーダーになれる、とGVは賭けている。今回の投資は、そのための賭け金である。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

CoreOSのStackanetesを使えばOpenStackのコンテナをKubernetesで管理運用できる

オースチンで行われているOpenStack Summitで今日（米国時間4/26）CoreOSが、OpenStackと、Googleのコンテナ管理サービスKubernetesを共用できるシステムStackanetesを発表した。OpenStackとKubernetesはともにオープンソースのソフトウェアで、前者OpenStackは、企業がそれを使ってAWS的なクラウドコンピューティングサービスを自己のプライベートな、あるいはパブリックなクラウドで運用できる。Stackanetes（そう、あまり良い名前ではないかもしれない*）を利用すると、Kubernetesで管理されるOpenStackソリューションを、Kubernetes単独、またはCoreOSのTectonicプラットホーム上で動かせる。〔*: Stackanetesの’netes’はたぶん、Kubernetesの’netes’。〕

OpenStackプロジェクトは、Dockerの成功でコンテナの人気が盛り上がるよりも以前にスタートした。最初、OpenStackとコンテナという二つの技術は同じ市場を争う、と思われていたが、しかし実際には両者は相補的な関係にあることが分かってきた。CoreOSは最初、コンテナを作って動かすことを主眼とする同社の軽量Linuxディストリビューション(CoreOS)に力を入れてきたが、その後、同社独自のコンテナ管理プラットホームTectonicを立ち上げた。

そしてこれからは、Tectonicの上でOpenStackのクラウドを運用し管理することができる。CoreOSの仕事はすべてGitHubのレポジトリにあるので、CoreOSのユーザーであれば誰でもTectonicを使える。特別の会員登録などは、要らない。Tectonicを介さずに直接Kubernetes + OpenStackを使うこともできるが、その場合は、今日のデモで示されたように、コマンドラインからの操作になる。

Kubernetes自身がいわゆる自然治癒(self-healing)のためのツールセットを提供しているから、そこからOpenStackのHorizonダッシュボードを自動的にリスタートしたり、そのほかのダウンしたOpenStackコンポーネントを再起動したりできる。またもちろん、デプロイメントのスケールアップ/ダウンもできる。

CoreOSの協同ファウンダーでCEOのAlex Polviによると、重要なのはOpenStackが単なるソフトウェアである、という認識だ。同社のチームは3週間でこのサービスを構築し、今日それをGitHub上でリリースする。このやり方でOpenStackをデプロイすれば、OpenStackのサービスのライフサイクル管理が容易になり、OpenStackとコンテナの両者をデプロイするための単一のプラットホームが提供される、とCoreOSは主張する。そして、この構造の中でいつでも、OpenStackの上にKubernetesをデプロイできる。

Polviによると、結局のところ今回の仕事(Stackanetes)も、CoreOSの全体的なミッションの一環だ。すなわち、インターネットの安全を確保し、そしてGoogleのインフラストラクチャ（Polviの造語ではGIFEE）を誰もが利用できるようにすることだ。

OpenStack FoundationのCOO Mark Collierはこう語る: “Kubernetesの実力は、OpenStackコミュニティの一員として体験的によく知っている。最近行ったユーザー調査でも、KubernetesはOpenStackのクラウド上でアプリケーションを管理する方法として人気がある。今回CoreOSがKubernetesとOpenStackの両コミュニティを結びつけ、同社の広範なコンテナ専門技術/知識を寄与貢献してくれることは、非常に喜ばしい”。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

MicrosoftのAzure Container Serviceが一般供用へ…オーケストレーションは主要二社の製品から選べる

MicrosoftのクラウドコンピューティングサービスAzure用のコンテナスケジューリングおよびオーケストレーションサービスAzure Container Serviceが、一般的に可利用になった。

このサービスではユーザーが、自分たちのコンテナをデプロイおよびオーケストレートするためにMesosphereのData Center Operating System(DC/OS)、またはDockerのSwarmとComposeを選ぶ。サービスが発表されたのは2015年9月で、公開プレビューは今年の2月に行われた。

MicrosoftのAzure担当CTO（でときどき小説家の）Mark Russinovichによると、DockerのSwarm/Composeと、DC/OSのオープンソース部位…どちらもオープンソースプロジェクトがベース…の両方を使えることが、Azure Container Serviceの、コンペティターにはない利点だそうだ。

Russinovichによると、同社は顧客に、二つのうちのどっちを使え、ということは言わない。“うちのクラウド上で顧客に、どちらか、または両方を使って、グレートな体験をしていただくことが、われわれの仕事”、だそうだ。

MicrosoftとMesosphereの関係は、もうかなり長い。最初同社は、AzureのユーザーがAzure上でMesosphereのDC/OSを使えるという方式を選び、Mesosphereとのパートナーシップにより、WindowsとHyper-VコンテナでもDC/OSを使えるようにした。さらにMicrosoftはMesosphereに戦略的投資を行い、昨年はMicrosoftがMesosphereをその年に買収するという噂もあった。Russinovichはもちろん、買収についてはコメントしないが。

Microsoftの考えでは、オープンソースのソリューションを使うことによってユーザーは、自分たちのワークロードを、必要に応じてオンプレミスに移すことも容易にできる。また、既存のオンプレミスのソリューションをAzureに移すこともできる。

しかしMicrosoftのこの陣容には、GoogleのKubernetesの姿がない。こちらもやはり、オープンソースのプロジェクトだが。この点についてRussinovichは、あくまでも顧客の要望の多いオープンソース技術を選んだのだ、と言う。Kubernetesはこれまでの要望になかった、ということだが、彼は、Azureが今後それをサポートする可能性がないわけではない、と言った。

Russinovich曰く、今Microsoftは、多くの企業がそのワークロードをコンテナに移しつつある状況を目撃している。“数年前にはdevの連中がテストしているだけだったが、今では全社的にそのプロダクションに採用している”、と。

しかしユーザーは、自分のデプロイに対するサポートを、直接、MesosphereやDockerから得なければならない。今MicrosoftがRed Hatとの契約でやってるような、‘Azureからのサポート’という形には、当面ならないようだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

CoreOSのコンテナセキュリティスキャナーClairがベータを脱してv.1.0へ

CoreOSが昨年11月に最初のプレビューを発表した、DockerコンテナのセキュリティチェックツールClairが今日、ベータを終了してClair 1.0のローンチに到達した。

デベロッパーは既製のコンテナに依存することが多く、同じものを再利用することもよくあるから、その中のソフトウェアを安全に保つことはきわめて重要だ。しかも問題はマルウェアばかりではなく、セキュリティの弱点があると分かっている旧版のパッケージが、そのまま使われていることもありえる。

CoreOSが同社のコンテナレジストリQuayにあるコンテナを調べたところ、検出された脆弱性の約70%は、コンテナの中にあるパッケージをアップグレードするだけで解消するものだった。

“インストールされているソフトウェアを最新バージョンにアップデートすれば、インフラストラクチャの全体的なセキュリティも向上する。したがってコンテナイメージのセキュリティ脆弱性を分析することと並んで、Clairが見つけたそれらの問題を解決するアップデートのための、明確な手順や方式を確立しておくことが重要である”、と同社は主張している。“コンテナイメージは頻繁にアップデートされないことが多いが、しかしClairのセキュリティスキャンニングにより、ユーザーは問題のあるイメージをより容易に見つけてアップデートできる”。

CoreOSによると、最初の発表から今日のv.1.0までに、多くの変更をClairに加えている。それらは、サービス全体をより拡張しやすくすることや、REST APIの改良などだが、Clair 1.0でいちばん重要なのは、検出された脆弱性の詳細説明が提供されることだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

DockerがAuroraによるオーケストレーションサービスのConductantを買収、「運用経験は良質な開発のベース」

Dockerが今日、オーケストレーションを専門とする小さなスタートアップConductantを買収した、と発表した。

Conductantを知らなかった人がほとんどだと思うし、そもそもWebサイトも外部資金の導入経験もまだない企業のようだが、この買収でDockerは相当数の人材を獲得することになる。

Conductantは、Bill FarnerとDavid Chungがファウンダーだ。TwitterにいたときFarnerのチームは、のちにApache Auroraとなるプロジェクトを作った。AuroraはMesosをベースとするスケジューリングシステムで、後者は個々のサーバーを抽象化することによって、デベロッパーやアドミンがクラスターの集合を単一のマシンのように扱えるようにする。Auroraは現在、Twitterなど多くの企業で、そのマシン群のオーケストレーションを担当している。

FarnerとChungとJohn SiroisがDockerに加わる。このチームは、GoogleやTwitterやZyngaで、大規模なミッションクリティカルシステムの構築と運用を長年経験している。

Dockerによると、チームはAuroraの商用ディストリビューションを作る仕事を担当する（それはMesosphereなどと競合することになるだろう）。また、AuroraをDocker Swarmに統合する。さらに今後は、AuroraをDockerスタックのコンポーネントとして統合することを目指す。

本誌がもらった内部メモによると、Farnerのチームはほかにも、Dockerの内部的なシステムをいろいろ手がけるようだ。その中には、Dockerの社員一人一人にDockerベースのサンドボックスを与え、個別にAWSのアカウントを持たなくてもよいようにするプロジェクトもある。これをやることを通じてチームは、上述したメインのプロジェクトの一部をドッグフード(dogfood, 毒味)していく。買収が公式に完了するまでの数週間、彼らはすでにそういうことを、やっていたようだ。

“このプロジェクトによって弊社は、Docker DNAの基本的な部分を強化していく。弊社はつねに、自分たちのソフトウェアの運用のプロでもなければならない”、と内部メモには書かれている。“Dockerの誕生も、まさにそのようにして行われた: Dotcloudにおける運用の経験からDockerは生まれたのだ。このように、開発(dev)と運用(ops)のあいだには善循環があり、そのことは、弊社がインフラストラクチャソフトウェアのベンダとして信頼されるための、不可欠の条件だ”。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

コンテナ化したアプリケーションの総合的一元的管理コンソールDocker DatacenterをDockerが提供

Dockerが今日（米国時間2/23）、Docker Datacenter(DDC)と名付けた新しいコンテナコントロールセンター（管理者用総合コンソール）を発表した。ユーザー企業は、規模の大小を問わず、このアドミンツールを使ってコンテナの作成や管理、それに配布をコントロールできる。

DDCは、同じく今日発表されたDocker Universal Control PlaneやDocker Trusted Registryなど、さまざまな商用製品で構成されている。また、一部には、Docker Engineのようなオープンソース製品も使われている。DDCのねらいは、Docker化されたアプリケーションの全ライフサイクルを一箇所の中心的なアドミンインタフェイスから管理できることだ。

この新しいツールは、顧客からの強力な要望に押されてできあがった。企業ユーザーはDockerのコンテナから得られるアジリティーを好感しているが、同時にまた、自分たちが作って配布するコンテナのアドミニストレーションやセキュリティ、それにガバナンスを総合的に管理しコントロールしたいと願っている。Dockerのプロマネ担当SVP Scott Johnstonが、本誌にそう語った。

同社はこれを、Containers as a Service(CaaS)と呼んでいる。Johnstonによると、顧客が同社にこのようなアドミン的コントロール機能を求めるとき、そういう言葉を使うことが多かったのだそうだ。

Docker Data Center architecture lets companies, build, ship and run containers.

画像提供: Docker

多くのオープンソースプロジェクトがそうであるように、Dockerも最初はデベロッパーたちのあいだで人気者になり、その後彼らが仕事をする企業にも浸透し、そして企業は、使いやすい管理ツールを求めるようになった。

DDCはまさに、そういう要望に応えたプロダクトだ。それはデベロッパーに、コンテナ化されたアプリケーションを作るため必要なアジリティーを与えると同時に、オペレーションに対しては、彼らの仕事に秩序をもたらすツールを提供する。

その典型的な過程は、まずデベロッパーが一連のコンテナ化されたコンポーネントを作り、それらのデプロイをオペレーションが承認し、次いで、完全に証明されたイメージのライブラリにアクセスする。これによってデベロッパーは、車輪を毎回再発明することなく、多様なアプリケーションから必要なピースを取り出すことができる。そしてそれにより、アプリケーションの開発とデプロイがスピードアップされる（コンテナが何よりもまず提供するはずのアジリティが、さらに一層強靭になる）。

DDCのベータのときには、この点がとくにADPにアピールした。この給与管理サービスの大手は、デベロッパーにとって可利用なイメージの集中管理的なリポジトリを企業が持てる点を、とくに気に入った。

ADPのCTO Keith Fultonはこう語る: “わが社の、企業にとってとても重要なアプリケーションを、マイクロサービス化して現代化するイニシアチブの一環として、デベロッパーたちが、IT部門が十分検査してセキュリティを確認したコアサービスの、一元管理されるライブラリを利用できるようにしたい、と考えた。それによって、デベロッパーたちの仕事もスピードアップされるはずだ”。

Dockerは、2010年にファウンダーのSolomon Hykesが最初、dotCloudという名前で作った。そして2013年に、Dockerに改名しコンテナ専門企業に変身した。dotCloudは2014年の8月に売却し、Dockerに専念することになった。

CrunchBaseによると、同社は2年前に、相次ぐ5回ものラウンドで計1億8000万ドルを調達し（うち1億6800万ドルがDockerになってから）、投資ブームに湧いた。投資家たちがそこまでDockerに注目したのは、同社が提供するコンテナ技術がアプリケーション開発を現代化する、と確信したからだ。それは、分散アプリケーションの構築と管理と配布を効率化する、新しい方法だった。

デベロッパーはコンテナ化によってこれらの分散アプリケーションを小さな離散的なピースの集まりとして構成でき、しかもそのアプリケーションは複数のサーバーにまたがって稼働する。それまでの、巨大な一枚岩のような、単一のサーバーの上で動く、アプリケーションではもはやないのだ。

Docker Datacenterの使用料は1ノード1か月あたり150ドルからだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

CoreOSのコンテナエンジンrktがバージョン1.0に到達…プロダクション利用可に

CoreOSのコンテナランタイム競合製品rktが今日（米国時間2/4）バージョン1.0に達し、同社によるとプロダクションユースに十分使えるレベルになった。

バージョン1.0ではセキュリティ機能が新たに増え、今後は、CLI（コマンドラインインタフェイス）とオン・ディスクフォーマットのいかなる変更も後方互換性が保証される。

rktは現在、CoreOS App ContinerのイメージおよびDockerのイメージフォーマットでパッケージされたアプリケーションをサポートする。したがって、コンテナをDockerで作って、それをrtkで動かすことが可能だ。

CoreOSがrktプロジェクトを発表したのは2014年の晩（おそ）くで、Dockerランタイムのオルターナティブを提供することがその意図とされた。当時CoreOSのCEO Alex Polviはこう述べた: “Dockerはわれわれみんなが同意できるシンプルなユニットになる、と考えていた。しかし残念ながら、シンプルで再利用できるコンポーネント、という方向には進まなかった。今のDockerは、クラウドサーバーやクラスタリングシステムをローンチするための構築ツールであり、イメージの構築やその実行、アップロード、ダウンロード、さらにオーバレイネットワーキングなど、多様な機能がすべて、一つの一枚岩的なバイナリへコンパイルされ、ユーザーのサーバーの上でもっぱらrootで動いている”。

rktのローンチとほぼ同時期にCoreOSは、App Container(appc)プロジェクトもローンチした。それは、Dockerコンテナのスペックとイメージフォーマットに代わるものだ。

昨年Dockerは、そのコンテナのスペックをOpen Container Initiativeに寄贈した。そこは、コンテナ関連の主要選手が全員参加している、オープンソースの連合団体だ。

一見すると、Dockerのこの動きによって傍系のプロジェクト、rktやappcやCoreOSのイメージフォーマットなどは、割りを食うことになりそうだ。でもPolviは今日、“OCIの主な目的はコンテナのランタイム環境のスタンダードを作ることであり、コンテナのイメージの〜〜ではない”、と主張している。

でも、DockerとCoreOSというこの分野の二大勢力が、とても目立つ競争をしていることは、コンテナにとって強力な追い風になるはずだ。標準化プロセスはまだ始まったばかりだから、元気な論争や競争があることは、とても良いことだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

コンテナを超えてマイクロサービス技術の広い世界を目指すDockerがUnikernel Systemsを買収

Dockerが今日（米国時間1/21）、Unikernel Systemsの買収を発表した。この、イギリスのケンブリッジのスタートアップは、unikernel(ユニカーネル)の普及を目指している（少なくとも、デベロッパに対する普及を）。

Dockerは、同社のツールやサービスにユニカーネルのサポートを統合する計画だ。最近の同社は、デベロッパがさらに効率的なマイクロサービスアーキテクチャを構築できるための、コンテナ以外の技術にも着目し始めている。買収の価額は公表されていない。

ユニカーネルとは、オペレーティングシステムを最小限ぎりぎりまでそぎ落として、特定のアプリケーションだけを動かす、というものだ。それ以上のものでも、それ以下のものでもない。アプリケーションが必要とするライブラリも、コンパイルしてオペレーティングシステムのカーネルに置く。

[ユニカーネルによる隔離と専門化]

アプリケーションがその上で動くマシン（仮想マシン）は極端に小さく、かつ、高速になり、通常のオペレーティングシステムのようなセキュリティの問題が少ない（攻撃を受け入れるインタフェイス〜入り口がほとんどない）。

そのため、ユニカーネルはセキュリティと効率が重視されるアプリケーションに向いている（セキュアであるべき政府のシステム、リアルタイムのトレーディングプラットホーム、IoTのアプリケーションなど）。

Dockerはなぜ、ユニカーネルに関心を持ったのか？　DockerのファウンダでCTOのSolomon Hykesによると、確かにこれは、Dockerが行った買収の中では“いちばん分かりにくい”ものかもしれないが、しかし同時に、彼らにとっては、これまででもっともエキサイティングな買収なのだ。

Unikernel Systemsの13名のチームは、その多くが、Xenハイパーバイザーを手がけたデベロッパだ。Unikernel Systemsはユニカーネルのエコシステムと、そのオープンソース部分に対する、主要な貢献者だ。Hykesによると、Dockerもそのコミュニティへの貢献は積極的に継続していく。

この買収により、Docker自身も大量の深い技術的知識をユニカーネルの世界に持ち込むことになる。“Dockerプラットホームがスタックのずっと下の方〔カーネルレベル〕でも問題解決に向けてきわめてアグレッシブであることを、お分かりいただけるだろう”、とHykesは述べる。“今回の買収はわれわれに、これらの問題を解決するための、さらに多くの能力を与える”。

でもそれは、この買収のひとつの側面にすぎない。Dockerといえば誰もが“コンテナ”を連想するが、しかし同社自身はDockerをコンテナに限定されないエコシステムと考えているようだ。その見方に立てばDockerは、マイクロサービスを推進する中心的な力であり、したがってユニカーネルの採用も、きわめて論理的な次のステップだ。

コンテナによってデベロッパは、“小さいことの味を知った”、とHykesは語る。彼のこの見方では、ユニカーネルは、ペイロードをVMからコンテナへ、コンテナからユニカーネルへと縮小していく路線の上にある。

しかし彼は、それが必ずしも、後者が前者を置換する過程であるとは考えていない。ユニカーネルの利用には、トレードオフが伴う…主に互換性やツールの部分で。Dockerは近い将来、同社独自のツールにユニカーネルのサポートを統合する計画だ。“誰も求めていないのは、三つの完全にばらばらなツール集合だ”、と彼は指摘する。“これはVM用、これはコンテナ用、そしてこれはユニカーネル用、なんてね”。

実は、昨年のDockerCon Europeで気づいた方もおられるかもしれないが、そのときからユニカーネルはすでにDockerの予定表に載っていた。Dockerはある短いデモで、同社のツールを使ってユニカーネルのデプロイメントを管理する例を見せたが、そのデモをステージ上で行ったのは、Unikernel SystemsのCTOで、MirageOSのプロジェクトリードAnil Madhavapeddyだった。MirageOSは、ユニカーネルを構築するための、オープンソースのライブラリオペレーティングシステムだ。

〔参考記事。〕

[原文へ]。
（翻訳：iwatani(a.k.a. hiwa）。

OracleがDocker運用管理サービスのStackEngineを買収、経営の軸足はますますクラウドへ

長年クラウドを馬鹿にしていたOracleが最近は逆にそれを、ものすごく重視している。先週ひそかにStackEngineを買収したのも、同社のPaaSの提供物をさらに一層充実させるためだ。

テキサス州オースチンのStackEngineは、同社のWebサイト上の短い声明で、Oracle.comへの合体を説明している。それによると、データベース大手のOracleが同社を買収し、その条件の一環として社員は全員Oracleに加わる。

StackEngineは昨年、二人のベテラン技術者たちが創業し、Dockerの運用管理を提供するサービスとして2014年10月にステルスを脱した。オープンソースのコンテナシステムであるDockerは、最近の数年間で、猫も杓子も使う日用品のような、普遍的人気者になっているが、それ自体は、ITのプロたちがアドミニストレータとしてコンテナを管理するための機構を欠いていた。StackEngineは、そのことに着目した。

ChefやPuppetとスクリプトを使えばそんな管理層を作ることは可能だが、StackEngineは、もっと最初からDockerに特化された適正な管理コンソールを提供したい、と考えた。今回の買収までに同社は、二度のラウンドで計450万ドルの資金を獲得している。

単独で見ればこの買収は、Oracleの買い物としては奇妙に見えるかもしれないが、むしろこれは、もっと大きな同社のクラウド計画の一環だ。同社は今年、クラウドに向かう大きな数歩を踏み出したが、今回の買収はDockerコンテナに直接関連していて、Oracleのコンテナ市場への参入と、その市場の将来性に賭ける姿勢を表している。

この買収はDockerにとって有意義だったかもしれないが、Dockerはこの前、競合製品Tutumを買収しており、そのほかのコンテナ管理スタートアップにとっては状況が不利になったかもしれない。Docker自身が選んだ管理レイヤが、Tutumなのだ。

Oracleは別の声明で、StackEngineの本拠地オースチンに新たにクラウド専用事業所を作ると言っている。その近くに、クラウド担当社員のための住宅も買うらしいから、今後の人材獲得策も含め、このプロジェクトへのOracleの“本気度”が伺える。

今月初めに発表された決算報告(.pdf)でOracleは、クラウドの売上が26%伸びて6億4900万ドルである、と言っている。その内、PaaSの売上は4億8400万ドルで34%伸びている。対して、オンプレミスの売上は7%ダウンだ。同社の、未来に向けての伸びしろはクラウドにしかない、ということか。

StackEngineにとっては嬉しいイグジットパス、そしてOracleにとってはPaaSの持ち駒のさらなる充実だった。今建設中のオースチンキャンパスは、2016年のOracleの新しい動き（新たな買収、プロダクト開発など）のメインの舞台になるだろう。

〔訳注: ここにグラフが表示されない場合は、原文を見てください（Oracle企業プロファイル）。〕
[graphiq id=”5kqMqbO7qrH” title=”Oracle Corporation (ORCL)” width=”700″ height=”461″ url=”https://w.graphiq.com/w/5kqMqbO7qrH” link=”http://listings.findthecompany.com/l/12055771/Oracle-Corporation-in-Redwood-City-CA” link_text=”Oracle Corporation (ORCL) | FindTheCompany”]

[原文へ]。
（翻訳：iwatani(a.k.a. hiwa）。

Hewlett Packard Enterpriseは今後何もかもコンテナが主軸…ハイブリッドクラウドをメインにしつつ

Hewlett Packard Enterprise(HPE)が今日（米国時間11/16）、バルセロナで行われたDockerのデベロッパカンファレンスで、同社のデベロッパ関連製品のアップデートをたくさん発表した。HPEのコンテナにかける意欲には、並々ならぬものがあるようだ。

HPEのインキュベータパートナー担当VP Tana Rosenblattは次のように語る: “コンテナは確かに画期的な技術だが、それは単に新しい技術であるだけでなく、ハイブリッドな環境を求める企業にとっても意味がある。今後のDockerとの、きわめて有意義なパートナーシップにより、その優れたやり方とプロダクトの恩恵に与れると期待している。その際のわが社の戦略は、受容して拡張せよ、だ。弊社には、devとopsおよび両者を結びつけることに関連した知財がたくさんある。それらをDockerと組み合わせれば、弊社のエンタプライズ顧客にさらに高い価値を提供していけると信ずる”。

HPEには今日ローンチしたハイブリッドクラウドのためのPaaS Helion Development Platform 2.0があり、それが最初からデフォルトでDockerをサポートする。したがってデベロッパとITオペレータはたとえば、このサービスを使って、Dockerコンテナとしてパックされたマイクロサービスをデプロイできる。

HPEにはさらに、クラウドの負荷とパフォーマンスをテストするStormRunnerと、モバイルのパフォーマンスモニタツールAppPulseがあり、これらもDocker化されたアプリケーションのデプロイとモニタリングをサポートする。

HPEのクラウドモニタリングツールSitescopeも、これからはDockerのSwarmクラスタをサポートする。それによりアドミンは、Dockerのクラスタのすべての層…Swarmからコンテナの個々のワークロードを実際に動かすDockerのデーモンに至るまで…をマップしモニタできる。

さらにまた、リリース管理サービスHPE CodarもDockerをサポートし、ストレージ配列3PAR StoreServとソフトウェア定義ストレージStoreVirtualもDockerイメージをサポートする。

以上すべてをひっくるめて、HPEは近いうちに24×7のエンタプライズコンテナサポートを開始し、Dockerのリファレンスアーキテクチャとデベロッパ向けの新たなリファレンスガイドが、ハイブリッド環境にコンテナをデプロイしたいユーザに提供される。

Rosenblattによると、HPE（当時のHP）が、コンテナに全（まる）がけすることを意思決定したのは1年半前だ。HPはこれまでさまざまなアーキテクチャのコンテナ技術をトライしてきたが、コンテナへのフルコミットメントの契機になったのはDockerだ。“今というタイミングを決めたのがDockrだ”、と彼女は述べている。“それへ向かって全社が動き始めたのが1月であり、これからのHPEは、フィジカルからクラウドまでのすべてのソリューションにおいて、顧客にはコンテナによるソリューションを提供していきたい”、というのだ。

[原文へ]。
（翻訳：iwatani(a.k.a. hiwa）。

コンテナのセキュリティをモニタするオープンソースツールClairをCoreOSがローンチ

データセンターのための軽量Linuxディストリビューションとして人気のCoreOSは、コンテナにも熱心だ。今日（米国時間11/13）同社は、コンテナのセキュリティをモニタするオープンソースのツールClairをローンチした。そしてその、まだベータのClairを、同社の有料のコンテナレジストリサービスQuayに統合する。その統合は、今後予定されているQuay Enterpriseでサポートされる。

コンテナはデベロッパの仕事を楽にしてくれるが、Linuxディストリビューションが脆弱性対策のためにたえずアップデートしているのと同じく、コンテナに収めたソフトウェアにも更新が必要な場合がある。たとえばCoreOSによると、同社のQuayサービスに保存されているDockerイメージの80%以上は、悪名高いHeartbleedバグへの対策をしていない。

coreos_clair_schema

Clairは、コンテナをスキャンして既知の脆弱性を探し、問題をデベロッパにアラートする。そのためにCoreOSは、Red HatやUbuntu、Debianなどの脆弱性データベースを参照する。

Clairのチームはこう書いている: “ソフトウェアには脆弱性がつきものだ。したがって、良質なセキュリティの実践によって事故に備えなければならない。とくに、セキュアでないパッケージを見つけ、それらをなるべく早くアップデートすることが重要だ。Clairは、コンテナの中にあるかもしれない、セキュアでないパッケージの発見を助ける”。

チームによれば、このツールの現状はまだまだ幼稚だ。Heartbleedは、このバグのあるOpenSLLのパッケージを使っているときにのみ、起きる問題だ。現状のClairは、コンテナにパッケージがあることは見つけるが、それが実際に使われているかいないかの判断はしない。“Clairにはそこまでの分析はできないので、その後のより深い分析が必要だ”、とClairのチームは言っている。

[原文へ]。
（翻訳：iwatani(a.k.a. hiwa）。

DockerがTutumを買収してコンテナアプリケーションの稼働管理サービスを充実

Dockerが今日（米国時間10/21）、Dockerコンテナのデプロイと管理を提供するクラウドサービスTutumを買収したことを発表した。サービスの対象となるユーザシステムは、クラウドでもオンプレミスでもどちらでもよい。

価額など買収の条件は公表されていない。

企業としてのDockerはこれまで、コンテナの構築、配備、そして稼働に重点を置いてきた。コンテナと呼ばれる離散的なプログラミング/ビルディングブロックは、マイクロサービスと呼ばれることもある。今日の買収によって同社は、これまでプログラマ任せだった、コンテナの継続的な稼働管理の部分も、サービスとして提供できることになった。

たとえばこれまで面倒だったのは、コンテナのデプロイと管理を行うカスタムスクリプトを書くことだ。多くのプログラマが、熟練した経験豊富なコンテナ技術者ではないから、そのスクリプトを書くのに数時間とか数日かかることもある。それによって、本来コンテナから得られるはずのスピードやアジリティが消し飛んでしまうこともある。…Dockerのプロダクト担当SVP Scott Johnstonはこう説明する。

Tutumを買収したことによってDockerは、必要な要素がすべて揃ったサービスのパッケージを顧客に提供できる。成熟したクラウドサービスには、不可欠の条件だ。

“エンタプライズITの市場は、導入したその日から使えるプロダクトを求めている。だから彼らはアプリケーションの構築には力を入れるが、カスタムスクリプトのメンテナンス、アプリのバージョンが変わるたびの書き換え、といった作業は苦手だ。Tutumが、それらの部分を自動化する”、と彼は述べる。

Docker strategy to build, ship and run containers.

Tutumはクラウドサービスで、最初からDockerのためのツールとして作られている。そのサービスによってコンテナ内部の点検ができ、その作成と始動と終了、デプロイが必要に応じてできる。また管理下にあるすべてのコンテナを、ダッシュボードから見張ることができる。

Tutumは2013年の10月に創業されたが、当時はまだDockerは単にLinuxプログラミングの技法の一つであり、プロダクトではなかった。しかし二人のファウンダBorja BurgosとFernando Mayoは、Dockerが無名の存在だったころから、Dockerによるコンテナ技術の将来性を見抜いていた。

BurgosによるとDockerは、10年に一つというタイプのでっかいイノベーションであり、起業のテーマとしてこれに飛びつくことは一種の賭だった。結果は、大穴と出た。

“うちとDockerは、歩を揃えて成長してきた。互いにコラボレーションすることを学び、ヴィジョンを共有してきた。今回の買収は、当然のような次の一歩だ。二つのツールは、相性がとても良い”、とBurgosは語る。

TutumはすでにDockerのコミュニティでは名を知られていて、24000名のユーザ数を誇り、社員も11名いるが、製品イメージの向上に欠かせない大企業ユーザがいまいちだった。しかしDockerの一部になったことによって、その問題も解消するだろう。

JohnstonによるとDockerはつねに、自分たちで作るか・買うか・パートナーするかを検討するが、Tutumの場合は、今のDockerに欠けている部分にぴったりと合う。しかも十分な顧客ベースがすでにあり、スケール能力も実証されており、企業文化も似ている。買収のターゲットとしては、理想的だった。

Tutumの11名のチームは今回の買収により、ニューヨークとマドリードからサンフランシスコに移り、Dockerのチームに加わる。

Tutumはこれまで、272万ドルの資金を調達している。最近では2014年の8月に265万ドルのシードラウンドを終えている。Dockerの調達総額は1億6200万ドルだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）。

AWSがコンテナの作成とローンチを管理するレジストリContainer Registryをサービスとして提供

Amazonが今日（米国時間10/8）のre:Inventカンファレンスで、デベロッパのためのコンテナ管理ツール Amazon EC2 Container Registryをローンチした。

昨年Amazonは、DockerイメージをサポートするコンテナサービスEC2を発表した。AmazonのCTO Werner Vogelsによると、コンテナイメージを生成し、保存し、ローンチするときには、それらを記録するレジストリを参照できることが日増しに重要になる。

“このツールはそれを、開発過程の一部にする”、とVogelsは説明する。デベロッパは自分が作ったイメージをテストし、ローンチOKとなったらレジストリに入れるのだ。

Amazonのそのほかのサービスでもそうだが、同社はレジストリを自作して使っている顧客が多いことを知った。しかしもちろんこれは、企業にとって余計な負荷になり、またそういう余裕のない企業もある。レジストリをサービスとして提供すれば、どちらの企業もコンテナ管理に欠かせないツールを簡単に手にすることになる。

もちろんこのコンテナレジストリはAmazonのコンテナサービスのそのほかの部分とうまく統合化され、イメージそのものはAmazon S3に保存されるので、ストレージの売上もそのぶん増える。

コンテナはデベロッパ界隈でますます人気が高まっているので、より幅広いコンテナ関連サービスを提供することは、Amazonにとっても当然だ。これらのサービスにより、コンテナを作り、管理し、動かすための作業が一層軽減されるだろう。

このサービスは今年の終わりごろより供用開始される。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）。

GoogleのCloud Platform上でDockerコンテナを使うための自動化管理サービスContainer Engineがベータを終えて一般公開

Googleが同社のオープンソースのKubernetesを使って、Googleのクラウドプラットホーム上でDockerのコンテナを動かし管理するサービスContainer Engineが、ベータを脱し一般公開される。すなわちGoogleはそれをプロダクションレディ（production-ready, 企業活動のための本格採用OK）と見なし、アップタイム99.5%のSLAを保証する。

Google自身が早くから、自社のデータセンターでコンテナを使ってきたし、昨年あたりからは、コンテナを大規模に使ってきた経験から学んだことを外部に公開し始めた。なにしろ同社のデータセンターでは、毎週20億個あまりのコンテナインスタンスがローンチされるそうだ。外部公開の典型的な例が、コンテナ管理ツールKubernetesだ。それは最近、新たに作られた団体Cloud Native Computing Foundationに寄贈された。

Container Engineは、コンテナに関する同社のそんな取り組みの頂点にあり、デベロッパはこれを利用して自分のコンテナ展開のための管理つきクラスタを、ほんの数クリックでセットアップできる。Googleによると、すでにRed HatやMicrosoft、IBM、Mirantis、VMWareなどが自社プラットホーム（主にOpenStackのプラットホーム）にKubernetesを統合し始めており、そのためデベロッパは自分のワークロードを、必要に応じて、複数のクラウドプロバイダ間で容易にポートできるようになった。

このEngineサービスを使いたいデベロッパは、自分のクラスタをセットアップし、コンテナの要件（CPUやメモリなど）を宣言する。するとEngineサービスはこれらの指示に従ってクラスタをモニタする。GoogleはContainer Registryも提供しており、こちらは2ヶ月前に一般公開された。このレジストリにプライベートなDockerイメージを保存してアクセスすることにより、デベロッパは自分のクラスタを必要に応じてスケールできる。またGoogle Cloud VPNを利用すると、コンテナネットワークのハイブリッドな展開も可能だ。

このサービスの使用料は仮想マシン5基までが無料（ただしCompute Engineのインスタンスは有料）で、その後、最大100仮想マシンまでの標準クラスタが、毎時15セントだ（こちらもCompute EngineやそのほかのGoogle Cloud Platformの費用は別)。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

MicrosoftがMesosphereの協力でMesosをWindows Server 2016に統合

Apache Mesosプロジェクトをベースとして、コンテナを軸とする“データセンターのためのオペレーティングシステム”を作ろうとしているMesosphereが、今日（米国時間8/20）行われたMesosConで、Windows Server 2016のプレビューバージョンの上で動くMesosの、初めての公開デモを行った。

Microsoftは昨日、DockerコンテナをサポートするWindows Serverのテクニカルプレビューをローンチしたばかりだから、デベロッパがこの機能を実際のプロダクションで使えるのはもっと先だろう。

Mesosphereの協同ファウンダBen Hindmanによると、彼のチームはMicrosoftと密接に協働して、オープンソースのApache Mesosプロジェクトとオープンソースでないサーバ製品との接合に努めた。彼によると、Mesosphereの企業顧客の多くもかねてから、自分たちがコンテナを本格的に使うようになればWindows Serverもサポートしてほしい、と言っている。

多くの企業の現実として、彼らのデータセンターではLinuxのワークロードとWindows Serverのワークロードの両方を動かしている。そこで、今回のMesos（〜Mesosphere）サポートにより、オペレータはどちらのワークロードのタスクでも、同一のコンテナ管理ツールを使えるようになる。

mesos_windows_server

Windows Server上のMesosは、Microsoftが最近のWindows Serverのプレビューで導入したMicrosoft作のDocker APIにプラグインすることになる。それによりデベロッパは、Windows Server Containerと、さらに今後のMicrosoft独自のコンテナHyper-Vの両方を使えるようになる。

Microsoft AzureのCTO Mark Russinovichによると、Microsoftがこのプロジェクトに参加したのは、Windows用のもうひとつのコンテナオーケストレーション技術を顧客に提供したいからであり、顧客もそれを求めているからだ。Azureクラウド上のMesosはすでにデモしたことがあるが、しかしそれは、Linux上で動くMesosだった。

一方Mesosphereのチームによると、今回の統合を実現したコードは（オープンソースだから）1〜2週間後にGitHubで公開される。その一部は、すでにアップされている。

最近では、MicrosoftがMesosphereを買収する、という噂もある。両社の仲は良好だし、Microsoftはコンテナ技術をクラウドとサーバの両方でより本格化したいと願っているから、ありえる話かもしれない。

また、このところMicrosoftは、これからはオープンソースコミュニティと積極的に関わっていく、と公言している。オープンソースコミュニティとの協働関係はGoogleの方が先輩だから、Googleとしても、鳶に油揚げをさらわれるのを、黙って見てはいないだろう。MesosphereがM/G 両社のあいだで競り値の高いオークションの標的になることも、考えられる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Open Container InitiativeにAT&T、Oracle、Twitterなどが加わり、より強力な標準化組織に

1か月前にDockerとLinux Foundationが、Dockerのデベロッパカンファレンスで、 Open Container Projectを発表した（日本語）。今それはOpen Container Initiative(OCI)と呼ばれ、Linux Foundationの事務局長Jim Zemlinが今朝（米国時間7/22）のOSCONで、このプロジェクトが急速に成長している、と述べた。新たに14の企業が参加しただけでなく、今ではOCIという組織の定款も作ろうとしている。

このイニシアチブを支える新たなパートナーはAT&TとClusterHQ、Datera、Kismatic、Kyup、Midokura、Nutanix、Oracle、Polyverse、Resin.io、Sysdig、SUSE、Twitter、そして本誌TechCrunchの新しいオーナーであるVerizonらで、彼らと創立時のメンバーAmazon、Microsoft、CoreOS、Docker、Intel、Mesosphere、Red Hatらが協働して、Dockerコンテナの今後の仕様等をガイドし、コンテナの共通スタンダードの確立を目指していく。

2015-07-22_1016

Dockerの企業マーケティング担当VP David Messinaによれば、今のOCIのメンバーは大と小がバランスよく入り混じっていて理想的な形だ。とくにOracleが参加したことにより、今後はSolarisの上のコンテナに関する活発なフィードバックが得られるようになるだろう。もちろん、Sun Microsystemなきあとは、OracleがSolarisの最大の経験者だ。またこれまでよりも多くのディストリビューションやモニタリング企業、そして大企業が加わったことによって、最終的に良質なプロダクトが作られるものと期待される。それは、各社それぞれの専門知識や技能の、寄与貢献が期待されるからだ。

“Open Container Initiativeには熱い関心が寄せられており、そのことは、コンテナがアプリケーション開発に提供する機会と、他方では規格や実装の多様化と分裂という危機の可能性、その両方を表している”、とLinux FoundationのJim Zemlinが今日の声明文の中で述べている。“強力なコミュニティサポートとコラボレーションにより、この取り組みが機会の方の比重を高めていくことを、確信している”。

DockerのエンジニアPatrick Chanezonによると、定款はなるべく軽量なものにしたい、という。今後問題が起きれば技術監視委員会で解決できるし、また今後の（規格準拠）証明交付事業では商標委員会が活躍するだろう、と。

今はコンテナのエコシステムがこれほどまでに急成長しているから、コンテナそのものと一部の関連ツールに関して標準化の声が高まるのも当然だ。またそれがなければ、コンテナの今後のポータビリティもおぼつかない。昨日（米国時間7/21）発表された（日本語）Cloud Native Computing Foundation(CNCF)によりLinux Foundationには、もうひとつのメジャーなコンテナ関連のオープンソースプロジェクトが加わったことになる。こちらはGoogleのコンテナ管理とスケジューリングのツールKubernetesに関連する組織だ。

しかしなぜ、Open Container ProjectがOpen Container Initiativeになったのか？　ZemlinはOSCONのキーノートで、Open Compute Projectと紛らわしいから名前をすこし変えた、と述べた。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

DockerをAWSやAzureで使う

unnamed-15.png

unnamed-16.png

unnamed-17.png

関連記事

関連記事

関連記事