コンテナの世界の愛と憎しみ

著者 |ルー・アイフェイ

Docker は過去 2 年間、論争に満ちてきました。たとえば、昨年末、K8s は Docker をサポートしないことを発表しました。ニュースが報道されるとすぐに、誰もが急いで Docker の代替案について議論しました。 Colima は Docker Desktop の人気のあるオープン代替品として、また Podman は Docker の代替品として、多くの開発者や企業から注目を集めています。今年、Docker社は中規模および大規模のエンタープライズユーザーに対してDocker Desktopの料金を請求すると発表し、「さようならDocker」の声が再び高まりました。

技術的なリーダーシップや収益性など、あらゆる面で Docker は遅れをとり始めています。かつて支配的だったコンテナ輸送の巨人に何が起こったのか、と問わずにはいられない。

コンテナの台頭

数年前まで、Docker について言及すると、人々はそれをコンテナ テクノロジーと同一視していました。 Docker がコンテナ技術の変革を主導した輝かしい時代は、今でも興奮を呼び起こします。 2013 年、Cloud Foundry はクラウド サービス分野の絶対的な焦点でした。 Cloud Foundry を中心とした PaaS プラットフォームのサービス機能の変革が、クラウド サービス分野全体を席巻しました。同時に、Salesforce Heroku、IBM Red Hat など、数多くの優れた PaaS プラットフォームが登場しました。その 1 つである dotCloud も、この PaaS ブームの一翼を担っています。しかし、当時の Cloud Foundry プロジェクトでは、コンテナは最も基本的な部分であり、あまり重視されていなかったため、dotCloud の製品は無視されていました。この受動的な状況を変えるために、dotCloud は独自のコンテナ プロジェクト Docker をオープンソース化することを決定しました。

わずか数か月で、Docker プロジェクトは急速に成長し、すぐに Cloud Foundry による PaaS プラットフォームの定義方法を覆しました。では、Cloud Foundry と比較した Docker の決定的な利点は何でしょうか?

これは Cloud Foundry のアプリケーション ホスティングから始まります。 Cloud Foundry のコア コンポーネントは、アプリケーションのパッケージ化と配布のメカニズムです。ユーザーは、コマンドを実行するだけで、ワンクリックでアプリケーションをクラウドに公開できます。このような機能をサポートするために、Cloud Foundry は実際にさまざまな言語やフレームワークごとに異なるパッケージャー (BuildPack) を公開し、ローカルの実行可能アプリケーションをパッケージ化して Cloud Foundry にアップロードします。 Cloud Foundry は、適切なエージェントをスケジュールしてアプリケーションをダウンロードし、デプロイメントを完了します。エージェント上のサービスが互いに分離されていることを保証するために、Cloud Foundry は Cgroup と Namespace を通じてアプリケーションに分離された「サンドボックス」オペレーティング環境を提供します。

Cloud Foundry と Docker を比較した後、Cloud Foundry の最高製品マネージャーは、Docker にはブラックテクノロジーは存在しないとも述べました。 Cloud Foundry と同様に、Cgroup と Namespace を利用して「サンドボックス」オペレーティング環境を作成します。

では、Docker が Cloud Foundry よりも優れている点は何でしょうか?その答えは、ミラーリングという特殊なアプリケーションパッケージング方法にあります。

一般的なアプリケーションの動作環境には、コード、依存関係、およびオペレーティング システムが含まれます。 Cloud Foundry はコードと依存関係の一貫性を確保できますが、システム環境を保証することはできません。そのため、アプリケーションはローカルでは正常に実行されるが、クラウドでは実行されない場合があります。問題が発生した場合、システム環境の違いを特定することが困難です。しかし、Docker は、イメージを通じて Rootfs を構築することでこの問題を解決し、ローカルとクラウドのオペレーティング環境の一貫性を完全に保証します。

これを基に、Docker はイメージを作成するための使いやすい Docker CLI も提供し、イメージを素早く配布して同性の友達を作るための Docker Hub も提供しています。 Docker の急速な成功を受けて、dotCloud も名前を Docker に変更し、Docker はコンテナ技術の代弁者となりました。

コンテナクラウド戦争

アプリケーションのパッケージ化の問題を解決するだけでは価値がありません。企業が本当に解決する必要があるのは、アプリケーションの展開の問題です。 Docker は、コンテナ プラットフォームの機能が成功の鍵であることを認識しています。 2014 年に Docker はすぐに Swarm プロジェクトをリリースしました。このプロジェクトでは、Docker の使いやすいコマンド スタイルが維持されており、わずか数個のコマンドで複数マシンのクラスター展開を完了できます。これを基に、同社はFigプロジェクト（後にComposeに改名）やコンテナグリッドを担当するSocketPlaneを買収するなど、新たな戦力の獲得を続け、プラットフォーム機能を充実させていった。現時点では、Docker がコンテナを完全に制御しており、Docker のプラットフォーム戦略は、Google や Red Hat などの企業を含む他のクラウド サービス プラットフォームの重要な利益に実際に挑戦しています。

Docker が市場で唯一の企業となっている状況を変えるために、Docker、Google、RedHat などの企業が共同で OCI (Open Container Initiative) を設立しました。これは、イメージとコンテナのランタイム標準を定義し、その標準を Docker プロジェクトの実装から分離することを目的としています。当然のことながら、Docker は自社の影響力を損なうプロジェクトにエネルギーを費やすつもりはないため、OCI 仕様の進展はゆっくりとしたものになっています。

しかし、Google と RedHat は黙って見過ごすことはなく、その後、最終兵器である Kubernetes を発表しました。両者は力を合わせてCNCF Foundationを設立し、Kubernetesプロジェクトをベースにオープンソースインフラベンダー主導のプラットフォームレベルのコミュニティを立ち上げ、Dockerを中心としたコンテナビジネスエコシステムに対抗する独立した財団として運営してきました。 Kubernetes は、その強力な設計と Red Hat の優れたコミュニティ運営により、独自のコンテナ オーケストレーションおよび管理エコシステムを急速に生み出し、Prometheus や Istio などの数多くの優れたオープンソース製品を生み出しました。 Kubernetes がもたらす課題に対処するために、Docker の主な戦略は Docker Native であり、既存の Swarm プロジェクトを放棄し、すべてのコンテナ オーケストレーションとクラスター管理機能を Docker プロジェクトに統合します。これは将来に潜在的な危険をもたらします。尻尾を取り除くのは困難です。

それでも、Docker は成長する Kubernetes コミュニティと競争することができず、最終的には失敗に終わりました。 Docker はコンテナ ランタイム runc プロジェクトを CNCF コミュニティに寄贈し、Docker プロジェクトの名前を Moby に変更して、コミュニティに引き渡して自己メンテナンスできるようにしました。 Docker は登録商標 Docker を取得し、Docker の顧客を自社の手に移し、完全に独自の商業活動を開始しました。

Docker のジレンマ

コンテナ クラウドをめぐる戦いは Docker の失敗で終わりました。クラウド プラットフォームの優位性を失った後、Docker には利益となるポイントがほとんど残っていませんでした。

• ソフトウェアの支払い
• プライベートハブ
• コンテナクラウドプラットフォーム
• 専門的な技術サポートとトレーニング

コンテナ クラウド プラットフォームの市場シェアが低いため、収益が限られています。 Docker は収益性を確保するために、Docker Hub と Docker Desktop を有料化するというビジネス上の決定を発表しましたが、これは喉の渇きを癒すために毒を飲むようなものです。技術的な観点から見ると、Kubernetes はコンテナ オーケストレーションの事実上の標準となっており、コンテナは全体の最も基本的な部分にすぎません。

OCI の仕様が形になり始めており、同様のコンテナ ランタイムである containerd が Docker に取って代わり、ほとんどのマネージド Kubernetes サービスで使用されるコンテナ ランタイムになりました。もう一度Docker Hubについてお話しましょう。基本的に、成熟したクラウド プラットフォームはすべて、Amazon Elastic Container Registry (ECR) などの独自のコンテナ レジストリをリリースしています。プライベート ハブの課金方法はまだ非常に脆弱です。

設計コンセプトが異なるため、Docker は Kubernetes では必須ではない、ユーザーフレンドリーなエクスペリエンスを確保するために多くのコンポーネントを追加します。また、Kubernetes の CRI 仕様には対応していません。下の図からわかるように、コミュニティは Kubernetes Node と Docker をつなぐ Docker Shim プロジェクトを維持する必要があります。当初、Docker エコシステムに統合するために、Kubernetes は当然この一連のプロジェクトを維持する意向がありましたが、OCI、CRI の仕様と製品が成熟するにつれて、コミュニティはプロジェクトを継続して維持する意欲を失いました。

(画像出典: Kubernetes は Docker サポートを削除しています、Kubernetes は Docker サポートを削除していません)

コンテナ オーケストレーションの立場を失ったことで、コンテナ標準に関する発言権は徐々に弱まってきています。喉の渇きを癒すために毒を飲むような課金ビジネス モデルと相まって、Docker は優れたユーザー エクスペリエンスに頼るだけで本当にすべてのユーザーを引き留めることができるのでしょうか?リアン・ポーは年老いているのに、まだ食べられるのだろうかと疑問に思わざるを得ない。