文字通り、自分を抑制しましょう。DockerとK8sを長く避けることはできません。

コメント仮想化を発明し、会社を設立し、富を築き、その後ずっと幸せに暮らし、誰からも愛された人たちを覚えていますか？ VMware のストーリーはまさにそれです。しかし、Docker の背後にいる人たちの中には、少し違うストーリーを目にする人もいるかもしれません。

ここ数年、Dockerは私のクライアントにとって非常に重要なテクノロジーです。Dockerを使用すると、コンテナ内でアプリケーションを実行できるため、仮想化とは異なり、はるかに軽量です。

仮想マシンは、独自のオペレーティングシステムインスタンスを実行する完全なコンピュータをシミュレートします。コンピュータのシミュレーションと多数のオペレーティングシステムインスタンスの両方に、膨大な計算能力が必要です。一方、Dockerコンテナは1つのオペレーティングシステムインスタンスのみを共有しますが、独自のネットワークインターフェースとファイルシステムを備えています。

その結果、Dockerは非常に優れたコンテナ分離を実現します。同時に、Dockerコンテナ内のプロセスは、オペレーティングシステム上で直接実行されるプロセスと同程度のリソース消費量しか消費しません。Dockerは仮想化をはるかに凌駕する効率性を実現します。数百ものDockerコンテナをラップトップで実行することも全く問題ありません。

忍び寄る隙間

さらに、Dockerはソフトウェアのインストールという別の問題も解決します。Dockerが登場する以前は、開発者はChefやPuppetなどのツールを使用して、再現性のあるソフトウェアインストールを行う必要がありました。スクリプトはサーバーがとるべき状態を定義します。この状態からツールは必要なインストール手順を導き出します。これはべき等性と呼ばれます。サーバーにソフトウェアが存在しない場合、ツールはソフトウェアを最初からインストールします。古いバージョンがインストールされている場合、またはソフトウェアの一部が既に利用可能な場合は、インストールが完了し、更新されます。しかし、望ましい状態の定義は複雑で時間がかかります。さらに、状態の一部が定義されていないため、ギャップが生じやすいという問題もありました。

一方、Dockerは独自のイメージを使用します。これらのイメージは、ベアサーバーからのインストールの全ステップを含むスクリプトによって作成されます。べき等的なインストールと比較すると、このアプローチははるかに簡単で、ギャップのない完全なインストールを保証します。バックグラウンドでは、イメージは他のイメージの一部を使用します。これによりディスク容量が節約され、新しい部分のみが実際にビルドされるため、新しいイメージの作成は非常に高速です。

Dockerはタイミングの良さから大きな恩恵を受けました。マイクロサービス化のトレンドは、多数のアプリケーションを効率的に運用する必要があることを意味します。低リソース消費と容易なインストールは、まさに絶妙なタイミングで実現しました。そしてもちろん、Dockerは現代の継続的デリバリーパイプラインにおける頻繁なデプロイにも役立ちます。

成功

そのため、昨年末にDockerの終焉を報じた記事（こちら）は、かなり誇張されているように思われます。しかし、この記事が実際に論じているのは、全く異なる点です。つまり、成功した技術が必ずしも発明者にとって商業的な成功を意味するわけではないということです。サン・マイクロシステムズはJavaを発明しました。Javaは一つの産業全体の基盤となった重要な技術ですが、そこから大きな利益を得ることはありませんでした。最終的に、サンは独立性を失い、オラクルに買収されました。

もしかしたら、この運命はDockerの背後にあるDocker Inc.を脅かすものなのかもしれません。Docker自体は単なる基盤に過ぎません。結局のところ、Dockerコンテナを単一のサーバーで実行してもあまり意味がありません。サーバーがクラッシュすれば、すべてのDockerコンテナが機能しなくなります。スケーリングは単一サーバーの性能によって制限されます。そのため、Docker上に構築された他のシステムは、Dockerコンテナをサーバーのクラスタ内で実行できるようにしています。これらのシステムは、負荷分散やフェイルオーバー機能でDockerを補完し、サービス検出など、マイクロサービスに特化した重要な概念を提供します。また、エンタープライズ仮想化に特有の機能を数多く備えています。このようなクラスタコンテナ技術は、Googleのインフラストラクチャの重要な部分であり、要求の厳しい環境でも十分に機能することが実証されています。

Docker社は、Dockerをクラスタ化するソリューションとしてDocker Swarm Modeを提供しています。これはシンプルな選択肢ですが、GoogleやLinux FoundationのKubernetesにはかないません。Kubernetesはより複雑ながらも、包括的なソリューションを提供しているからです。マイクロサービスのランタイム環境として、Kubernetesは現在、デファクトスタンダードになりつつあります。Amazon、Microsoft、Googleなど、主要なクラウドプロバイダーからもサポートされています。Docker社自身も、自社のDockerディストリビューションにKubernetesを組み込む予定です。Docker社はDockerに強い影響力を持っていますが、クラスタ技術に関しては競合他社の製品に切り替えつつあります。KubernetesはGoogleプロジェクトとして始まりましたが、現在はCloud Native Computing Foundationに属し、オープンに開発されています。ユーザーにとって、これは競争の激化とロックインの減少を意味します。

DockerとKubernetesは今や非常に活発に活動しており、マイクロサービスや継続的デリバリーの世界で欠かせない存在となっています。コンテナ技術は、より軽量で、要求の厳しいアプリケーションに求められる複雑なクラスター環境において実績があるため、仮想化のレガシーを凌駕し始めています。さらに、Dockerイメージはソフトウェアのインストールを信頼性と容易さの両方で実現し、従来のインストールツールに代わる優れた選択肢となります。

ソフトウェアのインストールに従来の仮想化やツールに頼り、Dockerをまだ検討していない人は、重要なトレンドを無視しています。Docker社が収益を上げているかどうかは、些細な問題です。®

エバーハルト・ウォルフは、アーキテクトおよびコンサルタントとして15年以上の経験を持ち、ビジネスとテクノロジーの交差点を専門としています。ドイツのinnoQのフェローでもあります。講演者としては国際会議で講演を行い、著者としてはマイクロサービスと継続的デリバリーに関する100以上の記事や書籍を執筆しています。技術的な焦点は、クラウド、継続的デリバリー、DevOps、マイクロサービス、NoSQLなどを含む最新のアーキテクチャにあります。2018年に開催されるContinuous Lifecycle Londonで講演予定です。