GoogleのContainer Engineがセキュリティ重視でアップデート、サービスメッシュへの拡張性も

Google Container Engineの最新のアップデートが今日(米国時間7/12)発表された。それはKubernetesを使用するコンテナアプリケーションをGoogleのクラウド上で運用するサービスだ。Google Container EngineをGoogleは、GCEとは呼ばずにKubernetesのKを取ってGKEと呼んでいるが、今回のアップデートも前と同様、Kubernetesプロジェクトからの最新アップデートが中心となる。

今やバージョン1.7となるKubernetesプロジェクトは、プライベートとパブリック両クラウドでコンテナ化ソフトウェアをオーケストレーションするためのデファクトスタンダードになりつつある。ここで一応Microsoftの顔も立てておくべきなら、同社の(顧客の)ワークロードをプライベートクラウドやハイブリッドクラウドで動かすならAzure Stack、そしてGoogleのやり方でハイブリッドクラウドをデプロイするならGoogle生まれのKubernetes、という棲み分けになるだろう。

今回のアップデートは、セキュリティを強調している。GKEを採用する企業が増えるにつれて、彼らのニーズも当然変わってきた。とりわけエンタープライズ(≒大企業)は、セキュリティ要件が厳しい。GKEのチームは、そのサービスが市場でもっとも安全なKubernetes実装だ、と主張するが、その理由として挙げるのは、コンテナのデプロイを構成するさまざまなノードの上で動くオペレーティングシステムをコントロールできるからだ。それはChromium OS(Chrome OSのベース)をベースとするオペレーティングシステムであり、しかもクラウドで動くバージョンは非常にミニマルな(==最小構成の)システムであり、攻撃の取っ掛かりとなる対外インタフェイスがほとんどない。しかもパッチ等はつねに、Google自身が先取り的に講じている。

今回のアップデートでは、Kubernetes自身の新しいセキュリティ機能(ポッド間の通信を制約できる新しいAPIなど)と、Googleのデータセンターの新しい機能の両方が、セキュリティに貢献する。たとえばデータがGoogle CloudのLoad Balancingサービスを通るとき再暗号化することによって、外の旅路だけでなくGoogleのネットワークに入ってからも暗号化状態を維持する。

またGoogleのチームによれば、エンタープライズはセキュリティと並んで拡張性も求めている。とくに、Kubernetesの能力をサードパーティのアプリケーション、たとえばIstioのようなサービスメッシュにも延伸できることだ。Kubernetes 1.7にはAPI集積機能があるから、ユーザーにそんな機能を提供することも可能だ。

もうひとつ光を浴びるべき新機能は、GPUベースのマシンのサポートだ。今はNvidiaのK80 GPUだが、今後はもっと強力なマシンもサポートされる。そのGPUマシンは現状でまだアルファだが、とくに機械学習のワークロードを動かしたいユーザーを顧客としてねらっている。

例によってアップデートはもっともっとたくさんあるが、その完全なリストはGoogleのブログ記事を見ていただきたい。とにかく今日のお話の最大の要点は、KubernetesのコミュニティとGoogleの両方がセキュリティを非常に重視していることだ。GKEをエンタープライズ向けに今以上に普及させたいなら、この姿勢を続けざるをえない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

サービスメッシュ型コンピューティングの普及に賭ける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))

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))

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と呼ばれているやり方だ〔※1※2〕。今日発表された新しいサービスにより顧客は、マイクロサービスへの全面的な移行をしなくても、コンテナのメリットを享受できる。

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

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

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

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

[原文へ]
(翻訳: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))

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

docker_whale_dockerconeu

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

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

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

screenshot-2017-03-02-08-54-22

写真提供: 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の死を招くか云々という議論がまだあった。しかしそんな不安はいかにも大げさであり、今やコンテナはこのプロジェクトの中核的部分のひとつだ。

2017-02-21_1746

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

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

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

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

docker_whale_dockerconeu

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

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

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

937d1e2d-bf31-4875-a19c-3604d104dd89

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

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

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

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

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

shutterstock_145340113

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

diagram-individual-instance

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のサポートが加わる

Container

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とコンテナの自動アップデートが容易に

Aerial view of container terminal

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

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

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

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

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSがローンチするBloxはEC2 Container Serviceのためのオープンソースツールのコレクション

img_20161201_102504

AmazonのクラウドコンピューティングプラットホームAWSはかなり前から、EC2 Container Service(ECS)でもってソフトウェアコンテナのサポートを提供してきた。今日の同社のデベロッパーカンファレンスre:Inventで同社は、コンテナのサポートの仕方に関するいくつかのアップデートを発表した。コンテナは今や、分散アプリケーションを運用する方法の定番とも言える地位に、急速に上(のぼ)りつめている。

まず、EC2のこのコンテナサービスは、カスタマイズの幅が広がる。とくに、Task Placement Engineと呼ばれるツールにより、デベロッパーはコンテナを特定の可利用域に配置できるようになる。

“コンテナの管理と実行は、弊社の少なからぬ顧客にとって、とりわけ一部のオープンソースソフトウェアを使った場合、苦労が多すぎた”、とAmazonのCTO Werner Vogelsが今日のキーノートで述べた。ECSの今回のアップデートは、その苦労の一部を軽減することが目的で、AWS上でコンテナを使うユーザーに、より多くの柔軟性を与える。

また今日Amazonが発表したBloxは、ECS用のコンテナ管理ツールを作るためのオープンソースプロジェクトのコレクションだ。たとえばコンテナのスケジューラーを作りたければ、MesosのようなサードパーティのスケジューラーをECSに統合できる。

Bloxが最初に提供する二つのプロジェクトは、どちらもGitHub上にある。それらは、クラスターのステートをチェックするサービスと、デーモンのスケジューラーだ。これまでオープンソースのコミュニティとは比較的‘浅い仲’だったAWSにしては、興味深い動きだ。しかしコンテナのエコシステムはその大半がオープンソースのプロジェクトに支えられているから、Amazonとしてもそろそろ積極的に関わった方が得策かもしれない。BloxプロジェクトはApache 2.0のライセンスで公開される。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

モニタリングサービスの老舗大手New Relicがコンテナ/マイクロサービスをモニタするDigital Intelligence Platformを立ち上げ

screenshot-2016-11-07-11-26-17

モニタリングはこれまで、比較的単純なタスクだった。モニタするアプリケーションの数はいつも一定、という企業が多い。しかも最近はWeb上で動かすアプリケーションが多く、一定数のサーバーの上で何年間も動き続ける。

しかし今日の環境は、もっと多様化し複雑だ。そこでNew Relicは今日(米国時間11/7)行った一連の発表で、アプリケーションをデリバリする新しい方法に顧客が対応できるよう、助けていきたい、と述べている。

今の企業は、モバイルアプリとWebアプリケーションの両方を提供していることもある。それらの一部は、オンプレミスでもクラウドでも、コンテナに収められたマイクロサービスの集まりだ。だからNew Relicのようなアプリケーションのパフォーマンスをモニタするサービスも、これまでとは違う対応を求められる。

このような、モニタする対象の変化に対応して同社は今日、Digital Intelligence Platformというものを発表した。それは、より広範なモニタリングを可能とするダッシュボードサービスで、顧客がどこにいようと、またデリバリの方法が何であっても、アプリケーションの状態報告を提供する。また顧客企業のニーズに応じて、ジョブ別に細かく分割したモニタリングも提供できる。

New Relicのマーケティング担当Barath Gowdaはこう説明する: “オペレーション(ops)とデベロッパー(dev)の両方がアプリケーション全体を理解できるための、単一のデスティネーションを作った。今アプリケーションの管理はどうなっているのか、コンテナの動作具合はどうか、構成に問題はないか、等々を両者が一望できる”。

コンテナの普及によって、モニタリングはそのぶん難しくなった。コンテナによって、アプリケーションを独立したマイクロサービスの集合としてデリバリできる。仕事を数マイクロ秒で終えるコンテナもあれば、数分あるいはそれ以上動き続けるのもある。そんな多様性と、つかの間的性質により、モニタリングも一筋縄では行かない。ずーっとスタティックにいてくれないものを、どうやってモニタリングするのだ?

この多様性に対応するためにNew Relicは、コンテナの(マイクロサービスの)変数をタグ付けする(variable tagging)、というまったく新しいやり方を考案した。モニタリングのインフラストラクチャは、それらのタグを見て、そのコンテナに今問題があるかどうか、ほかのアプリケーションデリバリシステムとの関係は正常順調か、などをチェックする。これによりユーザー企業は、パフォーマンスの問題とその原因がマイクロサービスにある場合を、検出できる。そのマイクロサービスが、自分のタスクを終えたあとでも。

それがどれだけうまくいくのか、その結論はまだ出ないが、理論的にはアプリケーションとインフラストラクチャに対してより幅広く制御が可能になるだろう。そのデリバリ方法が何であっても。

この、コンテナごと、マイクロサービスごとのモニタリング機能は11月16日から一般供用される。その日はNew Relicの顧客向けカンファレンスFutureStackの初日だ。

New Relicは2014年12月に上場したが、その直前には2億500万ドルあまりという巨額を調達している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Kubernetesによるコンテナ管理をステートフルなアプリケーションにまで広げるCoreOSのOperatorデザインパターン…最初の2つの実装をオープンソース化

Old Cord Switchboard Operator

CoreOSが今日(米国時間11/3)、コンテナ管理の新しいコンセプトOperatorsを発表した。同社によるとそれは、コンテナの管理をより一層自動化することによって、Kubernetesを使用するプロジェクトの進捗を早める。しかも同社は、この技術をオープンソースにする。

CoreOSのCTO Brandon Philipsはこう説明する: “Operators(オペレーター)はその名のとおり、システムのオペレーション(運用)の部分を担当し、自動化する。具体的にはそれは、エンジニアやデベロッパーがスクリプトやランブック(run book, 操作指示書)の中に書く大量の知識、とくにドメイン固有の知識を、自動化するソフトウェアだ”。

Googleのオープンソースのコンテナ管理プロジェクトKubernetesは、広く使われている。小さなマイクロサービスをコンテナに収めることによって、デベロッパーは複雑なアプリケーションを独立した部品に分割し、これまでのプログラミングデリバリ技術に比べてはるかに効率的に動かすことができる。

CoreOSがOperatorsでやろうとしているのは、生半可なことではない。従来の作業では、一連の複雑なタスクを取り上げて、それらをユーザーのプロジェクトのホワイトボードビュー(構造図・流れ図)にまとめる。そのプロジェクトが、3つのサーバーから成るクラスターを必要とするとしよう。すると各サーバーのIPアドレスを知り、構成ファイルを作り、それを3つのマシンにコピーする。以上は多くのデベロッパーがかなりの時間を投ずる作業であり、プランが変わったときには手作業で調整しなければならない。Operatorsを使うと、デベロッパーはこれらの手作業のすべてを、一つの宣言文: “Launch three clusters”(3つのクラスターをローンチせよ)に要約できる。あとはいっさい、 Operatorがやってくれる。

データベースやモニタリングツールなどの複雑なアプリケーションでは,このことがとくに重要だ。Philipsの説明によると、Kubernetesは、単純でステートレスなアプリケーションのスケーリングは得意だが、もっと複雑なステートフルなアプリケーションでは、大量のスクリプトを人間が書かなければならない。Operatorsは、そのたいへんな作業をなくすことが目的だ。

たしかに、昨年本誌TechCrunchのCrunchNetworkでゲスト記事I want to run stateful containers too(ステートフルなコンテナも動かしたいね)を書いたDean Peterson(abecornの協同ファウンダーでミネソタ州雇用経済開発部のソリューションアーキテクト)も、こんな嘆きを述べている:

今のぼくの考えでは、MongoDBのようなステートフルなアプリケーションも、ステートレスなクライアントやサービスと一緒にコンテナで動くべきだ。そう言うぼくは、馬鹿かもしれないが、でもコンテナの価値はアプリケーション全体を容易にスケールできることにある、と思う。

今日の発表で、Petersonの素朴な夢が実現への一歩を踏み出した。それには、二つのOperatorsのオープンソース化が含まれる。最初のetcd Operatorは、etcdのクラスターを管理し分散化する。etcdはKubernetesのためのキー-ヴァリューストアで、CoreOSが作った。もうひとつのPrometheus Operatorは、オープンソースのモニタリングツールPrometheusで使って、Kubernetesのリソースをモニタする。

Philipsによると、この二つのローンチがきっかけとなって、コミュニティによるそのほかのOperatorsの開発が盛んになることを期待したい。この二つを実際に使ってみたら、誰もがその気になるだろう、と彼は言う。

“Operatorの基礎部分の多くは、Kubernetesのコミュニティが作った。彼らとうちとの、初めての協働で、ドメイン固有の知識をKubernetesの上で管理するやり方が、だんだん分かってきたんだ。これをいわばパターン(‘デザインパターン’)として、この便利な仕組みをもっと広げてほしい”、と彼は語る。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

CoreOSがRedspreadをチームに加えてTectonicによるコンテナ管理を一層容易に

shutterstock_145340113

CoreOSが今日(米国時間10/17)、Redspreadのファウンダー(複数)を雇用したことを発表したY Combinatorで育ったRedspreadは、Kubernetesのコンテナクラスタによるソフトウェアのデプロイを手伝う、サービスやツールを提供している。今回のトップ引き抜きにより、RedspreadのオープンソースツールもCoreOSの傘下になる。

今日の発表では、RedspreadがCoreOSに“参加する(joining)”となっていて、CoreOSのスポークスパーソンは“参加する”の意味をはっきり言わない。はっきりしているのは、Redspreadの協同ファウンダーでCEOのMackenzie Burnettと、CTOのDan GillespieがCoreOSのチームに加わり、同社のオープンソース製品をCoreOSが管理する、ということだけだ。

hero-screenshot

Crunchbaseによると、Redspreadはこれまで24万ドルの資金を調達しており、また今回の“参加”に際して、ある程度のお金が動いたものと思われる。

Redspreadの主力製品であるSpreadは、Kubernetesによるクラスタを容易にデプロイし、Dockerコンテナ群を実稼働状態(プロダクション状態)までもっていく、コマンドラインツールだ。Spreadはユーザーのインフラストラクチャのバージョン管理を行い、必要なら旧バージョンへのロールバックもやってくれるが、そのために内部でgitを使用している。

CoreOSにはKubernetesによるコンテナのデプロイと管理を助けるツールTectonicがすでにあるが、Redspreadのコラボレーション的デプロイツールは、Tectonicに統合される予定だ。

CoreOSのCEO Alex Polviは、発表声明でこう述べている: “RedspreadがCoreOSに参加してくれたことに、ワクワクしている。その優れたチームが来てくれたことによって、ユーザー企業のためのKubernetes開発で弊社は、ますます優位に立てる。またKubernetesの利用は、Tectonicの利用によっても、なお一層容易になる。”

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

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自身の調査でも、今や多くの企業がコンテナを評価中だ。ここ数か月の動向を見ると、実装数はまだそれほど多くはないけれども。

unnamed

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))