Docker | SEO-LPO.net

Cloud FoundryがDocker互換のコンテナ管理システムDiegoを立ち上げ、DEAを廃棄へ

steel foundry in Redcar clouds billowing

PivotalとVMwareから孵化したオープンソースのPaaS企業Cloud Foundryが今、新製品のコンテナ管理システムDiegoに力を入れている。同社はこれまで、コンテナの管理にDroplet Execution Agents(DEA)と呼ばれるものを使ってきたが、しばらく両者を並行して使ってみた結果、これからはDiego一本に絞ることにした。この管理システムにより、一つのクラスターの中で最大25万までのコンテナを動かすことができる。

Cloud Foundryのユーザー企業でそれほど大規模にコンテナを使っているところは、まだ少ない。しかし最近のエンタープライズデベロッパーたちは口を揃えて、企業におけるコンテナの採用は多くの人が想像する以上に急成長している、と言う。Cloud Foundry自身の調査でも、今や多くの企業がコンテナを評価中だ。ここ数か月の動向を見ると、実装数はまだそれほど多くはないけれども。

Cloud Foundryが目をつけているのは、良質なコンテナ管理サービスにより大規模な展開が容易になれば、企業ユーザーの今後のコンテナの需要とデプロイメントも増え、Cloud Foundry自身の顧客ベースも安定拡大することだ。

しかし、GoogleのKubernetesやDockerのツールなど、既存の（そして比較的よく使われている）コンテナ管理サービスがすでにいくつかある中で、なぜCloud Foundryは、自社製に踏み切ったのだろうか。

Cloud FoundryのCEO Sam Ramjiによると、重要なのは、Dockerによってコンテナが人気者になる以前から同社は、DEAによりコンテナを使ってきた。“しかしそれは標準技術が登場する以前のことなので、かなり癖の強いシステムだった”、とRamjiは語る。たとえば、DEAが前提するコンテナのフォーマットは、独自のものだ。しかしDiegoは、Docker互換だ。つまりそれは、既存のリッチなコンテナエコシステムに、そのまま入っていける。そしてCloud Foundryは、ここ3年ぐらいの間に急速に勃興してきた新しいコンテナ技術の数々を、利用できる。

同社は、DEAの寿命を2017年まで、としている。CloudFoundryの公認ベンダは、それ以降DEAを使ってはならない。しかしこのことは、デベロッパーにはほとんど無関係だろう。Cloud Foundry上でアプリケーションをデプロイするために使うコマンドは、すべて前と同じだ。

[原文へ]
（翻訳：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））

Kubernetes/Docker Swarm両方をサポートするコンテナ管理プラットホームRancher LabsがシリーズBで$20Mを調達

KubernetesとDocker Swarmの両方をサポートするコンテナ管理プラットホームRancher Labsが今日（米国時間5/9）、シリーズBで2000万ドルを調達したことを発表した。このラウンドをリードした同社の新しい投資家は、中国の投資企業GRC SinoGreenで、既存の投資家MayfieldとNexus Venture Partnersも参加した。これで同社の資金調達総額は3000万ドルになる。

新たな資金は、営業とマーケティングの強化および、ユーザーの要望に合わせての製品の改良に充てられる、という。

Rancher LabsのCEO Sheng Liangは今日の発表声明の中でこう述べている: “コンテナ化によって企業は、アプリケーションのパフォーマンスと可利用性とコストを改良するための、すばらしいことがいろいろできるようになった。このパズルの次のピースはコンテナ技術の完成に貢献するものであり、それはコンテナの管理に関連するツールだ。ユーザーがコンテナ技術をフルに利用して、コンテナが約束する財務的および組織的な利益を得ていけるための、正しいツールを提供していくことが、弊社の目標である。弊社が今後もこの目標追求のための努力を継続できることは、きわめて喜ばしい”。

コンテナプラットホームの市場はやや混み合ってきたが、Rancher Labsによれば、KubernetesとDocker Swarmの両方をサポートしているために、Rancherはエンタープライズのコンテナ展開のための正しいツールになっている。しかしおそらくさらに重要なのは、それが、使用するクラウドを特定しないこと、およびエンタープライズがパブリックとプライベート両方のクラウドと、さらに従来からのデータセンターで、コンテナを使えることだ。

なお、Rancherはマルチテナントプラットホームなので、各チームが自分たちのニーズに即したやり方で自分のクラスタを管理できる。この方式では、たとえば、Kubernetesのクラスタのセットアップがわずか5分でできる。（ただしクラスタのデプロイを初めてやる方は、もっとかかるかもしれない。）

コンテナのデプロイを容易にするために同社は、アプリケーションカタログを提供している。それを利用すると、かなり複雑なアプリケーションのデプロイでも、わずか数クリックで簡単に構成できる。

投資をリードしたGRC SinoGreenのパートナーDr. James Zhangは発表声明の中でこう語る: “コンテナはソフトウェアの開発とITのオペレーションを急速にディスラプトしつつある。Rancher Labsはそのすばらしいオープンソース技術によって、ソフトウェア開発の加速化のためにはコンテナ管理が重要であることを企業に示し、同じく適正なコンテナ管理によってアプリケーションをプロダクション（本番稼働）における高い信頼性と効率で動かせることを、示してきた”。

[原文へ]
（翻訳：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）。

実習主体で企業の即戦力エンジニアを育てる新種のプログラミング校Holberton School

今はプログラミングスクールがとてもたくさんあり、それらの多くはだいたい２か月ほどかけて新人プログラマを育てる。でも、その‘卒業生’たちが、プログラマとして給料をもらえる本格的なエンジニアになるためには、１２週間のブートキャンプ(boot camp, 特訓コース)でも不十分だし、ネット上にもまだ本格的な上級コースはない。

しかしここでご紹介する”Holberton School of Engineering“は、まったく新しいやり方でソフトウェアエンジニアを育てようとしている。Holbertonはネット上のWebサービスなどではなく、サンフランシスコに実際に建物がある学校で、ファウンダの三人のエンジニアたちはそれぞれ、AppleとLinkedInとDockerにいた人たちだ。Holbertonの教程は、２年間の受講プラス、半年間のインターン経験だ。同校は今、いちばん最初の入学生を募集している。

Holbertonの協同ファウンダJulien Barbier（Dockerで成長(growth)とコミュニティを担当）によると、同校は従来の大学のような教科中心ではなく、プロジェクトを軸とし、大学に代わる新しい形の高等教育を目指している。

Holbertonの教育の中心は実習（演習）だ。公的資格のある教師はいない。その代わりに学生は、学生同士で学び合ったり、ファウンダたちが集めた多数のメンターたちから教わる。学生たちは、互いに教え/学び合うけれど、プロジェクトは一人でやる。

“実際の職場での経験から、この教え方/学び方がベストだと気づいたんだ”、とBarbierは語る。彼によると、今までの大学は、優秀な成績で卒業しても就職すると再教育が必要だ。でも現職のエンジニアをメンターに起用すれば、デベロッパとしての実際的なスキルが身につく、と彼らは期待している。

“学校の先生になってしまうと、仕事の現場から離れてしまうからね”、とBarbierは述べる。“でも世界は激しく動いているから、その動きについていけない人は古生代の恐竜になってしまう”。

Holbertonでは、入学の方式も独特だ。入学志願者は、まず最初に小さな宿題をいくつかやって、オンラインで提出する（締め切りはない）。次に、実際にWebサイトを作る大きな宿題をこなす。以上が、‘入学試験’だ。

入学を認められた学生が最初に勉強するのは、LinuxのシステムアドミニストレーションとC言語によるプログラミングだ。基本的なDevOpsの実践も体験する。そして２か月後には、Linuxのシェルを自分で書く、という課題をやる。

Barbierが強調するのは、最初からスタートアップを育てるのではなくて、学生たちが、今後スタートアップのファウンダになれるようなシステム力を身に付けることだ。

学生が卒業したら、デジタルの卒業証書がブロックチェーンに保存される。

最初の入学生は、無料で受講できる。学校自身がまだ試行錯誤の段階だから、まあ学生の方も、ベータテストの参加者に近い面がある。本格的に走りだしたときの学費はまだ未定だが、学費を払えない学生にも前向きに対応していきたい、とBarbierは言っている。

今、Holbertonの入学志願者は約1000名いる。定員はまだ決めていないが、最初の‘入学試験’を終えた者の23%は女性だ。そして二度目の課題を提出した者は、その40%が女性だった。

出だしは小さくても、将来的には一学年に3〜4クラスぐらいの規模を目指す。また、サンフランシスコ以外の都市でも開校していく予定だ。

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

Dockerアプリケーションの有料の総合デプロイ＆管理サービスをDocker自身が制作し発表

Dockerが今日（米国時間11/16）バルセロナで行われた同社のデベロッパカンファレンスで、商用のDockerデプロイ総合サービスDocker Universal Control Plane(UCP)を発表した。Dockerの有料サービスUCPは、opsチームによるクラスタのセットアップを容易化し、またそのクラスタに載るアプリケーションのデプロイを、デベロッパ向けに支援する。

Dockerのプロダクト担当VP Scott Johnstonによると、これまではつねに、Dockerなどの新しい技術を採用したいデベロッパと、会社のインフラストラクチャの安全性と信頼性を優先しなければならないITのオペレーションチームとのあいだに、対立があった。しかしスピードとセキュリティの両立は難しいので、何らかのトレードオフに落ち着くのが常だった。

今回の新しいツールを使うと、デベロッパはグラフィカルなユーザインタフェイスとDockerの標準のコマンドラインを使ってセルフサービス的に仕事ができ、一方ITはITでインフラストラクチャのデプロイと管理ができる。

Johnstonの説明によると、このプロダクトは基本的にはDockerの既存のツール（DockerネイティブのクラスタリングマネージャDocer Swarm、Docker Engine、Docker Compose、などなど）をラップするものだが、それだけでなく、エンタプライズが必要とするコントロール機能が大量に盛り込まれている。たとえばUCPは、既存のLDAPやActive Directoryのインストールを統合し、アドミンが個々のクラスタやアプリケーション、コンテナ、それにイメージなどをコントロールできるようにしている。

またユーザオーディットのログをとれるし、最初からTLS（標準化SSL）をサポートしている。アドミンとユーザには、クラスタをモニタリングするためのグラフィカルなツール集が提供される。

エンタプライズはUCPを使って、ローカルなクラスタと、パブリッククラウドに置いたクラスタの両方をコントロールできる。このサービス自身がDockerの標準APIを全面的に使っているので、Dockerに慣れているデベロッパにとってはきわめて使いやすいはずだ。

しかも、ということはこのサービスは、Docerのエコシステム中の既存のいろんなサービスでもって、容易に拡張できることを意味する。たとえば、もっと高度なモニタリング機能が欲しければ、そんな既存のサービスを見つけてプラグインすればよい。

Dockerは先月、Dockerアプリケーションをクラウドからデプロイし管理するクラウドベースのサービスTutumを買収したが、いろんな点でUCPは、それのエンタプライズ向けオンプレミスバージョンと言える。

UCPは今非公開ベータだが、ここで登録できる。料金の発表はなく、また、いつ一般公開されるのかも、現時点では不明だ。

[原文へ]。
（翻訳：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）。

Googleが主力のコンテナサービスContainer RegistryとContainer Engineをアップデート…Kubernetesを統合など

今年Googleは、Container RegistryやContainer Engineなどにより、同社のCloud Platform（IaaS)のコンテナ対応化にますます力を入れてきた。そして今日（米国時間11/10）は、この二つのサービス（ないしツール）のアップデートが発表された。

Container Engineは、クラスタの管理を自動化しコンテナの展開をオーケストレーションするGoogleのサービスだが、今回のアップデートでKubernetesの最新バージョン(version 1.1)をサポートすることになった。ニューバージョンでは随所にパフォーマンスの改良が行われ、そしてそれがContainer Engineのユーザにも可利用になった。

これによりContainer Engineでは、ポッド(pod, ノードの集合)の水平的スケーリング（クラスタへのサービスの追加）を自動的に行えるようになり、またHTTPのロードバランサも可能になる。後者では、トラフィックがその量に応じて別のKubernetesサービスへルートされる。

また、ネットワークのスピードも向上した。それにはContainer EngineにネイティブIPテーブルを導入し、CPUのオーバヘッドをほとんどなくし、信頼性を向上させたことなどが含まれる。

Container Registry（Dockerイメージのストレージ）の方も、今日同様のアップデートが行われた。それらはAPIのv2、パフォーマンスを40%アップ、高度な認証のサポートなどだ。高度な認証により、CodeshipやCircleCI、Drone、Jenkins、Shippable、Werckerなどの継続的なデリバリシステムを容易に統合できるので、デベロッパの仕事が相当楽になるはずだ。

Googleはまた、TwistLockとパートナーして、コンテナのためのセキュリティサービスを導入した。たとえばContainer Registryのユーザは、その上のコンテナへのアクセスポリシーを、設定できる。

[原文へ]。
（翻訳：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）。

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）

DockerをAWSやAzureで使う

unnamed-15.png

unnamed-16.png

unnamed-17.png

関連記事

関連記事

関連記事

関連記事

関連記事