私はDockerでDockerにさまざまな程度の精通度を持つコミュニティメンバーと話すことに多くの時間を費やしていますが、Dockerを最初に使用したときの人々の自然な反応は、仮想マシンの観点からそれを組み立てようとすることです。 Dockerコンテナが「軽量VM」と表現されているのを聞いた回数は数えられません。
私が最初にDockerを使い始めたときにまったく同じことをしたので、私はそれを手に入れました。 両方のテクノロジーがいくつかの特性を共有しているため、これらの点をつなぐのは簡単です。 どちらも、アプリケーションを実行するための分離された環境を提供するように設計されています。 さらに、どちらの場合も、その環境はホスト間で移動できるバイナリアーティファクトとして表されます。 他にも類似点があるかもしれませんが、私にとってはこれら2つの大きな問題です。
重要なのは、基盤となるアーキテクチャが 2 つの間で根本的に異なることです。 私が使用するアナロジー(あなたが私を知っているなら、あなたは私がアナロジーが好きであることを知っているので)は、家(VM)とアパートの建物(コンテナ)を比較することです。
家(VM)は完全に自己完結型であり、不要なゲストからの保護を提供します。 また、それぞれが独自のインフラストラクチャ(配管、暖房、電気など)を所有しています。 さらに、ほとんどの場合、家はすべて少なくとも寝室、リビングエリア、バスルーム、キッチンを持っています。 私はまだ「スタジオハウス」を見つけたことがありません–最小の家を買ったとしても、それが家が建てられる方法であるため、必要以上に購入してしまう可能性があります。(そこにいる衒学者のために、はい、私は マイクロハウスの新しいトレンド を無視しています、なぜなら彼らは私のアナロジーを破るからです)
アパート(コンテナ)も不要なゲストからの保護を提供しますが、共有インフラストラクチャを中心に構築されています。 アパートの建物(Dockerホスト)は、配管、暖房、電気などを共有しています。さらに、アパートメントは、スタジオからマルチベッドルームのペントハウスまで、あらゆる種類の異なるサイズで提供されています。 必要なものだけを借りています。 最後に、家と同じように、アパートには不要なゲストを防ぐためにロックされる正面玄関があります。
コンテナーでは、Docker ホストの基になるリソースを共有し、アプリケーションの実行にまさに必要なイメージを構築します。 基本から始めて、必要なものを追加します。 VM は反対方向に構築されます。 完全なオペレーティングシステムから始めて、アプリケーションによっては、不要なものを取り除くことができます。
皆さんの多くは「ええ、わかりました。 彼らは違う」 しかし、そう言いながらも、VM に関する現在の考え方やプロセスを適応させ、コンテナーに適用しようとしています。
- 「コンテナをバックアップするにはどうすればよいですか?」
- 「実行中のコンテナのパッチ管理戦略は?」
- 「アプリケーションサーバーはどこで実行されますか?」
私にとって、Dockerは仮想化テクノロジーではなく、アプリケーション配信テクノロジーであることに気付いたとき、電球の瞬間が訪れました。 VM 中心の世界では、抽象化の単位は、アプリケーション コードだけでなく、多くの場合、そのステートフル データを格納するモノリシック VM です。 VMは、物理サーバー上にあったすべてのものを取得し、それを単一のバイナリにパックして移動できるようにします。しかし、それはまだ同じことです。コンテナでは、抽象化はアプリケーションです。または、より正確には、アプリケーションを構成するのに役立つサービス。
コンテナーでは、通常、多くのサービス (それぞれが 1 つのコンテナーとして表されます) がアプリケーションを構成します。 アプリケーションは、はるかに小さなコンポーネントに分解できるようになり、本番環境での管理方法が根本的に置き換えられます。
では、コンテナをどのようにバックアップしますか。 データはコンテナーには存在せず、定義した 1-N コンテナー間で共有される名前付きボリュームに存在します。 データボリュームをバックアップし、コンテナのことは忘れます。 最適には、コンテナーは完全にステートレスで不変です。
確かにパッチは引き続き 世界の一部ですが、実行中のコンテナには適用されません。 実際には、実行中のコンテナーにパッチを適用し、パッチが適用されていないイメージに基づいて新しいコンテナーをスピンアップすると、悪い時間を過ごすことになります。 理想的には、Dockerイメージを更新し、実行中のコンテナを停止して、新しいコンテナを起動します。 コンテナはほんの一瞬でスピンアップできるため、このルートを使用する方がはるかに安価です。
アプリケーションサーバーは、コンテナ内で実行されるサービスに変換されます。 確かに、マイクロサービス ベースのアプリケーションがコンテナー化されていないサービスに接続する必要がある場合もありますが、ほとんどの場合、コードを実行するスタンドアロン サーバーは、はるかに少ないオーバーヘッドで同じ機能を提供する (そしてはるかに優れた水平スケーリングを提供する) 1 つ以上のコンテナーに取って代わられます。
「しかし、VMは伝統的にリフトアンドシフトに関するものでした。 既存のアプリはどうすればよいですか?」
コンテナで巨大なモノリシックアプリを実行する方法をよく聞かれます。 マイクロサービス アーキテクチャに移行するための有効な戦略は多数あり、既存のモノリシック アプリケーションを VM からコンテナーに移動することから始まりますが、これは最終目標ではなく、旅の最初のステップと考える必要があります。
組織で Docker を活用する方法を検討する際には、VM 重視の考え方から離れて、Docker が単なる "軽量 VM" 以上のものであることを理解してみてください。これは、選択したインフラストラクチャ上で高性能でスケーラブルなアプリケーションを提供するためのアプリケーション中心の方法です。
次のリソースを確認して、Docker とコンテナーの詳細について学習を開始してください。
ドッカーについてもっと知る
- ドッカーは初めてですか? 10分間の オンラインチュートリアルをお試しください
- 無料の Docker Hub アカウントでイメージを共有し、ビルドを自動化します
- Docker 1.10 リリースノートを読む
- ドッカーウィークリーを購読する
- 今後の Dockerオンラインミートアップにサインアップする
- 今後の Docker ミートアップに参加する
- DockerCon EU 2015 のビデオを見る
- Docker への貢献を開始する
フィードバック
「コンテナはVMではない」に関する0の考え