用語集

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

aufs

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

ベース・イメージ(base image)

親イメージを持たないイメージを、 ベース・イメージ と呼びます。

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 を使えば、1つのファイルに複数のコンテナ・アプリケーションを定義しておき、コマンドを1つ実行するだけで、アプリケーションを使うために必要な全てを実行します。

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

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 コンテナと同じように、2つのオプションを切り替えるだけで、Windows コンテナの迅速なセットアップや実行を Windows Server 2016 上でも行えます。Windows マシン上で Docker 対応アプリケーションの開発・構築・テスト・パッケージ・移動をしたい場合に、ベストな解決作です。Windows マシン上で Docker を使うにあたり、Docker for Mac は 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 を作りたい場合は、 ENTRYPOINTCMD のどちらか、あるいは両方の指定が必要です。

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

    $ docker run --entrypoint=/bin/ls ubuntu -l /tmp
    
  • CMDENTRYPOINT に追加されます。 ENTRYPOINT で利用可能な文字列であれば、複数のコマンドやフラグ1つなど、どのようなものでも 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 MacDocker for Windows への更新を推奨します。

レイヤ

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

libcontainer

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

libnetwork

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

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 が動作している物理または仮想マシンを指します。 g .. Manager nodes perform swarm management and orchestration duties. By default manager nodes are also worker nodes.

マネージャ・ノード(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 は複数の DOcker ホストを一緒にまとめ(プールし)、1つの仮想的な Docker ホストのように装います。Swarm は標準 Docker API を提供するため、既に Docker で使えるツールであれば、複数のホスト上で透過的にスケールさせることができます。

別名:docker-swarm

タグ

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

注釈

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

タスク

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

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

_images/services-diagram.png

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 ストレージの使用 をご覧ください。

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

仮想マシン

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

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

別名:VM

ボリューム

ボリュームとは特別に設計されたディレクトリであり、ユニオン・ファイル・システムを迂回し、複数のコンテナ内で使えます。ボリュームは永続的なデータを保管するために設計されており、コンテナのライフサイクルとは独立しています。そのため、Docker はコンテナの削除時に、ボリュームを決して自動的に削除しません。そればかりか「ガベージ・コレクト」(ゴミ収集;garbage collect)ボリュームとして、コンテナからは参照できないようにもできます。これは データ・ボリューム(data volume) とも呼ばれます。

ボリュームは、ホスト(host)、匿名(anonymous)、名前付き(named)の3種類です。

参考

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