Dockerプロジェクト10周年！コンテナの10年を振り返る

2023年3月15日は、Solomon HykeがPyConで行った有名なライトニングトークから10周年にあたる日でした。このトークで、彼はDockerを世界に紹介しました。

この10年で何が変わったのかを振り返り、今日のコンテナ化された世界への道を切り開いてきた人たちの話を聞いてみましょう。コンテナやクラウドネイティブの知り合いが詰まった小さな黒い手帳を開き、Dockerとの出会い、そしてMobyとMollyに初めて出会ってからの10年間に現場で経験した興味深いエピソードを共有してもらいました。

Hello wowrld!

PyCon 2013で講演するSolomon Hykes

2013年、Dockerが世界に登場しました。多くの開発者にとって、cgroupsやnamespaceをはじめ、プロセスを「隔離」するために使われるLinuxテクノロジーに触れる初めての機会でした。Dockerの人たちがよく口にするように、彼らはコンテナテクノロジーを「民主化」し、Linuxシステム管理の専門知識がなくても簡単に使えるようにしたのです。

驚きと魔法のような体験

Dockerを初めて使ったときの体験を尋ねると、魔法のよう、衝撃的、「あっ、そういうことか」といった言葉が何度も出てきました。

DockerCon 2015で講演するNirmal Mehta

想像してみてください。2013年、オレゴン州ポートランドで開催されたO'Reilly Open Source Conference。Dockerがオープンソースとして公開されてから数か月後のことで、オープンソース、クラウド、DevOpsなど、さまざまなITコミュニティですでに人気が高まり始めていました。カンファレンス最終日の金曜早朝、私はDockerという新しい技術についてのセッションに参加しました。登壇者はSolomon Hykes。コンテナのレイヤーの概念から話を始め、その機能や基盤となるテクノロジーについて説明しました。そして最後にデモを披露しました。記憶が正しければ、apache/httpdコンテナを5個、10個、15個、20個と、わずか数秒で起動したのです！朝早く、まだ眠気の残る少人数の聴衆にとっても、そして何より私にとっても、衝撃的でした……パラダイムシフトの始まりを目の当たりにしていると感じ、すべてを知りたいと思いました！

Dockerが、分離されたプロセスやコンテナを実現する基盤技術を組み合わせた最初の存在ではないことは知っています。それでも、あの日に示されたユーザー体験は、今日まで変わらず魔法のようです。

- Nirmal Mehta、AWS Principal Specialist SA

Dockerグッズを身に着けて防寒するBrandon Mitchell

Dockerを初めて使ったのは、AnsibleやChefなどのツールでnginxを動かすVMをセットアップした後のことでした。プレイブックを作るのに1時間かけ、起動したVM用に設定し、インストールが実行されるのを待つ。ところが、Dockerコマンドでnginxを起動すると、30秒も経たないうちに、魔法のように隔離された環境でプロセスが動き始めました。その体験をきっかけに、何が起きたのか、Dockerはどう動くのかを知る冒険が始まりました。

- Brandon Mitchell、BoxBoat（IBM傘下）Solutions Architect

Dockerとの出会いは、魔法の力を手に入れたようなものでした。仮想化によってサーバーが置き換わったとき、物理インフラにVMを詰め込んで最大限活用できるようになったのと同じです。Dockerは、さらに夢の階層を降りていくような体験でした。今度はアプリケーションをVMに詰め込み、ハードウェアをもっと有効活用できるようになったのです。

- Adrian Goins、Rancher/SUSE 元Developer Advocate

Andy Clemenko氏、Dockerの初期導入者でフィールドエンジニア

2015年初頭、勤務先から「Docker」のエキスパートになるよう頼まれました。Orangeサイトの投稿を少し見た程度で、ほとんど何も知らなかったので、実際に使ってみることにしました。誰もがそうするように、まずは定番のDocker Hello Worldの例としてNginxを試しました。私にとって「あっ、そういうことか」と腑に落ちた瞬間はすぐに訪れました。長年システム管理者をしていた私には、プロセスの分離が大きな進歩に見えたのです。その日から、キャリアの軸足をコンテナへと移しました。幸運にも、米国政府が複数の機関でコンテナを導入し始めるのを支援できました。1年半後には、Docker社に入社してこの旅を続ける機会にも恵まれました。

- Andy Clemenko、Rancher Government Solutions Field Engineer

最悪のシナリオ

Dockerを最初期から導入したDavid Flanaganは、自社のデプロイを大きく変える可能性にすぐ気づきました。

Rawkode Academy創設者、楽しいパパのDavid Flanagan

Dockerを初めて知ったのは、2013年のSolomonによるPyConのデモでした。当時、私は英国のラジオ・雑誌会社で開発ディレクターを務め、事業を21世紀にふさわしいものにしようと取り組んでいました……そう、デジタルトランスフォーメーションです。最大の課題はスケーリングで、「MotörheadのLemmyが亡くなったら、どう対処する？」という「最悪のシナリオ」まで想定していました。負荷は非常に予測しやすいものでしたが、そうでなくなることもあります。ニュースの発生は予測できません。可能な限り迅速に、リアルタイムでスケールする必要があるのです。

しばらくVagrantとVMを使っていましたが、すばやくスケールさせるのは大変でした。事前に過剰なリソースを確保し、「その出来事」が終わったらコストを抑えるためにすぐ縮小する必要がありました。そんなときにDockerを見て、ひらめいたのです。ただし……当時のDockerには「docker build」がありませんでした……。しかし、それもすぐに登場し、現在も使われている「Build. Ship. Run」というタグラインが掲げられました。Dockerはランタイムの課題を解決しただけではありません。コンテナイメージのビルドを驚くほど簡単にし、さらに配布（Ship）の仕組みまで提供しました。現在どのコンテナランタイムを使っているかにかかわらず、Kubernetesとクラウドネイティブは、初期のdotCloudチームに大きな恩義があります。

- David Flanagan、Rawkode Academy創設者

グリッドの安定化

私もDockerを初期から使っています。少しばかり僭越ながら、私の経験を紹介します。

James SpurinのTwitterスクリーンショット：Kubecon 2022に参加したJames Spurin、Eric Smalling、Bret Fisher、Chad Crowell、Kunal Kushwaha、Ramesh Kumar

2013年後半、私はDockerを使い始めました。大規模なeコマースWebアプリケーションの各コミットに対して、何百もの機能テストやエンドツーエンドテストを実行するCIパイプラインで活用していました。ピーク時には、VMベースのSelenium2 Gridsを介して2,000を超えるブラウザーインスタンスを稼働させることもあり、グリッドの安定性の問題による不安定なテスト結果に悩まされていました。クラウド上でインスタンスを頻繁に起動・停止し、起動時間の短縮、安定性の維持、コストの最小化に向けて、長年にわたりさまざまな方法を試しました。スポットインスタンスも試し、複数のリージョンで入札合戦まで繰り広げたほどです！

WebアプリとテストスイートのコントローラーにはすでにDockerを使っていましたが、私にとってのひらめきは、ブラウザーとxvfbを含むイメージを作成してすぐに起動できると気づいた瞬間でした。これにより、1つのノードに収まるだけのブラウザーを載せた、安定したSeleniumグリッドを実行できるようになりました！（グリッドが不安定になる主な原因は、1つのノードで多くのブラウザーをスケールできないことでした。そのため、少数のブラウザーを載せた小さなノードを多数用意する必要がありました。）この方法は大成功し、クラウドベースのインスタンスをほぼ廃止して、グリッドには少数のローカルVMだけを使うようになりました。週に数千ドルものコスト削減につながりました。

- Eric Smalling、Snyk Sr. Developer Advocate

幅広い導入を促す

エンタープライズソフトウェア開発に携わり始めたばかりの人には、コンテナやその周辺で発展したエコシステムの利点は当然のことに思えるかもしれません。しかし、最初の5、6年間、Dockerの将来は決して確かなものではありませんでした。

成果がすべてを物語る

変化は人にとって難しいものですが、Dockerの目に見えるメリットは、導入を後押ししました。

私は新しい魅力的な技術を持ち込むことが多かったので、「Daveがまた新しいおもちゃを持ってきた」というあきれた空気がいつもありました。チームの大半がMacユーザーだったので、間違いなく嫌がられていました！

しかし、当時のDockerは主にサーバーサイドで使っていて、boot2dockerもまだありませんでした。そのため、開発にはVagrantを使い続け、Dockerはその後、導入のメリットが明らかになった段階で取り入れました。チームはデプロイパイプラインが簡素化されるのを実感し、納得してくれました。

デプロイに40分かかっていたのが約3分になったのですから、反対するのは難しかったですね！

- David Flanagan

Sevi Karakulaが変革を起こす！

Dockerに初めて触れた頃、私はソフトウェア開発者として十分な経験を積んでいて、新しいメンバーが必要なツールをすべて使えるようになるまで、どれほど大変かを知っていました。また、開発環境に新しいフレームワークや言語を導入し、全体を少しでも軽量化しようとするたびに、開発者の多くはうんざりした顔をするため、骨が折れることも経験していました。

Dockerは、チームに教える必要があるのが魔法のようなツールひとつだけで、その複雑なインストールや設定を扱わなくても、すぐにメリットを実感できたため、私たちの仕事を大きく楽にしてくれました。開発者が解放されたと感じる、大きな転機でした。厳しく管理されたマシンにツールを一つひとつインストールせずに済み、承認申請の返事を待つ必要も、ライセンスを気にする必要もありません。イメージさえあれば、すぐに使えました。

- Sevi Karakulak、Container Solutions Engineering Lead

「エンタープライズ対応」ではない

「エンタープライズ対応」という言葉の意味は主観的で、企業によって異なります。DockerのSolutions EngineerだったMatt Bentleyが初期のDockerの「魅力」について、そして実際には魅力的ではなかった理由について語ります。

DockerCon 2019でのMatt Bentley

……顧客はDockerというテクノロジーを気に入り、Docker Trusted Registry製品も気に入っていました。しかし、APIとコマンドラインだけではない何かを用意するまでは、経営陣にエンタープライズ対応だと認めてもらえないと言われました。

社内で製品のデモを見せるプロセスがありました。Jenkinsで構築したCI/CDパイプラインを使い、コードを取得してコンテナ内でビルド・テストし、デプロイしてイメージを昇格させるという私のデモを見せても、理解してもらえなかったでしょう。エンタープライズ対応のソリューションには、見栄えのよいユーザーインターフェースが必要だったのです。

- Matt Bentley、VMware Manager, Solutions Engineering

よく聞かれたもう一つの懸念は、プロジェクトがまだ成熟していないということでした。基盤となるテクノロジーは何年も前から存在していたものの、スタートアップから生まれたオープンソースプロジェクトに運命を託すこと、しかも漫画のマスコットやペットのカメがデプロイをするようなプロジェクトを選ぶのは、多くの企業にとってハードルが高すぎました。

KubeCon EU 2022でのRachel LeekenとEric Smalling

2015年にDockerについて学び始め、その可能性を感じた私は、当時使っていた古くて高価なベンダー製ソリューションの代わりに、モダナイゼーションの候補として検討する価値があると提案しました。しかし顧客は採用しませんでした。コンテナテクノロジーに確信が持てず、契約期間の5年間、存続しているかどうかも分からないと言われたのです。

- Rachel LeeKin、AWS Containers Specialist SA

自ら招いた問題

チームにコンテナを導入してもらうことより、正しく使えるよう指導することのほうが難しい場合もありました。

Adrian Goinsと、彼のパラモータークアッド「Iron Condor」

当初、クライアントを説得するのは大変でした……導入した人たちも、必ずしもメリットやコンテナの活用方法を理解していたわけではありません。あるクライアントは、コンテナにシェルで入ってアプリケーションや依存関係を再コンパイルし、コードリポジトリのようにコンテナをコミットしていました。運用中のコンテナは巨大で、おそらくコンテナ化前のインフラよりも壊れやすい状態でした。

- Adrian Goins

関心が高まる

年月が経つにつれ、コンテナがもたらす可能性に気づく人が増えていきました。オーケストレーターの成熟もその後押しとなりましたが、オーケストレーターならではの課題もありました。Adrian Mouat（@adrianmouat | @adrianmouat@hachyderm.io）は、著者であり、Docker Captainの草創期からのメンバーでもあります。初期のDockerConカンファレンスの様子や、より多くの人がコンテナを試し始め、企業がニーズに応えるソリューションを提供し始めた頃の活気あふれる動きを振り返ります。

KubeCon NA 2022でBetty Junod、Eric Smalling、Matt Jarvisと写るAdrian Mouat

今でもよく覚えているのは、2014年に登壇者が（私も含めて）「Dockerを使っている人は？」と尋ねると、手が一斉に上がったことです。「本番環境でDockerを使っている人は？」と聞くと、ほぼ全員の手が下がりました。

とはいえ、Dockerが1.0になり、本番環境での利用に対応したと宣言される前（2014年10月）から、本番環境でDockerを使っていた人の数は驚くほどでした。

「自分のマシンでは動くのに」という問題を解決するものとして、船舶にたとえた表現をよく使っていました。残念ながら、k8sが登場して同じ問題が再び起きました。

Container Solutionsにいた頃、NEMO Science Centerで初開催となるDocker Con EUの運営を支援しました。会場の熱気はすさまじく、誰もが大きな何かの始まりに立ち会っていると感じていました。CoreOS（Rocketを発表！）や、Weaveネットワーキングを推進するAlexis Richardson、ClusterHQとflockerデータマネージャーを率いるLuke Marsden、Giant Swarmで素晴らしい取り組みをしていたTimo Derstappenも参加していました。大企業の人々も大勢集まり、いったい何が起きているのかを理解しようとしていました。

- Adrian Mouat、Chainguard プロダクトマネージャー

Bret FisherがDockerCon 18 Europeで「Tip of the Captains Hat」を受賞

SolomonのPyCon 2013での講演を見て、2014年にNode.jsのテストを改善しようとdockerを試しましたが、まったく理解できませんでした。サーバー全体をコンテナイメージに詰め込もうとしては失敗し、ネットワーキングはまるで魔術のように思えました。自動化の新しい仕組みや概念があまりにも多く、いったん諦めて、半年後に再び取り組みました。今度は腑に落ち、衝撃を受けました。イメージをビルドし、レジストリに保存し、そこからコンテナを実行するという三段階の流れに心を奪われ、それ以来、振り返ることはありませんでした。

- Bret Fisher、DevOpsの専門家、Docker Masteryの制作者

オーケストレーター

PyCon 2013でのDockerの発表が火花となって火をつけたのだとすれば、コンテナオーケストレーションプラットフォームの登場は、森に燃え広がる炎をあおる風でした。Mesosphere、Rancher、Swarm、Nomad、Kubernetesは、コンテナを一気に普及させた「キラーアプリ」でした。それぞれのプラットフォームの長所と短所については数え切れないほど語られてきましたが、コンテナの大規模な普及において、これらが果たした役割はいくら強調してもしすぎることはありません。

現在はKubernetesが主流のプラットフォームですが、Swarmを使い続ける熱心なコミュニティがあり、Nomadにも根強い人気があります。MesosはDockerよりも前から存在しており、今でもかなりの数のユーザーがいることでしょう。Kubernetesは複雑すぎると感じる人もいましたが、市場シェアが示すとおり、ほとんどの人が採用するようになりました。

Kubernetesが登場したとき、私は嫌いでした。大きなメリットがない抽象化レイヤーがまた一つ増えた、と思ったのです……そのメリットが明らかになるまでは。それからは大好きになりました。サーバーとそのVM、コンテナを使って、小さなデータセンターを作れるようになったからです。24時間365日、システムを見守るプロセスがあったおかげで、私は別のことに取り組めるようになりました。

- Adrian Goins

現在、コンテナをデプロイするための事実上の標準となっているKubernetesですが、この分野の進化や、その周囲に数多くの抽象化レイヤーが生まれていることは興味深いものです。

大規模なコンテナ導入にオーケストレーターが不可欠だと明らかになったとき、私は複数の主要なオーケストレーターが共存できると考えていました。それぞれが独自の強みを持ち、最適なユースケースがあると思っていたのです。Swarmの素晴らしいところは、シンプルなdocker runコマンドを理解している人や、わかりやすいDocker Composeファイルを作れる人なら、数分でSwarmサービスをデプロイできることでした。Docker CLIやDocker Composeのようなツールは、そのシンプルさが見事でした。どちらかを使って単一ホストでコンテナを動かせる人なら、コンテナのオーケストレーションを始めるのも簡単でした。今、業界ではKubernetesを開発者から見えないように抽象化する取り組みが進んでいます。オーケストレーションに注力しすぎるあまり、開発者が開発に集中できなくなっていたからです。開発者がオーケストレーションに費やす時間が増えれば、取り組んでいるアプリを通じてビジネス価値を届けることに集中できる時間は減ります。

- Matt Bentley

キャリアと人生を変えたもの

Dockerの旧SFOオフィスにいたクジラのMoby

この記事のために話を聞いた人たちに共通していたのは、Dockerプロジェクトとその周りに育まれたコミュニティが、多くの人のキャリアや、さらには生計までも変えてきたということでした。

これはインフラの次なる進化だと確信しました。夢中になり、キャリアのすべてをコンテナに捧げました。

- Bret Fisher

あの日を境に、キャリアのすべてをコンテナに注ぐようになりました……今もなお、米国政府のコンテナ活用を支援し、導いていくことに取り組んでいます。これほど変革をもたらすテクノロジーが10年続いているのは、本当に素晴らしいことです。

- Andy Clemenko

学べば学ぶほど、コンテナ化がもたらす可能性に夢中になりました。やがてDockerを教えるようになり、キャリアの方向をコンテナ、そしてKubernetesへと転換することにしました。今振り返ると、Dockerが人生を変えたと胸を張って言えます。

- Sevi Karakulak

Snykはオープンソースを大切にしています

Dockerプロジェクトが10年にわたって変革をもたらしてきたことに、心から敬意を表します。ここで紹介した方々の力強い証言に加え、世界中で日々コンテナを使ってビルド、出荷、実行を行う何百万人もの開発者が、その成果を物語っています。

Snykは2015年、開発者が安全にコードを書き、オープンソースソフトウェアを利用できるよう支援することを目指して設立されました。そこには、ソフトウェアを動かすコンテナも含まれます。オープンソース開発モデルの力と重要性を強く信じているため、Snykは創業当初から、個人の開発者にスキャンツールを無料で提供しています。

クレジット

この記事に協力してくださった皆さん、ありがとうございました！