Dockerの誕生前の背景
こんにちは、OSSのレキシラジオです。
このポッドキャストでは、エンジニアであるhentekoが、毎週一つのOSSプロジェクトを取り上げて、そのプロジェクトにまつわる歴史を紹介する番組になります。
今週のテーマは、Dockerの歴史についてです。それでは見ていきましょう。
まず、Dockerについてなんですけど、Dockerは当時、.cloudというPaaSプラットフォームアザーサービスのサービスを展開していた.cloudという会社が開発したコンテナの技術です。
このコンテナの技術がどういったことかというと、アプリケーションとその他実行環境をコンテナという箱にまとめて、そのコンテナをどこでも同じように開発実行できるようにした仮想化技術のことです。
現在では有名なサービスのほとんどのサーバー上で利用されているんじゃないかなというぐらい普及しているようなものになっています。
現在ではDockerという名前自体が分離していまして、コア技術にあたる部分に関してはModyという名前になっています。
正確にはDockerという名前はまだ残っていまして、そちらの方はCLIツールとしてコマンド名みたいな形で残っています。
プラスアルファ内部実装としてModyというものがあるというような形になっています。
僕自身Docker自体はバージョン確か0.8ぐらいの頃から買い始めてまして、結構馴染み深いというか、かなり好きな技術になっています。
さてここからはDockerの歴史について見ていけたらなと思うんですけど、その前にですね、Dockerが誕生する前、開発された背景みたいなところを少しだけご紹介させていただければなと思います。
まずですね、Docker誕生前はですね、どのような環境だったかというと、開発者はですね、依存関係にとても悩まされていました。
これがどういうことかというと、アプリケーションを何らか開発する際に、もちろんローカル、自分のパソコンで開発するんですけど、
その開発が終わった後、リリースしようとしてもですね、プロダクションのサーバー上で動かそうとしたら、なかなか動かないというような現象が頻発しました。
その原因としては、プロダクションサーバーでインストールしているライブラリとローカル、自分のパソコンでインストールしているライブラリというのが、
そもそもバージョンが違ったり、そもそもライブラリの種類が違ったりとか、そういったことで動かないということが頻発しました。
この時代の象徴的なフレーズとして、私のマシンでは動いたというような言葉があったりするような形です。
この当時の対策としてはですね、どのようにしていたかというと、ハードウェアの仮想化技術であるVMを使うということが一つだけ、
一つの手段としてありました。ただ、このVMというのは、OS全体を実行するというのに等しい行動をしているので、重大なオーバーヘッドというのが存在しています。
詳しく言うと、リソースの消費が激しくて、起動するのにそもそも何分間もかかるというような形になっていました。
なので、ローカルとプロダクションサーバーで同じ環境で全く同じ動作、同じ依存環境、同じライブラリというような環境を揃えるということがそもそもかなり難しかったということが挙げられます。
さらに他の環境で言うと、技術的なところで言うと、Linuxにおいてはコンテナという技術はそもそも最初からありました。
LXCというものです。Linux Containersというものなんですけど、こちらはどういったものかというと、Linuxカーネルの名前空間、ネームスペース機能と、あとはCグループス、コントロールグループスという機能の組み合わせによって、
単一ホスト上に複数の隔離されたLinuxシステムというのを実行するような技術がありました。
ただし、このLXCに関しては軽量な仮想マシンとして設計されていたので、例えば簡易のアプリケーションというのを開発して、それをパッケージングして配布してプロダクションサーバーで動かすみたいな形で、
今のDockerみたいな形で統一されたワークフローというものはそもそも存在しませんでした。
そして、さらにLXCに関しては高度なスキルを持つシステム管理者が使うような機能だったので、なかなか一般の開発者、アプリケーション層を触るような開発者は触れることがないような技術になっていました。
DotCloudの革新
さて、そんな環境でDockerというのはここから誕生していくんですけど、時は遡って2008年ですね。2008年のフランスパリでDotCloudという企業が設立されました。
こちらのDotCloudという会社はプラットフォームアザーサービス、PaaSと呼ばれるものですね。そういったサービスを提供するような会社だったんですけど、
このプラットフォームアザーサービスというのはどういったものかというと、すごい簡単に言うと、開発者の方がインフラ環境を管理することなく、
PythonやRuby、Javaなどの多様な言語で書かれたアプリケーションというのをデプロイできる環境というのを用意してくれていたサービスでした。
このPaaSプラットフォームアザーサービス、DotCloudというサービス上で多言語サポートを効率的に実現するためにですね、
DotCloudの社内ではLXCをベースとした内部ツールというのが開発されていました、もともと。
このツールというのは何を解決していたかというと、コンテナの複雑さ、LXCによるコンテナの複雑さというのを抽象化したものなんですけど、
これについてですね、2013年にDotCloudの創業者たちが競合にあたるヘロクなどとバチバチ戦っていたんですけど、
その中で苦戦している中でですね、この内部ツールであるLXCをベースにした内部ツールのコンテナエンジン技術部分がですね、
革新的な価値があるということに気づきます。そしてこれらをオープンソース化するということを決断します。
そして2013年の3月20日にですね、サンタクララで開催されたPyConというようなイベントでDotCarという名前で一般公開がされました。
そこでこの最初のデモではですね、コードと依存関係というのを一緒にまとめた形で、
軽量なポータブルなコンテナとしてパッケージング化するということが可能になっていました。
開発者のパソコンとプロダクションのサーバー上でですね、
同一の環境でアプリケーションを動作させるということに成功していました。
さて、そういった形でDotCarというのは誕生したんですけど、
ここからはですね、少しだけDotCarの内部についてお話しできればなと思います。
まずはLXCの依存についてです。
DotCarのバージョン0.9よりか前においてはですね、
主にLXCを内部的に利用した高レベルのラッパーとしてDotCarというのは機能していました。
主にですね、LXCが管理する既存のLinux管理機能というのを利用してDotCarというのが動いていたようなイメージです。
そこでLXCとDotCarの大きな違いとしてはですね、
LXCがシステムコンテナという完全なOS環境に焦点を当てていたのに対して、
DotCarというのはそのさらに上のレイヤーですね、
アプリケーションコンテナという概念を導入したというのが大きな違いがありました。
さらにですね、この時点での革新部分としてDotCarイメージという存在があります。
こちらDotCarイメージというのはUnion File Systemというものを使用した仮想化ファイルシステムとして構成されているものなんですけど、
これによって何が嬉しいのかというと、
DotCarイメージを作る際にですね、変更されていないレイヤーというのを再利用することでビルドを高速化したりとか、
あとは書き込み可能なコンテナレイヤーへの変更のみを保存することでストレージ効率というのを向上させたり、
あとはですね、そのDotCarイメージ自体をインターネット上に公開してプルしたりプッシュしたり、
共有するということができるDotCarHubというようなサービスの存在のおかげで、
中央レジストリからイメージをプッシュプルするということができるような形になり、
ローカルからDotCarHubに対してDotCarイメージをプッシュすることで、
DotCarの進化
プロダクションサーバーなどでプルしてきて、どんな環境でもDotCarイメージを動作させるというようなことが可能になりました。
これらによってですね、DotCarというのはコンテナ技術を開発者が誰でも簡単に使えるようにしたというような点で大きな貢献を果たすことになります。
ただしですね、LXCに依存するという設計がですね、安定性と移植性に対して問題点があるというようなことが現れてきたというのも事実ではあります。
このLXC自体はですね、DotCarの外部のプロジェクトなので、そのアップデートや破壊的な変更というのがDotCarコンテナ自体を破損するようなリスクがありました。
こういったLXCの依存によってですね、DotCarが目指すあらゆる場所で動くというような目標、ビジョンというのが制限されてしまっているというような環境になっていました。
さらに余談なんですけど、2013年にですね、もともとドットクラウドというような会社が開発したDotCarというようなプロダクトだったんですけど、
こちらのドットクラウド社というのがDotCarをリリースしたことによって、DotCar社というような名前に名義変更がされました。
さてここからはですね、LXCからの脱却、依存からの脱却というのをDotCarというのは目指していきます。
LXCから脱却するためにですね、DotCarはバージョン0.9、2014年の参加図にリリースされたんですけど、
においてですね、LXCから自社開発のLibコンテナというものに置き換えます。
こちらのLibコンテナに関しては、Goで開発されたものなんですけど、
DotCarはですね、こちらによってLXCに依存することなく、Linuxカーネルの仮想化機能であるNamespaceやCgroupsなどの機能を直接操作できるようになりました。
これによってDotCarはですね、LXCの開発サイクルや破壊的な変更などに左右されなくなって、
Linux以外の広範なアーキテクチャへのサポートというような道も開かれるような形になりました。
反面ですね、こういった形でどんどん開発というのはDotCar自体の開発での進んでいったんですけど、
2013年から2015年にかけてですね、DotCarの機能というのはどんどん拡大し続けてきました。
単なるコンテナのランタイムとして始まったDotCarなんですけど、そこからさらにどんどん機能が広がり続けて、
イメージのビルドだったり、ボリュームの管理だったり、ネットワークオーケストレーションという機能、スワームという機能ですね。
それらの機能のREST APIをサポートしたり、認証機能などサポートがどんどん増えていきました。
その結果どうなったかというと、すごく巨大なシステムというものに成長していってしまいました。
こうすることで2015年時点ではDotCarの実行場合であるDotCar Daemonというものがあるんですけど、
そちらのDotCar Daemonという場合が巨大なものになってしまったというものがあります。
この影響でですね、DotCar Daemonがクラッシュしてしまうと、実行中のコンテナが全て停止する恐れだったりとか、
あとアップデート中、DotCar Daemonをアップデートする際にはですね、Daemonの再起動が必要になってしまったりだったりとか、
そういった懸念点、DotCar Daemonに集中してしまっているがゆえに起きている問題というものがありました。
これら全てユニックス哲学である一つのことをうまくやるというものに違反していたので起きてしまった問題というものがあります。
またですね、DotCar自体が解決したはずであった依存関係の問題というものがDotCar自体のコードで再現され始めてしまいました。
バージョン1.12でオーケストレーション機能であるSWARMというものがエンジンに含まれることになったんですけど、
そちらがですね、似たような機能として外部で開発されていたKubernetesなどのプレイヤーと競合してしまうというような問題が発生しました。
これによってですね、DotCar自体は使いたいんだけども不要な機能、SWARMだったりとかそういった機能を強制する重いランタイムとして見られるようになってしまいました。
DotCarの進化
そういった形で様々な問題はありつつもDotCar自体の採用というのは急増していきます。
ニーズ自体は確実にあるのでDotCar自体も使いやすいですし、どんどん拡大というのは広がっていきます。
ただここでですね、業界内で競合にあたるCoreOSなどの他社からですね、DotCarが事実上の独自規格になりつつあるというような批判が上がり始めます。
そしてこれに対応するためにですね、DotCar社はGoogleやRed Hatなどの業界リーダーと一緒にOpen Container InitiativeというOCIというような団体を設立します。
これはですね、どんな目的の団体かというと、企業間に中立な仕様を作成するというようなことを目的とした団体です。
具体的にはですね、ランタイムの仕様やイメージの仕様というのをどうするのかというのを決めていくというのを、中立的な立場として決めていくというものを行うような団体になっています。
またですね、DotCar社はですね、LibContainerというような技術を持っていたんですけど、こちらをOCIに寄贈して最終的にはですね、こちらのLibContainerというのはLANシーというスタンダードアナウンスのCLIツールとして再パッケージされて実施されます。
こちらのLANシーというものがOCIが定めたランタイム仕様のリファレンス実装になっています。
こちらのLANシーはですね、具体的にはOCIのランタイム仕様に従ってコンテナを生成し実行するというような単一の機能を持つCLIツールとして動作しています。
こういった形でLANシー自体は切り離されて、実行処理というのを担当することになったので、DotCar社はですね、残りの部分も分割して大規模なリファクタリングというものに着手し始めます。
その結果生まれたのがコンテナーデーモンというものです。
こちらは2015年の12月に発表されているものになります。
コンテナーデーモン自体はですね、LANシーを制御するようなデーモンとして設計されています。
これによってですね、コンテナの監視機能というのがDotCarエンジンから切り離されて独立したデーモンとして動作するような形になりました。
コンテナーデーモン自体はコンテナのライフサイクルとか、イメージの転送、ストレージ管理、実行の監視というような責務を持つことになります。
これによってですね、一つの巨大的なシステムだったDotCarデーモンというものがDotCarエンジンという高レベルなAPIやネットワークなどのCLIツールとして管理できるものと、
コンテナーデーモンというランタイム管理のデーモンと、あとはLANシーというランタイムという3つのレイヤーで分離に成功しました。
これによってですね、DotCarというCLIツールは変えずに、一番下であるLANシーというレイヤーですね、
などをセキュアな別のランタイムに変更するみたいなことが理論上は可能になったというような形になっています。
ちなみにですね、DotCar社はこのコンテナーデーモンというものもクラウドネイティブコンピューティングファウンデーションというCNCFという団体に寄贈しています。
こうすることによってKubernetesなどのプラットフォーム、別のところで開発されたプラットフォームなどで使用されるような業界標準ランタイムにコンテナーデーモンというものはなりました。
ここまででですね、3つのレイヤーに分かれたDotCarなんですけど、ここから様々にどんどん内部的には他のところでも内部的なコンポーネント化というのはどんどん進んでいきました。
そういった形で内部的には進んでいったんですけど、外部から見た時にはですね、DotCarは依然として単一のプラットフォームとして認識されていました。
そこでですね、2017年の4月に開催されたDotCarConにてですね、DotCar社はオープンソース戦略の抜本的な再構築というものを発表します。
それがModyプロジェクトです。
こちらModyプロジェクトなんですけど、目的としてはコンテナシステムをレゴクラブとして再構築するというようなものです。
この発表に伴ってですね、具体的に何が実行されたかというと、GitHubにホスティングされていたDotCarすらDotCarリポジトリというものがModyすらModyリポジトリというような名前に変更されました。
この変更の動機としては、プロダクトとしてのDotCarとオープンソースプロジェクトとしてのModyというような形で明確に区別をしたかったからというものがあります。
DotCar自体は開発者向けのプラットフォームとしてCLIやGUIなどで使いやすさを重視したデフォルト設定で提供するようなツールとして提供する。
さらにModyの方はですね、システムビルダー向けのモジュールツールキットを提供することによって、例えばカスタムしたコンテナシステムを組み立てたいというようなシステムビルダー向けにコンポーネントを提供するというような形で明確に区別するというような目的がありました。
ここのModyのシステムビルダー向けのモジュールツールキットみたいなところが、Modyのそもそものプロジェクトとしての目的であったレゴクラブみたいなところの表現として現れています。
レゴを組み立てるような形でコンテナシステムというのを作れるよというような形を目指したものがModyというものです。
ただですね、この移行というのがですね、GitHubの主要なレポジタリを強制的に移動してしまったためですね、コミュニティに大きな混乱というのをもたらすことになりました。
多くの開発者はですね、Dockerが消滅する、もしくはクローズドソース化されるんじゃないかというような誤解をこの時点でしました。
またですね、今まで親しみがあったクジラの青いロゴですね、というのがなくなってModyというようなシステムビルダー向けのフレームワークに変わったことで、
ちょっとブランドがあやふやになってしまったというのがあります。
ただですね、このようにModyをDockerというプロダクトから切り離して、
Unix、哲学である一つのことをうまくやるという方針でModyは複数のコンポーネントにどんどん分割していたんですけど、
Modyプロジェクトの再構築
それによって得られたことというのはたくさんあります。
Dockerとは別のコンテナエンジンというのが複数あるんですけど、その中でもバレーナエンジンというものがいい例です。
このバレーナエンジンというのは何かというと、IoTデバイス向けに特化したコンテナエンジンになっています。
こちらがどのように実装されているのかというと、
ModyをフォークしてIoT環境では不要なSWARMだったりとか、重いログドライバーなどを除外して、
その代わりに独自開発されたイメージのバイナリサブのみ適用可能なアップデート方式だったりとか、
電源の切断に強い対障害性などのIoT独自の機能を追加する形でコンテナエンジン、バレーナエンジンというものを構築しました。
これができたのはModyがレゴブロックのようにコンテナをコンポーネントとして提供していたから、
実現できたというところが大きくあります。
そういった形でDockerとModyというのは分割されたんですけど、
現在ではModyプロジェクトの混乱は過去のものになりました。
Modyはコアエンジンの開発用のレポジトリとして完全に機能し、
DockerはCLIなどの高レベルなAPIを提供して内部ではModyを操作できるような形になっているというような形で機能しています。
またModyでコンポーネント化したことによって、
例えばコンテナのオーケストレーションにおいては事実上Kubernetesが標準化したかなと思うんですけど、
こちらの機能と被っている機能としてDockerの元々の機能であるSWARMというものがあるんですけど、
そちらの方はModyプロジェクト的には戦略上重要性というのはどんどん低下しているんですが、
それが影響してModyプロジェクトやDockerプロジェクトに何か影響があるかというと、
大きな影響というのは事実上ないんですよね。
これっていうのがKubernetesがそもそもModyプロジェクト由来のコンポーネントを利用していたりとかするので、
実質的にKubernetes自体もModyの派生と言ってしまっても、
Dockerの歴史の総括
語弊はないのかなというところとして機能しているというところが挙げられます。
こういった形でいろんなコンポーネント化したことによって再利用性が高まり、
いろんなプロジェクトで使われているというのが現状のMody、ないしはDockerというような形になっています。
さてここまでですね、Dockerプロジェクトの歴史についてお話をしてきました。
ここで最後にまとめたいと思います。
2013年にですね、ドットクラウドという会社から発表された社内ツールであったDockerというようなツールがあります。
こちらのDockerに関してはコンテナをかなり便利に開発者の方が使えるように再パッケージングしてくれていたので、
その便利さから急速に復旧が始まります。
そして最終的には標準化されるまでになりました。
さらに進化した結果、Modyという名前に現在では変えて、現状でもですね、幅広く利用されているようなツール技術になっています。
さてDockerの歴史についてはここで以上となります。
もし少しでも今回の話がいいねと思ったらお聞きのプラットフォームでの高評価とフォローお願いします。
またXなどでハッシュタグOSSの歴史ラジオで感想などつぶやいてもらえると励みになります。
次回はですね、現代の開発者であればおそらく毎日使っているんじゃないかなと思われるGitの歴史について見ていきたいなと思っております。
それでは次回もよろしくお願いします。バイバイ。
