Coreos | SEO-LPO.net

RedHatのCoreOSがKubernetesアプリケーションを管理するツールキットを発表

Red Hatが今年初めに2億5000万ドルで買収したLinuxディストリビューションとコンテナ管理のスタートアップCoreOSが今日（米国時間4/30）、Kubernetesのクラスターを管理するオープンソースのツールキットOperator Frameworkを発表した。

CoreOSがソフトウェア概念としてのOperatorについて最初に言及したのは、2016年だった。その考え方は、コンテナベースのアプリケーションをデプロイし管理するためのベストプラクティスをコードとして実装することだった。“まあOperatorとは、最良のオペレーター社員を絵に描いたようなものだ”、とRedHatのOpenShiftのプロダクトマネージャーRob Szumskiは語る。理想としては、Operator Frameworkはオペレーションのチームをあらゆる雑用や単純労働から解放して、高いレベルのタスクに集中させる。そして同時に、Operatorがつねに会社のルールブックに従うことによって、その過程からエラーしがちな人間を取り除く。

CoreOSのCTO Brandon Philipsは、今日の発表声明でこう説明している: “Kubernetesを最大限に有効利用するためには、Kubernetesの上で動くアプリケーションをサービスし管理するための一連の統一的なAPIを広げる必要がある。われわれはOperatorを、Kubernetes上のそういうアプリケーションを管理するランタイムだ、と見なしている”。

Szumskiによれば、CoreOSのチームは、同社独自のTechtonicコンテナプラットホームを作って管理するときに（そのユーザーコミュニティからのものも含めて）、これらのベストプラクティスを開発した。それらがコードとしてのOperatorとして動くようになると、Kubernetesのクラスターを監視し、アップデートを処理し、たとえば何かがおかしくなったら、数ミリ秒以内にその不具合に反応する。

全体としてのOperator Frameworkは、三つの部分から成る。1)実際のOperatorを作ってテストしてパッケージするためのSDK、2)OperatorをKubernetesのクラスターにデプロイしてそれらを管理するためのOperator Lifecycle Manager、そして、3)チャージバックや顧客への課金を必要とする企業のためにKubernetesのユーザーを（リソース使用量などを）計量することだ。

軽量ツールは全体の絵の中ではつけたり的だが、Szumskiによると多くの企業がそれを求めるのであり、CoreOSもKubernetesでそれをやるのはうちが初めて、と主張している。

今日のCoreOS/Red Hatによる発表は、今後各方面から、さまざまなKubernetes関連の発表が行われそうな週の、始まりにすぎない。数日後にはCloud Native Computing FoundationのデベロッパーカンファレンスKubeConが始まるし、そこではコンテナのエコシステムに帰属する企業のほとんどが、何かを発表すると思われるからだ。

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

Red HatがCoreOSを$250Mで買収してKubernetes路線を強化

エンタープライズLinuxの代表的企業であるRed Hatは近年、同社のOpenShiftプロダクトで、Kubernetesを軸とするコンテナ技術に積極的に注力してきた。そして今日（米国時間1/30）同社は、その路線のさらなる拡張のために、コンテナ管理のスタートアップ*CoreOSを2億5000万ドルで買収すると決定した。〔*: 元々はCoreOSはDockerコンテナの使用を前提とするエンタープライズLinuxディストリビューションである。〕

CoreOSのメインのプロダクトは、LinuxディストリビューションCoreOSと、Googleが開発したオープンソースのコンテナオーケストレーションプラットホームKubernetesをベースとするコンテナ管理ソリューションTectonicだ。本誌TechCrunchのコンテナ入門記事が、ここにある。

CoreOsとRed Hatは、Google, FathomDB, ZTE Corporation, Huawei, IBM, Microsoft, Fujitsu, Mirantisなどと並んでKubernetesの最大のコントリビューターの一員だ。

おそらくKubernetesをめぐる密接な協働関係が契機となって、CoreOSとRed Hatの仲が深まり、この際一つになった方が顧客の共有や人材の有効活用の点で有利、という結論に達したのだろう。両者はコンテナを前提とするLinuxディストリビューションでも、CoreOS vs. Red Hat Atomicで競合してきたが、これについてもやはり、デベロッパー環境を統一すべき、という結論になったのだろう。

次世代の中心的なソフトウェア環境が、自社データセンター上のオンプレミスとパブリッククラウドを併用するハイブリッドクラウドになるのなら、クラウドネイティブな枠組みにより、統一的な方法でアプリケーションをデリバリしていくことがとても重要になる。Red Hatでプロダクトとテクノロジーを担当するPaul Cormierによると、両社の合体はそのようなハイブリッド環境や複数のクラウド環境を統一的に扱える力を与える。

Cormierは声明文の中でこう述べている: “次世代のテクノロジーは、複数の、そしてハイブリッドなクラウド環境にまたがるコンテナベースのアプリケーションが駆動する。それらは、物理環境、仮想環境、プライベートクラウド、パブリッククラウドなど多様な要素から成る環境だ。KubernetesとコンテナとLinuxが、この変化の核であり、Red Hat同様CoreOSも、これらのイノベーションを推進する上流のオープンソースコミュニティと、エンタープライズ級のKubernetesを顧客に提供していく能力の両方において、リーダー的存在だった”。

昨年CoreOSのCEO Alex Polviもインタビューでこう語った:“うちはGoogleやDocker、Red Hatなどと共に、コンテナという新しい技術カテゴリーを作ってきた、という自負を持っている。うちはこれまで、まったく新しいカテゴリーのインフラストラクチャを作ってきた”。

彼の企業は、エンタープライスKubernetesプロダクトを作って早くからゲームに参戦し、そのことを有利に生かしてきた。“Kubernetesについては、その初期から、すごい大物になる、と感じていた。そして当時からすでに、TicketmasterやStarbucksなどのシステムにKubernetesを導入してきた”、と彼は語る。

彼によると、同社のコンテナ管理システムTectonicには4つのメイン成分がある: ガバナンス、モニタリング・ツール、課金、そしてワンクリック・アップグレードだ。

Red HatのCEO Jim Whitehurstも昨年のインタビューで、うちもコンテナとKubernetesに関しては早かった、と述べた。彼によると、同社はオペレーティングシステムのカーネル（すなわちLinux）もコンテナに入れられることを理解していた。同社は本来Linux企業なのでKubernetesと（Linux上の技術である）コンテナ化技術に早期から専念して、OpenShiftを作った。

CoreOSは2013年の創業以来5000万ドルを調達している。主な投資家であるGV（元Google Ventures）とKleiner Perkinsは、おいしいリターンを得たようだ。いちばん最近のラウンドは、GVがリードするシリーズBの2800万ドルだった。Kubernetesの作者で最大のコントリビューターでもあり、CoreOSの主要投資家であるGVを同系とするGoogleが、Red HatというトンビにCoreOSという油揚げをさらわれた形になったのはおもしろい。

買収は今月中に完了するものと思われる。ただし1月はあと1日だけなので、すでに完了しているのかもしれない。

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

CoreOSの商用化KubernetesツールTectonicがv.1.8にアップデート、外部サービスの利用が容易に

CoreOSが、ポピュラーなコンテナオーケストレーションツールKubernetesを企業向けに使いやすく商用化して提供するTectonicのマイナーアップデート、v.1.8をリリースする。その新しい機能Open Cloud Services Catalogにより、ユーザー企業のDevOpsは、外部サービスを容易にKuberneesにプラグインできる。

CoreOSでTectonicのプロダクトマネージャーをやっているRob Szumskiが、ニューバージョンを発表する同社のブログ記事で言ってるように、パブリッククラウドは使いやすくて便利ではあるけれども、そこにロックインされてしまって、プロプライエタリなツールしか使えないこともある。

CoreOSのOpen Cloud Services Catalogは、その問題を解決する。‘カタログ’の名のとおりここには、特定のプロプライエタリなツールに代わる多様な選択肢があり、クラウドやハイブリッド環境など、複数の実行環境間の移動や行き来が容易にできる。

“Tectonic 1.8では、CoreOSのOpen Cloud Servicesで、マネージドクラウド（管理サービスを伴うクラウド）が提供すると期待されている苦労のないオペレーションに、さらに一味加えたものを体験できる。通常のプロプライエタリなクラウドサービスと違ってOpen Cloud Servicesは、CoreOSのTectonicプラットホームの上で走る第一級の、完全に自動化された、Kubernetesリソースの集合だ”、とSzumskiはそのブログ記事で述べている。

CoreOSは、提供物のすべてをできるかぎりオープンでポータブルにして、顧客のあらゆる特殊条件や要求にも柔軟に対応したい、と考えている。それだけでなく今度のOpen Cloud Services CatalogはTectonicsのコンソール本体上にあるので、外部サービスの導入も、またその無効化も、きわめて簡単容易である。

Open Cloud Servicesの初期のリソースとしては、etcd, Prometheus, Vaultなどが挙げられる。

Open Cloud Service CatalogはあくまでもTectonic 1.8のリリースの一部であり、基本的には9月の終わりにリリースしたオープンソースバージョンの路線は維持されている。とくにCoreOSが強調するのは、それがあくまでもKubernetesのオリジナルバージョンであり、フォークではないことだ。Kubernetesの管理団体であるCloud Native Computing Foundationも、それがピュアなオープンソースバージョンとして維持されることを期待し奨励している。

なお、このバージョンにより、コンテナエンジンDockerも自動的にアップデートされる。デベロッパー(Dev)は、このエンジンを使って、コンテナに収めたアプリケーションを作る。そしてオペレーション(Ops)はKubernetesを使ってコンテナの管理とデプロイを行う。というわけでこのツールは、コンテナのDevOpsの両サイドの面倒を見てくれる。

この最新バージョンは年内にダウンロード可能になるが、既存のTectonic 1.7からのアップデートは自動的に行われる。

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

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

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

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

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

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のOpenStackクラウドを15分でデプロイできるツールStackanetes（OpenStack+コンテナ+Kubernetes）がテクニカルプレビューに達す

6か月前に、小型のLinuxディストリビューションとコンテナ管理サービスを提供するCoreOSは、その複雑さで敬遠されがちなOpenStackによるプライベートクラウドを、コンテナと、Googleのコンテナ管理ツールKubernetesを利用して容易にデプロイできるやり方をデモした。そして今日（米国時間10/26）同社は、そのツールのテクニカルプレビューのローンチにまでこぎつけ、誰もがたった一つのコマンドで、Kubernetes上のOpenStackをわずか15分でデプロイできるようになった、と発表した。

この、OpenStackとKubernetesをセットにしたプロダクトは“Stackanetes”と呼ばれ、CoreOSのチームは残念ながらこの奇妙な名前を気に入っているのだが、OpenStackの最新リリースであるNewtonを使用し、そのプラットホームのすべてのインフラストラクチャサービスを揃えた完全な高可用性OpenStackデプロイメントをセットアップする。

しかしOpenStackのクラウドをセットアップしている企業の多くは、Mirantis, Canonical, HPEなどのサードパーティベンダを利用してミッションクリティカルなワークロードをセットアップしている場合がほとんどだから、15分自力セットアップを訴求するCoreOSの今回のプロダクトは、一種のスタントでもある。しかしこれにより、OpenStack/コンテナ/Kubernetesという組み合わせが、少なくともOpenStackのベーシックなデプロイを、これまでになく、大幅に簡易化することを、多くの人びとに見せつけることはできる。これまで、OpenStackを使うことなど考えたこともなかった企業すら、前向きの関心を示すかもしれない。

StackanetesはコンテナエンジンとしてDocke Engineではなく、それと競合するCoreOSのrktを使用し、クラスタオーケストレーションツールとしてKubernetesを用いる。またCoreOSのチームによれば、Kubernetes自身もそのキー-ヴァリューストアとしてCoreOSで育ったetcdを使用している。

CoreOSのこのプロダクトでは、OpenStackのクラウドをセットアップするために必要なKubernetesの全オブジェクトが、約300行のYAMLのマークアップで定義されている。

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

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

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

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

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

OpenStackがもうすぐKubernetesを利用してコンテナ内で動くようになる…Google, Intelなど主要プレーヤーが尽力

企業等がAWS的なクラウドコンピューティングサービスを自分のデータセンターで動かせるためのオープンソースのプロジェクトOpenStackが、最近の数回のアップデートを経てコンテナのサポートを加えてきた。しかし、OpenStackそのものをコンテナで動かす、となると、別の話だ。CoreOSはStackanetesという奇妙な名前のプロジェクトで、OpenStackをコンテナに入れて動かすための環境を作ったが、それはOpenStackのコミュニティやOpenStackの中核的なデプロイおよび管理のためのツールの、外部で起きたことだ。

しかしもうすぐ、Mirantis, GoogleおよびIntelなどの尽力で、デプロイメントツールOpenStack Fuelが、CoreOSの〜〜netesの場合と同じく、KubernetesをOpenStackのオーケストレーションエンジンとして使えるようになる。理想としては、これにより、OpenStackの大規模なデプロイメントの管理が容易になるだろう。

MirantisのCMO Boris Renskiはこう語る: “コンテナのイメージフォーマットとしてはDockerが、そしてコンテナのオーケストレーションではKubernetesが今やスタンダードだから、分散アプリケーションのオペレーションにやっと継続性が見えてきた。KubernetesとFuelの組み合わせでOpenStackの新しいデリバリモデルが開かれ、それによりアップデートをより迅速にこなして、顧客に結果を早く届けられる”。

これは、もうすぐOpenStackをGoogleのクラウド上のコンテナで動かせるようになる、という意味でもある。というか、Kubernetesをサポートしているクラウドサービスならどこでも…。

Googleの上級プロダクトマネージャーでKubernetesプロジェクトのファウンダーの一人でもあったCraig McLuckieは今日の発表声明で、こう述べる: “FuelでKubernetesを利用すればOpenStackが本格的なマイクロサービスアプリケーションになり、レガシーのインフラストラクチャソフトウェアと次世代のアプリケーション開発とのあいだのギャップを橋渡しする。コンテナと高度なクラスタ管理を、障害に強くスケーラビリティの高いインフラストラクチャの基盤として利用すれば、多くの企業が大きな利得を得るだろう”。

Mirantisのチームは以前、IntelやCoreOSとともにStackanetesを手がけたことがあり、そのときの経験や見聞が今回の新しいプロジェクトにとって実質的に概念実証になっている。“今日（米国時間7/25）発表したGoogleやIntelとのイニシアチブでもCoreOSとのコラボレーションを継続し、Stackanetesに見られるものの一部を取り入れたい”、とMirantisのスポークスパーソンは語った。

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

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

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

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

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

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

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

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

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

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

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

CoreOSが古典的ビッグサーバーではなく分散コンテナクラスタ向けに最適化されたストレージシステムTorusをオープンソースでローンチ

CoreOSが今日（米国時間6/1）、同社の最新のオープンソースプロジェクトTorusをローンチした。Torusは、スタートアップやエンタープライズに、GoogleなどのWebスケールの企業が内部的に使っているものと同種の技術にアクセスさせよう、とする取り組みの一環だ。Torusの場合それは、分散ストレージである。

アプリケーションがコンテナでデプロイされ、それらがGoogle育ちのコンテナ管理サービスKubernetesを使っている場合、Torusはデベロッパーに、信頼性が高くてスケーラブルなストレージシステムを提供する。

CoreOSのBarak Michenerが今日の発表声明でこう述べている: “コンテナクラスタというインフラストラクチャにおけるパーシステントなストレージは、コンピューティングにおける今もっとも興味深い問題の一つだ。マイクロサービスが作り出し消費するデータの、膨大な量のストリームを、どこに保存すべきなのか。とりわけ、イミュータブルで離散的にコンテナ化された実行コードが、これほどまでに強力なデザインパターンになっているときには？”

つまりCoreOSのチームが主張するのは、既存のストレージソリューションはコンテナのクラスタが使うために設計されていない、という点だ。それらは大きなマシンの小さなクラスタを想定しており、一方今日のコンテナベースのやり方では、比較的小さなマシンで動く大規模なクラスタが主力だ。またコンテナのデプロイメントは、必要に応じてコンテナを迅速に始動しまたシャットダウンもする、というやり方だが、多くのデベロッパーは、これらのコンテナの上で動くアプリケーションにデータを供給できるパーシステントなストレージシステムを求める。

“クラスタの中で始動、停止、アップグレード、ノード間のマイグレーションを頻繁に繰り返すこれらのコンテナマイクロサービスのためにパーシステントなストレージを確保することは、モノリシックなアプリケーションのグループや、まして複数の仮想マシンが動く単一のサーバーを支えるストレージを提供することのように単純ではない”、とMichenerは書いている。

Torusは、ファイルの保存と取り出しにキー-ヴァリュー方式のデータベースを用いる。それならノード数数百までスケールできる、とCoreOSは主張する。今の、初期的バージョンのTorusは、ファイルをNetwork Block Deviceによるブロック指向のストレージとして露出する。しかしそのシステムは拡張性を前提としているから、今後誰かが必要なツールを作って、Torusの上でオブジェクト指向のストレージシステムがサポートされることを、CoreOSは期待している。

Torusは、CoreOSのLinuxディストリビューションCoreOSや、コンテナエンジンrkt、ネットワーキングツールflannelなどと共に、同社のオープンソースプロジェクトの一員になる。これらと、さらにそのほかの多様なツールが相まって、同社の商用製品であるコンテナ管理システムTectonicや、ソフトウェアコンテナの構築、保存、および配布を行うQuayなどを動かしている。

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

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

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

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

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

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

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

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

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

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

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

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）

CoreOSのコンテナ管理サービスTectonicが完全な暗号化保証によりコンテナ採用システムのセキュリティを強化

ソフトウェアを開発しデプロイする方法としてコンテナの人気がますます大きくなりつつあるが、しかしそれとともに、コンテナのデプロイのセキュリティという問題も、ますますクローズアップされてきた。コンテナのセキュリティに関しては、これまでにもDockerやCoreOSなどの取り組みが見られるが、CoreOSは今日、それをさらに一歩進めて、同社のKubernetesベースのコンテナ管理サービスTectonicのために、”Distributed Trusted Computing“と呼ばれるセキュリティサービスをローンチした。

このサービスは企業のシステム環境の全体、ハードウェアからアプリケーションに至るまでのすべての層に、暗号化によるセキュリティの保証を与える。ハードウェアのレベルでは顧客の暗号キーがハードウェアのファームウェアに組み込まれ、一方オペレーティングシステムのCoreOSはブート時に、いじられていないことを確認する。またコンテナは、信頼できる鍵で署名されているものしか、動かせない。

CoreOSのCEO Alex Polviが、今日の発表声明で述べている: “セキュリティは弊社CoreOSの中心的なミッションである。まったく新しい種類のコンピューティングを市場に導入することは容易ではないが、その大きな阻害要素であるセキュリティは、Distributed Trusted Computingで担保できる。これは企業のセキュリティ能力を一挙に高めるものであり、初めての、完全に暗号化が保証されたエンドツーエンドのデータとコンピューティングおよび環境の、制御能力を提供する”。

しかし、これらの新しい機能がユーザをTectonicプラットホームに縛り付けることはない。

コンテナを使ったソリューションのデプロイが、今後の企業現場で増加するに伴い、CoreOSが提供しているようなセキュリティ機能が必須のスタンダードになるだろう。Dockerも暗号による署名を新しいコンテナのデフォルトにしようと努めている。でも現状では、コンテナのセキュリティ機能・サービスがいちばん進んでいるのはCoreOSだろう。

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

CoreOSのKubernetesベースのコンテナプラットホームTectonicが今日から一般供用へ

数か月前にCoreOSは、Tectonicのプレビューをローンチした。それはGoogleのコンテナ管理/オーケストレーションツール、Kubernetesを使用するコンテナプラットホームだ。今日からそのTectonicが、ベータを脱する。

CoreOSのCEOで協同ファウンダのAlex Polviによると、チームはベータ期間中に数百の顧客と協働してバグなどを見つけ、それらを修復した。そして、一般公開OKと判断した。

まだ料金体系は未定だが、クラスタのメモリ使用量に応じて課金されるだろう、とPolviは言っている。つまり、メモリの使用量が増えれば料金も上がる。“コンテナの最大のメリットの一つが、クラウドと自前のデータセンターの両方に透明に跨（また）がれることだ。そんな環境ではノード数による公平な課金はできない”、とPolviは述べる。

Polviによると、Tectonicの現在の顧客はきわめて多様だが、とくに多いのは、これから基本業務をWebサービスとしても提供しよう、というところ、たとえば銀行や通信企業などだ。どちらもこれまでは、物理店舗におけるカウンター接客が主だった。

今日CoreOSはTectonicの一般供用開始の発表と並行して、ベルリンにエンジニアリングのオフィスを開設したことを発表した。また、同じく今日からは、Google Compute Engineを立ち上げ、Kubernetesプロジェクトにも貢献したJoe Bedaが、CoreOSの顧問団に加わる。

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