タグ: コンテナ

複数クラウドにまたがるアプリケーションの管理をコンテナとKubernetesで自動化するOverclock Labs

Overclock Labsは、アプリケーションの複数のクラウドにまたがるデプロイと管理を自動化により容易にするためのサービスを提供している。そのために同社が作った、分散クラウドインフラストラクチャを自動化するツールは、今どき当然ながらコンテナを使用する。そしてそれらのツールの主役は、コンテナオーケストレーションツールKubernetesだ。

今日（米国時間11/21）、2年前に創業されたOverclock Labsはステルス状態を脱し、130万ドルの資金調達を発表した。投資家はシリコンバレーの複数のエンジェルとCrunchFund、こちらは本誌TechCrunchと名前や経歴を多少共有しているが、本誌と特別の関係はない。

同社は、今回初めて一般に公表される資金を使って、DISCOというものを開発していた。DISCOは Decentralized Infrastructure for Serverless Computing Operations（サーバーレスコンピューティングオペレーションのための分散インフラストラクチャ）の頭字語だ。サーバーレスとあるからにはそれは、AWSのLambdaやAzure Functionsのようなイベントドリブンのサービスか？　そう考えたくなるのも無理もないが、しかしOverclock Labsの協同ファウンダーGreg Osuri(CEO)とGreg Gopman(COO)によると、彼らの言う“サーバーレス”とは、完全な自動化のことだ。Lambdaは、イベントドリブンなアプリケーションのためにリアルタイムの自動化をやってくれるが、オープンソースにする予定のDISCOの場合は、もっといろんなアプリケーションのサポートを目指している。なお、同社の三人目の協同ファウンダーは、Adam Bozanichである。

Osuriが説明するその基本的な考え方は、ユーザーがどんなクラウドサービスのプロバイダーでも使えて、それら複数のクラウド間を容易に行き来できるようにすることだ。そのようなデベロッパー体験は、クラウドアプリケーションプラットホームのHerokuにやや似ており、ユーザーインタフェイスはGUIとコマンドラインの両方を提供している。

目下このツールがサポートしているのはAWSとGoogle Cloud Platform、そしてベアメタルのスペシャリストPacketだが、今後徐々にそのほかのクラウドもサポートしていく。DISCOはオープンソースだから、ほかの人たちが自分のものを統合するのも容易だ。

DISCOを使ってアプリケーションをデプロイするやり方は、二（ふた）とおりある。12-factor appのありがたい教えに従ってアプリケーションを作っている場合は、DISCOは単純にソースコードを取り込んでアプリケーションをデプロイする。あるいは独自のコンテナでアプリケーションを作ってる場合は、それらのコンテナをDISCOに渡してデプロイさせる。するとDISCOがコンテナレジストリを扱い、コンテナをデベロッパーに代わって管理する。

DISCOの約束は、アプリケーションのデプロイをHerokuを使う場合のように容易にすること、ただしその1/3のコストで。前にAngelHackを一緒に作ったOsuriとGopmanには、オープンソースのツールを作った経験が豊富にあり、今でもオープンソースのエコシステムの一員だ。だからDISCOをオープンソースにするのも自然な流れで、その上に有料サービスを乗っけていく気だ。

その有料サービスは現段階ではまだ具体化していないが、とにかく同社が真っ先にやることは数か月後にDISCOをリリースし、そのまわりにエコシステムを築いていくことだ。

今では高度なオープンソースのプロジェクトが毎日のようにローンチしているから、DISCOのエコシステムづくりも容易ではないだろう。でも同社のファウンダーたちは、その過程について現実的な見方をしている。それに、コンテナとKubernetesによるアプリケーションのマルチクラウドデプロイと管理の自動化は、誰にでもできることだから、そのうち競合他社があふれてくるだろう。近くAWSのre:Inventカンファレンスがあるから、そのへんの情況を確認してみたい。でもOverclock Labsの連中は、早くスタートした者にはそれなりの優位性があり、ビッグプレイヤーになれる、と信じている。

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

Cloud Native Computing Foundationに署名方式の強力なセキュリティプロジェクトNotaryとTUFが加わる

Cloud Native Computing Foundation(CNCF)は、コンテナオーケストレーションツールKubernetesのホームとして知られているが、そのほかにもさまざまなオープンソースプロジェクトが身を寄せている。どれも、現代的なクラウドネイティブ関連のツールで、GoogleやMicrosoft、Facebookなどをはじめ、各社において、今ではそれらの利用が日常化している。

今日（米国時間10/23）はCNCFの厩（うまや）に、Docker生まれの2頭、NotaryとThe Update Framework(TUF)が入った。その最初の開発者はニューヨーク州立大学のJustin Cappos教授と、そのTandonエンジニアリングスクールのチームだ。二つは互いに関連していて、どんなコンテンツにも保護と安心の層を加えるNotaryは、TUFの実装なのだ。

これらの背後にある基本的な考え方は、単純にTLSプロトコルを使ってWebサーバーとクライアント間のコミュニケーションを保護するのでは不十分、サーバー自身がハックされることもある、という認識だ。たとえば、Dockerのコンテナを配布して、それらが安全であると保証したいなら、Notary/TUFのクライアント/サーバアプリケーションがメタデータの署名を扱うことによって、さらなる安心の層を加えるのだ。

“デベロッパーのワークフローの中で、セキュリティは後知恵になりがちだ。しかしそれでも、
デプロイされるコードはOSからアプリケーションに至るまですべての部分が署名されていなければならない。Notaryは強力な安心保証を確立して、ワークフローの過程中に悪質なコンテンツが注入されることを防ぐ”、とDockerのシニアソフトウェアエンジニアDavid Lawrenceは語る。“Notaryはコンテナの分野で広く使われている実装だ。それがCNCFに加わることによって、さらに広く採用され、さまざまな新しいユースケースが登場してきてほしい”。

たとえばDockerはこれを使って、そのDocker Content Trustシステムを実装しているし、LinuxKitはカーネルとシステムパッケージの配布に利用している。自動車業界も、TUFの別の実装であるUptane使って、車載コードの安全を図っている。

Notary/TUFについて詳しく知りたい方には、Dockerのドキュメンテーションが勉強の入り口として最適だろう。

“NotaryとTUFの仕様は、コンテンツのデリバリに関する、信頼性の高いクロスプラットホームなソリューションを提供することによって、コンテナを利用するエンタープライズの重要な課題に対応している”、とCNCFのCOO Chris Aniszczykが今日の発表声明に書いている。“これらのプロジェクトが一体的なコントリビューションとしてCNCFに加わることは、とても嬉しい。今後、これらを軸としてさまざまなコミュニティが育っていくことを、期待したい”。

Docker Platform（EnterpriseとCommunityの両エディション）や、Moby Project, Huawei, Motorola Solutions, VMWare, LinuxKit, Quay, KubernetesなどはすべてすでにNotary/TUFを統合しているから、CNCFのそのほかのツールとの相性の良いプロジェクトであることも確実だ。

NotaryとTUFが加わったことによって、CNCFを実家とするプロジェクトは計14になる。

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

MicrosoftのAzure Container Serviceの頭字語がACSからAKSに変わった、そのココロは？

コンテナのオーケストレーションに関してはKubernetesが急速にデファクトスタンダードになりつつあり、Docker SwarmやデータセンターOS(DC/OS)を自称するMesos/Mesosphereなどは今や、なんとか自分なりのニッチを見つけようと努力している。そんな中でMicrosoftは長きにわたって、同社のマネージドAzure Container Service(ACS)のアドバンテージのひとつは複数のオーケストレーションツールをサポートすることだ、と主張してきた。しかし今日（米国時間10/24）からは、それがすこし変わるようだ。Azure Container Serviceの頭字語が、なんと、“AKS”になるのだ。

お察しのとおり、この唐突な“K”はKubernetesであり、Microsoftは明らかにそのサービスをこのオーケストレーションツールに向かわせようとしている。サービスの正式名は変わらないのに。

Azureに、マネージドなKubernetesが加わるこのAKSは、目下プレビューだ。

AKSでMicrosoftは、そのフォーカスの中心にKubernetesを置く。Azureのコンテナ対応主席PM Gabe Monroyによると、コンテナサービスは至近の6か月で300%成長し、そしてその顧客は、同社の現在のKubernetesサポートを“とても気に入っている”、という。他の類似サービスと同様にAzureも、Kubernetes環境の管理と運用をできるかぎり容易にしているのだ。

なお、AKSそのものは無料だが、コンテナを動かすためには当然、AzureのVMを有料で使わなければならない。これに対しGoogle Container Engineは、そのサービスの使用時間とクラスター数に応じて課金される。

Microsoftが強調するのは、今でもDocker EnterpriseやMesosphereのDC/OSへの関心が存続していることと、既存のACSデプロイメントエンジンのサポートは今後も続けることだ。Monroyは今日の発表声明でこう述べている: “Azureの顧客でもあるこれらの顧客のニーズに対応するために、DockerとMesosphereのエンタープライズ製品の統合は弊社のAzure Marketplaceにおいて、さらに強化していく。Azure MarketplaceはACSと同様の容易なデプロイメントを提供し、またエンタープライズエディションへの容易なインプレースアップグレード（稼働時アップグレード）を提供していく。それはまた、付加価値としての商用機能と24×7のサポートを提供する”。

この春Microsoftは、KubernetesにフォーカスするコンテナプラットホームDeisを買収した。また同社は最近、オープンソースソフトウェアとしてのKubernetesの‘実家’Cloud Native Computing Foundationに加盟した。Kubernetesの共同制作者の一人Brendan Burnsは、今ではAzureのコンテナ関連サービスのトップだ。こういった最近の動きはすべて、同社がますます強力に、このオープンソースのプロジェクトを支持するようになったことの現れ、と見なさざるをえない。

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

DockerもついにKubernetesをネイティブでサポート、Swarmの併用も可能

コンテナのオーケストレーションといえば、Googleが開発したオープンソースのツールKubernetesが今や事実上のデフォルトスタンダードになってしまったようだ。だから今日Dockerが、コペンハーゲンで行われたDockerCon EuropeでKubernetesのネイティブサポートを発表したことには、誰も驚かないだろう。

同社独自のオーケストレーションツールDocker Swarmを完全に放棄したわけではないが、今回初めてKubernetesのネイティブサポートを提供したということは、今やそのユーザー数がとても多いから、コンテナ企業である以上、サポートせざるをえないのだ。ただしDockerの場合は、ユーザーがランタイムにオーケストレーションエンジンを選択できる。DockerのプロダクトマネージャーBanjot Chananaによると、毎回SwarmかKubernetesかどちらかを選べるが、コードを替える必要はない。

これまでも、DockerでKubernetesを使うことはできたが、それは必ずしも容易ではなかった。今回発表されたKubernetesのサポートにより、Docker Enterprise EditionとDocker Developer Editionのどちらのユーザーにとっても、それがずっと単純になったはずだ。

Chananaによると、Dockerのアーキテクチャのおかげで、KubernetesとDocker Swarmの併用はそれほど難しくなく、違和感もない。Dockerは顧客に、プログラムのコンテナを作るための標準的な方法を提供している。それはDevOpsモデルでは通常、デベロッパーの担当になる。

一方オペレーションの方は、コンテナのライフサイクルの間にそのデプロイとセキュリティと管理を担当し、そのためにコンテナオーケストレーションツールを使用する。最近の2年間でAWS, Oracle, Microsoft, VMwareとPivotalなどのビッグネームがこぞってKubernetesを採用し、彼らはオープンソースのKubernetesプロジェクトの拠点であるCloud Native Computing Foundationにも参加した。それによりデフォルトスタンダードとしてのKubernetesの地位が、いよいよ確定した。

これだけの企業がKubernetesバスに乗り込んでしまったからには、Dockerも顧客の要望に従わざるをえない。Dockerはこれまで、自社のオーケストレーションツールを使いながらKubernetesをサポートすることもできていたが、でも今後は、大多数のコンテナワークロードでKubernetesが選ばれることが、確実になってきた。

なお、今週のThe Informationの記事によると、GoogleはKubernetesを開発していた2014年に、Dockerをコラボレーションに誘（さそ）っている。でも当時DockerはSwarmを選び、そしてGoogleはCloud Native Computing Foundationへと向かった。今日の発表は、まさに円が閉じたようであり、これからはDockerも、（コードはホストしないけれど）Kubernetesをサポートしていくことになる。

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

年商50億ドルに向かって着実に進むRed Hat、豊富なLinux経験が未来への資産

Red HatのCEO Jim Whitehurstにこの前会ったのは2016年の6月だったが、そのときの彼は売上50億ドルを目指すという、かなりの大風呂敷を広げた。当時のそれは、実現不可能な目標と思えた。そのころの同社は、売上が20億ドルを超えた初めてのオープンソース企業にすぎなかった。50億が相当な難関と思われたのは、彼も指摘したように、企業は大きくなればなるほど成長カーブが徐々にゆるやかになるからだ。

でも同社はその後も元気旺盛で、このまま行けば次の二つの四半期内には売上30億ドルを超えそうな勢いだ。Red HatはLinuxのエンタープライズ向けバージョンを提供していることがいちばん有名だが、クラウドやコンテナなどで変化していく世界にも積極的に適応している。そして同社のRHEL(Red Hat Enterprise Linux)の顧客も徐々に変わりつつあるが、変化を支える新しい技術を得るためにもRed Hatを使い続ける。Whitehurstが言うには、しかもそれは決して偶然ではない。

クラウドやコンテナは主にLinux上の産物であり、Red Hatの得意技（わざ）は何かといえば、それはLinuxだ。Whitehurstによると、レガシーのRHELビジネスも依然14%の高率で成長しているが、新顔のクラウドとコンテナの事業はそれを大きく上回る40%の成長を維持している。そしてそれが、売上に強力なインパクトをもたらしている。

先月発表された最新の決算報告では、全体的な売上は四半期ベースで21%増の7億2300万ドル、年商換算では28億ドルになる。投資家たちもそれを好感し、株価は上昇を続けている。2016年の12月に$68.71だった株価は、今日（米国時間2017/10/13）見ると$121とほぼ倍増だ。どこをどう切っても、良好なリターンと言えよう。

Whitehurstによると、同社のさまざまな事業部門が互いにシナジー効果を上げている。同社は、Googleで開発されたオープンソースのコンテナオーケストレーションツールKubernetesに早くから賭けてきたが、それがのちには、Kubernetesを使うコンテナ化アプリケーションのデリバリ、という新しい事業形態に結実して稼いでいる。Red HatはLinuxをエンタープライズのITにおいてもっとも有能であるようにパッケージして提供しているが、それと同じことを、KubernetesとOpenShiftプロダクトとの組み合わせでもやっている。というかWhitehurstが冗談で言うのは、OpenShiftは名前の中にKubernetesがあればもっと認知度が上がっただろう、と。

この分野での成功は、技術の適時適材適所という正攻法だけでなく、Red Hat独自の特性にも負っている。Whitehurstは曰く、“うちには、エンタープライズにとってベストなアーキテクチャを見分けることのできる独自のスキルがある”。しかもそれは初期からコミュニティに還元され寄与貢献しているだけでなく、今や同社は、Kubernetesに対してもGoogleに次ぐ最大のコントリビューターだ。

しかし彼が言うのは、やはりLinuxとの結びつきだ。コンテナがもともとLinux上の技術であることが、Red Hatのコンテナ〜Kubernetesビジネスを強くしている最大の要因であり、Linuxに関する同社の長年の知識と技術の集積を、コンテナにもそのまま応用できることが、大きな強みだ。

Red Hatの収益を支える大企業は、彼らのアプリケーションの全在庫をコンテナ化するほど急いではいない。これらの企業はもっとゆっくり進もうとしており、そこでRed Hatとしては、顧客が今どの段階にいてもしっかりサポートできる体制が必要だ。クラウドで仮想マシンを使うべき段階か、オンプレミスで行くべきか、それともアプリケーションをコンテナ化して動かすべきか、などなど。

Whitehurstは、彼の会社がフリーソフトウェアを売ってることを理解している。だから、売るものはあくまでも、実装を容易にするサービスや、これらのツールを顧客に代わって管理してさし上げるサービスでなければならない。“フリーなソフトウェアを売るときには、IPは無料だから何が価値かを真剣に考えなければならない”、と彼は語る。数字を見るかぎり、顧客は価値を実感しているようだ。50億ドルへの道は、かなり平坦なのではないか。

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

ソフトウェアのサプライチェーンを監視するためのAPI集合GrafeasをGoogleやIBMなど8社が共同開発

コンテナとマイクロサービスによって、ソフトウェアの作り方が急速に変わりつつある。しかし、どんな変化にも問題はつきものだ。コンテナが目の前にあるとき、それを誰が作ったのか、その中で何が動くのかを知りたいだろう。この基本的な問題を解決するために、Google, JFrog, Red Hat, IBM, Black Duck, Twistlock, Aqua Security, そしてCoreOSの計8社が今日（米国時間10/12）、共同のオープンソースプロジェクトGrafeas※を発表した（※: ギリシア語で“scribe, 書記官”の意味）。その目的は、ソフトウェアのサプライチェーンを検査し統轄するための標準的な方法を確立することだ。

併せてGoogleは、もうひとつの新しいプロジェクト、Kritis※を立ち上げた（※: ギリシア語で“judge, 鑑定人”の意味…Kubernetesの成功以来、Googleの新しいオープンソースプロジェクトにはほかの言葉を使えなくなったのだ！）。Kritisは、Kubernetesのクラスターをデプロイするとき、コンテナに一定のプロパティを強制する。

Grafeasは、コードのデプロイとビルドのパイプラインに関するすべてのメタデータを集めるための、APIの集合だ。そしてそのために、コードの原作者や出所、各コード片のデプロイ履歴〜デプロイ時の記録、どのようなセキュリティスキャンをパスしたか、どんなコンポーネントを使っているか（そして各コンポーネントの既知の脆弱性）、QAからの承認の有無、などの記録をキープする。そうすると、新しいコードをデプロイする前にGrafeasのAPIを使ってこれらの情報をすべてチェックでき、それが（得られた情報の範囲内で）脆弱性なしと認定されていたら、プロダクションに放り込める。

一見するとこれは、平凡すぎる感じがしないでもないが、でもこんなプロジェクトのニーズは確かにある。継続的インテグレーションや分散化、マイクロサービス、どんどん増えるツールセット、そして各種バズワードの奔流、といった動向の中でエンタープライズは、自分たちのデータセンターで実際に何が起きているのかを知ることに苦労している。今動かしているソフトウェアの本性を知らずに、セキュリティやガバナンスを云々しても空しい。そしてデベロッパーが使うツールは統一されていないから、そこから得られるデータもまちまちだ。そこでGrafeasは、どんなツールでも一定の標準化された、業界全員が合意しているデータ集合が得られるようにする。

Googleのオープンソースプロジェクトの多くがそうであるように、Grafeasも、この問題のGoogle自身の対処方法を模倣している。規模が大きくて、しかもコンテナやマイクロサービスを早くから採用しているGoogleは、業界全体の問題になる前にこれらの問題を数多く体験している。Googleによる本日の発表によると、Grafeasの基本的な内容は、Google自身がそのビルドシステムのために開発したベストプラクティスを反映している。

そのほかのパートナーたちも全員が、このプロジェクトにいろんなおみやげを持参している。しかしたとえばJFrogは、同社のXray APIにこのシステムを実装するつもりだ。Red Hatは、同社のコンテナプラットホームOpenShiftのセキュリティとオートメーションを強化するためにこれを導入し、CoreOSは同社のKubernetesプラットホームTectonicにこれを統合する。

Grafeasの初期のテスターの中には、Shopifyがいる。同社は現在、一日に約6000のコンテナをビルドし、それらが33万点の画像を同社のメインのコンテナレジストリに保存する。Grafeasがあると、たとえば、今どのコンテナがプロダクションで使われているか、それはいつレジストリからダウンロードされたか、その中ではどのパッケージが動いているのか、そして、コンテナの中のコンポーネントのどれかに既知の脆弱性はないか、などが分かる。

Shopifyは、今日の発表声明の中でこう言っている: “Grafeasによってコンテナの正確なメタデータが得られるので、セキュリティチームがこれらの質問に答えられるようになり、またShopifyでわれわれがユーザーに届けるソフトウェアの検査やライフサイクル管理に、適切な肉付けがなされるようになった〔形式だけではなくなった〕”。

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

サーバーレスで複雑なコンテナアプリケーションを開発デプロイできるPlatform9のFission Workflowsサービス

企業ITのクラウド化をいろんな面からサポートするPlatform9の新製品Fission Workflowsには、あなたのお好きなバズワードがすべて揃っている。Kubernetes、Dockerのコンテナ、そしてサーバーレスコンピューティング。しかもそれは、これらの技術の、必然的な次のステップのようだ。

Platform9のプロダクトとしてのFission自体は、コンテナオーケストレーションサービスKubernetesの上で動くオープンソースのサーバーレスコンピューティングプラットホームだ。サーバーレスアプリケーションは、その初期のころはもっぱら、何かのイベント（“ファイルがアップロードされた”など）にトリガされる小さなファンクションを作ることだった。しかしFission Workflowsの提供意図は、もっと複雑なサーバーレスアプリケーションの開発を支援することだ。

Workflowsは、サーバーレスのファンクション〔複数形〕のオーケストレーションを助ける。サーバーレスアプリケーションが複雑になればなるほど、使用するファンクションも多くなり、それらお互いに依存関係のあるファンクションの管理やアップデートが難しくなる。同時にまた、アプリケーションのモニタリングやトラブルシューティングも難しい。

Platform9のソフトウェアエンジニアでFissionを作ったSoam Vasaniによると、Fissionは、デベロッパーがKubernetesをもっと楽に使えるようにしたい、という願いから生まれた。 “Fissionがないころは、うちの顧客たちはKubernetesを使いこなせるまでに数週間もかかることが多かった”、と彼は語る。しかし今では、彼らは一時間ぐらいで彼らの最初のFissionのファンクションを動かせるようになる。そして、Fission Workflowは次の問題に取り組む: サーバーレスのアプリケーションがシンプルなファンクションから本格的なアプリケーションに成長するとき、何が起きるのか。

Fission WorkflowsはKubernetesの上で動くので、どんなクラウドでも、プライベートなデータセンターでも、あるいはデベロッパーのラップトップ上でローカルにも、動かせる。デベロッパーは自分のアプリケーションをPython, NodeJs, Go, C#, PHPなどで書く。

しかしFission Workflowsには、Microsoft Flowのようなドラッグ＆ドロップのインタフェイスがない。今のところデベロッパーは自分たちのワークフローを手書きしなければならないが、Platform9のCEOで協同ファウンダーのSirish Raghuramによると、そのうちWorkflows用のビジュアルエディターを作るそうだ。ただし、現在すでに、ワークフローを視覚化するツールはある。

Fission本体と同様に、Workflowsも完全なオープンソースにする予定だ。Raghuramによると、同社のビジネスプランは、そのオープンソースのフレームワークを顧客にサービスとして提供するときに課金することだ。今すでにKubernetesとOpenStackに関してはその方式だが、Fissionもいずれそのポートフォリオに加わるだろう。ソフトウェアそのものは今後もずっとオープンソースで、オープンコアやフリーミアムモデルに移行するつもりは、まったくない。

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

Kubernetesがコンテナ時代のソフトウェア産業を全面的に支配、大企業もCloud Native Computing Foundationに参集する

駅を出て徐々にスピードを増す列車のように、Cloud Native Computing Foundationは急速に強くなり、テクノロジー業界の大物たちを吸引してきた。過去1か月半だけでも、AWS, Oracle, Microsoft, VMwareとPivotalなどがこぞって参加した。

これらの企業は必ずしも毎日仲が良いわけではないが、しかしそんな中でKubernetesは業界の必須のツールへと育ち、どの企業もCNCFに参加してそのミッションをサポートすることが必要だ、と考えている。これは部分的には顧客の要望によるものであり、そして残りの部分は、Kubernetesやそのほかのクラウドネイティブ技術に自分も口出しをしたいという欲求の表れだ。

この団体はLinux Foundationの傘下にあり、最初はGoogleが開発したオープンソースのプロジェクトKubernetesもこの親団体の管理下にある。Kubernetesはコンテナ化されたプログラムのオーケストレーション部分を担う。そしてコンテナは、ソフトウェアを、以前のように大きな一枚岩的なプログラムとしてではなく、マイクロサービスと呼ばれる離散的な小片の集まりとして配布するための形式ないし方法である。

過去2年ほどはDockerがコンテナの普及に大きく貢献し、コンテナ化されたプログラムを作るための共通的な方法をデベロッパーに提供してきた。そして今では、企業はこれらのコンテナ化されたアプリケーションを“クラウドネイティブ*に”動かすことを欲している…CNCFの事務局長Dan Kohnはそう語る。〔*: cloud-native, ‘クラウド生まれ’、アプリケーションの作成も実稼働もクラウド上で行われること。〕

彼の説明によると、企業がAWS, Azure, GCPのようなパブリッククラウドへ行くにせよ、あるいはオンプレミスのプライベートクラウドでアプリケーションを動かすにせよ、どちらの場合も同じ技術がベースになる。アプリケーションがどっちにあっても、Kubernetesはそれらを整合性のある形で動かし管理するためのツールを提供する。

コンテナ化されたクラウドネイティブなアプリケーションをローンチする企業にとって、Kubernetesはオーケストレーションとオペレーションのレイヤを提供し、それを軸として驚異的なほど高い生産性が実現する。だから冒頭に挙げた巨大企業ですら、そのことを認識して、今やCNCFというバスに乗り込んでくるのだ。

というわけで、すべての中心にあるものはKubernetesだが、Kohnによるとそれは、見た目ほどシンプルではない。コンテナオーケストレーションツールを採用しCNCFに参加することには、企業目的が伴っている。“全員が輪になって手を握り合い、Kumbayaを歌う、という状況ではない。同じ顧客を奪い合う競合関係もある。しかし彼らは、コンテナオーケストレーションツールをめぐって争っても一文の得にもならないことを、十分に理解している”、とKohnは語る。

Kohnによると、Kubernetesは今やコンテナオーケストレーションのデファクトスタンダードだから、企業はもはやその部分では競合せず、コンテナの管理体験を向上させるそのほかの部分のサービスで優位に立とうとしている。業界の大物たちも、コンテナのオーケストレーションは今や解決済みの問題であり、今さら車輪の再発明に取り組むのは愚かである、という認識を共有している。

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

Kubernetes展開お助けサービスで起業したHeptioが創立1年足らずでシリーズB $25Mを調達

オープンソースのコンテナオーケストレーションツールKubernetesの協同ファウンダーCraig McLuckieとJoe Beda〔共に元Google〕が創業したHeptioが今日（米国時間9/13）、Madrona Venture Partnersが率いるシリーズBのラウンドで、2500万ドルを調達したことを発表した。Lightspeed Venture PartnersとAccel Partnersもこのラウンドに参加したが、同社はシリーズAで850万ドルを調達してからまだ1年経っていない。ただしこのシアトルのスタートアップは、シード資金を獲得していない。なお、Kubernetesのもう一人の協同ファウンダーBrendan Burnsは、今Microsoftにいる…MicrosoftからGoogleに来たBedaとは逆だ。

HeptioのCEO McLuckieは、“短い8か月だったが、すばらしい体験をした”、と語る。“シリーズAのときは、次の資金調達がこれほどすぐだとは、想像もしなかった”。Kubernetesやそのほかのクラウドネイティブ技術のエンタープライズへの導入を支援する彼らのビジネス機会が、これほど急速に大きくなるとは、彼らも予想しなかった。そして今彼が強調するのは、その機会が単にKubernetesの機会ではないことだ。

McLuckieは語る: “Kubernetesは核であり、それを取り巻くようにしてこの会社を作った”。そしてさらにそのまわりには、クラウドネイティブコンピューティングをエンタープライズが容易に採用できるようにするためにやるべき仕事が、山のようにある。また、さらにそれに伴って、デベロッパーの新しいワークフローも生まれる。Kubernetesはコンテナオーケストレーションツールだが、McLuckieによると、ほかに大量の関連ツールも作らなければならない。

“Kubernetesの人気が盛り上がるのを見て、われわれにはこれをビジネス機会として捉える資格がある、と感じた”、そうMcLuckieは述べる。

では、Heptioは実際に何をやっているのか？　企業向けの、Kubernetesお助けサービスがビジネスになる、と確信していたが、最初はプロダクトの具体的なイメージはなかった。でもその後の数か月で、徐々にビジネスモデルがはっきりしてきた。要するにHeptioは、Kubernetesを採用したがっている企業にプロフェッショナルなサービスを提供し、教育訓練やサポートも提供する。McLuckieが強調するのは、それが企業のKubernetes利用を助けるだけでなく、彼らをオープンソースのコミュニティに接近させる意味合いもあること。そのためにチームは、Kubernetesのいくつかの具体的な特性と、それがオーケストレーションするコンテナクラスターを管理するための、独自のオープンソースプロジェクトも作っている。

新たな資金はヨーロッパとアジアへの進出に充てる予定だが、さらにチームを拡大するとともに、新市場開拓に役に立ちそうな買収を検討するかもしれない、という。

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

OracleがCloud Native Computing Foundationにプラチナ会員として参加、Java EEをオープンソースに

Oracleが今日（米国時間9/13）、Cloud Native Computing Foundation(CNCF)にプラチナ会員として加わることを発表した。これによって同社は、Amazon, Cisco, Google, IBM, Intel, Microsoft, RedHatらとともに、このLinux Foundation傘下の団体に参加し、コンテナオーケストレーションプロジェクトKubernetesとその関連ツールを支えていくことになる。

CNCFへの入会はお安くない。プラチナ会員は、年会費が37万ドルだ（Linux Foundationの既存の会員には割引がある）。したがってこの団体に加わることは、その企業がKubernetesのエコシステムを支援していく意思表明になる。

Oracleは単に同団体に参加するだけでなく、Oracle LinuxにKubernetesを加え、Oracle Cloud InfrastructureのためのKubernetesインストーラーTerraformをオープンソースにする。このほかすでにOracleは、Kubernetesに多くのコントリビューションをしており、関連するコンテナツールも提供しているから、今日の正式加入は、エコシステムへのこれまでの投資を、公式化する動きにすぎない。

CNCFのCOO Chris　Aniszczykは、今日の声明文でこう述べている: “Oracleには、世界クラスのエンタープライズのニーズに対応してきた数十年に及ぶ経験がある。そんなOracleをCNCFのプラチナ会員として迎えることは大きな喜びであり、同社はエンタープライズクラウドの未来を定義していくことに重要な役割を果たすと思われる”。

現時点ではKubernetesがコンテナオーケストレーションツールのデフォルトスタンダードであることに、もはや疑いの余地はなく、今やほとんどすべての企業が、お金の面やコードの寄与貢献の面でこのプロジェクトを支えている。

Oracleの加入の発表と並行してCNCFは今日、同団体が資格認定したKubernetesサービスプロバイダーの最初の一群を発表した。この分野の深い知識と同団体の公式の資格をもって企業のコンテナオーケストレーションを助けていくサービスプロバイダーは、Accenture, Booz Allen Hamilton, Canonical, CoreOS, Giant Swarm, そしてSamsung SDSである。

また今日は、二つの新たなプロジェクトが同団体のオープンソースツールの仲間に加わった。それらは、分散トレーシングシステムJaegerと、Lyftの開発チームが提供したエッジとサービスのプロキシEnvoyだ。

Oracleも今日、オープンソースの発表を行った。同社は、これまでクローズドソースだったJava Enterprise Edition(Java EE)をEclipse Foundationへ移し、そのコードをGitHubに置いた。

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

MesosphereがデータセンターオペレーティングシステムDC/OSにKubernetesのサポートを導入

今Kubernetesは確実に、コンテナオーケストレーションサービスのデファクトスタンダードになっている。Mesosphereはわりと初期からコンテナを採用し、企業顧客の、分散システムによるクラウド上のビッグデータ分析を支えているが、今日（米国時間9/6）は、大規模な分散アプリケーションを動かすためのOSのような同社のプラットホームDC/OSがKubernetesをサポートする、と発表した。Mesospereはいわば、Apache Mesosの実装系であるが、MesosとDC/OSのためのコンテナオーケストレーションツールとしては長年、同社独自のMarathonを提供してきただけに、今回の動きは意外である。〔*: DC/OS == Data Center Operating System〕

KubernetesのサポートはDC/OS 1.10のベータから提供され、それは9月11日にローンチされる。

今朝この情報をもたらしたThe Informationの記事は、MesosphereがKubernetesに“屈した”、という見方をしている。同じく今朝、ぼくがMesosphereの協同ファウンダーでCEO Florian LeibertやMesosphereのCMO Peter Guagentiに取材したら、両人は屈服説を断固否定した。両人が強調するのは、大企業が多い同社の顧客に選択肢を提供する、という考え方だ。“うちの顧客は大企業のインフラやオペレーションを担当しているプロであり、一つの組織内で何十万ものデベロッパーに奉仕している”、とGuagentiは語る。“そんな彼らにとっていちばん重要なのは、選択の自由だ”。

Leibertの見解では、Kubernetesをオーケストレーションエンジンの一つとして提供することは、これまで同社が、複数のデータサービスや継続的インテグレーションのプラットホーム、あるいは複数のネットワーキングツールをサポートしてきたことの延長にすぎない。さらにGuagentiが強調して曰く、顧客にとってMesosphereは、コンテナを利用するためのプラットホームではなく、あくまでも、データ集約的なアプリケーションをデプロイし管理していくためのインフラなのである。

Leibertによると、MarathonとKubernetesではユースケースが異なる。Marathonは、コンテナ技術を使っていないレガシーのアプリケーションを動かすためにも使えるが、Kubernetesは当然ながらコンテナのためのツールだ。“だから両方をサポートするのが自然であり当然だ”、と彼は言う。“これらの技術の多くはレヤーケーキにとてもよく似ていて、たとえばKubernetesとMesosはとても相性が良い。コンテナのワークフローをKubernetesが担当するが、Hadoopのようにコンテナを使わないアプリケーションもある”。

Guagentiに言わせると、コンテナの分野でもMesosphereはリーダーだ。ユーザーがプロダクションで動かしているコンテナの数でもたぶんトップだし、コンテナサービス企業の中で売上でもトップだろう、という。売上の金額は、教えてくれなかったけど。

LeibertとGuagentiは、これまでと変わらずMarathonへの投資は続ける、と断言した。

今後ユーザー企業のデベロッパーたちは、Kubernetesを使うコンテナのデプロイを、DC/OSを使ってセットアップおよび管理できるようになる。もちろん同じインフラストラクチャの上でDC/OSはそのほかのコンテナデプロイメントも動かすし、Kubernetesも各デプロイによってバージョンがさまざまに異なったりするだろう。このプロジェクトでMesosphereはGoogleと協働し、Mesosphereがユーザーに、ベンダー固有の変更がなく、互換性の問題も起きない、源流的（最上流的）なバージョンのKubernetesを提供できるようにしている。

GoogleでKubernetesとGoogle Cloud Platformを担当しているプロダクトマネージャーAllan Naimはこう語る: “KubernetesをDC/OSに導入することによってMesosphereは顧客に、データリッチなコンテナ化アプリケーションを、彼らのデータセンターやクラウド上で構築、デプロイ、そしてオペレートできる堅牢なプラットホームを提供することになる。コンテナにはKubernetes、そしてマシンインテリジェンスにはTensorFlowを使うプロジェクトを、MesosphereのDC/OSとGoogle Cloud Platformの両プラットホームで動かせば、企業は強力な、そしてオープンなハイブリッドクラウドプラットホームを確保することになる。その意味でMesosphereとの協働、およびコミュニティの前進に継続的に貢献できることが、これからも楽しみである”。

Mesosphere側の結論としては、単純に顧客の選択肢を増やすことに帰結するが、Kubernetesのエコシステムがまた一勝を挙げたことも確実だ。そのエコシステムは、これまで独自のニッチを築いてきたMesosphereにとっては脅威ではないが、これまでコンテナの普及推進の主役だったDockerにとっては、主役を奪われる危険性があるかもしれない。たしかに今回のMesosphereの動きによって、Dockerの独自性の確立と維持が、やや難しくなったようだ。

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

PivotalとVMwareとGoogleがコンテナでパートナー、すでに提供プロダクトも具体化

PivotalとVMwareとGoogleがチームを作って、コンテナプロジェクトの開発とデプロイと管理を、十分なスケーラビリティを維持しつつ単純化する総合的サービスを提供していくことになった。

三社はオープンソースのプロダクトをベースとする商用サービスにより、このパートナーシップを構成するさまざまなパーティーと共にそのプロダクトを市場化していく。GoogleはそれをGoogle Cloud Platformの一環として売ることになり、PivotalとVMwareでは彼らの標準の営業品目として売り、両社の親会社であるDell-EMCはハードウェアを含めたパッケージとして売っていく。

彼らの役割分担を整理するとこうなる: GoogleはオープンソースのコンテナオーケストレーションツールKubernetesを提供する。PivotalはCloud FoundryによりPaaSの要素を提供、そしてVMwareは全体をまとめる管理層を加える。

プロダクトの名前にはPivotalが使われ、Pivotal Container Serviceとなる。省略形はPCSではなくPKSだが、たぶん彼らは頭字語という言葉の意味をよくわかっていないのだろう。いずれにしても、三社が肩を組んでやることは、VMwareのvSphereとGoogleのCloud Platform(GCP)をベースとする“プロダクションに即対応する(production-readyな)Kubernetes”を提供していくことだ。そしてそれは継続的に、Google Container Engineとの互換性が確約される。後者はご想像どおり、GCEではなくてGKEなのだ。¯_(ツ)_/¯

以上は説明だが、このプロダクトが実際にベースとするものはGoogleとPivotalが作ったコンテナ管理プロダクトKuboだ。そしてPKSは、PivotalのCloud Foundryによる、デベロッパーにとっておなじみのコンテナ開発環境を提供する。デベロッパーはKubernetesの経験者であることが前提だ。

VMwareは縁の下の力持ちのように管理層を提供し、その上でDevOpsのOpsの連中がコンテナをデプロイし、コンテナのライフサイクルの全体を管理する。以上を総合すると、エンタープライズ級のコンテナ開発〜デプロイ〜管理のシステムの、一丁あがり、となる。

Google Cloudのプロダクトマーケティング担当VP Sam Ramjiによると、昨年Googleに来る前、Cloud Foundry Foundationにいたときすでに、コンテナをプロダクションに持ち込むためのいちばん容易な方法がCloud Foundryだ、と直観していた。そして当時の彼らは、Kubernetesを統合するやり方を研究していた。

一方、PivotalのJames Watersはこれまで、PivotalのツールとともにGoogle Cloudのツールを使っている大企業顧客が多いことに気づいていて、そのツールキットに、人気急上昇中のKubernetesを含める必要性を痛感していた。

VMwareはどうか、というと、Sanjay PoonenらVMwareの連中はこれまで、コンテナの開発環境としてCloud Foundryを使う大企業顧客が多いことと、Kubernetesがコンテナオーケストレーションエンジンとしての勢いを増していること、この二つの支配的な状況を日々、目にしていた。

そして今回、そのような三者が交わったところに出現したコンテナ統合環境（開発/デプロイ/管理サービス）が、今回の三社パートナーシップの成果だ。その供用開始は、今年の第四四半期を予定している。

〔関連記事:
●三社パートナーシップに導いた7つの動向（未訳）
●VMware CloudがAWSからも提供（未訳）
〕

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

CoreOSのTectonicコンテナプラットフォームがMicrosoft Azureをフルサポート

本日（米国時間8月17日）CoreOSは、KubernetesベースのTectonicコンテナ管理プラットフォームの、Microsoft Azure対応を発表した 。これまでは、ベアメタルサーバとAWS上へのコンテナデプロイメントだけが完全にサポートされていた。3月に登場したAzureへのベータサポートに続く今回の新規リリースで、Tectonicはサポート対象の3つのプラットフォームにまたがるマルチクラウドデプロイメントへの統合サポートを提供することになった。

「Microsoft Azureに向けてのTectonicsの安定版メジャーリリースは、マルチクラウドに対応し、インフラと運用をより効率的かつスケラーブルなものにするというお約束に向けた、非常に重要なステップです」と語るのはCoreOSのTectonicプロダクトマネージャーRob Szumskiだ。「Azure向けTectonicは、Kubernetesインフラストラクチャを初めから正しく構築し、展開サイクルをスピードアップすることで、時間とコストを節約します。ハイブリッドクラウドのデプロイメントが可能なことで、インフラストラクチャ責任者たちは、ユーザーをクラウドコンピューティングやクラウドサービスにロックインしないプラットフォームの自由度と柔軟性を手に入れることができます」。

Tectonicのその他のアップデートとしては、Google謹製コンテナオーケストレーションサービスの最新リリースであるKubernetes 1.7への完全サポートも含まれる。最新リリースへのアップグレードはワンクリックで完了し、アップデート中にダウンタイムが発生しないことが約束されている。これはKubernetesの初期版と比べると大きな利点だ。当時はどのようなプラットフォームを選んでもアップグレードは一苦労だった。

また新機能としてインバウンドトラフィックをより詳細に制御できるようにするネットワークポリシーのサポート（アルファ版）が入り、コンテナの展開中に問題が発生した場合のアラートを、あらかじめ設定しておくこともできるようになった。

[ 原文へ ]
（翻訳：Sako）

Red HatのコンテナプラットホームOpenShiftのアップデートに外部サービスへの接続インタフェイスを導入

Red Hatが今日（米国時間8/9）、OpenShiftプラットホームの今四半期のアップデートをリリースし、社内や社外のさまざまなサービスへの接続を作る機能、Service Catalogを新たに加えた。

OpenShiftは、KubernetesとDockerをベースとするPaaSで、コンテナのスタンダードとしてOpen Container Initiativeを採用している。KubernetesはGoogleで開発されたコンテナ管理プラットホーム、Dockeは広く使われているコンテナ作成プラットホームだ。

企業が仮想マシンからコンテナへ移行していくに伴い、OpenShiftのようなコンテナデプロイプラットホームのニーズがますます高まっている。そして今やRed Hatの顧客の中には、Deutsche Bank, Volvo, United Healthのような有名大企業もいる。

Red HatでOpenShiftを担当するプロダクトマネージャーJoe Fernandesによると、コンテナへ移行しようとする企業は最近ますます多くなり、すべての企業が何らかの形でコンテナの採用を目指していると言っても過言ではない。今では“いちいち表に書ききれないほど多い”、と彼は言う。

同社の、コンテナを利用する顧客ベースの増大とともに、大企業のIT部門の現実的なニーズを満たす、コンテナ化アプリケーションの展開プラットホームが重要になっている。とくに最近よく聞くニーズは、コンテナ化したアプリケーションが社内や外部のサービスに容易に接続できるようにしてほしい、という要望だ。

Service Catalogは、アプリケーションストアみたいな機能で、デベロッパーがそこへ行って構成済みのコネクターを見つけ、それらをサービスへのインタフェイスとして利用する。それは会社のOracleデータベースへのコネクターのこともあれば、AWSやAzureのようなパブリッククラウド、すなわち社外的サービスへのコネクターのこともある。Fernandesによると、アプリケーションストアの比喩は適切だが、今のところ正規の調達の手順は組み込まれていない。それが今後の課題だ、という。

これまでも、顧客がサービスへの接続を自作できたが、それには大量の作業を要した。ユーザーの面倒な作業を要しない、パッケージ化されたやり方でないと、時間と労力を取られすぎる。

そのために登場したService Catalogは、今回のリリースではテクニカルプレビューだ。次のリリースは、今年の終わりになる。

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

コンテナ化という大きな趨勢にとってはスタンダードがきわめて重要、AWSは自らその意思を示す

AWSが今日（米国時間8/9）、コンテナの標準化団体Cloud Native Computing Foundation(CNCF)の正会員になったとき、同社の重要なマイルストーンが刻まれた。GoogleやIBM, Microsoft, Red Hatなど、この分野の有力企業の仲間入りをすることによって、コンテナの管理に関してはスタンダードを無視できないことを、認めたのだ。

なにしろ、これまでもっぱら我が道を行くだったAWSである。しかもAWSは今や、その強力な巨体で広大なマーケットシェアを支配しているから、さまざまな面で自分流を貫いても平気だ。しかし、コンテナは違った。今コンテナを支配しているのは、かつてGoogleで生まれたオープンソースのコンテナ管理ツールKubernetesだ。

聡明なAWSは、Kubernetesが業界標準になりつつあることと、作るか買うかオープンソースで行くかの三択に関しては、戦いがすでに終わっていること、とっくに結論が出ていることを悟った。

コンテナ管理におけるGoogleの優勢を認めたからには、次の論理的ステップはCNCFに加わり、業界全体が使っている同じコンテナの規格に従うことだ。人生には戦うよりも自分を変えた方が得策なこともあり、これがまさに、その典型的な例だ。

そしてAWSがCNCFに加わったことによって、業界全体としてのコンテナ化に向かう路程が明確になった。今それは、とくに大企業において大きなブームになっている技術だが、それには十分な理由がある。アプリケーションをいくつもの離散的な塊に分割して構築していくので、メンテナンスとアップデートがきわめて容易である。そしてDevOpsのモデルにおいて、デベロッパーのタスクとオペレーションのタスクを明確に分離できる。

いくつかのスタンダードが、コンテナを開発し管理するための共通基盤を提供している。その上で各人が、独自のツールを作ることもできる。GoogleのKubernetesも、最初はそのひとつだったし、Red HatのOpenShiftやMicrosoftのAzure Container Serviceなども、そんな独自ツールの例だ。

しかしスタンダードがあると、誰が何を作っても、その構造や動作の共通性をあてにできるし、したがってその利用も楽だ。どのベンダーもサービスのベースはほぼ同じであり、違いは上位的な機能や構造にのみ現れる。

業界の大半がスタンダードに合意すると、その技術は離陸していく。World Wide Webは、その偉大なる例だ。それは、Webサイトを作るスタンダードな方法だから、完全な共通技術へと離陸できた。ビルディングブロックに関して多くの企業が合意したら、そのあとはすべてがうまく行く。

スタンダードの欠如が、技術の足を引っ張った例も少なくない。全員が共通のビルディングブロック（構築部材）を持つことは、きわめて有意義なのだ。しかしときには、だんとつのマーケットリーダーが合意に参加しないこともある。今日のAWSは、そんなリーダーにとってもスタンダードが重要であるという認識を、示したのだ。

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

AWSがKubernetesのホームCloud Native Computing Foundationに参加

噂では、AmazonのクラウドコンピューティングプラットホームAWSが近く、Kubernetesベースの独自のコンテナ管理サービスをローンチする、とされていた。その噂は、今日（米国時間8/9）AWSが、KubernetesプロジェクトのオープンソースのホームであるCloud Native Computing Foundation(CNCF)に、最上位メンバーのプラチナ会員として参加したことにより、かなり具体性を帯びてきた。AWSの参加によって、MicrosoftやGoogle、IBMなどを含むメジャーなパブリッククラウドプロバイダーの全員が、この、Linux Foundationを上位団体とする現代的なクラウド管理技術の推進団体に加わったことになる。

最近の調査によると、Amazon(==AWS)はすでに、Kubernetesを用いたデプロイの大半をホストしているので、Amazonが、ある意味ではKubernetesプロジェクトの本拠地であるCNCFに加わっても、それほど意外ではない。しかも重要なのは、AWSはほかにも大量のオープンソースプロジェクトを利用しているし、また自分のプロジェクトをGitHubで頻繁に公開していることだ。また同社は2013年以来、Linux Foundationのメンバーであり、そこのCore Infrastructure Initiativeの創設メンバーだ。同社が主なコンペティターたちと違うのは、Cloud Foundry Foundationに参加していないことだ〔関連記事〕。

CNCFに関しては、Amazonは同グループのコンテナランタイムcontainerdを提供している。CNCFは今日の声明で、こう言っている: “AWSはクラウドネイティブのコミュニティで積極的な役割を果たし、containerdなどでKubernetesなどのクラウドネイティブ技術に寄与貢献している”。AWSのクラウドアーキテクチャ戦略担当VP Adrian Cockcroftが、CNCFの理事会に加わる。

Cockcroftの発表声明は、Kubernetes関連のAmazonの短期的プランを述べていないが、すでに同プラットホームへの広範な支援を提供し、この急速に拡大している分野において、競合するGoogleやMicrosoftの利益にもなっているわけだから、今後はAWS上でKubernetesをよりダイレクトにサポートしていくことは、ほぼ確実だろう。これまでAWS上でKubernetesを使うためには、サードパーティ製のツールを使う必要があった。

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

Kubernetesによるコンテナクラスターのプロダクションレベルのデプロイを「安全化」するHeptioのオープンソースプロジェクト

シアトルのHeptioは、Kubernetesの協同ファウンダーCraig McLuckieとJoe Bedaが最近立ち上げた会社で、企業におけるKubernetesの本格的な利用（プロダクションレベルでの利用）を、より容易にすることをねらっている。2016年に創業したこの資金豊富な会社はこれまで、鳴り物入りの新製品発表などはまったくなかったが、でも今日（米国時間8/3）同社は、二つのオープンソースプロジェクトArkとSonobuoyをリリースした。

Kubernetesの人気は急成長し、それは今やもっとも人気のあるコンテナオーケストレーションシステムだと思うが、でもその周りにできるエコシステムは、誰もが認めるように、今でも未発達だ。Kubernetesをサポートするサービスやオープンソースのプロジェクトは山ほどあるが、現状はまだまだ、成熟期というより成長期だ。Heptioがその二つのプロジェクトで解決しようとする問題は、Kubernetesのクラスターのステートをバックアップすること（Ark）と、これらのクラスターのテストと診断（エラー検出）だ。

Arkのようなツールの標準的なユースケースといえば、インフラストラクチャやデータが落ちたときの災害復旧だ。同社の今日の発表では、こう言われている: “われわれの顧客がKubernetesのプロダクションユースに向かうに伴い、彼らの多くが、クラスターのバックアップとリストアの管理、という難題に直面する。そんなときデベロッパーは、（etcdで）クラスターのステートの直接的なレプリカからクラスターをリカバリしようとするが、うまく行かないこともある”。そこでArkはすべてのクラスターオブジェクトのバックアップを作り、ボリュームのスナップショットを作らせ、クラスター全体を前のステートへリストアする能力を与える。

一方Sonobuoyは、災害の防止だ。それはデベロッパーとオペレーションのチームが彼らのKubernetesのデプロイをテストし、それらが想定通り動いていることと、正しく構成されていることを確認する作業を支援する。

二つのプロジェクトはどちらもGitHubから入手でき、オープンソースなので多方面からのフィードバックやコードの寄与貢献を歓迎している。

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

Microsoftの新しいAzure Container Instancesは、コンテナの利用を素早く簡単に行えるようにする

コンテナについてのニュースが流れない日はほとんどない。このことは、このテクノロジーがいかに素早く開発者たちの間に普及し、かつそれらをサポートするプラットフォームやスタートアップが増えているのかを物語っている。そして今度はMicrosoftの番だ。Azureクラウドコンピューティングプラットフォーム用の新しいコンテナサービス、Azure Container Instances（ACI）を開始する。

本日（米国時間7月26日）同社はまた、”Cloud Native Computing Foundation”（クラウドネイティブコンピューティング財団）にプラチナ会員として参加することも発表した（年会費は37万ドルだ）。

これまで私たちは、主要なクラウドベンダーによるコンテナ中心のサービスについて見てきたが、ACIは既存のサービスであるAzureのContainer Service 、AWSのEC2 Container Service、そしてGoogle Container Engineなどとは一線を画するものだ。

現在プレビュー版が公開されているACIは、単純さを売り物にしている。利用者が指定したメモリとCPUコアを用いて数秒のうちにシングルコンテナが起動し、課金は秒単位で行われる。Microsoftが強調するように、これらのコンテナはAzure上のファーストクラスオブジェクトであり、同プラットフォーム上で期待されるものと同じレベルの、ロールベースのアクセスコントロール、課金タグ、その他の機能がすべて備えられている。Microsoftによれば、これらのコンテナは「実証済みの仮想化テクノロジー」を利用して他の顧客から隔離されている。

一方、ユーザーにとっては、VM管理の苦労はなくなり、コンテナのオーケストレーション（協調動作）に関する学習は不要になる。とはいえ、もしオーケストレーションを行いたい場合は、Microsoftの新しいオープンソースプロダクトのKubernetesコネクタの助けを借りて、行うことが可能だ。これにより、Kubernetesクラスタが、コンテナをACIに直接展開できるようになり、開発者は必要に応じてVMとACIを混在させることができるようになる。

現在、ACIはLinuxコンテナだけをサポートしているが、程なくWindowsコンテナも同様にサポートする。コンテナをデプロイするには、いくつかの基本パラメータと共にコマンドを1つだけ使用する、そしてDocker Hubのようなパブリックコンテナや、Azureのプライベートリポジトリなどからコンテナを取得することができる。

そのスピードを考えると、ACIの主なユースケースはは、おそらくバースト的な作業負荷とスケーリングに対応するためのものとなるだろう。コンテナの主な利点の1つは、それらをサービス間で簡単に移動できることだ。よって、ACIから従来のVMベースのコンテナインフラストラクチャに移行することも問題なく行える。

「このことは、Kubernetesのデプロイに俊敏性を提供し、他の他のクラウドプロバイダーとは異なり基盤となるVMなしで数秒のうちにサービスを開始することが可能になり、秒単位で課金とスケールが行われるようになります」と、MicrosoftのAzure Compute製品の責任者であるCorey Sandersが、本日の声明の中で述べている。

Sandersがまた本日発表した通り、Microsoftは”Cloud Native Computing Foundation” (CNCF)にプラチナメンバーとして参加することを決めた。この財団では、Kubernetesプロジェクトだけでなく、コンテナベースのアプリケーションを構築、監視、管理するのに役立つ、増え続けるオープンソースのツールが管理されている。その他のCNCFプラチナメンバーには、Cisco、CoreOS、Dell Technologies、Docker、Google、Huawei、IBM、Intel、Joyent、RedHatなどが名前を連ねている。CNCFは、Linux Foundation（Linux財団）の共同プロジェクトである。Microsoftは昨年Linux Foundationに参加している。

「Kubernetesのようなクラウドネイティブテクノロジーは、開発者の生産性を向上させ、より高頻度のデプロイと、コンピューティングリソースのより効率的な活用を可能にします」と、CNCFのエグゼクティブディレクターであるDan Kohnは私に語った。「Microsoftのような企業による積極的な取り組みが意味するのは、クラウドネイティブなやり方が、新しく未開拓のアプリケーションをデプロイするための手段として、そして既存のモノリシックなアプリケーションをクラウドネイティブな未来へと移行する際の標準なプラットフォームとして、一般的になりつつあるということです」。

[ 原文へ ]
（翻訳：Sako）

FEATURED IMAGE: SHUTTERJACK/GETTY IMAGES

Open Container Initiativeがコンテナの仕様の標準規格v.1.0をリリース

ついにやっと今日（米国時間7/19）、Open Container Initiative(OCI)が、そのコンテナランタイムとソフトウェアコンテナのイメージの仕様の標準規格、バージョン1.0のローンチにこぎつけた。この、今年で2歳になるオープンソースのファウンデーションは、Dockerをはじめコンテナエコシステムのリーダーたちが、まさにこれらの共通仕様を確立し維持管理するために作った組織だ。すなわちそれらは今後、コンテナのフォーマットとランタイムの業界標準になる。

Dockerは、これらの仕様の基盤となるものの多くをOCIに提供した。たとえば同社は、同社のコンテナランタイムのコードベースをOCIに寄贈した。さらにその後、同社の技術コミュニティがコンテナのイメージのフォーマットをOCIのプロジェクトに加えた。OCIの現メンバーは40社あまり、クラウドでプレイする大手テク企業のほとんどが参加している（AWS, Cisco, Facebook, Google, Huawei, IBM, Intel, Microsoft, Oracle, Red Hat, VMwareなどなど)。またRancherやWerckerのような、コンテナ技術を専業とする企業も、少なからず加盟している。

OCIの事務局長を務めるChris Aniszczykによると、たしかに、この組織における仕事の進め方やリリースの形式が決まるまで、かなりの時間がかかった。“同じコラボレーションでも、オープンソースのプロジェクトと違ってスタンダードの作成には困難な側面がある。オープンソースのプロジェクトでも、多くの企業がさまざまなやり方ですでに業務に使用しているものは、意見の違いが大きくなりがちだが、共通スタンダードについても同じことが言える”、と彼は語る。しかし、Linux Foundationの傘下となった今では、ガバナンスの構造も適正かつ安定してきた、と彼は感じている。この取材の席にいたDockerのStephen Walliは、こんだけたくさんのメンバーがいること自体、組織とプロジェクトの成功を物語っている、と付言した。

Aniszczykによると、仕様の策定作業でとくに大きく貢献したのがRedHat, Docker, CoreOS, そしてHuaweiだった。またFujitsu, Microsoft, Google, Oracle, Cisco, Tencentなども積極的に動いてくれた。

バージョンが0.xでなく1.0でリリースされたことは、そのスペックは一般的な採用が可能で、今後、採用者がコードを大きく書き換えなければならないような変更はない、ということを意味している。

今後の計画としてAniszczykは、次に取り組みたいのは検定（仕様への合致の証明）だが、そのほかに、すでに温めている企画として、現状のLinuxだけでなくそのほかのプラットホームのサポートと、レジストリのアクセスやコンテナの配布のためのAPIの標準化作業がある、と語った。

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

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