用語集¶

用語の定義や、ドキュメント内でタグ付けされたトピックを参照するには、各項目をクリックしてください。

aufs ¶

aufs （advanced multi layered unification filesystem；複数のレイヤを統合した高度なファイルシステム、の意味）は Linux のファイルシステムであり、Docker がサポートするストレージ用のバックエンドです。

boot2docker ¶

boot2docker （ブート・トゥ・ドッカー）は Docker コンテナの実行に特化した Linux ディストリビューションです。Mac 及び Windows 向けの boot2docker は、Docker Toolbox のインストールに含まれる docker-machine に置き換えられました。

btrfs ¶

btrfs （B-tree file system；ビー・ツリー・ファイルシステム、バター・エフエス）は、Docker がストレージ用のバックエンドとしてサポートする Linux のファイルシステムです。これはコピー・オン・ライトのファイルシステムです。

ビルド（build）¶

ビルド（build）とは、 Dockerfile を使って Docker イメージを構築する方法です。構築時には Dockerfile と「コンテクスト」（内容物の意味）を使います。コンテクストとは、イメージ構築に必要なファイル群が置かれているディレクトリです。

cgroups ¶

cgroups （control groups；コントロール・グループ）は Linux カーネルの機能であり、プロセスの集合が使うリソース（CPU、メモリ、ディスク I/O、ネットワーク等）を制限・計算・隔離します。Docker はリソース上限の管理と隔離に cgroups を使います。

cgroups の別名：control groups

Compose ¶

Compose （コンポーズ）は、Docker で複雑なアプリケーションの実行と定義をするツールです。Compose を使えば、１つのファイルに複数のコンテナ・アプリケーションを定義しておき、コマンドを１つ実行するだけで、アプリケーションを使うために必要な全てを実行します。

Compose の別名： docker-compose、fig

コピー・オン・ライト(copy-on-write)¶

Docker はイメージとコンテナのリソース最適化とスピード性能のために、コピー・オン・ライト技術とユニオン・ファイル・システムを使います。

複数のコンテナは同じイメージに共有してアクセスできます。そして、コンテナの書き込み可能なレイヤに対する固有の変更が可能であり、コンテナ削除時にこのレイヤは削除されます。

イメージとは実質的にファイルシステムのレイヤであり、一般的には書き込み可能なレイヤの下にはベース・イメージを基礎としています。そして、ベース・イメージとは異なったレイヤを積み上げます。これによりイメージの容量を最小化し、開発環境でイメージを共有できるようになります。

Docker の文脈におけるコピー・オン・ライトの詳細は、イメージ、コンテナ、ストレージ・ドライバについてをご覧ください。

コンテナ ¶

コンテナ（container）は docker イメージを実行するときの実体（runtime instance）です。

Docker コンテナには、次のものを含みます。

Docker イメージ
実行環境
命令の標準セット

Docker コンテナの概念は、輸送用のコンテナから拝借したものです。コンテナは物を世界的に輸送するために標準が定義されています。Docker はソフトウェアを送るための標準を定義しています。

Docker ¶

Docker （ドッカー）には次の意味があります。

Docker プロジェクト全体を指す言葉であり、開発者やシステム管理者がアプリケーションを開発・移動・実行するためのプラットフォームです。
ホスト上で動く docker デーモンのプロセスであり、イメージとコンテナを管理します。Docker Engine（エンジン）とも呼びます。

Docker Datacenter ¶

Docker Datacenter（データセンタ）は Docker で構築するプラットフォームをエンタープライズに強化するもので、サブスクリプションを基本とする Docker 向けのサービスです。Docker ネイティブのツールが統合されることで、オンプレミスの CaaS プラットフォームを構築でき、組織における時間の接続や、開発からプロダクションへのアプリケーション構築をシームレスに行えます。

Docker for Mac は、 Mac 向けに特化したインストールが簡単で、軽量な Docker 開発環境として設計されています。ネイティブな Mac アプリケーション実行のため、Docker for Mac は macOS のハイパーバイザ・フレームワーク、ネットワーク機能、ファイルシステムを使います。 Mac 上で Docker 対応アプリケーションの開発・構築・テスト・パッケージ・移動をしたい場合に、ベストな解決策です。macOS 上で Docker を使うにあたり、Docker for Mac は Docker Toolbox の後継としての位置付けです。

Docker for Windows ¶

Docker for Windows は、Microsoft Hyper-V（Professional、Enterprise、Education）をサポートしているWindows 10 システム向けに特化した、軽量な Docker 開発環境として設計されています。Docker for Windows はネイティブな Windows アプリケーション実行のため、Hyper-V 仮想化を使います。標準的な Linux コンテナと同じように、２つのオプションを切り替えるだけで、Windows コンテナの迅速なセットアップや実行を Windows Server 2016 上でも行えます。Windows マシン上で Docker 対応アプリケーションの開発・構築・テスト・パッケージ・移動をしたい場合に、ベストな解決作です。Windows マシン上で Docker を使うにあたり、Docker for Windows は Docker Toolbox の後継としての位置付けです。

Docker Hub ¶

Docker Hub （ドッカー・ハブ）は Docker とこのコンポーネントで動くリソースを集めた場所です。以下のサービスを提供します。

Docker イメージを預かる（ホスティング）
ユーザ認証
イメージの自動構築と、構築トリガ（build triggers）やウェブ・フック（web hooks）のようなワークフロー・ツール
GitHub 及び Bitbucket との統合

Dockerfile ¶

Dockerfile（ドッカーファイル）はテキスト形式のドキュメントです。通常は、 Docker イメージを構築するために手動で実行が必要な全ての命令を含みます。Docker は Dockerfile の命令を読み込み、自動的にイメージを構築します。

ENTRYPOINT ¶

Dockerfile において、 ENTRYPOINT は一番初めに実行すべきコマンドのオプション定義です。docker run コマンド実行時、何も引数を追加しなくても実行可能な Dockerfile を作りたい場合は、 ENTRYPOINT か CMD のどちらか、あるいは両方の指定が必要です。

ENTRYPOINT を指定すると、単一のコマンドとしての指定になります。公式 Docker イメージの大部分は /bin/sh または /bin/bash を ENTRYPOINT` に指定しています。 ENTRYPOINT を指定しなければ、Dockerfile の FROM キーワード指定されているベース・イメージの指定を継承します。実行時に ENTRYPOINT を上書きしたい場合は、 --entrypoint を使えます。次の例はエントリーポイントを /bin/ls に置き換え、 CMD を -l /tmp に指定します。
$ docker run --entrypoint=/bin/ls ubuntu -l /tmp

CMD は ENTRYPOINT に追加されます。 ENTRYPOINT で利用可能な文字列であれば、複数のコマンドやフラグ１つなど、どのようなものでも CMD に書けます。実行時に CMD を上書きするには、コンテナ名や ID のあとに追加するだけです。次の例は CMD を /bin/ls -l /tmp に上書きします。
$ docker run ubuntu /bin/ls -l /tmp

実際には、 ENTRYPOINT を頻繁に上書きしません。しかしながら、 ENTRYPOINT の指定によってイメージをより柔軟かつ再利用しやすくします。

ファイルシステム ¶

ファイルシステムとは、オペレーティング・システムがファイルに名前を付け、かつ、効率的な保管と修正のためにファイルに場所を割り当てます。

例：

Linux : ext4, aufs, btrfs, zfs
Windows : NTFS
OS X : HFS+

イメージ ¶

Docker イメージはコンテナの元です。イメージとはルート・ファイルシステムに対する変更を並べ集めたもので、コンテナを実行する間に使われる実行パラメータに相当します。典型的なイメージはユニオン・ファイル・システムの層（スタック）がお互いに積み重なっています。イメージは状態を保持せず、変更もできません。

Kitematic ¶

以前からある Docker コンテナ管理用 GUI であり、 Docker Toolbox に同梱されていました。Kitematic に代わる Docker for Mac か Docker for Windows への更新を推奨します。

レイヤ ¶

イメージ内部において、イメージに対する変更がレイヤです。これらは Dockerfile 内における命令を意味します。ベース・イメージから最終的なイメージを作成するまで、レイヤは順番に重なります。イメージの更新や再構築時は、更新が必要となるレイヤのみを変更し、変更のないレイヤはローカルでキャッシュします。これが Docker イメージはなぜ高速かつ軽量なのかという理由の１つです。各レイヤの容量の合計が、最終的なイメージの容量と同じです。

libcontainer ¶

libcontainer（リブコンテナ）は Go 言語のネイティブな実装であり、名前空間・cgroup・機能・ファイルシステムへのアクセス管理を持つコンテナを作成します。コンテナを作成後、コンテナに対してライフサイクル上の追加操作を可能にします。

libnetwork ¶

libnetwork（リブネットワーク）は Go 言語のネイティブな実装であり、コンテナのネットワーク名前空間や他のネットワーク・リソースを作成・管理します。コンテナを作成後、コンテナに対してライフサイクル上の追加操作を可能にします。

リンク機能（link）¶

リンク機能は同じホスト上で実行している Docker コンテナ間を接続するための、レガシーな（古い）インターフェースです。リンク機能を使うと、ホスト側のネットワーク・ポートを開く必要がありません。現在は、この機能の替わりに Docker ネットワーク機能を使います。

Machine ¶

Machine （マシン）は Docker ホストを簡単に作成できるようにするツールであり、クラウド・プロバイダ上やデータセンタでも利用できます。Machine はサーバを作成し、そこに Docker をインストールし、Docker クライアントで通信できるように設定します。

別名： docker-machine

名前空間（namespace）¶

Linux 名前空間（namespace；ネームスペース）は Linux カーネルの分離（isolate）と仮想システム・リソース機能です。名前空間によって制限されたプロセスは、同じ名前空間内のリソースやプロセスとしかやりとりできません。名前空間は Docker の分離モデルにおける重要な部分です。名前空間は各リソース・タイプごとに存在しています。リソース・タイプとは net （ネットワーク機能）、 mnt （ストレージ）、 pid （プロセス）、 uts （ホスト名の制御）、 user （UID 割り当て）です。名前空間に関する詳しい情報は、 Docker run リファレンスとユーザ名前空間入門（英語）をご覧ください。

ノード ¶

ノードとは、swarm モード上における Docker Engine が動作している物理または仮想マシンを指します。

マネージャ・ノード（Manager node） は swarm（クラスタ）管理とオーケストレーションの責務を処理します。デフォルトでは、マネージャ・ノードはワーカ・ノードも兼ねます。

ワーカ・ノード（Worker node） はタスクを実行します。

オーバレイ・ネットワーク・ドライバ ¶

オーバレイ・ネットワーク・ドライバ（overlay network driver）は、クラスタ上の Docker コンテナに対して、複数ホスト間のネットワーク接続性を簡単に提供します。

オーバレイ・ストレージ・ドライバ ¶

OverlayFS は、他のファイルシステムに対するユニオン・マウントを Linux に実装するもので、ファイルシステム向けのサービスです。

レジストリ（registry）¶

レジストリ（registry）とはイメージを持つリポジトリを預かるサービス（ホステッド・サービス）であり、レジストリ API に応答します。

デフォルトのレジストリにアクセスするには、ブラウザで Docker Hub を開くか、 docker search コマンドを使います。

リポジトリ（repository）¶

リポジトリ（repository）とは Docker イメージの集まりです。リポジトリはレジストリサーバに送信すると、共有されるようにできます。リポジトリの中では、イメージの違いをタグでラベル付けします。

共有 Nginx リポジトリとタグの例です。

SSH ¶

SSH（secure shell；安全なシェル）はリモート・マシンやアプリケーションに接続するための安全なプロトコルです。インターネットのような安全ではないネットワーク越しに、認証や暗号データ通信を行います。SSH はログイン認証にあたって公開鍵/秘密鍵のペアを使います。

サービス ¶

サービスは、 swarm 上でアプリケーション・コンテナをどのように実行するかの定義です。最も基本的なレベルのサービス定義とは、swarm 上でどのコンテナ・イメージを実行するか、そして、どのコマンドをコンテナで実行するかです。オーケストレーションの目的は「望ましい状態（desired state）」としてサービスを定義することです。つまり、いくつのコンテナをタスクとして実行するか、コンテナをデプロイする条件（constraint）を指します。

時々、巨大なアプリケーションという文脈において、マイクロサービスのことをサービスとも呼びます。サービスとは HTTP サーバやデータベースかもしれません。これは、分散環境において実行したい、あらゆる種類の実行可能なプログラムです。

サービス・ディスカバリ ¶

Swarm モードのサービス・ディスカバリは、swarm クラスタ内部における DNS コンポーネントです。これは、オーバレイ・ネットワーク上の各サービスに対し、VIP と DNS エントリを自動的に割り当てます。ネットワーク上のコンテナはゴシップ（訳者注；分散環境における通信プロトコルの一種です）を経由し、各サービス向けに割り当てられた DNS を共有します。そのため、ネットワーク上における全てのコンテナ上にあるサービスに対し、サービス名でアクセスできます。

サービスごとにポートを公開する必要がないため、同じオーバレイ・ネットワーク上で他のサービスが動いているかどうかを確認する必要はありません。アクティブなタスクごとサービス用の VIP を持ち、swarm の内部ロードランサはリクエストごとにアクセスを分散します。

Swarm ¶

swarm とは swarm モードで動作する Docker Engine のクラスタのことです。

Docker Swarm ¶

Docker Swarm と Docker Engine の swarm モードを混同しないでください。

Docker Swarm は Docker 用に独立したネイティブなクラスタリング・ツールです。Docker Swarm は複数の Dcker ホストを一緒にまとめ（プールし）、１つの仮想的な Docker ホストのように装います。Swarm は標準 Docker API を提供するため、既に Docker で使えるツールであれば、複数のホスト上で透過的にスケールさせることができます。

別名：docker-swarm

タグ ¶

タグ（tag）はリポジトリ上の Docker イメージに割り当てるラベルです。タグを使い、リポジトリ上のイメージを互いに識別します。

注釈

ここでのラベルとは、docker デーモン用のキー・バリューで設定するラベルとは関係がありません。

タスク ¶

タスクは swarm 内でスケジューリングする最小単位です。タスクは Docker コンテナを運び、コンテナ内部にあるコンテナを実行します。ノードへのタスク管理を管理し、サービスをスケールするために、ワーカ・ノードに複数のレプリカを割り当てます。

下図はサービスにおけるタスクとコンテナの関係性を示します。

Toolbox ¶

Docker Toolbox は Mac と Windows に対応した過去のインストーラです。こちらは Oracle VirtualBox 仮想化を使います。

Mac で OS X EI Capitan 10.11 か、これよりも新しい macOS リリースをお使いであれば、 Docker for mac のほうが良いソリューションです。

Windows 10 で Microsoft Hyper-V のサポートがあれば（Professional、Enterprise、Education）、 Docker for Windows のほうが良いソリューションです。

ユニオン・ファイル・システム ¶

ユニオン・ファイル・システム（Union file system）はユニオン・マウントの実装であり、レイヤ作成時に処理するものです。Docker はユニオン・ファイル・システムで結語するためにコピー・オン・ライト(copy-on-write) 技術を使い、非常に軽量勝つ高速なコンテナ用のブロックを構築します。

Docker 及びユニオン・ファイル・システムの詳細は、 AUFS ストレージ・ドライバの使用、Btrfs ストレージ・ドライバの使用、 OverlayFS ストレージの使用をご覧ください。

ユニオン・ファイル・システムの実装例は UnionFS 、AUFS 、 Btrfs です。

仮想マシン ¶

仮想マシン（Virtual Machine）とは、コンピュータと疑似専用ハードウェアの全体をエミュレートするプログラムです。他のユーザと物理ハードウェアのリソースを共有しますが、オペレーティング・システムからは隔離されています。エンドユーザは専用ハードウェアと同じように仮想マシンを操作できます。

コンテナと比べると、仮想マシンの実行は重たいものですが、更なる隔離を提供し、自身でリソースを持っており、共有は最低限です。

別名：VM

ボリューム ¶

ボリュームとは、いくつかのコンテナ内にて用いられる特定のディレクトリのことであり、ユニオン・ファイル・システムを通じて利用されます。ボリュームはデータを永続的に保持する目的で設計されており、コンテナのライフサイクルには影響されません。したがってコンテナを削除したとしても、Docker はボリュームを自動的に削除するようなことはしません。たとえコンテナから参照されなくなったボリュームであっても、「ガベージ・コレクト」により失われることもありません。これは データ・ボリューム（data volume） とも呼ばれます。

ボリュームには、ホスト（host）、匿名（anonymous）、名前付き（named）という３種類のタイプがあります。

参考

Docker Glosary.rst: https://docs.docker.com/glossary/