Dockerコンテナ時代の第一章の終わり、そして第二章の展望など

2017年12月11日

コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。そうして始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで基盤技術の基本要素がおおむね固まり、一つの区切りがついたように見えます。そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。この記事では、Docker登場から現在までを振り返り、その次の段階を展望します。

2013年、Docker登場

Dockerが登場したのは2013年3月26日のことでした。 Dockerリリース 2010年に創業し2011年からPaaSを提供するクラウドベンダーだったdotCloudが3月、オープンソースのソフトウェアとして公開しました。 ●Opening docker - Docker Blog dotCloudからDockerへ そのDockerは登場当初から急速に注目されるようになり、その結果dotCloud社は社名をDockerに変更し、Dockerを同社のビジネスとして立ち上げるという大胆な発表を行います。

クラウドプロバイダーの「dotCloud」が「Docker」へ企業名を変更。コンテナ型仮想化ソフト「Docker」のビジネス立ち上げにフォーカス－ Publickey

「about Docker - Docker Inc.」から引用

Docker 0.7 2013年11月に登場したDocker 0.7で、Ubuntuなど一部のLinuxでしか利用できなかったDockerが、RHEL、SUSE、DebianなどすべてのLinuxディストリビューションに対応します。

2014年、Googleは毎週20億のコンテナを起動していた

2014年は、コンテナがIT業界の大きなトレンドとして認識された年でした。 Docker 0.9 2014年3月にリリースされたDocker 0.9では、それまで依存していたLXCから独自に実装したlibcontainerへ切り替えることで安定性が向上。 2014年4月には、Red HatがDocker専用の軽量OS﹁Red Hat Enterprise Linux Atomic Host﹂を発表。Dockerはニッチではなくメインストリームの技術であるという認識が広まり、日本でもDocker Meetupなどのイベントが開催されるようになりました。 ●今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2 － Publickey Googleはすべてをコンテナ化していた こうしてコンテナへの注目度が国内外で高まる中、Googleはすでに全部のソフトウェアをコンテナ化しており、毎週20億個ものコンテナを起動していると発表し、多くのエンジニアを驚かせました。

Docker 1.0リリース 6月10日は早くもDocker 1.0が登場。同時にDockerイメージを管理するDocker Hubが発表されました。 ●﹇速報﹈コンテナ型仮想化のDocker 1.0がリリース。Dockerはコンテナエンジンからプラットフォームになると宣言－ Publickey ●﹇速報﹈Docker Hub発表。ビルド、テスト、デプロイの自動化、Dockerイメージの管理など。Dockerのプラットフォーム化を推進－ Publickey Google、Kubernetes発表 その同じ6月10日、GoogleはKubernetesをオープンソースとして公開することを発表します。 ●Google Cloud Platform Blog: An update on container support on Google Cloud Platform VMware、マイクロソフトが相次いでDockerと協業発表 8月にはVMwareがDockerとの協業を発表。10月にはマイクロソフトもDockerと提携し、Windows ServerでDocker採用と発表。そして同じ頃、DockerはdotCloudのビジネスをcontrolCloudに売却し、Dockerビジネスに専念することを表明。 Docker Swarm 12月にはDockerが独自のコンテナオーケストレーションツールのDocker Swarmを発表します。

2015年、コンテナ仕様は標準化へ

2月、Red HatはOpenShift V3でそれまでのアーキテクチャを捨てて、DockerとKubernetesをコアとすると発表。Kubernetesへの傾倒を明確にします。 ●DockerとKubernatesを核にしたPaaS基盤へと変わるOpenShift V3 － Publickey Open Container Initiativeスタート コンテナ実装のあり方についてやり合っていたDockerとCoreOSが一転、6月にマイクロソフト、Google、Red Hat、VMware、Amazon Web Servicesらと共同でコンテナの標準化団体﹁Open Container Initiative﹂︵発表時の名称はOpen Container Project﹂︶の発足を発表。それまでDockerやCoreOSなどそれぞれのベンダが独自に実装していたコンテナが、一気に標準化へ舵を切ります。

［速報］「Open Container Project」発足。Docker、CoreOS、マイクロソフト、Amazon、Googleらが合流し、コンテナは統一仕様へ－ Publickey

Cloud Native Computing Foundation設立 7月、それまでGoogleが主導してオープンソースの実装を進めてきたKubernetesも、バージョン1.0に達すると同時に、ベンダから独立した団体である﹁Cloud Native Computing Foundation﹂を設立。開発主体がこの団体へ移動します。 ●Kubernetesが1.0に到達。今後は開発の主体を新団体﹁Cloud Native Computing Foundation﹂へ－ Publickey 8月にはDockerと提携したマイクロソフトが、Dockerを搭載したWindows Server 2016 Technical Preview 3を公開。9月にはVMwareがvSphereにコンテナエンジンを統合した﹁vSphere Integrated Containers﹂を発表します。

2016年、Swarm対Kubernetes

Docker for Mac/Windows登場 3月にはVirtualBoxなどが不要でOSネイティブの仮想化を用いた﹁Docker for Mac/Windows﹂が登場。 DockerにSwarmバンドルを発表 6月におこなわれたDockerCon 16では、Dockerにコンテナオーケストレーション機能のDocker Swarmを内蔵することを発表。このあたりから、SwarmとKubernetesを軸としたコンテナオーケストレーションツールの主導権争いが表面化してきます。 ●﹇速報﹈Docker、最新バージョンでDocker Engineにオーケストレーション機能を内蔵。外部ツール不要でクラスタ運用を実現。DockerCon 16 8月には発表通り、Docker Swarmを内蔵した﹁Docker 1.12﹂が登場。 Kubernetesが独自コンテナランタイム開発を表明 Kubernetes側は当然のことながら、こうしたDockerの動きを歓迎しませんでした。10月には、Kubernetesの開発陣が独自のコンテナランタイム﹁cri-o﹂を開発中であることを表明します。 ●Kubernetes、独自のコンテナランタイム﹁cri-o﹂開発中。コンテナランタイムのインターフェイスを標準化し、Dockerだけでなくどんなコンテナランタイムでも対応可能に－ Publickey Dockerからcontainerdが分離 これをDocker側が警戒したのかどうかは不明ですが、12月にはDockerエンジンのコアランタイムを﹁containerd﹂として分離、独立したオープンソースプロジェクトとなります。また、11月には日本人としては初めてのDockerメンテナとして、NTTの須田氏が就任しました。

2017年、Kubernetesが事実上の標準に

そして今年、コンテナオーケストレーションツールをめぐる状況は大きく動きました。 Kubernetes優勢の状況へ 2月、CoreOSはKubernetesがコンテナオーケストレーションツールのデファクトになったとし、自社で開発していたオーケストレーションツール﹁fleet﹂の開発終了を発表します。 ●﹁Kubernetesはオープンソースのコンテナオーケストレーションのデファクトになった﹂と、CoreOSがfleetの開発を終了、代わりにKubernetes採用を発表－ Publickey この頃から、Kubernetesがコンテナオーケストレーションツールとして頭一つ抜け出した状況が見え始めます。 Kubernetes 1.6登場 3月に登場したKubernetes 1.6は、etcd3とgRPCを採用したことで大幅に性能向上。さらに名前空間の分離や物理ノードの考慮などの機能向上も果たしました。 Moby Project発表 4月、DockerCon 2017でDockerはMoby Projectを発表します。Moby Projectはさまざまなコンテナ関連のソフトウェアをコンポーネント化することで、目的ごとに特化したコンテナシステムを作ることができるフレームワークです。

Dockerが「Moby Project」を発表。すべてをコンテナで組み立てる世界を目指す。DockerCon 2017 － Publickey

6月にはオラクルもKubernetesへの注力を発表。 コンテナ標準のOCI 1.0発表 7月にはついにOpen Container Initiativeによるコンテナランタイムとコンテナイメージの標準化作業が完了し、﹁OCI 1.0﹂として発表されます。 7月、8月、9月と相次いでマイクロソフト、AWS、VMware、オラクルがKubernetesの開発をホストするCloud Native Computing Foundationへの加盟を発表。状況はKubernetesへ一気に傾き始めました。 DockerがKubernetesの統合を発表 そして10月に開催されたDockerCon Europe 2017で、DockerはついにKubernetesの統合とサポートを発表しました。コンテナオーケストレーションの事実上の標準がKubernetesになったと言えます。

［速報］DockerがKubernetesとの統合およびサポートを発表。DockerCon EU 2017 － Publickey

主要クラウドもKubernetesマネージドサービス提供 10月にはMicrosoft AzureがKubernetesのマネージドサービス﹁Azure Container Service﹂︵AKS︶を発表。Google Cloudはこれまで提供してきたKubernetesベースのGoogle Container Engineを﹁Google Kubernetes Engine﹂︵略称GKEはそのまま︶にサービス名を変更。そして11月にはAWSも﹁Amazon Elastic Container Service for Kubernetes﹂︵Amazon EKS︶を発表しました。 Kubernetesのコンテナランタイム﹁cri-o 1.0﹂リリース Kubernetesが独自に開発を進めていたコンテナランタイムのcri-oも1.0に到達。コンテナランタイムとKubernetesのあいだのAPIも﹁CRI﹂︵Kubernetes Container Runtime Interface︶となりました。 ●Kubernetes、Dockerに依存しないKubernetes用の軽量コンテナランタイム﹁cri-o﹂正式版1.0リリース－ Publickey これによってコンテナランタイムとコンテナイメージの標準は﹁OCI﹂、コンテナランタイムとKubernetesとの間のAPIは﹁CRI﹂として標準化されたことになります。

コンテナランタイムの多様化

こうして2017年末のコンテナの主な状況をまとめると、コンテナランタイムが標準化され、コンテナオーケストレーションツールの事実上の標準の座にKubernetesがつき、主要クラウドベンダはKubernetesのマネージドサービスを開始した、ということになるでしょう。この状況から今後なにが起きるのかを少し考えてみます。ひとつは標準に沿ったうえでのコンテナランタイムの多様化ではないでしょうか。実際にKubernetesは独自のコンテナランタイムであるcri-oをリリースしています。オラクルは、Rust言語で実装したより高速に起動するコンテナランタイムの﹁Railcar﹂をオープンソースで公開していますし、OpenStack Foundationは、軽量さと堅牢さを追求した﹁Kata Containers﹂の開発をスタートさせました。コンテナがアプリケーションの基盤としてさまざまな用途で使われるようになるとすれば、その用途に合った特徴を備えたさまざまなコンテナランタイム実装が登場することは自然なことなのかもしれません。とはいえ、現在のところコンテナ実装はcontainerdが事実上の標準となっています。そのcontainerdは今月、バージョン1.0に到達したばかりです。いましばらくこうした状況が続くとみられます。 ●事実上の標準コンテナランタイム﹁containerd﹂がバージョン1.0に到達－ Publickey

Kubernetesによるマルチクラウド

AWS、Azure、Google Cloudなどの主要なクラウドによるマネージドなKubernetesのサービスがはじまったことも注目に値します。しかもKubernetesの開発をホストしているCloud Native Computing Foundationはなかなかやり方が上手で、﹁Kubernetes適合認証プログラム﹂を開始し、独自のKubernetes実装などによるAPIの齟齬などが広まらないように手を打っています。そうするとすぐに思いつくのが、複数の異なるクラウドをKubernetesのレイヤで抽象化する、というアイデアでしょう。これまでクラウド間で仮想マシンを柔軟に移動させることは可能ではありましたが面倒であり、動的に行えるような柔軟性もありませんでした。しかしどのクラウドも同じコンテナオーケストレーションツールのKubernetesと標準仕様のコンテナが使われているのであれば、これをKubernetesのレイヤで束ねてコンテナをクラウド間で柔軟に移動する、ということが可能になります。少なくともDockerは昨年からDocker Datacenterで︵Kubernetesとは異なる実装で︶こうしたことを実現しようとしていました。今年、Kubernetesとの統合を発表した同社としては、あらためてKubernetesを用いた実装で実現しようとしてくると思われますし、おそらく他のベンダやオープンソースなどでも同様のソフトウェアが登場してくるのではないでしょうか。これが機能するようになれば、ユーザーはKubernetesのオーケストレーション機能を用いてワークロードの種類や価格に合わせてクラウドを自由に使い分ける、といったことがやりやすくなります。一方で、クラウドベンダにとって自社のクラウドがKubernetesで抽象化されてしまうのは、独自性や付加価値を失うことにつながってしまいます。そこでクラウドベンダとしては、コンテナをベースにアプリケーションの開発、テスト、デプロイ、本番運用までの一連のライフサイクル全体でユーザーに使いやすくなるようなツールやサービスを構築することで、できるだけ競合他社のクラウドへワークロードが逃げないような施策を打つことでしょう。その点で、AWSがAmazon EKSを発表すると同時に、それよりも使いやすいコンテナの実行環境として﹁AWS Fargate﹂を発表したのは、さすがによく考えられた戦略に沿ってサービスができているように見えます。

ハイブリッドクラウドもKubernetesになるか？

ではオンプレミスでのKubernetesの展開はどうでしょうか？もしもオンプレミスでもKubernetesがある程度使われるようになるとすれば、前述のパブリッククラウド同士の連携と同様に、Kubernetesのレイヤでハイブリッドクラウドを構築するための基盤として展開されるものになると考えられます。ただし、まだオンプレミスでのKubernetesの展開は未知数です。VMwareと関連会社のPivotalが、VMware環境上にKubernetes環境を展開する﹁Pivotal Container Service﹂︵PKS︶を今年の8月に発表していますので、動向を注目したいと思います。