Dockerは、開発者がコンテナ を構築、デプロイ、実行、更新、管理できるようにするオープンソース・プラットフォームです。コンテナとは、アプリケーションのソースコードと、そのコードをあらゆる環境で実行するために必要なオペレーティング・システム(OS)ライブラリーおよび依存関係を組み合わせた、標準化された実行コンポーネントです。
コンテナは、分散アプリケーションの開発と配信を簡素化します。 組織がクラウドネイティブ開発やハイブリッド・マルチクラウド環境に移行するにつれて、その人気はますます高まっています。 開発者は、Linuxやその他のオペレーティング・システムに組み込まれている機能を直接操作することで、Dockerを使用せずにコンテナを作成できます。 しかし、Dockerを使用することで、 コンテナ化 はより速く、より簡単に、より安全になります。 この記事の作成時点で、Dockerは、1,300万人を超える開発者によって使用されているプラットフォーム(英語)(ibm.com外部へのリンク)であると報告されています。
Dockerとは、Dockerの商用版を販売している会社であるDocker社(英語) (ibm.com外部へのリンク)と、Docker社と他の多くの企業および個人が貢献しているDockerオープンソース・プロジェクトのことを指します。
コンテナは、Linuxカーネルに組み込まれているプロセスの分離の機能と仮想化の機能によって実現します。 プロセス間でリソースを配分するコントロール・グループ(Cgroups)や、プロセスによるシステムの他のリソースまたはエリアへのアクセスや可視性を制限するネームスペース といった機能により、複数のアプリケーション・コンポーネントで、ホスト・オペレーティング・システムの単一のインスタンスのリソースを共有できるようになります。これはハイパーバイザーによって、複数の仮想マシン(VM)で、単一のハードウェア・サーバーのCPU、メモリー、その他のリソースを共有できるようにする方法とほぼ同じです。
結果として、コンテナ・テクノロジーはアプリケーションの分離、コスト効率に優れた拡張性、廃棄可能性などのVMのすべての機能性とメリットに加え、次の重要なメリットをもたらします。
軽量:VMとは異なり、コンテナはOSインスタンスやハイパーバイザー全体のペイロードを伝送するわけではありません。 コンテナに含まれるのは、コードの実行に必要なOSのプロセスと依存関係のみです。 (一部のVMはギガバイト単位となるのに対し)コンテナのサイズはメガバイト単位です。コンテナではハードウェア容量をより有効に活用し、起動時間を短縮できます。
開発者の生産性の向上:コンテナ化されたアプリケーションは、一度作成すればどこでも実行できます。 また、VMと比較して、コンテナはデプロイ、プロビジョニング、再起動がより高速で簡単です。 これは、継続的インテグレーションと継続的デリバリー(CI/CD)のパイプラインでの使用にとって理想的であり、アジャイルとDevOpsのプラクティスを採用する開発チームにとっては、より適した選択肢となります。
リソース効率の向上:コンテナを使用すると、開発者は、VMを使用する場合の数倍の数のアプリケーションを同じハードウェアで実行できます。 これにより、クラウドへの支出を減らすことができます。
コンテナを使用している企業は、アプリケーションの品質の向上、市場の変化への迅速な対応など、数多くのメリットを挙げています。 詳細については、以下のインタラクティブ・ツールでご覧ください。
Dockerは非常に人気があるため、「Docker」と「コンテナ」は同じ意味で使用されています。 しかし、初期のコンテナ関連テクノロジーは、Dockerが2013年に一般にリリースされる数年前、さらには数十年(英語)(IBM外部へのリンク)前から利用可能でした。
特に、2008年にはLinuXContainers(LXC)がLinuxカーネルに実装され、Linuxの単一インスタンスの仮想化が完全に実現されています。 LXCは現在でも使用されているものの、Linuxカーネルを使用した新しいテクノロジーが登場しています。 最新のオープンソースのLinuxオペレーティング・システムであるUbuntuも、この機能を備えています。
Dockerを使用すると、開発者は簡単なコマンドを使用してこれらのネイティブなコンテナ化機能にアクセスし、作業を軽減できるアプリケーション・プログラミング・インターフェース(API)を使用して自動化できます。 LXCと比較して、Dockerは以下を提供します。
さらに軽量で詳細な更新:LXCでは、複数のプロセスを1つのコンテナ内で組み合わせて実行することができます。 これにより、アプリケーションの一部が更新または修復のために停止されている間も実行を継続可能なアプリケーションを構築できます。
コンテナの自動作成:Dockerは、アプリケーションのソースコードに基づいてコンテナを自動的に構築できます。
コンテナのバージョン管理:Dockerでは、コンテナ・イメージのバージョンの追跡、以前のバージョンへのロールバック、誰がどのようにバージョンを作成したかのトレースが可能です。 既存のバージョンと新しいバージョンの差分のみをアップロードすることもできます。
コンテナの再利用:既存のコンテナは、基本的に新しいコンテナを構築するためのテンプレートのように、ベース・イメージとして使用できます。
現在、Dockerコンテナ化はMicrosoft WindowsおよびApple MacOSでも機能します。 開発者は、あらゆるオペレーティング・システムでDockerコンテナを実行でき、Amazon Web Services(AWS)、Microsoft Azure、IBM Cloudなど、ほとんどの主要クラウド・プロバイダーは、開発者がDockerでコンテナ化されたアプリケーションを構築、デプロイ、実行するのに役立つ特定のサービスを提供しています。
Dockerを使用する際に開発者が目にするツール、用語、テクノロジーには、以下が挙げられます。
すべてのDockerコンテナは、Dockerコンテナ・イメージを構築する方法についての説明を含む、単純なテキスト・ファイルで始まります。 DockerFile は、Dockerイメージの作成プロセスを自動化します。 基本的には、イメージをアセンブルするためにDocker Engineが実行するコマンド・ライン・インターフェース(CLI)の命令のリストです。 Dockerコマンドのリストは膨大ですが、標準化されています。Dockerの操作は、コンテンツ、インフラストラクチャー、その他の環境変数に関係なく、同じように動作します。
Dockerイメージ には、実行可能なアプリケーション・ソースコードと、アプリケーション・コードをコンテナとして実行するために必要な、すべてのツール、ライブラリー、および依存関係が含まれています。 Dockerイメージを実行すると、コンテナの1つのインスタンス(または複数のインスタンス)になります。
Dockerイメージを最初から作成することは可能ですが、ほとんどの開発者はイメージを一般的なリポジトリーからプルします。 1つのベース・イメージから複数のDockerイメージを作成でき、それらのイメージでスタックは共通したものとなります。
Dockerイメージはレイヤーで構成されており、各レイヤーはイメージのバージョンに対応しています。 開発者がイメージに変更を加えるたびに、新しい最上位レイヤーが作成され、前の最上位レイヤーに替わってこのイメージの現行バージョンとなります。 前のレイヤーは、ロールバック用に、あるいは他のプロジェクトでの再利用のために保存されます。
Dockerイメージからコンテナが作成されるたびに、コンテナ・レイヤーと呼ばれるさらに別の新しいレイヤーが作成されます。 ファイルの追加や削除など、コンテナに加えられた変更は、コンテナ・レイヤーにのみ保存され、コンテナの実行中にのみ存在します。 この反復的なイメージ作成プロセスにより、複数のライブ・コンテナ・インスタンスを単一のベース・イメージから実行でき、またその際にはインスタンスで共通のスタックが活用されるため、全体的な効率が向上します。
Dockerコンテナ は、あるDockerイメージの、実行中のライブのインスタンスです。 Dockerイメージは読み取り専用ファイルですが、コンテナはライブの一時的な実行可能コンテンツです。 ユーザーはコンテナと対話でき、管理者はDockerコマンドを使用してコンテナの設定と条件を調整できます。
Docker Hub (英語)(ibm.comの外部リンク)は、Dockerイメージのパブリック・リポジトリーであり、「コンテナ・イメージに関する世界最大のライブラリーおよびコミュニティー」を自称しています。 Docker Hubは商用ソフトウェア・ベンダー、オープンソース・プロジェクト、および個々の開発者から調達した、10万を超えるコンテナ・イメージを保有しています。 これには、Docker社によって作成されたイメージ、Docker Trusted Registryに属する認定イメージ、および、その他の何千ものイメージが含まれます。
すべてのDocker Hubのユーザーは、イメージを自由に共有できます。 また、Dockerファイル・システムから事前定義されたベース・イメージをダウンロードして、コンテナ化プロジェクトの開始点として使用することもできます。
その他のイメージ・リポジトリーもあり、その代表がGitHubです。 GitHubは、アプリケーション開発ツールや、コラボレーションとコミュニケーションを促進するプラットフォームとして定評のある、リポジトリー・ホスティング・サービスです。 Docker Hubのユーザーは、多くのイメージを保持できるリポジトリー(repo)を作成できます。 リポジトリーは公開することも非公開にすることもでき、GitHubやBitBucketのアカウントとリンクさせることができます。
Docker Desktop(英語)(ibm.com外部へのリンク)は、MacまたはWindows向けのアプリケーションであり、Docker Engine、Docker CLIクライアント、Docker Compose、Kubernetesなどが含まれます。 また、Docker Hubへのアクセスも含まれます。
Dockerデーモン は、クライアントからのコマンドを使用してDockerイメージを作成および管理するサービスです。 基本的に、Dockerデーモンは、Docker実装環境のコントロール・センターとして機能します。 Dockerデーモンが動作するサーバーをDockerホストと呼びます。
Dockerレジストリー は、Dockerイメージ用の、拡張が容易なオープンソースのストレージおよび配信システムです。 レジストリーを使用すると、識別用のタグ付けによって、リポジトリー内のイメージのバージョンを追跡できます。 これは、バージョン管理ツールであるgitを使用して行われます。
わずかなコンテナしか稼働していない場合、業界の事実上のランタイムであるDocker Engine内でアプリケーションを管理するのは極めてシンプルです。 ただし、デプロイメントが数千のコンテナと数百のサービスで構成されている場合、そのワークフローの管理は、いくつかの専用ツールを使用しない限りは、ほぼ不可能です。
Dockerプラグイン(英語)(ibm.com外部へのリンク)を使用して、Dockerの機能をさらに強化できます。 Docker Engineのプラグイン・システムには多数のDockerプラグインが含まれており、サード・パーティーのプラグインをロードすることもできます。
開発者は、Docker Composeを使用して、すべてのコンテナが同じDockerホスト上で稼働するマルチコンテナ・アプリケーションを管理できます。 Docker Composeは、アプリケーションに含まれるサービスを指定するYAML(.YML)ファイルを作成し、単一のコマンドでコンテナをデプロイして実行できます。 YAML構文は言語に依存しないため、YAMLファイルはJava、Python、Ruby、およびその他の多くの言語で記述されたプログラムで使用できます。
また、開発者は、Docker Composeを使用して、ストレージ用の永続ボリュームを定義し、基本ノードを指定し、サービスの依存関係を文書化および構成することもできます。
より複雑な環境でコンテナ・ライフサイクルをモニタリングおよび管理するには、 コンテナ・オーケストレーション ・ツールが必要です。 Dockerには独自のオーケストレーション・ツール(Docker Swarmと呼ばれる)が含まれていますが、ほとんどの開発者はKubernetesを選択します。
Kubernetesは、Google社で社内使用目的で開発されたプロジェクトから派生した、オープンソースのコンテナ・オーケストレーション・プラットフォームです。 Kubernetesは、コンテナのデプロイメント、更新、サービス・ディスカバリー、ストレージのプロビジョニング、ロード・バランシング(英語)、正常性モニタリングなど、コンテナ・ベースのアーキテクチャーの管理に不可欠なタスクをスケジュールおよび自動化します。 さらに、IstioやKnativeなどのKubernetes用のツールのオープンソース・エコシステムにより、組織はコンテナ化されたアプリケーション向けの生産性の高いPaaS(Platform as a Service)を導入できると共に、より迅速にサーバーレス・コンピューティングを展開することが可能となります。
Red Hat OpenShift on IBM Cloudは、パブリック環境やハイブリッド環境でOpenShiftを活用して、俊敏性、市場への即応性、拡張性、信頼性の向上を図ります。
IBM Cloud Satellite®では、オンプレミス、エッジ、パブリッククラウドなど、あらゆる環境で一貫したクラウド・サービスを利用できます。
オンプレミス、プライベートクラウド、パブリッククラウドでIBMのハイブリッドクラウド・ストレージ・ソリューションを活用することで、アプリケーションやサービスに最適な方法でデータを保存できます。
マネージド・クラウド・サービスのアプローチにより、従来のIT管理とDevOps文化の間の潜在的な緊張が緩和されます。