Docker の詳細なイラスト

1. Dockerの紹介

1.1 仮想化

1.1.1 仮想化とは何ですか?

コンピュータにおける仮想化とは、サーバー、ネットワーク、メモリ、ストレージなど、コンピュータのさまざまな物理リソースを抽象化および変換し、物理構造間の切り離せない障壁を打ち破り、ユーザーが元の構成よりも優れた方法でこれらのリソースを使用できるようにするリソース管理テクノロジです。これらの新しい仮想リソース部分は、既存のリソースが地理的または物理的に展開される方法によって制約されません。一般的に、仮想化されたリソースにはコンピューティング能力とデータ ストレージが含まれます。

実際の運用環境では、仮想化技術は主に、高性能な物理ハードウェアの容量過剰と古いハードウェアの容量不足の問題を解決し、再編成して再利用することで、基礎となる物理ハードウェアを透明化し、物理ハードウェアの使用率を最大限に高めてリソースを最大限に活用するために使用されます。仮想化技術には、ソフトウェア仮想化、ハードウェア仮想化、メモリ仮想化、ネットワーク仮想化（VIP）、デスクトップ仮想化、サービス仮想化、仮想マシンなど、多くの種類があります。

1.1.2 仮想化の種類

（１）完全仮想化アーキテクチャ：仮想ハードウェア -> 仮想オペレーティングシステム

仮想マシンのモニター（ハイパーバイザー）は、VMware のワークステーションなどのホスト OS 上で動作するユーザー アプリケーションに似ています。この仮想化製品は仮想ハードウェアを提供します。

（２）OS層仮想化アーキテクチャ：ハードウェア仮想化なし、同一カーネルオペレーティングシステム

（３）ハードウェア層仮想化

ハードウェア レイヤー仮想化では、ハイパーバイザーがハードウェア上で直接実行されるため、パフォーマンスと分離性が高く、VM の OS からハードウェア リソースへのアクセスを制御できます。このソリューションを使用する製品には、VMware ESXi や Xen サーバーなどがあります。

ハイパーバイザーは、物理サーバーとオペレーティング システムの間で実行される中間ソフトウェア レイヤーです。これにより、複数のオペレーティング システムとアプリケーションが基本的な物理ハードウェアのセットを共有できるようになります。したがって、仮想環境の「メタ」オペレーティング システムと見なすこともできます。サーバー上のすべての物理デバイスと仮想マシンへのアクセスを調整できます。仮想マシン モニター (VMM) とも呼ばれます。

ハイパーバイザーは、すべての仮想化テクノロジの中核です。サーバーが起動してハイパーバイザーを実行すると、各仮想マシンに適切な量のメモリ、CPU、ネットワーク、ディスクが割り当てられ、すべての仮想マシンのクライアント オペレーティング システムがロードされます。ホスト

ハイパーバイザーは、すべての仮想化テクノロジーの中核です。ハードウェアとソフトウェアのアーキテクチャと管理をより効率的かつ柔軟にし、ハードウェアのパフォーマンスをより有効に活用できるようにします。一般的な製品には、VMware、KVM、Xen などがあります。オープンスタック

1.2 Dockerとは何か

1.2.1 コンテナ技術は OS 層の仮想化アーキテクチャに似ています。

コンピューティングの世界では、コンテナには長くて歴史のあるものがあります。コンテナはハイパーバイザ仮想化 (HV) とは異なります。ハイパーバイザ仮想化では、中間層を介して物理ハードウェア上で 1 台以上の独立したマシンが仮想的に実行されますが、コンテナはオペレーティング システム カーネル上のユーザー空間で直接実行されます。そのため、コンテナ仮想化は「オペレーティング システム レベルの仮想化」とも呼ばれます。コンテナ テクノロジにより、複数の独立したユーザー スペースを同じホスト マシン上で実行できるようになります。

コンテナはオペレーティング システム上の「ゲスト」であるため、基盤となるホストと同じまたは類似のオペレーティング システムしか実行できず、あまり柔軟性がないようです。たとえば、Ubuntu サーバーで Redhat Enterprise Linux を実行することはできますが、Ubuntu サーバーで Microsoft Windows を実行することはできません。

完全に分離されたハイパーバイザー仮想化と比較すると、コンテナは安全ではないと考えられています。この見解に反対する人々は、仮想コンテナは完全なオペレーティング システムを仮想化するため、攻撃の範囲が間違いなく拡大し、ハイパーバイザ レイヤーの潜在的な露出リスクも考慮する必要があると考えています。

制限があるにもかかわらず、コンテナはさまざまなアプリケーションで広く導入されています。コンテナ テクノロジーは、超大規模なマルチテナント サービスの展開、軽量サンドボックス、セキュリティ要件がそれほど厳しくない分離された環境で非常に人気があります。最も一般的な例は、プロセスを実行するための分離されたディレクトリ環境を作成する chroot jail です。権限分離刑務所内で実行中のプロセスが侵入者によって侵害された場合、侵入者は権限が不十分なためにコンテナによって作成されたディレクトリ内に閉じ込められ、ホスト マシンにそれ以上の損害を与えることができないため、自分自身が「監禁」されていることに気付くことになります。

最新のコンテナ テクノロジには、OpenVZ、Solaris Zones、Linux Containers (LXC) などがあります。これらの新しいテクノロジーにより、コンテナは単なる運用環境ではなくなりました。コンテナは、独自の権限クラス内では、完全なホスト マシンに似ています。 Docker の場合、コントロール グループや名前空間テクノロジなどの最新の Linux 機能の恩恵を受けます。コンテナとホスト間の分離はより徹底しています。コンテナには独立したネットワーク スタックとストレージ スタックがあり、独自のリソース管理機能も備えているため、同じホスト上の複数のコンテナが友好的に共存できます。

コンテナは、オーバーヘッドが限られているため、無駄のないテクノロジーであると考えられています。従来の仮想化や準仮想化と比較すると、コンテナではエミュレーション層やハイパーバイザ層は必要なく、代わりにオペレーティング システムのシステム コール インターフェイスが使用されます。これにより、単一のコンテナを実行するために必要なオーバーヘッドが削減され、ホスト上でより多くのコンテナを実行できるようになります。

コンテナは輝かしい歴史を持つにもかかわらず、まだ広く受け入れられていません。非常に重要な理由の 1 つは、コンテナ テクノロジの複雑さです。コンテナ自体は比較的複雑で、インストールが容易ではなく、管理や自動化が困難です。 Docker はこれらすべてを変えるために誕生しました。

1.2.2 コンテナと仮想マシンの比較

（１）本質的な違い

（２）使用法の違い

1.2.3 Dockerの機能

（１）始めやすい。

ユーザーがプログラムを「Docker 化」するには、わずか数分しかかかりません。 Docker はコピーオンライトモデルを採用しており、アプリケーションの変更が非常に高速です。「好きなようにコードを変更できる」状態に到達していると言えます。

その後、アプリケーションを実行するためのコンテナを作成できます。ほとんどの Docker コンテナは 1 秒以内に起動します。ハイパーバイザーのオーバーヘッドを排除することで、Docker コンテナは高いパフォーマンスを実現し、同じホスト マシン上でより多くのコンテナを実行できるため、ユーザーはシステム リソースを最大限に活用できます。

（２）責任の論理的分類

Docker を使用すると、開発者はコンテナ内で実行されるアプリケーションについてのみ心配する必要があり、オペレーターはコンテナの管理方法のみを心配する必要があります。 Docker 設計の目的は、開発者がコードを記述する開発環境とアプリケーションがデプロイされる本番環境間の一貫性を高めることです。これにより、「開発中は正常だったのに、運用保守の問題に違いない（テスト環境は正常だったが、オンライン化後に問題が発生したので、運用保守の問題に違いない）」という認識が軽減されます。

（３）迅速かつ効率的な開発ライフサイクル

Docker の目標の 1 つは、コードの開発、テスト、展開、オンライン操作のサイクルを短縮し、アプリケーションの移植性、構築の容易さ、共同作業の容易さを実現することです。 (簡単に言うと、Docker は多くのオブジェクトを格納できる箱のようなものです。これらのオブジェクトが必要な場合は、箱から 1 つずつ取り出すことなく、大きな箱から直接取り出すことができます。)

（4）サービス指向アーキテクチャの利用を奨励する

Docker は、サービス指向アーキテクチャとマイクロサービス アーキテクチャも推奨します。 Docker では、単一のコンテナで 1 つのアプリケーションまたはプロセスのみを実行し、分散アプリケーション モデルを形成することを推奨しています。このモデルでは、アプリケーションまたはサービスを内部的に相互接続された一連のコンテナとして表すことができるため、分散アプリケーションのデプロイ、アプリケーションの拡張またはデバッグが非常に簡単になり、プログラムのイントロスペクションも向上します。 （もちろん、1つのコンテナで複数のアプリケーションを実行することもできます）

1.3 Dockerコンポーネント

1.3.1 Dockerクライアントとサーバー

Docker はクライアント サーバー (C/S) アーキテクチャ プログラムです。 Docker クライアントは Docker サーバーまたはデーモンにリクエストを送信するだけで、サーバーまたはデーモンがすべての作業を実行し、結果を返します。 Docker は、コマンドライン ツール Docker と完全な RESTful API セットを提供します。 Docker デーモンとクライアントを同じホスト上で実行することも、ローカル Docker クライアントから別のホスト上で実行されているリモート Docker デーモンに接続することもできます。

1.3.2 Dockerイメージ

イメージは Docker の構成要素です。ユーザーはイメージに基づいて独自のコンテナを実行します。イメージは、Docker ライフサイクルの「ビルド」部分でもあります。イメージは、一連の命令によって段階的に構築されるユニオン ファイル システムに基づく階層構造です。例えば：

• ファイルを追加します。
• コマンドを実行します。
• ウィンドウを開きます。

イメージはコンテナの「ソース コード」と考えることもできます。画像は小さく、持ち運びが容易なので、共有、保存、更新が簡単です。

1.3.3 レジストリ

Docker はレジストリを使用してユーザーが構築したイメージを保存します。レジストリには、パブリックとプライベートの 2 種類があります。 Docker Inc は Docker Hub と呼ばれるパブリックレジストリを運営しています。ユーザーは Docker Hub にアカウントを登録し、独自のイメージを共有および保存できます (注: Docker Hub からイメージをダウンロードするのは非常に遅いため、独自のプライベート レジストリを構築できます)。

1.3.4 Dockerコンテナ

Docker はコンテナの構築と展開に役立ちます。独自のアプリケーションまたはサービスをコンテナにパッケージ化するだけです。コンテナはイメージに基づいて起動され、コンテナ内で 1 つ以上のプロセスを実行できます。イメージは Docker ライフサイクルにおけるビルドまたはパッケージ化の段階、コンテナは起動または実行の段階と考えることができます。 コンテナはイメージに基づいて起動されます。コンテナが起動したら、コンテナにログインして必要なソフトウェアやサービスをインストールできます。

つまり、Docker コンテナは次のようになります。

• 画像形式。
• 一連の標準的な操作。
• 実行環境。

Docker は標準コンテナの概念を借用しています。標準的なコンテナは世界中に商品を輸送しますが、Docker はこのモデルを自社の設計に適用しました。唯一の違いは、コンテナは商品を輸送し、Docker はソフトウェアを輸送することです。

コンテナと同様に、Docker は上記の操作を実行するときに、コンテナ内に Web サーバー、データベース、アプリケーション サーバーなど何が含まれているかを気にしません。すべてのコンテナは同じ方法でコンテンツを「ロード」します。

Docker では、コンテナをどこに発送するかも考慮されません。自分のラップトップでコンテナを構築し、それをレジストリにアップロードし、テストのために物理サーバーまたは仮想サーバーにダウンロードしてから、コンテナを特定のホストに展開することができます。標準的な輸送コンテナと同様に、Docker コンテナは簡単に交換でき、積み重ねることができ、配布も簡単で、多用途に使用できます。

Docker を使用すると、アプリケーション サーバー、メッセージ バス、ユーティリティ セット、継続的インテグレーション (CI) テスト環境、その他のアプリケーション、サービス、ツールをすばやく構築できます。完全なテスト環境をローカルに構築したり、複雑なアプリケーション スタックを本番環境や開発環境に素早く複製したりできます。

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。これについてもっと知りたい場合は、次のリンクをご覧ください。