Docker が生まれるまでの課題と背景とは ?
スペシャリストから学ぶコンテナ技術 第 2 回
Author : 原田 和則 / 林 政利
こんにちは、テクニカルソリューションアーキテクトの原田です。
「スペシャリストから学ぶコンテナ技術 第 1 回」では、環境差分をなくすための手段の 1 つとして、アプリケーションの構成要素のうち、アプリケーションコード、ランタイム、ライブラリなどの依存物をパッケージングして、隔離された環境で実行するコンテナならびにコンテナ技術について紹介しました。
今回は、コンテナ実装のソフトウェアとしてデファクトスタンダードになっている Docker について、取り上げたいと思います。
前回に続き、コンテナスペシャリスト ソリューションアーキテクトの 林さん (@literalice) を招いてインタビュー形式で進めていきます。それではお楽しみください 。
「スペシャリストから学ぶコンテナ技術」の連載記事はこちら
- 選択
- スペシャリストから学ぶコンテナ技術 第 1 回
- Docker が生まれるまでの課題と背景とは ?
- コンテナイメージを実際に作成してみよう !
- コンテナイメージを運んで、別環境で起動してみよう !
Docker が生まれた背景とは ?
原田「今回は、Docker についてですね。よろしくお願いします。」
林「はい、よろしくお願いします。」
(写真左) 原田 和則 テクニカルソリューションアーキテクト
(写真右) 林 政利 コンテナスペシャリスト ソリューションアーキテクト
原田「前回の話で、Docker はコンテナ技術を実装するソフトウェアの 1 つ。というところまで分かったのですが、そもそも Docker はどういう背景で生まれたのでしょうか ?」
林「そうですね。説明がやや長くなってしまうので、今回は、読者の方が飽きないように例え話を使って説明させてください。」
アプリケーションホスティングサービス始めてみる ?
林「唐突ですが、約 10 年前に、原田さんがとある IT サービスを始めようとしたとします。そうですね、例えば、そのサービスは、ユーザーがアプリケーションコードを用意、そして、それをアップロードするだけで、裏側で自動的にアプリケーションの実行環境を用意してくれて、アプリケーションをデプロイ・ホスティングしてくれるサービスだったとします。今でこそ、こういったサービスはよく聞きますが、10 年前なので、原田さんはそこにビジネスチャンスを感じたわけです。」
原田「10 年前の私がビジネスを始めるなんて想像できないですが、とりあえず続きを聞かせてください (笑)」
林「アプリケーションコードを用意するだけで、アプリケーションが動くことは当然ありえないので、足りない部分をサービス側がユーザーの代わりに用意する必要があります。ユーザーのアプリケーションを動かすために、少なくともサービス側は何を用意しないといけないでしょうか ?」
原田「前回の話を踏まえると、アプリケーションの構成要素は、『アプリケーションコード、ランタイム、ライブラリなどの依存物、設定値』です。このサービスの場合は、アプリケーションコードと設定値はユーザーが用意するので、『ランタイムとライブラリなどの依存物』をサービス側で用意しないといけません。」
林「はい、そうです。加えて、Web アプリケーションは何らかのフレームワークを使って開発されることが多いです。一例ですが、Ruby だと Ruby on Rails だったり、Node.js だと Express だったりですね。つまり、場合によっては、フレームワーク自体も用意してあげないといけません。」
原田「なるほど。ユーザーアプリケーションが動くには、少なくとも、ランタイム・ライブラリ・(必要に応じて) フレームワークを私 (サービス側) は用意しないといけない。そして、ランタイムは Ruby や Node.js のように言語を分けるだけではダメで、Node.js v13 と v14 のように同じランタイムでも複数のバージョンを用意しないといけない。同様に、ライブラリにもバージョンがある。更には、フレームワークにも 例えば Ruby だと Sinatra と Ruby on Rails のように、同じ言語でも複数のフレームワークがある。そして、もちろん、各フレームワークにもバージョンがある。」
原田「そして、これらのバージョンが、アプリケーションの開発環境とデプロイ先ですべて揃っていないと、前回の話のように、アプリケーションの動作に問題が発生する可能性があると。・・・うーん、これはちょっと大変そうですね。10 年前の私なら、このビジネス、諦めちゃいそうです。」
環境差異のため本番だけアプリケーションが動かない例
(詳細は 第一回 に記載しています)
アプリケーションホスティングは大変
林「ここで諦めちゃうと話が続かないので、諦めないでください (笑) ほら、ユーザーにアプリケーションコードだけでなく、各ランタイムやフレームワークの種類やバージョンなどが記載された設定ファイルも用意してもらって、それもアップロードしてもらう。そして、サービス側はそれを読み取って、その都度、自動的に環境構築・デプロイをする仕組みを作れば、なんとなく動くものはできそうじゃないですか ? もちろん、使い勝手、スケーラビリティ、セキュリティといった乗り越えないといけない壁はたくさんありますが、それはひとまずおいておきましょう。」
原田「なるほど、それだとまだ諦めなくて済みそうですね。」
林「この方法は、大雑把に言うと、予めサービス側で、ランタイムとそのバージョン、フレームワークとそのバージョンなどの組み合わせを用意しておいて、その中だったら、アプリケーションコードをアップロードするだけで、デプロイできますよというものですね。」
原田「なるほど、ユーザー側から見ると、使用できるランタイムやフレームワークの種類やバージョンが増えれば増えるほど便利になりますね。ただ、サービス側からみると新しいバージョンを導入するたびに全パターンのテストをしたり、問題があれば修正したり、結構大変そうですね。」
林「そうですね。ただ、ユーザーの利便性を考えるとある程度は必要な対応かもしれないですね。ただ、組み合わせをいくら事前に増やしても、対応できない、つまり、動作しないアプリケーションも実はあります。」
原田「ほう、それはどういったアプリケーションでしょうか ?」
林「一番分かりやすい例が、自社のみで使っている独自のフレームワークを使ったアプリケーションですね。例えば、アプリケーションの動作環境を指定する設定ファイルに『このアプリケーションのランタイムは「Ruby 2.7.3」 です。ただし、「林スペシャル v1 」というフレームワークで動きます』と書かれていても、サービス側はその『林スペシャル v1』フレームワークのインストール方法や起動方法といった詳細は一切知らないので、そのフレームワークに依存したアプリケーションは当然動きません。」
林「もちろん、『林スペシャル v1』のセットアップ方法等が公開され、サービス側のラインナップに加われば、デプロイできるようにはなりますが、1 社でしか使われていないフレームワークをサービスラインナップに加えるのはビジネス判断としてはかなり厳しいのではないでしょうか。」
原田「そうですね、私はやりたくないですね。というより、そもそもそのフレームワーク名、どうにかなりませんか ?」
林「独自フレームワークの例は、かなり極端な例ですが、『リリースされたばかりのランタイムやバージョンを使いたい』とか『マイナーなフレームワークだけど、自社のアプリケーション開発には絶対にこれが必要なんです』とか、つまり、ユーザー独自のアプリケーションにどう対応するかという課題が絶対に出てきます。原田さんだったらどう対応しますか ?」
原田「(華麗にフレームワーク名はスルーされてしまった・・・) そうですね、10 年前の私なら、『できるだけラインナップに追加する仕組みや体制を作る』『イレギュラーなユースケースには基本的には対応しない』『そもそもこのビジネスを諦める』のどれかがぱっと思いつきますね。」
林「はい、普通はそうなりますよね。」
dotCloud 社とは ?
林「実は、約 10 年前に、実際にこの課題に直面した企業がありました。それが、 dotCloud 社 (現 Docker 社) です。dotCloud 社は、当時、アプリケーションホスティングサービスを展開しており、コンテナ技術を実装するソフトウェア (後に Docker という名前で OSS として公開) を開発し、コンテナ技術を使うことで『ユーザー独自のアプリケーション対応』という課題を解決しました。」
林「具体的に言うと、ユーザーは、自身の環境で、そのソフトウェアを使って、アプリケーションコード、ランタイム、ライブラリなどの依存物、フレームワークなどアプリケーションが動作するのに必要な環境をまるっと事前にパッケージングして、アップロードします。その後のアプリケーションのデプロイやホスティングなどは、dotCloud 社のサービスが担保しますよといったものです」
Docker 登場
原田「なるほど、ユーザーはアプリケーションのパッケージング (イメージ作成) を自分で行いさえすれば、あとのアプリケーションの実行はサービスが行ってくれる。アプリケーションの動作環境がまるっとパッケージングされているので、環境差異は発生しない。そして、ユーザー側はアプリケーションの動作環境をパッケージングする責務、サービス側はパッケージングされたアプリケーションを動作させる責務といったように、それぞれ責務が明確に別れているので、互いにとっても便利そうですね。」
林「そして、このソフトウェアは 2013 年 3 月に Docker という名前でオープンソースとして公開され、dotCloud 社のサービス以外、つまり、どんな環境でも、アプリケーションのパッケージング・イメージ作成 (docker build)、イメージの運搬 (docker push/pull)、そして、アプリケーションの実行 (docker run) ができるようになりました。ちなみに、同年に dotCloud 社は Docker に社名を変更しています。なので、資料によっては、Docker は Docker 社が開発したと書いてあったり、dotCloud 社が開発したと書いてあったりします。」
原田「なるほど、これが Docker が生まれた経緯なんですね。つまり、もともとは dotCloud 社が自社サービスの課題を解決するために開発したコンテナ技術の実装ソフトウェアで、それがオープンソースとしてどこでも動作する形で公開されたのが Docker ということですね。」
林「はい。前回お話したとおり、コンテナ技術自体は昔からありました。しかし、Docker の登場によって、どんなアプリケーションでも、パッケージングしてイメージを作成する。そして、作成したイメージを実行環境まで運搬する。そして、イメージからコンテナを立ち上げることで、どんな動作環境でも一貫性を持ってアプリケーションを実行できるようになりました。そして、そのライフサイクルが docker コマンドというシンプルなインターフェースで実現できた点、そして、それが開発のフィードバックループを高速に回すために役立つと期待された点が、特に開発者に響き、Docker は爆発的に広がりました。そして、現在では、コンテナ実装のソフトウェアとしてデファクトスタンダードになっています。」
原田「なるほど、よく分かりました。この 7 月号では、Docker が生まれた背景について伺いました。来月の 8 月号では、実際に Docker を使って、実際に簡単なアプリケーションを動かしながら、技術的な詳細について伺い、このインタビュー連載は終わりにしたいと思います。」
「スペシャリストから学ぶコンテナ技術」の連載記事はこちら
- 選択
- スペシャリストから学ぶコンテナ技術 第 1 回
- Docker が生まれるまでの課題と背景とは ?
- コンテナイメージを実際に作成してみよう !
- コンテナイメージを運んで、別環境で起動してみよう !
筆者プロフィール
原田 和則
アマゾン ウェブ サービス ジャパン合同会社
テクニカルソリューションアーキテクト
インフラエンジニアとして経験を積む中で、クラウドに携わりたい想いで AWS へ。
業種業態、技術領域を問わず、様々なお客様の AWS 活用支援を行っています。
林 政利 (@literalice)
アマゾン ウェブ サービス ジャパン合同会社
コンテナスペシャリスト ソリューションアーキテクト
フリーランスや Web 系企業で業務システムや Web サービスの開発、インフラ運用に従事。近年はベンダーでコンテナ技術の普及に努めており、現在、AWS Japan で Amazon ECS や Amazon EKS でのコンテナ運用や開発プロセス構築を中心にソリューションアーキテクトとして活動中。
AWS を無料でお試しいただけます