コンテナ | SEO-LPO.net

サービスメッシュ型コンピューティングの普及に賭けるBuoyantがシリーズAで$10.5Mを調達

Buoyantは、TwitterのインフラストラクチャエンジニアだったWilliam MorganとOliver Gouldが作った企業だが、同社は今日（米国時間7/11）、シリーズAで1050万ドルを調達したことを発表した。このラウンドをリードしたのはBenchmark Capital、これに、女性を中心とするTwitterの新旧役員グループ#Angelsと、これまでの投資家A Capital Ventures, Data Collective, Fuel Capital, SV Angel, そしてWebb Investment Networkが参加した。BenchmarkのPeter FentonがBuoyantの取締役会に加わるが、彼は数か月前にTwitterの取締役会を降りたばかりだ。

Buoyantは誰もが知ってる名前ではないが、オープンソースのLinkerdプロジェクトを作った企業だ。今年の初めにCloud Native Computing Foundationの一員となったこのプロジェクトは、いわゆる“サービスメッシュ”(service mesh)と呼ばれる、新しいインフラストラクチャツールの中で、たぶんもっとも人気のあるシステムだ。サービスメッシュ（サービスの網）とは、今日のアプリケーションを構成するさまざまなサービスを互いに通信/コミュニケーションさせるための、インフラストラクチャ層だ。たとえば、Kubernetesなどのコンテナオーケストレータの上で動く複雑なアプリケーションは、たぶん何百ものさまざまなサービスで構成されているだろう。これらのサービスは、静的とはとても言えないネットワークの上で、互いに通信できなければならない。LinkerdやIstioのようなサービスメッシュは、ロードバランシングとダイナミックルーティングを組み合わせて、それらのサービス間の通信を確保する。なお、Istioは、最近発表されたGoogle/Lyft/IBMのコラボレーションだが、今ではLinkerdと共用できる。

現在のLinkerdのユーザーには、Ticketmaster, Apprenda, NextVR, Houghton Mifflin Harcourt, Monzo（イギリスの銀行スタートアップ）などがいる。

“ソフトウェア産業の全体がクラウドコンピューティングへ移行すると、アプリケーションの作られ方や運用のされ方が大きく変わる”、 BenchmarkのFentonは今日の発表声明でこう述べている。“Buoyantによるサービスメッシュの導入は、マイクロサービスのコンポーネントやクラウドネイティブなソフトウェアと同じぐらい基本的な成分になる可能性がある。ネットワークプログラミングにとって、TCP/IPがそうであったように。そしてLinkerdが昨年思い切ってオープンソースを採用したことによって、そのニーズが企業にとって喫緊のものであることが明白になってきた”。

BuoyantのCEO William Morganによると、サービスの収益化についてはまだ何も決めていない。今度の資金は、エンジニアと製品開発部門の増員に充てられる。今社員は13名だが、エンタープライズユーザーにはすでに有料サポートを提供している。Linkerdを中心とするエコシステムを築くことが先決で、収益化云々に関心を向けるのは時期尚早である。“ある時点で方向を変えてお金を稼がなければならないけど、短期的にはオープンソースの採用が関心の中心になる”、と彼は語る。

企業のアプリケーションの開発が“クラウドネイティブ”型へ移行していくに伴い、Linkerdのようなプロダクトへのニーズもたちまち明らかになってくると思われるが、現時点ではまだ時期が早く、とくに大企業は歩みが遅い。しかしMorganによれば、アーリーアダプタたちの多くは大企業よりむしろスタートアップたちである。“彼らは今すでにクラウドネイティブのスタックへ移行しつつあるし、それには正当な理由がある”、とMorganは語る。“彼らは自分たちのアプリケーションをこのクラウドモデルで運用したいと願っている。それなら、ハードウェアのコントロールがほとんど不要だからだ”。

DockerとKubernetesがこのパズルの一片を解いたが、往々にして一つのソリューションが新しい問題をもたらすのだ。

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

AppDynamicsのアプリケーションパフォーマンス管理サービスがDockerのコンテナに対応

今年初めに37億ドルで買収されてCiscoの傘下になったAPM(application performance management/monitoring)プレーヤーAppDynamicsが、今日（米国時間6/29）のアップデートでついに、成長が今も続いているトレンド、コンテナに対応することになった。

コンテナの問題は、なにしろその数が多いことだ。コンテナを利用すると一枚岩的なアプリケーションを小さなマイクロサービスの集合に分割できるが、そうすると、パフォーマンスの劣化等の原因を、個々のコンテナのレベルで特定しなければならない。AppDynamicsのデベロッパー対応担当Matt Chotinは、そう語る。

その問題の原因が分かっても、アプリケーションがどのようなコンテナ構造（マイクロサービス構造）でデプロイされているのか、ユーザーに聞いても分からない場合が多い。ユーザーにとってアプリケーションは動けばいいのであって、最近のAppDynamicsの調査によると、アプリケーションのユーザーとは、辛抱強くない動物である。アプリケーションの調子が悪くなって、問題が簡単に解決しないと、別のアプリケーションへ移ってしまう。

コンテナでデプロイしている場合は、パフォーマンスの問題の原因を見つける作業が非常に困難になる。“同じコンテナの複数のインスタンスをデプロイしていて、どれも同じ状態のように見えても、実際にはどれかが問題を抱えている。そんなとき、問題のコンテナをどうやって特定するのか？”、とChotinは問う。

AppDynamicsのMicroservices iQはDockerのコンテナモニタリング機能を統合して、三つの領域の情報をユーザーに提供する: 1)ベースラインメトリックス、2)コンテナメトリックス、3)その下のホストサーバーメトリックス。これらによりオペレーションのチームに、不良なコンテナを見つけるために必要な情報を与える。

同社はまた、Tier Metrics Correlatorと呼ばれるヒートマッププロダクトをリリースした。分かりづらい名前だが、これはコンテナのデプロイ状態を視覚化するツールで、問題を抱えているコンテナがすぐ分かるように表示される。

これまでさまざまなデータソースを手作業で調べていたオペレーションチームも、情報がこのように視覚化されると、相当な時間節約を達成できる。この新しいツールは要するに、たくさんの点と点をつないで像を作り、問題領域を指摘する。

Chotinによると、コンテナは数が多いから、このことがとくに重要だ。“ひとつの仮想マシンではなくて、数十から数百というたくさんのコンテナが相手だ。それらをいちいち、人間が調べることはできない。良質な視覚化がどうしても必要なんだ”、と彼は説明する。

Chotinによると、同社の周辺でもコンテナを採用する企業が増えている。そして少なくとも今は、需要はDockerに集中している。“今のコンテナ・ブームの中でうちの顧客は、圧倒的多数がDockerを使っている。でも、今後そのほかのコンテナ技術にうちのツールを対応させることは、それほど難しくない”、と彼は言う。

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

MicrosoftのDraftはコンテナ化の面倒を引き受けるクラウドサービス、デベロッパーはアプリケーションのコードをローカルに書くだけ

Microsoftが今日（米国時間5/31）、Kubernetesのクラスターの上で動くコンテナベースのアプリケーションを、より簡単に作れるオープンソースのツールDraftをローンチした。簡単というのは、デベロッパーは自分のアプリケーションにだけ集中すればよくて、DockerやKubernetesについては関知しなくてよい、という意味だ。というか、そもそも、コンテナという技術を支えるこれらのツールは、自分のマシンにインストールされていなくてもよいのだ。

4月にMicrosoftは、コンテナプラットホームDeisをEngine Yardから買収した。今日のリリースは、その最初の果実だ。Deisは、デベロッパーがコンテナを簡単に使えるようにすることを使命とし、買収されるまでWorkflow, Helm, Stewardといったオープンソースのツールをいくつかローンチしていた。Draftは、これらDeisの成果物の一部を利用している。

今日の発表声明には、次のように述べられている: “Draftは、デベロッパーのワークフローの“インナーループ”に集中する。デベロッパーがコードを書き、それをバージョンコントロールへコミットする直前までの過程だ”。Draftを使う場合、デベロッパーは‘draft create’というひとつのコマンドで“Draft pack”というものを作る。Draftは、そのコードが書かれている言語を自動検出し（Python, Node.js, Java, Ruby, PHP, Goをサポート）、検出スクリプトとDockerのファイルとKubernetes HelmのChartを書いて、packをソースツリーへとビルドする。そこから先は、そのコードを既存の継続的インテグレーションに入れるだけだから簡単だ。

もうひとつのコマンドでデベロッパーは、自分のアプリケーションに対する仕事をローカルに開始でき、そのコードが自動的にKubernetesの開発クラスターへ入れられる…それが動いているのはローカルでもリモートでもどちらでもよい。ローカルに加えた変更は、数秒以内にそのクラスター上で可利用になる。“そのため、デベロッパーがコードをローカルに書いも、しかし開発環境はクラウドにあり、そこでアプリケーションの依存性のすべてにアクセスできる”、とチームは説明している。

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

CoreOSがコンテナプラットホームTectonicをアップデート、Kubernetesの最新バージョンとetcdデータストアをサポート

CoreOSが今日（米国時間5/31）、サンフランシスコで同社のユーザーカンファレンスを開催している。当然ながらそのイベントでは、同社のあれやこれやがたくさん発表された。そしてその多くは、Kubernetesベースのコンテナインフラストラクチャを管理するTectonicプラットホームに関連している。

アップデートの多くは、単純明快だ。たとえばTectonicは今やKubernetesの最新バージョン1.6.4を使っているが、同社によると、エンタープライズ対応のKubernetesプラットホームでその最新バージョンを使っているのはTectonicだけだ、という。ただしそのバージョンは主にバグフィクスが目的で、メジャーバージョンではない。

しかしさらに重要なのは、デベロッパーが今や簡単に、CoreOSで人気のキー-ヴァリューデータストアetcdを導入し利用できることだ…そのためには新たなツールetcd Operatorを使う。etcdを使いたいデベロッパーは、Operatorを使ってetcdを必要に応じてスケールするが、エラーはサービス側がおだやかに処理し、アップデートも自動的に行う。

CoreOSのファウンダーでCEOのAlex Polviによると、同社が今注力しているのはエンタープライズ顧客の獲得だ。彼の主張では、今エンタープライズと呼べるほどの企業は、コンテナによるアプリケーション開発に注目している（そして既存のアプリケーションはクラウドへ）。しかしAmazon, Microsoft, Googleなど特定のベンダーにロックインされたくはない。“でも1年ぐらいそこにいただけで、請求書は屋根を突き抜け、彼らのAPIをすべて使い、そして完全にロックインされる。われわれは、そんなサイクルを終わらせたい”。

Kubernetesは多くの企業にとってコンテナオーケストレーションプラットホームの第一の選択肢だから、CoreOSも、主なクラウドプラットホームすべての上で（そしてオンプレミスでも）その利用を手伝いたいが、主なプラットホームすべてをサポートすることで、そのようなロックインを避けたい。

Polviによると、同社がエンタープライズへの直接的な営業を開始したのはやっと2016年の最後の四半期からだ。最近ではそれがほぼ軌道に乗り、そしてPolvi説ではKubernetesも離陸したから、CoreOSの営業活動のエンジン全開もこれからだ、という。

〔関連記事：Microsoftのコンテナアプリケーション開発ツールDraft（未訳）〕

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

マイクロサービスの集まり（単一/複数アプリケーション）を安全に管理するプラットホームIstioをGoogleとIBMとLyftが共同で立ち上げ

マイクロサービス(microservices)は、大きなアプリケーションを小さな部品に分割して、それらがAPI経由で互いに通信し合う、という開発方式だが、今ではとくに、コンテナをベースとするマイクロサービスが、多くのデベロッパーのあいだで最大人気のアプリケーション・アーキテクチャになっている。しかし、小さなサービスの大軍を管理することには、それなりの課題が伴う。デベロッパーとDevOpsたちが彼らのマイクロサービスベースのアプリケーションを管理しその安全を確保できるために、Google, IBM, およびLyftが今日、デプロイしたサービスのネットワークを作れるオープンなプラットホームIstioを発表した。そしてそれには、ロードバランシングやサービス間認証、モニタリングなどのツールが含まれている。

このプラットホームの利用にあたって、既存のアプリケーションの変更は必要ない。その理由として、Istioはネットワークのレベルにいて、ユーザーのマイクロサービス間のネットワーク通信をプロキシを使って捕捉するからだ。使用するプロキシはLyftが開発したEnvoyで、そのほかにサービス発見やロードバランシングのためのツールも含む。

Istioのチームはこう説明する: “一枚岩的なアプリケーションがマイクロサービスの集合に分解されると、分散システムの上で複数のサービスを統合していくことが、新たな課題になる。そしてそのためには、サービス発見、ロードバランシング、フォールトトレランス、エンドツーエンドのモニタリング、機能の実験のための動的ルーティング、そしてとりわけ重要なコンプライアンスとセキュリティを備えなければならない。これらを揃えるにあたって不整合が生じたり、つぎはぎだらけのライブラリやStackOverflowで拾ったコード片を使ったりしていると、複数の言語やランタイムにわたって互換性を欠く、ばらばらなソリューションができあがり、観察性/観測性が劣化し、その結果セキュリティが壊れることも少なくない”。

単一のライブラリに標準化してサービス間の通信を管理することは、理論的には可能だが、実際にはなかなかありえないことだ、とチームは主張する。そこで既存のサービスがそのまま残り、柔軟性を欠くことになる。

Istioはデベロッパーに単一のサービスメッシュを提供し、その中に、ロードバランシングやフローコントロールやセキュリティポリシーの実装に必要なモニタリングサービスがあって、ネットワークの信頼性が落ちてもアプリケーションが動き続けられるようにする。また、複数のアプリケーション間の通信に必要な認証とセキュリティを、TLS接続により提供する。そうするとデベロッパー自身は、証明の管理などの雑務を免除される。

IstioにはGoogleも参加しているから、今のところはコンテナオーケストレーションサービスとしてKubernetesしかサポートしていないが、いずれは他の環境もサポートしていく計画だ。むしろIstioの基本的な考え方は、特定の環境に縛られないことだから、今後はMesosなどもサポート対象になるだろう。またGoogle自身も、同社のユーザーAPI提供/管理プラットホームCloud EndpointsやApigeeをIstio対応にする措置を講じている。Googleは昨年Apigeeを、6億2500万ドルで買収した。

ただし、今やKubernetesプロジェクトの‘公共的住処（すみか）’となったCloud Native Computing Foundationにも、Istioに類似したプラットホームlinkerdがある。linkerdはすでに、DockerとMesosphereのDC/OS（データセンターオペレーティングシステム）のサポートを提供している。

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

Red Hatがコンテナ化アプリケーションを開発するためのクラウドIDE、OpenShift.ioを立ち上げ

Red Hatが今日（米国時間5/2）、OpenShift.ioを立ち上げた。それは同社としては初めての、本格的なクラウドベースのデベロッパーツールだ。その名が示すように、OpenShift.ioは、Kubernetesをベースとする同社のコンテナ管理プラットホームOpenShiftを使用し、クラウドネイティブでコンテナを利用するアプリケーションの構築に必要なツールを提供する。それらは、チームコラボレーションのためのサービス、アジャイルプランニングのツール、デベロッパーのワークスペース管理、コーディングとテストのためのIDE、モニタリング、そしてもちろん、継続的インテグレーションとデリバリのサービスだ。

方向性はやや違うが、これはいわば、MicrosoftのVisual Studio Team ServicesのRed Hatバージョンだ。しかしRed Hatがここでやっているのは、fabric8, Jenkins, Eclipse Che, それにもちろんOpenShiftといった既存のオープンソースプロジェクトをひとつのサービスにまとめて、主にコンテナベースのアプリケーションにフォーカスした体験を提供することだ。

OpenShift.ioは中でもとくに、チームのコラボレーションを重視し、そのためのさまざまな開発方法論や哲学をサポート、そしてソースコントロールシステムを提供している。またプロジェクトマネージャーやビジネスアナリストなど、チーム内のノンプログラマーがプロジェクトの状態を追えるためのツールも、充実している。

Red Hatでプロダクトとテクノロジーを統轄するPaul Cormier社長が、今日のブログ記事で述べている: “Red Hatは、クラウドネイティブと従来型の両方のアプリケーション開発に取り組むための、オープンで自由度が高く安全なツールを、標準的ツールをベースとする全体的に斉合性のあるプラットホームとして提供している。今日私たちはご覧のように、Red HatのコンテナプラットホームOpenShiftを利用してコンテナ化されたアプリケーションを構築するための、クラウドベースのフレームワークを立ち上げる。それは、今日の類似製品の中でもっとも総合的な、エンタープライズ向けKubernetesプラットホームだ”。

Red Hatは今日、OpenShift.ioのほかに、Red Hatおよび同社のISVパートナーたちのすべてのコンテナ関連製品の、セキュリティや安定性などを調べて評価できるContainer Health Indexを発表した。またもうひとつ今日ローンチしたRed Hat OpenShift Application Runtimesは、マイクロサービスのための、構築済みのコンテナ化ランタイムの基盤群だ。これらのランタイムには、Node.js, Eclipse Vert.x, WildFly Swarmなどのサポートが含まれる。

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

OpenStackの古参Mirantisが顧客の要望に逆らえずKubernetesをクラウドサービスの核に加える

OpenStackのエコシステムにその初期からいるMirantisが今日、これまでのメインプロダクトMirantis OpenStackのサポートを2019年5月に終了し、OpenStackとコンテナプラットホームKubernetesを組み合わせたクラウドサービスMirantis Cloud Platformをその後継プロダクトにする、と発表した。この新しいサービスでは、Kubernetesだけ、というサービス形態もありえる。

もちろんMirantisがOpenStackから一抜けるわけではないが、コンテナプラットホームとしてのKubernetesの人気と関心がMirantisの顧客のあいだでも最近はますます高まっているので、同社もそれに合わせざるをえない。今日発表された新しいプラットホームでは、OpenStackと共存してKubernetesの複数のクラスターをデプロイできるし、両者別々や、Kubernetesのみ、というデプロイも可能だ。顧客の中にはこのように、OpenStack抜きでソフトウェアのデプロイ方式を現代化したい、という要望もある。

新しいプラットホームは、その配布方法も変わっている。同社は顧客のMirantis Cloud Platformのデプロイを少なくとも6か月、彼らに代わって運用するが、その後は運用を顧客のOpsチームに委（ゆだ）ねる。同社は今日の発表声明で、こう言っている: “このデリバリモデルによって、ソフトウェアだけでなく、顧客のチームと工程もDevOpsのベストプラクティスに確実に従うようになる”。アップデートもこれからは、一定期間間隔で、迅速かつ楽に行われるようになる。従来の同社のOpenStackソリューションでは、アップデートもそれほど楽ではなかった。

Mirantisの協同ファウンダーでCMOのBoris Renskiは、自分の意見を言うとき、いわゆる歯に衣着せぬタイプだが、OpenStack vs. Kubernetesという議論に関しては、“人気と価値は違う”、と言う。“ハイスクールで人気者だった子が、大人になってフェラーリに乗ってるとはかぎらない。今のOpenStackは人気者ではないし、人気者はKubernetesだ。そして顧客は、人気者になびく場合が多いのだ”。

彼によると、Mirantisの顧客にもOpenStackを避けてKubernetesだけで行く、という企業が増えている。CanonicalのDustin Kirklandも、今月の初めに同じことを言っていた。Renskiは曰く、“OpenStackが人気トップだったころは、顧客は自分のデータセンターでOpenStack以外の何もかも脇に置くようになった。そして失敗した。重要なのは、その仕事に合った正しいツールを使うことだ。今、コンテナならKubernetesが良い。VMなら、OpenStackだ。たぶん明日になればAWSがLambdaをオープンソースにして、今度はKubernetesとコンテナが脇へ追いやられるだろう”。

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

レガシーアプリケーションをコンテナ化するDockerの新サービスModernize Traditional Applications

今日（米国時間4/19）オースチンで行われたDockerConカンファレンスでDockerが、Modernize Traditional Applications(MTA) Program（従来型のアプリケーションを現代化する事業）と呼ばれるサービスを発表した。それは、現役の古いアプリケーションをDockerのコンテナに収め、Docker Enterprise Editionの管理下に置き、それらに現代的なインフラストラクチャを使わせるようにするサービスだ。

同社はアプリケーションをそのように移行させる能力に自信を持っていて、アプリケーションが一定の基準を満たしていれば良い結果を‘保証する’とまで言っている。

Dockerがこのツールを作っていた最近の半年間で気づいたのは、顧客たちがコンテナ化をやりたくてうずうずしていることだ。彼らは必ずしも、マイクロサービスに全面的に移行できるほどのスキルや意志は持っていないが、コンテナ化がもたらす数々のメリット…ポータビリティ、効率、セキュリティなど…をいつまでも指をくわえて見ていたくはない。DockerのCOO Scott Johnstonはそう説明する。

“アプリケーションを本格的なマイクロサービスのプロジェクトに移行しなくても、弊社の技術で既存のアプリケーションをコンテナに入れられることに、彼らは喜んでいる”、と彼は語る。

これまでのアプリケーションは、全体が一つの一枚岩のようなものとして配布されていた。しかしコンテナ化のキモであるところのマイクロサービスアーキテクチャでは、アプリケーションを、マイクロサービスと呼ばれる個々の離散的なピース（小片）の集まりへとモジュール化し、それによってデプロイと管理を大幅に容易にする。そんな形の環境では、デベロッパーはプログラミングに集中し、アプリケーションのデプロイをオペレーションのチームが担当できる。これがいわゆる、DevOpsと呼ばれているやり方だ〔※１、※２〕。今日発表された新しいサービスにより顧客は、マイクロサービスへの全面的な移行をしなくても、コンテナのメリットを享受できる。

そのためにDockerのチームは、Avenade, Cisco, Microsoft, HPEなどのパートナーの協力を仰ぎ、彼らのレガシーアプリケーションの一部をコンテナ環境へ移行させた。しかもこれらのベンダが抱える多くの企業顧客は、そうした方が良さそうなアプリケーションをたくさん動かしているから、Dockerの市場開拓という面からも都合がよろしい。

同社は、一定の基準を満たしているレガシーアプリケーションなら、そのコンテナ化の成功を期間限定一定料金で保証できる、と感じた。この一見大胆な約束は、このサービスのベータ期間に得た所見に基づいている。レガシーアプリケーションの中には、簡単にコンテナ化できるものもあれば、あまり良い候補とは言えないものもあった。そしてそのような体験から、保証は可能、と確信した。

“われわれとして言えるのは、エンタープライズのアプリケーションスイートは何千ものアプリケーションで構成されていて、その中には必ず、その基準を満たすものもある、ということだ。確実に、そう言えるね”、とJohnstonは語る。

彼によると、今の企業の中には、IT予算の80%近くをレガシーアプリケーションのサポートに費やしているところもある。Dockerなら、大げさなことをしなくても、それらを現代的なアーキテクチャへ移行して、サポート費用を軽減できる。しかも保証対象のアプリケーションなら、その工程は超簡単だ。

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

WerckerをOracleが買収、コンテナベースのデベロッパープラットホームに既存大手も着目

コードの試験とデプロイを高速化するオランダのスタートアップWerckerが登場したのは、2012年だった。そのころはデベロッパーのアプリケーション構築を助ける類似サービス、CloudBees, CircleCi, それに新人のCloudMunchなどが新しいプラットホーム市場を作りつつあった。同社はシードラウンドのあと昨年は、シリーズAで450万ドルを調達した。

同社は今日（米国時間4/17）、額面非公開でOracleに買収されたが、それは明らかに同社の、コンテナをベースとするクラウドネイティブな開発自動化プラットホームの魅力だ。

Oracleは今、同社のクラウドコンピューティングプラットホームのためのIaaSとPaaSの基盤を築こうとしているから、Werckerはうってつけのパートナーだ。

WerckerのシリーズAはInkef Capitalがリードし、既存の投資家Notion Capitalが参加した。同社のこれまでの調達総額は750万ドルになる。

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

MicrosoftがKubernetesデプロイ技術とツールのベテランDeisを買収、Azureのコンテナプラットホームを強化

Microsoftが今日（米国時間4/10）、Googleが産み育てたコンテナオーケストレーションサービスKubernetesの上でアプリケーションを構築し管理するための、さまざまなツールを作っているDeisを買収したことを発表した。買収の価額は公表されていない。

なおDeisは2015年にEngine Yardに買収されており、したがってMicrosoftは実際には、Engine YardからDeisを買収したのである。

Microsoft Azureのコンテナサービスは、Mesos、Docker Swarmなどさまざまなコンテナオーケストレーションフレームワークをサポートしていたが、Kubernetesが急速にデファクトスタンダードになり、Microsoftも最近はKubernetesへの投資を増やしていた。コンテナがアプリケーションの構築とデプロイの方法を根本的に変えつつある現状では、Microsoftとしてもそのトレンドの最先端に付き添って行かざるをえない。

“最近では、コンテナ化したワークロードをAzure上でデプロイする顧客や、またそのことへの関心が爆発的に増えている。われわれとしても、Azureをコンテナのためのベストの場所にしていきたい”、とMicrosoftのクラウド/エンタープライズ担当SVP Scott Guthrieが今日の発表声明で書いている。“そのための活動の一環として、今回Deisの買収合意を発表できることは、とても喜ばしい。同社は、コンテナ革命の主役的な企業の一つなのだ”。

この買収の目的は明らかに技術の獲得だが、Kubernetesのベテラン技術者という希少財を路上で素手で見つけることはきわめて困難だから、今回MicrosoftはKubernetesに詳しい人材を一挙に大量に取得したことになる。

Deisの中核製品は、Kubernetesのデプロイを管理するための三つのオープンソースツールだ：まず、デベロッパーとオペレーションチームがコンテナ化アプリケーションを容易にデプロイし管理できるためのプラットホームWorkflow、そしてKubernetesのパッケージマネージャーHelm、そしてアプリケーション間通信をサポートするKubernetesネイティブのサービスブローカーStewardだ。そのほかの類似企業と同様に、同社のビジネスモデルも、これらのアプリケーションの有料サポートと教育だ。

Microsoft傘下になってからもチームはこれらのツールの開発とサポートを継続するが、現在のユーザーの中にはMozillaやCloudMine、SocialRadarなどもいる。MicrosoftのGuthrieによると、“Deisのチームは、オープンソース技術の深い経験をもたらし、Microsoftのの顧客の選択肢をさらに充実し、デベロッパーの生産性の向上に寄与していくことだろう”、という。

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

Cloud Native Computing Foundationが抱えるプロジェクトと会員を大幅増、最新コンテナ技術の教育/人材育成にも注力

人気続伸中のコンテナオーケストレーションサービスKubernetesや関連のオープンソースプロジェクトを管理提供するCloud Native Computing Foundation(CNCF)が、例年のデベロッパーカンファレンスを今日（米国時間3/29）から開催し、それを機に、DockerとCreOSのプロジェクト(containerdとrkt)を仲間に加えたことを発表した。

Dockerのcontainerdは同社のコンテナランタイムで、Dockerのコンテナ管理およびオーケストレーションサービスの中核的部分だが、Dockerとしては標準的なコンテナライフサイクル管理の機能を、コンテナの実行を担当するDocker Engineから切り離したかったため、ランタイムを別立てにした。しかし多くの企業ユーザーは、Dockerを使うことを通じて同時にcontainerdも使っている。DockerのPatrick Chanezonは今日からベルリンで始まったカンファレンスのキーノートで、同社がcontainerdをCNCFに寄贈することに決めたのは、その正しい世話役として中立的な機関を探していたからだ、と語った。

一方CoreOSのrkt（‘ロケット’と発音する）は、Linuxのクラスターのための同社のコンテナエンジンだ。containerdと違ってデーモンではなく単一の実行プログラムであり、Kubernetesなど、ほかのコンテナプロジェクトとの統合がねらいだ。CoreOSは最初、rktをDocker Engineの競合製品としてローンチし、同社独自のコンテナ形式を前提していた。でも今では、スタンダードに準拠したコンテナエンジンになっている。

CNCFのディレクターDan Kohnは、こう言う: “Kubernetesなどのコンテナオーケストレーションにとっては、rktのような信頼性の高い、コミュニティベースのコンテナランタイムの方が便利だ。うちのような単一の機関の下にrktのようなコンテナランタイムと、コンテナクラスターの管理システムKubernetesの両方があると、業界に堅実なエンドユーザーソリューションを提供できる。それは巨大な便益だ”。

CNCFの新しい会員も発表された。Linux Foundationが管理しているすべてのプロジェクトと同様に、CNCFの場合も会費が資金源だ。まず、Dellが大型のプラチナ会員になり、年間37万ドルを提供する。そのほか、Cisco, CoreOS, Docker, Google, Huawei, IBM, Intel, Red Hatなどもプラチナ会員だ。SUSEは年会費12万ドルのゴールド会員、HarmonyCloud, QAware, Solinea, TenxCloudはシルバー会員だ（会費は社員数により7000から50000ドル）。

Dell EMCのテクノロジー担当VP Josh Bernsteinが、今日の入会ご挨拶でこう述べた: “今日の環境では、オープンソースがアジリティの鍵だ。環境が、ソフトウェアが求める迅速な変化と進化を支えなければならないからだ。CNCFに参加することにより弊社は、変化の促進にさらに深くコミットでき、エンタープライズITの戦略の核として、ソフトウェアをオープンでアクセス性と利用性の良いものにしていける”。

なお、CNCFは今後、Kubernetes Certified Administrator Exam（Kubernetes認定管理者試験）のカリキュラムを、オープンソースのライセンスで無料提供する。このところオープンソースの世界は、いろんな認定事業がトレンドになっている。OpenStackやCloud Foundryのようなオープンソースプロジェクトも、CNCFと同様の人材枯渇を解消するために、認定事業を検討している(Cloud Foundryの認定事業については別記事あり）。それらは、企業の既存社員の教育〜レベルアップだけが目的ではなく、明確なカリキュラムに基づいた事業により、新しい人材のプールを作ることもねらいだ。

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

CoreOSのKubernetesデプロイサービスTectonicがAzureとOpenStackをサポート

CoreOSはたぶん今でも、Linuxのディストリビューションとしていちばんよく知られていると思うが、でも今やそれは、同社の多様なサービスへの、敷居の低い入り口にすぎない。今同社のビジネスの核になっているのは、KubernetesをベースとするコンテナデプロイサービスTectonicだ。これまでTectonicは、KubernetesをベアメタルとAWSにインストールし管理していたが、今日から（米国時間3/23）は、AzureとOpenStackをサポートする。この二つのプラットホームのサポートは、現在、プレビューである。

具体的には、近くオープンソースのCoreOS Tectonic Installerというものが提供されるので、ユーザーはそれを使ってKubernetesのクラスターをAzureやOpenStackの上にセットアップする。ここにGoogleのCloud Platformが欠けていることが目立つが、それも今後十分な需要があればきっとサポートされるだろう。

以前と同様、Tectonicは10ノードまでのデプロイは無料だ。同社のサービスを利用してどうやってKubernetesのクラスターをセットアップするのか、同社は初心者のための実地演習チュートリアルを数種提供している。

CoreOSのもうひとつのメインサービスQuayは、エンタープライズ向けのコンテナレジストリだが、Kubernetesベースのアプリケーションをサポートするために拡張されたQuayもある。そのレジストリには、複数のコンテナイメージのほかに、アプリケーションの構成ファイルなども収まる。

“新しいレジストリプラグインを使うと、Helmが直接Quayと対話して、アプリケーションの定義を取り出し、それを使って必要なイメージに構成を適用し、アプリケーションを成功裡にデプロイする”、と同社は今日の発表声明で述べている。“これらはすべて、App Registryと呼ばれるコミュニティのAPI仕様で行われるので、Kubernetesのエコシステムはより高度なツールとより信頼性の高いデプロイパイプラインを開発できる”、という。

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

MesosphereのDC/OSにワンクリック統合の対象サービスが増え、とくに機会学習のサポートを充実

Mesosphereが、マイクロサービスとビッグデータアプリケーションをプライベートとパブリックのクラウドで動かすためのプラットホームDC/OSをアップデートした。今回バージョン1.9になったDC/OSは、一見メジャーアップデートではないような番号だが、実は大型リリースだ。

このアップデートによりDC/OSのユーザーは、一度のクリックで100以上のサービスをデプロイできる。このバージョンで新たに加わったサービスは、高速分散ストレージアクセスAlluxio、NoSQLデータベースCouchbase、分散データベースサービスDataStax Enterprise、アナリティクスサービスElastic Search、そしてインメモリデータ構造Redisなどだ。これらの新しい統合はすべて、DC/OSのPartner SDKを使っている。同社によると、そのために、完全なデータサービスインフラストラクチャの構築が比較的容易に（とは言っても単純ではないが）なり、数日で構築できる。

さらにDC/OSにGPUベースのスケジューリングのサポートが加わったので、インフラのGPU部分をプールしておいて機械学習のワークロードに向ける、といったことができる。それはNvidiaとMesosphereが2015年に発表した提携事業の延長だ。

新しいデータコレクションやメトリクスも加わり、複数のコンテナにまたがるデプロイメントをモニタできる。その単純化されたログシステムは、SplunkやDatadogなど、そのほかのモニタリングツールと統合できる。

MesosphereとDockerとKubernetesは、同じ顧客を奪い合っているように見えるかもしれないが、しかしMesosphereは、ビッグデータの世界に自分のニッチを見つけた。今回のアップデートも同社がその強みに乗ったものだが、機械学習のサポートは新しい。企業のデータウェアハウスが、大量のデータを処理する機械学習のブームでまた忙しくなってることも、同社の追い風になっている。

[DC/OS紹介ビデオ]

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

コンテナのデプロイをマルチプラットホーム化するDockerのEnterprise Editionで企業ユーザーのコンテナ導入を単純化

Dockerのコンテナプラットホームのようなシステムを実装しようとすると、そのためのかなり専門的なスキルが必要になる。Dockerは、ユーザーが同社のプロダクトを使おうとするときにぶつかる複雑性を緩和するために今日（米国時間3/2）、Docker Enterprise Editionをリリースした。

このエンタープライズエディションは、DockerがサポートしているLinuxやWindowsのフレーバー（ディストリビューションやバージョン）、およびAWSやMicrosoft Azureのようなクラウドプラットホームのすべてに亙ってシームレスに使用できる、準汎用的なツールのパッケージだ。これらのツールがあれば、コンテナアプリケーションの複数のプラットホーム間の移動が、コードを書き換えることなく可能だ、とDockerは主張している。

本当にそれほど簡単なターンキーシステムのようなものなら、デベロッパーとオペレーションスタッフの双方にとってコンテナのライフサイクル管理がずっと楽になるだろう。DockerはLinuxデベロッパーのためのコンテナプラットホームとして誕生したが、これからは多様なインフラプラットホームと、企業によって異なるやり方をサポートしていくことになる。無料のCommunity Editionは継続するが、それは有料のEnterprise Editionほど多様なプラットホームをサポートしない。

写真提供: Docker

もちろんDockerには、今回のリリースの前にもエンタープライズプロダクトのようなものはあったけれども、それも今度のEnterprise Editionに編入されている、と、Dockerのマーケティング担当SVP David Messinaは語る。前のエンタープライズプロダクトDocker Datacenterは、今ではエンタープライズエディションの中へモジュールとしてバンドルされている。“Docker Datacenterは、これまでの有料サポートつきコンテナエンジンの基盤だった。今パッケージされているのは、前に売っていたものの進化形だが、完全に新しいプロダクトの一部でもある”、とMessinaは説明する。

同社は新パッケージのリリースと並行して、新しいリリースの番号システムとリリースサイクル(release cadence, リリースケイデンス）を発表した。まず番号は、単純な順序数ではなく、1703のようにリリースの年月を表す。今年の6月のリリースは、1706になるだろう。

またリリースサイクルは、ユーザーがジョブのタイプに応じて指定できる。たとえばコードの最新のアップデートをいつも入手したいデベロッパーなら、各月のリリースを選ぶだろう。一方、安定性を重視するオペレーションスタッフなら、四半期リリースのチャネルを契約するかもしれない。なお、四半期リリースは1年契約となる。

Enterprise Editionの課金プランは、ベーシック、スタンダード、アドバンスドの3段階になる。Docker Datacenterはスタンダードに含まれ、アドバンスドではもっと多様なエンタープライズ機能が提供される。

なお、パートナー各社のサードパーティプロダクトを提供するDocker Storeが開店した。Messinaによると、“このストアの最大のメリットは、Dockerの証明つきであること。それにより、パートナーが商業的成功をシェアできるエコシステムになっていくことだ”、という。証明つきとは、Dockerが試用結果に基づいて品質を証明しているから、ユーザーは安心して買える、という意味だ。

エンタープライズエディションとストアの二つが組み合わさると、企業顧客にとって、Dockerのプロダクトやサードパーティ製のアドオンを自社の複雑な環境へ導入することが、よりスムースでシンプルな過程になるだろう。

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

OpenStackの第15リリースOcataはコンテナのサポートをさらに充実、プライベートクラウドの第二の夜明けを目指す

Fibre-optic cables feed into a server inside a comms room at an office in London, U.K., on Friday, Oct. 16, 2015. A group of Russian hackers infiltrated the servers of Dow Jones & Co., owner of the Wall Street Journal and several other news publications, and stole information to trade on before it became public, according to four people familiar with the matter. Photographer: Chris Ratcliffe/Bloomberg via Getty Images

今日（米国時間2/22）OpenStack Foundationが、同プラットホームの最新バージョンをローンチする。企業はOpenStackを使って、AWSのようなクラウドコンピューティングプラットホームを自己のデータセンターでプライベートに運用できる。Ocataと呼ばれる今日の15回目のリリースは、前回のリリースからわずか4か月後と早いが、今後は通常の6か月サイクルに戻る。今回とくに早かったのは、Foundationが近くデベロッパーのためのイベントを開催するからだ。短いサイクルなので新しい機能よりも安定性が重視されているが、しかしそれでも、いくつかの新機能を見ることができる。

今やOpenStackは巨大なプロジェクトで、20近いサブプロジェクトで構成されている。もちろんどれもコンスタントにアップデートされているが、今回の新機能で目立つのは、OpenStackにおけるソフトウェアコンテナのサポートがさらに充実したことだ。OpenStackのCOO Mark Collierによると、コンテナプロジェクトは他のプロジェクトよりも進捗が早い。彼によるとOpenStackとGoogle生まれのコンテナオーケストレーションシステムKubernetesの組み合わせは“クラウドのLAMP”みたいなものであり、Kubernetesの人気が高いのはGoogleや特定一社がそれをコントロールしようとせずに、オープンソースのコミュニティにその成長を委ねたからだ、とCollierは語る。

今回のOctaリリースにおけるコンテナサポートの改良は、OpenStackのコンテナによるデプロイをサポートするプロジェクトKollaにKubernetesをより完璧に統合したことだ。それによってOpenStackのデプロイの管理が容易になるだけでなく、アップグレードもよりシンプルな工程になる。そのほかのアップデートとしては、コンテナのオーケストレーションサービスを支えるOpenStackのメインプロジェクトMagnumがMesosphereをより本格的にサポートするようになったことが挙げられる。またOpenStackのコンテナネットワーキングサービスKuryrが、Docker Swarmをサポートする。

OpenStackは明らかに、コンテナエンジンに関してえこひいきはしていない。わずか1年前ですら、コンテナがOpenStackの死を招くか云々という議論がまだあった。しかしそんな不安はいかにも大げさであり、今やコンテナはこのプロジェクトの中核的部分のひとつだ。

OpenStackの今後に関連してCollierの説では、このところ、企業のプライベートクラウドの見方が変わってきている。OpenStackにかぎらず、最初の世代のプライベートクラウドサービスは、あまり使いやすくはなかった。“今よりもずっと大きなチームを必要としたし、採用もPayPalやWalmartなど超大企業に限られていた。つまりクラウドをプライベートで立ち上げるのは、ふつうの企業には無理だった”。でもCollier説によると、今はプライベートクラウドの第二世代だ。プライベートクラウドを立ち上げるのに、もはや巨大なチームは要らない。それに今では、セットアップを手伝ってくれる企業のしっかりとしたエコシステムがある。

初期には、OpenStackのクラウドをセットアップするために必要なマンパワーの量が大きすぎて、小さなチームでは難しかった。しかしCollierによると、今では費用の面でもプライベートクラウドがAWSなどのパブリッククラウドサービスと十分に競合できる。パブリッククラウドサービスはいろんなオプションなどで費用がかさむことが多いが、OpenStackなどを自前で使えば、持続可能なワークロードを低費用で維持できる。つまり彼の主張では、これからはプライベートクラウドの方がAWSなどを使うより費用効率が良い、というのだ。

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

Dockerはコンテナの機密情報の管理を同社エンタープライズ製品に内蔵化、デベロッパーの仕事を楽に

数年前には、アプリケーションをコンテナで構成しようとすると、仮想マシンの場合と違って、セキュリティ関連のいろんなトレードオフに直面しなければならなかった。コンテナの利用が企業間で予想以上に急速に普及していくに伴い、次第にこの問題を放って置けなくなり、Dockerのようなコンテナ技術を提供する企業は、セキュリティをプライオリティの上の方に置かざるをえなくなった。そしてとくにDockerの場合は、このセキュリティ重視の姿勢を業績にも反映させようとしている。

今日同社は、Docker Datacenterのためのコンテナネイティブな機密管理ソリューション(container-native secrets management solution)を提供する、と発表した。このサービスの下でデベロッパーたちは、APIや暗号の鍵、そしてパスワードなどを安全に作成し、それらを、サードパーティのサービスを使うことなくアプリケーションから利用できるようになる。

Dockerのセキュリティ担当ディレクターNathan McCauleyによると、これらの機密情報の従来的な共有方法は、ホストへ直接コピーするとか、ソースコード中にそのまま置く、というやり方だった。“しかしそんなやり方は、コンテナの場合は破滅的だ。コードはあちこちへ任意に移動していくし、まったく別のインフラストラクチャへ行ってしまうこともある”、とMcCauleyは述べる。そこで現状は、デベロッパー各自がいろんな工夫を凝らしたり、あるいはHashiCorpのVaultに代表されるようなサードパーティのサービスを使っている。

コンテナのオーケストレーションサービスは今やDocker以外にもいろいろあるが、McCauleyによると、それらが独自に貼り付けているようなセキュリティのソリューションも、本質的に不備なものが多い。たとえばKubernetesも、セキュリティを管理するためのツールを内蔵している。

Dockerのソリューションでは、セキュリティをクラスター（Docker用語では“swarm(群れ)”)に比較的容易に付加できる。そうすると機密の共有は同じ証明を共有するTLS接続の上でのみ可能になり、またマネージャーノードに保存される場合も、暗号化されていない状態でディスクに書き込まれることはない。これらの過程のいくつかの実例を、ここで見ることができる。そしてこれらの仕組みの中心的なねらいは、デベロッパーが容易にそれらを…アプリケーションのレベルで…実装できて、アプリケーションを支えているインフラストラクチャとはいっさい無関係であることだ。

Dockerのエンタープライズマーケティング担当VP David Messinaによると、今や同社は、セキュリティをメインのセールスポイントのひとつと考えている。彼の主張では、これからの企業があえてDockerを選ぶメインの理由が、他社製品に比べてセキュリティが優れているから、になるだろう。もちろん、いろんなレガシーのソリューションに比べても、だ。“Dockerはお買い得だよ。うちはこれまでも一貫して、アジリティとポータビリティという二本の柱を重視してきた。顧客企業が他社よりもうちに魅（ひ）かれるのも、そのためだ。そしてこれからは、三本目の柱として、セキュリティが加わるね”。

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

DreamHostの新しい簡易WebサイトビルダーRemixerはOpenStackとKubernetesの上で動くコンテナアプリケーションだ

Webサイト作りとWordPressホスティングの老舗DreamHostが今日、新しい、より簡略なWebサイトビルダーRemixerを立ち上げた。ユーザーは、単純でメンテナンスの楽なWebサイトを、HTMLのコードすら1行も書かずに作れる。この新しいプラットホームは、DreamHostの従来のホスティングプランのどれにも含まれることになる。

こういうGUI方式のWebサイトビルダーを使ったことのある人は、Remixerに親しみをおぼえるだろう。まず、提供されているテーマの中からどれかを選ぶ（現在は13、今後はもっと増える）。画像をアップロードしたり、あるいはInstagramやFacebookなどなどからインポートできる。オーディオやビデオをSoundCloud, YouTube, Vimeoなどからインポートすることもできる。そのほか、類似のサービスと同様に、地図、コメント欄、フォームなどを数クリックで加えられる。こういったいろんな部品は、70種用意されている。

また、60万種類の自由に利用できる画像やグラフィクスを提供しているから、そこから選んでもよい。

DreamHostは長年、ホスティングサービスとして知られているが、近年ではOpenStackのエコシステムにおける重要なプレーヤーだ。OpenStackは、大企業や通信企業、ホスティング企業などがAWSのようなクラウドコンピューティングサービスを自前で（自分とこのデータセンターで）運用できる、オープンソースのプロジェクトだ。実はRemixerは、OpenStack + コンテナ管理サービスKubernetesの上で動いている。つまりこのアプリケーション、というかサービスは、マイクロサービスの集合としてKubernetesが管理するクラスターの上で動いている。そしてそれらがさらに、OpenStackが動かすDreamComputeクラウドプラットホームの上で動くのだ。

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

Cloud Native Computing Foundationが5つ目のホストプロジェクトとしてLinkerdを加える

よく知られているコンテナ管理システムKubernetesをはじめ、各種のオープンソースのコンテナオーケストレーションサービスを提供しているCloud Native Computing Foundation(CNCF)が、その5つめのサービスとしてLinkerdを加えたことを発表した（“リンカーディー”と発音する）。BuoyantでインキュベートされたLinkerdは、Kubernetes, Prometheus, OpenTracing, FluentdなどそのほかのCNCFのプロジェクトと肩を並べて、ユーザーのクラウドおよびコンテナ管理をサポートすることになる。

CNCFのミッションは、“現代的な分散システム環境向けに最適化され、何万もの自己治癒型マルチテナントノードへスケールできるような、新しいコンピューティングパラダイムの作成と採用促進を図る”、とされている。

そのような全体像の中でLinkerdの役割は、上記のような、現代的で、もっぱらコンテナ中心型のアプリケーションに、いわゆる“サービスメッシュ”を提供することだ。Linkerdはスタンドアロンのプロキシで、その中心的な機能は、さまざまなサービスの相互コミュニケーションを支えることだ。サービスメッシュとは、何か。

“つまり、サービスAがサービスBに直接話しかけるのではなく、サービスAはLinkerdのインスタンスを介してBに話しかける。ただしそのときでも、正常な状態なら、AはLinkerdが介在したことを知る必要がない”、とBuoyantのCEOで協同ファウンダーのWilliam Morganは語る。彼は前にTwitterにいたとき、この種の問題を体験したことがある。“そして実際には、何十、何百、何千ものLinkerdインスタンスをデプロイすることになり、それらが堅牢で順応性に富むコミュニケーションの‘メッシュ’を形成する”。誰もがすでによく知っている一種のプロキシのように（たとえばWebトラフィックを扱うNginx）、Linkerdはアプリケーションの内部的トラフィックのために、それらと同様の機能を提供するのだ。

Morganによると、現代のアプリケーションは、Webサーバー -> アプリケーション -> データベースといった少数のサービスを単純に呼び出すのではなく、おそらく10以上ものマイクロサービスを呼び出すから、そういうコミュニケーションがなお一層、重要な課題になる。“私たちの基本的な信念として、現代のアプリケーションのアーキテクチャでは、丈夫なアプリケーションの要求がイコール、丈夫なサービスコミュニケーションの要求だ、と言っても過言ではない”、とMorganは述べる。複数のマイクロサービスで成り立つアプリケーションは、サービス間のコミュニケーションが命（いのち）、というわけだ。

Linkerdは言語を特定しないメッセージングレイヤを形成するだけでなく、ロードバランシングやエラー/レイテンシ対応など、マイクロサービス群で成り立つアプリケーションの健康な応答性を維持するための、そのほかのサービスも提供する。

Buoyantはこれまで、350万ドルを調達している。中でもLinkerdは同社の旗艦的オープンソースツールだが、でもいちばん注力しているのは、企業のクラウドネイティブアプリケーション（最初からクラウド育ちのアプリケーション）の、インサイトとコントロールを提供するHeliumだ。

では、その同社がなぜ、LinkerdをCNCFに献呈したのか？　Morganによるとそれは、Linkerdをもっとも有効に活用できる企業は、すでに“クラウドネイティブな環境”をITのメインにしている企業だからだ。

“また、私たちにとって本当に重要なのは、

a) 具体的な価値を提供し、コミュニティが元気で、スタンドアロンのプロダクトとして通用する（==単独で機能が完備している）オープンソースのプロジェクトがあること、と、

b) ビジネスとして利益を上げ、優秀な人材を吸引でき、ほかの企業のために重要なインフラストラクチャの問題を解決できること、

このa)とb)のバランスの取れたスタートアップであることだ。CNCFはこのような二重性に対してきわめてオープンであり、またわれわれと同様に、その両方ができる、両方を上手にできる、と信じているからだ”、とMorganは付言した。

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

Amazon AWSのEC2 Container ServiceにWindows Containersのサポートが加わる

Microsoftは3か月前のWindows Server 2016の立ち上げのときに、Windowsのサーバー上でDockerエンジンを使ってコンテナを動かすことを可能にした。これによりデベロッパーは、Windowsの実行コードをコンテナに収めてWindowsのサーバー上で動かすことができる。もちろんWindowsの実行コードをLinux上で動かすことはできないが、使用するDockerエンジンやそのコマンド体系はデベロッパーにとってすでにおなじみのものだ。そして今日（米国時間12/20）AWSは、同社のEC2 Container Service(ECS)がWindows Containerをベータでサポートする、と発表した。

Amazonはそのために、ECSのコンテナエージェントのWindowsバージョンを独自に開発した。しかも、Amazonとしては異例にも、エージェントのコードはApache 2.0のライセンスによりGitHub上で提供される。

MicrosoftとDockerの密接な協働により、DockerエンジンがWindows上で動くようになった（Windows 10のAnniversary Update以降を含む）。Windows Server 2016上ではDocker Engineの商用サポートも提供され、今後はエンタープライズ向けのサポートも提供される。ただしWindowsのコンテナは、Dockerの管理ツールに触れることなく、PowerShellからでも管理できる。

なお、一般的にコンテナは軽量のリソースと見なされるが、Windows ServerのDockerイメージはかなり大きくなりがちだ（Amazonによると9.66 GB）。ECS上でWindows Containersを使い始めるためにも、Linuxのコンテナと違って、かなりややこしい部分がある。

古いアプリケーションをクラウドへ移す、という最近のエンタープライズの動向に伴い、Windows上のコンテナはそれらをレガシーのハードウェアからAWSやGoogle Cloud Platform、それにMicrosoft自身のAzureプラットホームなどへ移行させるための、容易な方法と見なされるようになった（AzureはWindows Containersをかなり前からサポートしている）。Amazonは今回Windows Containersを新たにサポートすることにより、この市場のちょっとした分け前をいただきたいのだ。

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

CoreOSのコンテナ管理サービスTectonicがバージョンアップ、Kubernetesとコンテナの自動アップデートが容易に

CoreOSが今日（米国時間12/12）、Kubernetesを使用する同社のコンテナ管理サービスTectonicをアップデートし、Kubernetesとそれが管理するコンテナの両方を容易に自動アップデートできるようにした。

これまでは、Kubernetesのクラスタをダウンタイムなしでつねに最新状態に維持することは、意外に困難だった。CoreOSが“自動運転インフラストラクチャ(self-driving infrastructure)”と呼ぶ今回の新たなサービスでは、ユーザーの指定により、アプリケーションをダウンさせずに、Tectonicにこれらのアップデートを管理させられるようになった。CoreOSのオペレーティングシステム本体にはかねてから同様の機能があり、今回は同じ機能をTectonicとその上で動くアプリケーションに持ち込んだ形だ。最近のユーザーの使用状況にちなんで同社は、CoreOSをContainer Linuxとも呼んでいる。

アップデートの発表声明は、こう言っている: “企業は、オープンソースコミュニティの活発なイノベーションのペースに遅れずに追随し、自分たちのソフトウェアがつねに最新の機能と高度なセキュリティを提供していくことを、必要としている。自動運転インフラストラクチャは、前進アップデートと、ときには後退アップデートを、ボタンひとつでできることにより、これらの問題を解決している”。

今回のアップデートと並行して同社は、ノード数が10未満のユーザーはTectonicの使用を無料にする、と発表した。それ以上は、ノード数に応じての課金になる。これにより、これまでよりも多くのデベロッパーがこのサービスを試用できるようになり、その後彼らの企業に本格的に導入することを、同社は期待している。

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