コンテナ時代の第一章の終わり、そして第二章の展望など
コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。
そうした始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで、基盤技術の基本要素がおおむね固まり、第一章としての区切りがついたように見えます。
そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。
この記事では、Docker登場から現在までを振り返り、その次の段階を展望します。
2013年、Docker登場
Dockerが登場したのは2013年3月26日のことでした。
Dockerリリース
2010年に創業し2011年からPaaSを提供するクラウドベンダーだったdotCloudが3月、オープンソースのソフトウェアとして公開しました。
dotCloudからDockerへ
そのDockerは登場当初から急速に注目されるようになり、その結果dotCloud社は社名をDockerに変更し、Dockerを同社のビジネスとして立ち上げるという大胆な発表を行います。
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などのイベントが開催されるようになりました。
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をオープンソースとして公開することを発表します。
VMware、マイクロソフトが相次いでDockerと協業発表
8月にはVMwareがDockerとの協業を発表。10月にはマイクロソフトもDockerと提携し、Windows ServerでDocker採用と発表。
そして同じ頃、DockerはdotCloudのビジネスをcontrolCloudに売却し、Dockerビジネスに専念することを表明。
Docker Swarm
12月にはDockerが独自のコンテナオーケストレーションツールのDocker Swarmを発表します。
2015年、コンテナ仕様は標準化へ
Open Container Initiativeスタート
コンテナ実装のあり方についてやり合っていたDockerとCoreOSが、6月にマイクロソフト、Google、Red Hat、VMware、Amazon Web Servicesらと共同でコンテナの標準化団体「Open Container Initiative」（発表時の名称はOpen Container Project」の発足を発表。それまでDockerやCoreOSなどそれぞれのベンダが独自に実装していたコンテナが、一気に標準化へ舵を切ります。
Cloud Native Computing Foundation設立
7月、それまでGoogleが主導してオープンソースの実装を進めてきたKubernetesも、バージョン1.0に達すると同時に、ベンダから独立した団体である「Cloud Native Computing Foundation」を設立。開発主体がこの団体へ移動します。
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を軸としたコンテナオーケストレーションツールの主導権争いが表面化してきます。
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がコンテナオーケストレーションツールとして頭一つ抜け出した状況が見え始めます。
Kubernetes 1.6登場
3月に登場したKubernetes 1.6は、etcd3とgRPCを採用したことで大幅に性能向上。さらに名前空間の分離や物理ノードの考慮などの機能向上も果たしました。
Moby Project発表
4月、DockerCon 2017でDockerはMoby Projectを発表します。Moby Projectはさまざまなコンテナ関連のソフトウェアをコンポーネント化することで、目的ごとに特化したコンテナシステムを作ることができるフレームワークです。
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になったと言えます。
主要クラウドもKubernetesマネージドサービス提供
10月にはMicrosoft AzureがKubernetesのマネージドサービス「Azure Container Service」（AKS）を発表。Google Cloudはこれまで提供してきたKubernetesベースのGoogle Container Engineを「Google Kubernetes Engine」（略称GKEはそのまま）にサービス名を変更。そして11月にはAWSも「Amazon Elastic Kubernetes Service」（Amazon EKS）を発表しました。
Kubernetesのコンテナランタイム「cri-o 1.0」リリース
Kubernetesが独自に開発を進めていたコンテナランタイムのcri-oも1.0に到達。コンテナランタイムとKubernetesのあいだのAPIも「CRI」（Kubernetes Container Runtime Interface）となりました。
これによってコンテナランタイムとコンテナイメージの標準は「OCI」、コンテナランタイムとKubernetesとの間のAPIは「CRI」として標準化されたことになります。
コンテナランタイムの多様化
こうして2017年末のコンテナの主な状況をまとめると、コンテナランタイムが標準化され、コンテナオーケストレーションツールの事実上の標準の座にKubernetesがつき、主要クラウドベンダはKubernetesのマネージドサービスを開始した、ということになるでしょう。
この状況から今後なにが起きるのかを少し考えてみます。ひとつは標準に沿ったうえでのコンテナランタイムの多様化ではないでしょうか。
実際にKubernetesは独自のコンテナランタイムであるcri-oをリリースしています。オラクルは、Rust言語で実装したより高速に起動するコンテナランタイムの「Railcar」をオープンソースで公開していますし、OpenStack Foundationは、軽量さと堅牢さを追求した「Kata Containers」の開発をスタートさせました。
コンテナがアプリケーションの基盤としてさまざまな用途で使われるようになるとすれば、その用途に合った特徴を備えたさまざまなコンテナランタイム実装が登場することは自然なことなのかもしれません。
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がAWS EKSを発表すると同時に、それよりも使いやすいコンテナの実行環境として「AWS Fargate」を発表したのは、さすがによく考えられた戦略に沿ってサービスができているように見えます。
ハイブリッドクラウドもKubernetesになるか？
ではオンプレミスでのKubernetesの展開はどうでしょうか？
もしもオンプレミスでもKubernetesがある程度使われるようになるとすれば、前述のパブリッククラウド同士の連携と同様に、Kubernetesのレイヤでハイブリッドクラウドを構築するための基盤として展開されるものになると考えられます。
ただし、まだオンプレミスでのKubernetesの展開は未知数です。VMwareと関連会社のPivotalが、VMware環境上にKubernetes環境を展開する「Pivotal Container Service」（PKS）を今年の8月に発表していますので、動向を注目したいと思います。
一方、マイクロソフトはWindows上でのKubernetesについて目立った動きを見せていません。しかしWindows ServerでDocker対応を発表したように、おそらく何らかの発表を来年にはしてくるのではないでしょうか。
2018年はコンテナによるソリューションのフェーズへ
Kubernetesにはまだ、仮想ネットワークの構築やコンテナに適したストレージをどうするか、といった課題も残っています。来年にはこうした課題に対するソリューションも安定したものになってくると思われます。
とはいえ、2017年末でコンテナとコンテナオーケストレーションの基盤技術をめぐる競争はおおむね終結したように見えます。
2018年はその基盤を用いてどんな価値のあるソリューションを構築するか、そういう新たなフェーズへと入っていくのではないでしょうか。
カテゴリ Docker / コンテナ / 仮想化
タグ Docker , Kubernetes , コンテナ
おすすめ記事
前の記事
コンテナの軽量さと仮想マシンの堅牢さを兼ね備えた新しいコンテナ実装「Kata Containers」、OpenStack Foundationが発表
Junichi Niino（jniino）
