コンテナのセキュリティをサービスするAquaがシリーズCで約68億円相当を調達

コンテナのセキュアな立ち上げを助けるAqua Securityが、Insight Partners率いるシリーズCで6200万ドルを調達したことを発表した。

これまでの投資家であるLightspeed Venture Partners、マイクロソフトのベンチャーファンドM12、TLV Partners、そしてShlomo Kramerも参加した。米国時間4月2日の投資で、「これまでの累積調達額は1億ドルを超える」と同社は言っている。

初期の投資家たちは、同社が2015年に創業されたとき賭けに出た。というのも当時はコンテナはまだ何者でもなかった。でもファウンダーたちは、次に来るものに関して確かなビジョンを持っていた。そしてその後、賭けはでっかく当たって今同社は、先行馬のアドバンテージを享受している。ますます多くの企業がKubernetesとコンテナの方を向くようになり、コンテナという特殊な環境を最初から想定したセキュリティ製品が必須になりつつある。

共同ファウンダーでCEOのDror Davidoff氏は、Fortune 500社のうち60社が同社の顧客だというが、その社名は明かさない。でもひとつのヒントとして、世界のトップバンクのうち5行が顧客だそうだ。そんなクラスの企業がコンテナのような新しい技術へ舵を切ったら、しっかりとしたセキュリティオプションなしでは本気で前へ進めない。それを、Aquaが提供する。

Davidoff氏はこう語る。「うちの顧客はみな、思い切った決断をして新しい技術を採用している。彼らは、既存のセキュリティツールでは問題を解決できないことも、よく知っている」。彼によると、みな最初は小さく始めるが、まわりでコンテナの採用が増えるにしたがって自分たちもコンテナの利用を拡大している。

コンテナのような軽量で短命(エフェメラル)なコンセプトはセキュリティの脅威も少ない、と思いがちだが、しかしDavidoff氏によると、コンテナはオープンな技術だから不正行為に遭いやすい。彼はこう言う。「今のコンテナは、誰も知らない初物技術ではない。多くの人に知られており、したがって危険性も増している。技術そのものがオープンだから、ハックもしやすいし脇道にも行きやすい。コンテナに機密情報があれば、その情報には容易にアクセスできる」。

Aquaは、コンテナのイメージをスキャンしてマルウェアを探し、安全を証明されたコンテナだけが確実に本番で動いているようにする。いわばAquaがコンテナの関所になるから、悪者が不正なイメージを挿入することが困難になる。しかしコンテナの短命という性質が、何かがこっそり入り込むことを許してしまう。DevOpsがいるところなら、欠陥コンテナを取り外して新たに証明されたコンテナに迅速に入れ替えるのも簡単だが。

同社は150名の社員がボストン周辺のオフィス、そしてR&Dチームはイスラエルのテルアビブにいる。今回の新たな資金で同社は、営業とマーケティングそしてカスタマサポートを充実させたい、と言っている。またプラットホームとしての能力を、サーバーレスコンピューティングなど新しい領域にも拡張したい。あれやこれやでDavidoff氏の皮算用によると、今から12ないし18カ月後には社員数は倍増、顧客数は3倍から4倍増を期待している。

これだけの資金があれば同社は今後のコンテナ化の拡大に遅れを取ることなく成長でき、プロダクションにおけるコンテナを安全に保ちたいと願う各社からの、セキュリティソリューションの需要に対応していけるだろう。

関連記事: Four years after its release, Kubernetes has come a long way(Kubernetesの誕生後の4年は長い旅路だった、未訳)

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

AWSのSnowball Edgeは100TBのストレージとコンピューティング機能を提供する

snowball-edge

Amazonのストレージ・コンテナSnowballは広い層に利用されている。同社の今日のre:inventカンファレンスでは、そのメジャーアップデートが発表された。同じ日にあのとんでもない化け物AWS Snowmobileが発表されて、影が薄くなってしまったが、Snowballではコンピューティングの機能に加えて、ストレージを100テラバイトまで増設できる。

今回のアップデートで提供されるSnowball Edgeでは、各デバイスから直接に、データに対する基本的なアナリシスができる。これは、リアルタイムのインサイト(洞察)が必要とされる現場作業にとって、理想的だ。昨年のモデルと同じく、満杯になったデータを直接AWSのデータセンターに送って利用できる。

AWSを仕切っているAndy Jassyによると、たとえばGeneral Electricは、同社のウィンドファームでコンピュテーション機能を利用している。そのウィンドファームでは各タービンのリアルタイムデータを集めて、異状を分析する。クラウドをフルに利用できない船舶や航空機でも、集めたリアルタイムデータに対し、同じことができる。そういうところでは、インサイトに加えてデータのセキュアなバックアップも要請される。

  1. img_20161130_143252.jpg

  2. img_20161130_143339.jpg

Snowball Edgeでは万全のセキュリティのために、データを三種類の方法で暗号化する。またクラスタリング機能により、ひとつのエンドポイントに複数のデバイスが接続し、アクセスできる。サポートはS3やNFSのエンドポイントからの、データ保存とアクセスに対しても適用される。接続性が改善されたため、100TBのデータ転送が19時間で終わる。

EdgeはPythonで書かれたAWSのLambdaファンクションをサポートする。このファンクションに関しては課金の計画がないが、デバイス本体は利用料金が300ドルだ。これは、10日で完了するデータ転送の料金である。それを過ぎると、1台一日あたり30ドルが追加課金される。

[原文へ]
(翻訳: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を利用でき、彼らが大小さまざまなスケールで分散システムを管理できるよう心がけた”。

flower

今回のアップデートでユーザーは、複数のクラスターから成るサービスをセットアップでき、しかもそれらは複数のクラウドからホストされていてもよい。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))

DockerがコンテナのオーケストレーションをDocker Engineに統合、単独サービスを不要に

img_20160619_175158

Dockerが今週シアトルで行ったデベロッパーカンファレンスは、事前にチケットが売り切れてしまう盛況だったが、そこでは同社のメインの製品であるDocker Engineに新しい大きな要素が加わった。これまで同社は、コンテナの構築、それらのデプロイ、オーケストレーションなど、主な工程を分割して提供していたが、今回はDocker Engineの中にコンテナのオーケストレーション機能を組み込んだ。

同社はまた、そのツールをMicrosoftのAzureやAmazonのAWSの上で、より容易にデプロイできるようにした。

DockerのCOO Scott John Johnstonによると、これらはすべて、コンテナをもっと使いやすくし、またCEOのBen Golubが今日(米国時間6/20)のキーノートで強調したように、コンテナのオーケストレーションを民主化するための努力の一環だ。コンテナのオーケストレーションは、KubernetesやMesosなど、そのためのフレームワークがすでにいろいろあるにも関わらず、依然としてデベロッパーにとって大きな痛点だ。

docker_engine_swarm_mode

今回Dockerがやったことは、昨年11月にベータを終えたクラスタリングサービスDocker Swarmと、オーケストレーションサービスComposeの、Engine本体中への統合だ。これからは、デベロッパーが”Swarmモード”をonにすると、Dockerエンジンの自己治癒型でお互い同士を発見できるクラスターが作られる。Swarmモードにはオーバレイネットワークのサポートが含まれ、それにより自動的サービス発見とロードバランシングのツールが利用できる。また新たに提供されるService Deployment APIにより、デベロッパーはこれから使うサービスや画像、ポートなどを宣言できる。

Johnstonによると、Dockerの既存のSwarmとComposeツールには何も変更がない。それはユーザーの既存のデプロイを壊したくないからであり、また、サードパーティのツールと併用できるという約束に、違反したくないからだ。同社によると今回の統合化によって“Dockerプラットホームを軸とする構築の機会がさらに拡大され”、またそのプラグイン方式のアーキテクチャにより、今後はネットワーキング、ストレージ、ログ取り、パートナーのモニタリングなど、これらのネイティブなオーケストレーション機能を利用する多方面の進化が期待できる。

docker_swarm-commands

しかしそれと同時に、彼によれば、これらの新しい機能を使いたいと思っているデベロッパーとシスアドミンの両方が、すでに使い慣れている同じDockerコマンドラインを使えるし、アプリケーションをテストしデプロイするために必要なインフラストラクチャをより容易に構成稼働できる。“分散コンピューティングは難しいが、シスアドミンは分散アプリケーションを管理するために学校へ戻るわけにもいかない”、とJohnstonは語る。“これを構築することによって、ノードが複数ある場合にも、必要なことをすべてオーケストレーションツールがやってくれる”。

またDockerの主張によれば、そのシステムは、外部のインフラストラクチャに依存する特定のエラー発生箇所を持つことがない。セキュリティ機能をSwarmモードにも拡張したため、すべてのノードがTLSとDockerのCryptographic Node Identityを使って通信し、アドミンがやることは、ワークロードを信頼できるノードへディスパッチするだけだ。

これらの新しい機能をすべて揃えたDocker 1.12は今、リリース候補(リリースキャンディデート)を利用できる。一般公開は、7月を予定している。その後さらに徹底的なテストを重ねて、Swarmモードなどの新しい機能が商用製品として提供されるのは、今年の後半だ。

IMG_20160620_092304

DockerをAWSやAzureで使う

これらの新しい機能と並行してDockerは今日、Docker for AWSとDocker for Azureを発表した。これにより、Docker Engineをこれら両プラットホームで容易にデプロイできるようになる。Johnstoneは語る、“最近の弊社の拡大した市場には、これまで自分たちが選んで使ってきたインフラストラクチャの上でそのまま、Dockerを使いたい、というユーザーが少なからずおられる”。そこでたとえばDocker for AWSは、AWS自身のインフラサービス(AWS Autoscaling, Elastic Load Balancer, Elastic Block Storeなど)とタイトに統合され、Azureエディションは同様に、Microsoftのクラウドサービスと統合化されている。

ここにGoogleのCloud Platformが抜けていることについてJohnstonは、まず市場の圧倒的多数派に対応した、という。Google Cloudのユーザーは、まだ少数派だ。しかし、複数のクラウドを使いたいというエンタープライズも少なくないので、今後のDocker製品のスケーリングと拡張においては、GoogleやRackspaceなどもサポートしていきたい、と彼は述べる。

IMG_20160620_100449

さらにまた、Docker for OS X(近未来のDocker for macOS?)とDocke for Windowsが非公開ベータを終えて今では公開ベータが提供されている。いずれもDocker体験としては同じだが、AWSやAzureの場合と同様、これらのプラットホーム向けに特別にチューニングされているバージョンだ。

ただしDocker for AWSとDocker for Azureの方は、当面、非公開ベータでのみ提供される。

 

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

CoreOSのコンテナエンジンrktがバージョン1.0に到達…プロダクション利用可に

rkt-1-0-banner

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で動いている”。

2016-02-04_1048

rktのローンチとほぼ同時期にCoreOSは、App Container(appc)プロジェクトもローンチした。それは、Dockerコンテナのスペックとイメージフォーマットに代わるものだ。

昨年Dockerは、そのコンテナのスペックをOpen Container Initiative寄贈した。そこは、コンテナ関連の主要選手が全員参加している、オープンソースの連合団体だ。

一見すると、Dockerのこの動きによって傍系のプロジェクト、rktやappcやCoreOSのイメージフォーマットなどは、割りを食うことになりそうだ。でもPolviは今日、“OCIの主な目的はコンテナのランタイム環境のスタンダードを作ることであり、コンテナのイメージの〜〜ではない”、と主張している。

でも、DockerとCoreOSというこの分野の二大勢力が、とても目立つ競争をしていることは、コンテナにとって強力な追い風になるはずだ。標準化プロセスはまだ始まったばかりだから、元気な論争や競争があることは、とても良いことだ。

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

Googleが主力のコンテナサービスContainer RegistryとContainer Engineをアップデート…Kubernetesを統合など

docker-google

今年GoogleはContainer RegistryContainer Engineなどにより、同社のCloud Platform(IaaS)のコンテナ対応化にますます力を入れてきた。そして今日(米国時間11/10)は、この二つのサービス(ないしツール)のアップデートが発表された。

Container Engineは、クラスタの管理を自動化しコンテナの展開をオーケストレーションするGoogleのサービスだが、今回のアップデートでKubernetesの最新バージョン(version 1.1)をサポートすることになった。ニューバージョンでは随所にパフォーマンスの改良が行われ、そしてそれがContainer Engineのユーザにも可利用になった。

これによりContainer Engineでは、ポッド(pod, ノードの集合)の水平的スケーリング(クラスタへのサービスの追加)を自動的に行えるようになり、またHTTPのロードバランサも可能になる。後者では、トラフィックがその量に応じて別のKubernetesサービスへルートされる。

また、ネットワークのスピードも向上した。それにはContainer EngineにネイティブIPテーブルを導入し、CPUのオーバヘッドをほとんどなくし、信頼性を向上させたことなどが含まれる。

Container Registry(Dockerイメージのストレージ)の方も、今日同様のアップデートが行われた。それらはAPIのv2、パフォーマンスを40%アップ、高度な認証のサポートなどだ。高度な認証により、CodeshipやCircleCI、Drone、Jenkins、Shippable、Werckerなどの継続的なデリバリシステムを容易に統合できるので、デベロッパの仕事が相当楽になるはずだ。

Googleはまた、TwistLockとパートナーして、コンテナのためのセキュリティサービスを導入した。たとえばContainer Registryのユーザは、その上のコンテナへのアクセスポリシーを、設定できる。

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

SaaSアプリケーションのオンプレミスバージョンを簡単に提供できるコンテナツールReplicated

shutterstock_263329226

SaaSの企業がそのアプリケーションのオンプレミスバージョンを、もっと容易に提供できるように助けるReplicatedが今日(米国時間6/23)、150万ドルのシード資金の獲得と、ベータに参加している顧客企業を発表した。

同社はDockerのコンテナ技術を利用して、デベロッパが一度だけ書いたコードからアプリケーションのまったく同じ二つのバージョンを作り出す。ひとつは通常どおりクラウドにインストールされるバージョン、もうひとつはアプリケーションをプライベートクラウドや自社のデータセンターに置きたいと望む顧客のためのバージョンだ。

また、同社のベータに参加している企業は、Travis-CICode Climate、そしてNPMだ。いずれも、この生後9か月の企業(Replicated)にすでに1週間あまり協力している。

そしてシード資金は、ラウンドを仕切ったのがBoldStartで、これにFounder CollectiveとMucker Capital、TenOneTen、WonderVC、そしてWTIが参加した。また、David Lee(元SV Angel)やTom McInerney、GitHubのファウンダTom Preston-Wernerなどのエンジェルたちも参加している。

企業ユーザとSaaSの相性は必ずしも…

ReplicatedはファウンダのGrant MillerとMarc Campbellにとって二つ目のスタートアップで、最初はカスタマサービスをモバイルのチャットでやる、というアプリLook.ioを立ち上げ、それは2012年にLivePersonに買収された。

その後二人は2年間LivePersonで仕事をしたが、そのとき、問題に気づいた。大企業にはアプリケーションをSaaSでは使いたくないが、そのアプリケーションそのものは欲しい、という場合がある。しかし多くのSaaS企業には、別途オンプレミスバージョンを作ってメンテしてサポートしていく余力がない。

当時は、Dockerに代表されるコンテナ技術の黎明期だった。コンテナによって企業は、ポータブルなアプリケーションを作れる。そしてアプリケーションがポータブルであれば、“LivePersonなどの企業はアプリケーションのDockerイメージをユーザ企業に提供してファイヤーウォールの背後で動かしてもらえる”、とMillerは語る。

コンテナがなければ、顧客が求めているオンプレミスバージョンは二つ目のプロダクトとして作らざるをえない。それは時間と費用がかかるだけでなく、うまくいかないこともある。コンテナはこの大きな問題を解決してくれるので、MillerとCampbellにとっては渡りに船だった。

単なるインストーラではない

しかしReplicatedは、単純なインストレーションツール以上のものだ。それはまず、Active DirectoryやLDAPなどの認証システムを統合し、インスタンスに関する情報をダッシュボードで提供し、アップデートがあればユーザに報告、オーディティング(システム監査)ツールやバックアップサービスまで提供する。

Replicated administrative dashboard.

コードベースが二つも要らないのだから、アプリケーションの制作提供企業にとってReplicatedはとても便利だ。Repricatedにエンジェルとして投資しているGitHubのファウンダTom Preston-Warnerは先週、彼の個人的なブログでこう書いている:

“GitHubでは、GitHub独自のインストーラを作ろうとして何度も挑戦した。それは、インストールする環境のセキュリティを確保し、ライセンス管理を自動化し、シングルサインオンサービスを統合し(LDAP, Active Directory, CASなどなど)、検索できるオーディットシステムがあり、顧客がレビューできるサポートバンドルをサポートし(ログなどの診断出力)、さまざまなバックアップ戦略が可能で、そのほか、数えきれないほど多くのエンタプライズ的機能を具備していなければならない。それらの課題はすべて、GitHubのエンタプライズ利用をこれまで阻(はば)んできた要素なのだ。

Replicatedは、上にPreston-Warnerが挙げている問題をすべて解決し、顧客はエンタプライズインスタンスを驚くほどはやく作れる。同社のデモページは、8分ですべて終る、と主張している。現実にはもっと長くかかるかもしれないけど、重要なのは、これまでのような多大なる苦労が要らない、簡便である、という点だ。なおPreston-Warnerは今GitHubにいないし、GitHubはReplicatedの顧客ではない。

昨日(米国時間6/22)行われたDockerConで、コンテナ技術の主な選手たちが協力してコンテナのオープンスタンダードを作ることになった、と発表された〔関連記事〕。それは、Millerにとっても朗報だ。コンテナが標準化されれば、Replicatedの仕事は理想的な単純性に達する。CoreOSなどをはじめ、いろんなコンテナ技術をサポートしなくてもすむからだ。そのスタンダードに対応した製品を一つだけ作れば、あらゆるSaaSベンダが自分のプロダクトにそれを使えるようになる。

Replicatedはまだ歩き出したばかりだが、彼らが最初のスタートアップの成功をreplicate(複製する、再現する)できるなら、ほんとにすばらしいことだ。

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

Red Hatが企業利用に便利なレディメイドのLinuxコンテナプラットホームをローンチ、DockerとGoogle Kubernetesをサポート

アプリケーションのコンテナ化によってエンタプライズコンピューティングの様相が変わりつつあることに対応してRed Hatはこのほど、Red Hat Enterprise Linux Atomic Hostと呼ばれるLinuxコンテナプラットホームをベータでリリースした。

コンテナ化という新しいトレンドによってアプリケーションの配備と展開が仮想マシンを使った場合に比べて効率的になり、迅速になった。それはある意味では一歩進んだ仮想化技術であり、これまでの仮想化技術から余計なものを剥ぎとってリソース効率を高め、迅速な展開を可能にした。

今日(米国時間11/11)ベータリリースされたRed Hat Enterprise Linux Atomic Hostは、企業にコンテナ化のためのレディメイドのスタックを提供しようとするもので、ユーザはこのプラットホーム上で自己のコンテナ技術を構築できる。Red Hatのプロダクトマーケティング担当シニアディレクターMark Cogginによると、これによりISVやそのほかのデベロッパは、いわば保証つきのコンテナを作って動かせるようになる。当然それによって顧客は、自分たちが使っているコンテナがRed Hatの優れた技術で作られているという安心感を得ることができる。もちろん、デベロッパに頼まず企業が自力でコンテナを構築してもよい。

Cogginによると、その基本的な考え方は、アプリケーションと一部のランタイムライブラリと、要らないものを削ぎ落としたLinuxを収めたコンテナを作ること、それによってアプリケーションの稼働に必要なコア的サービスを配布することだ。彼によると、そういう超簡素化されたLinuxを含めることによって、可搬性が増し、展開とメンテナンスと管理が容易かつ単純になる。

これは、今人気の高いコンテナ技術Dockerと競合するものではなく、むしろこのプラットホームもDockerとの協力により内部的にDockerを利用している。またGoogleのKubernetesもサポートされるので、そのオーケストレイションレイヤ(クラスタ管理層)により、コンテナの全ライフサイクルにわたる管理ができる。Cogginによると、Kubernetesに関してはすでに何か月もGoogleと協働しているので、まだ若いシステムではあるが、このRed Hat Enterprise Linux Atomic Hostのスタックに重要な管理機能を提供する。

Coggin曰く、物理サーバは立ち上げに数時間を要し、仮想マシンのセットアップには数分を要する。しかしコンテナのセットアップと立ち上げに要する時間は約10秒だ。アジリティとスピードを重視する企業にとっては、これによりIT部門が各業務部門からのニーズに直ちに対応できるようになり、今日の競争の激しい企業環境において大きなアドバンテージをもたらす。

スピードだけでなく、コストのアドバンテージも大きい。このLinuxコンテナは要らないものをすべて排除して簡素化されているので効率が高く、従来だと一台のサーバ上で10のVMを動かすのがせいぜいだったが、コンテナなら100ぐらい動かせる。データセンターのランニングコストに、大きな違いをもたらすだろう。

ただし、今回のベータの時点ではマルチホストの展開がサポートされず、プラットホームはシングルホストの実装のみだ。したがって複数のサーバを使って実現できるような効率性は、今後の(正規立ち上げ後の)オプションとなる。Cogginは、これはまだ非常に初期的なリリースなので…、と言い訳している。彼は本番立ち上げのスケジュールを明言しなかったが、‘いずれは’(eventually)という言い方をした。

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


Dockerがついにv1.0に、サポートとドキュメンテーション完備で本格商用化へ

Dockerプラットホームを支える企業Docker, Incが今日、同社主催のカンファレンスDockercon14で、Docker 1.0のリリースと“Docker化”されたプロダクトのためのマーケットプレイスを発表した。

CEOのBen Golubによると、これらの発表は同社のこれまでの15か月にわたる集中的な開発努力の成果だ。Golubの説明によると、1.0は初めての、商用サポートとドキュメンテーションが完備したプロダクションクォリティーのバージョンである。彼曰く、これまでは多くの人たちが0.xバージョンの開発に従事してきたが、これからはコミュニティサポートではなく商用サポートがつくので、銀行などの保守的な企業でも安心してDockerを利用できる。

Docker 1.0はGoogleが開発した新しいコンテナ技術の実装系の一つで、アプリケーションを、これまでのように変更を加えたり、開発サイクルの新しいステージに入るたびに、まったく新たな再インストールや再構成を必要とせず、安全に配布できる。

これまではデベロッパと運用者(ユーザ、オペレーション側)は利害が相反していた。デベロッパは必要に応じて変更を加えたいし、運用者は安定性を欲する。しかし変更を加えたことによって、他の部分や構成要件などが変わって、オペレーションサイドを悩ませることが多かった。

“Dockerは、この面倒な問題でデベロッパを救った”、と彼は言う。“それと同時に、アドミンの苦労もなくなった。DevとOpsの両方がハッピーになった”。

彼の説明では、Docker 1.0ではデベロッパはラップトップの上でボタンを一つ押すだけであり、プロダクションや、ステージング、顧客環境の側では、すべてが従来どおりに動く。デベロッパが開発ワークフローの次のステップに移って何かを変えても、プログラムを壊したり、問題の原因究明に苦労することがない。

すなわちプログラムをDockerのコンテナに安全に収めることによって、デベロッパがその内部を変えても外側の状態は前と変わらない。

また、Docker 1.0と併せて発表されたDocker Hubは、デベロッパが“Docker化”されたアプリケーションを見つけたり発表する場だ。Docker化アプリケーションとは、Dockerを使って動かすように調整されているアプリケーション、という意味だ。このハブでデベロッパは、ほかのデベロッパとコラボレーションすることができるし、また、Dockerのメンテなたちに会うことができる。ここに寄与貢献されるものを、メンテナたちがフィルタして、特定のジョブやプラットホームに合ったものを見つけるのだ。

Golubが言うには、オープンソースで行くなら全身でその世界に浸らないとだめだ。今では社員35名(+1匹の亀さん) を450名のデベロッパのコミュニティが支え、Dockerの開発や、カンファレンスの開催に尽力している。始まってからまだわずか15か月なのに。

このコミュニティ集団こそが、DokcerプロダクトとDocker Hubのメンテナンスの中心的な力であり、彼らがあらゆるコンテンツのクォリティーをたえずチェックしている。また、彼らの寄与貢献に悪い部分があれば、市場から叱声が返ってくる。

カンファレンスについては、Golub曰く、たった二つの新製品だから、カンファレンスなんかたいしたことない、と最初は考えていた。でも日程を決めて実際に準備を初めてみると、すごい大仕事であることが分かった。“最初は、カンファレンスはいいアイデアだと思ったんだけどね”、と彼はジョークを言う。

数からいえば、大成功だった。最初は500名を予定していたが、先週金曜日には急遽100名追加し、それでも、チケットにあぶれた人が400名以上いた。

講演者はGoogle、IBM、Rackspace、Red Hatなど大物企業の人たちばかり。Wired誌は、GoogleがDockerに深くコミットしていると報じ、GooglerのEric Brewerが二日目に行ったスピーチは、Dockerの知名度と関心を大きく高めただろう。

最近同社は、シリーズBで1500万ドルを獲得した。本誌TechCrunchの記事によると、そのラウンドを仕切ったのはGreylock Partnersだ。参加した投資家はInsight Venture Partners のほかに既存の投資家Benchmark CapitalTrinity Venturesだ。なお、Yahoo!のファウンダJerry Yangも、初期に同社に投資している。

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