コンテナ

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

次の記事

遠隔医療のPlushCareがシリーズAで800万ドルを調達

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