用語集¶
amd64¶
AMD64 とは、インテルの x86 アーキテクチャの AMD による 64 ビット拡張であり、x86_64 (または x86-64) とも呼びます。
aufs¶
aufs (advanced multi layered unification filesystem;複数のレイヤを統合した、高度なファイルシステム、の意味)は Linux の ファイルシステム であり、ストレージ用のバックエンドとして Docker がサポートします。Linux ファイルシステムに対する ユニオンマウント(Union mount) の実装です。
ベースイメージ ¶
ベースイメージ は Dockerfile で親イメージを指定しないものです。ベースイメージを作成するには、Dockerfile で FROM scratch
命令を使います。
btrfs¶
btrfs (B-tree file system;ビーツリーファイルシステム)は、ストレージ用のバックエンドとして Docker がサポートする Linux の ファイルシステム です。これは コピーオンライト のファイルシステムです。
ビルド ¶
ビルド(build)とは、 を使って Docker イメージを構築する工程です。構築には、 Dockerfile と「コンテクスト」(内容物の意味)を使います。コンテクストとは、イメージ構築に必要なディレクトリに置いてあるファイル群です
cgroups¶
cgroups とは、プロセスの集合が使うリソース(CPU、メモリ、ディスク I/O、ネットワーク等)を制限・計算・隔離(isolate)する Linux カーネルの機能です。リソース上限の管理と隔離をするため、Docker は cgroups に依存します。
cgroups の別名:control groups
クラスタ ¶
クラスタとはマシンのグループであり、ワークロードの実行と高可用性を備えるために連携します。
Compose ¶
Compose (コンポーズ)は、Docker を使い、複雑なアプリケーションの実行や定義をするツールです。Compose では、1つのファイルに複数のコンテナアプリケーションを定義します。それから、コマンドを1つ実行するだけで、アプリケーションを使うために必要な全てを素早く立ち上げます
Compose の別名: docker-compose、fig
コピーオンライト ¶
Docker はイメージとコンテナのリソース最適化とスピード性能のために、 コピーオンライト 技術と を使います。Docker コンテナや Docker イメージに、複数のコピーが存在するときは、実体である同じイメージレイヤを共有します。また、それぞれのレイヤに対する変更処理は、個々のレイヤにのみ反映します。
複数のコンテナは、同じイメージへのアクセスを共有できます。そして、特定のコンテナに対する変更とは、書き込み可能なレイヤに対して行いますが、そのコンテナを削除すると(コンテナ用の)レイヤも削除されます。これが、コンテナの開始時間とパフォーマンスの速度を向上します。
イメージとは、実質的にファイルシステムのレイヤです。一般的には書き込み可能なレイヤは、その下にベースイメージがあると予測され、ベースイメージとは異なったレイヤを積み上げます。これによりイメージ容量を最小化し、共有しながら開発できるようにします。
Docker の文脈におけるコピーオンライトの詳細は、 イメージ、コンテナ、ストレージドライバの理解 をご覧ください。
コンテナ ¶
Docker コンテナを構成するのは、次のものです。
Docker イメージ
実行環境
命令の標準セット
Docker コンテナの概念は、輸送用のコンテナから拝借したものです。コンテナとは、全世界へ物資を輸送するために定義された規格です。Docker はソフトウェアを送るための規格を定義しています。
Docker ¶
用語としての Docker (ドッカー)は、次のことを指します。
Docker プロジェクト全体を指す言葉です。開発者やシステム管理者が、アプリケーションを開発・移動・実行するためのプラットフォームです。
イメージとコンテナを管理する、ホスト上で動く docker デーモンのプロセスです。
Docker Engine とも呼びます。
Docker Desktop for Mac¶
Docker Desktop for Mac はインストールが簡単で、Mac 向けに特化して設計された、軽量な Docker 開発環境です。Docker Desktop for Mac は Mac 固有のアプリケーションを実行するために、macOS ハイパーバイザーフレームワーク、ネットワーク機能、ファイルシステムを使います。Mac 上で Docker 対応アプリケーションの開発・構築・テスト、パッケージ化、移動するために、ベストな解決作です。
Docker Desktop for Windows¶
Docker Desktop for Windows はインストールが簡単で、Microsoft Hyper-V(Professional、Enterprise、Education)をサポートしているWindows 10 システム向けに特化して設計された、軽量な Docker 開発環境です。Docker Desktop for Windows は Windows 固有のアプリケーションを実行するために、Hyper-V 仮想化を使い、固有の Windows アプリのように動作します。Windows Server 2016 上でも動作し、2つのオプションを切り替えるだけで、標準的な Linux コンテナと同じように、Windows コンテナの迅速なセットアップや実行ができます。Windows マシン上で Docker 対応アプリケーションの開発・構築・テスト・パッケージ・移動をするために、ベストな解決作です。
Docker Hub ¶
Docker Hub とは、 Docker と自身のコンポーネントで動くリソースを集めた場所です。以下のサービスを提供します。
Docker イメージを預かる(ホスティング)
ユーザ認証
イメージの自動構築と、
構築トリガ やウェブフック のようなワークフローツールGitHub 及び Bitbucket との統合
Dockerfile ¶
Dockerfile はテキスト形式のドキュメントであり、このファイルに含むのは、通常は Docker イメージを構築するために、手作業で実行する全ての命令です。Docker は Dockerfile の命令を読み込み、自動的にイメージを構築できます。
ENTRYPOINT ¶
Dockerfile において、実行したいコマンドを真っ先に定義するオプションが ENTRYPOINT
です。 docker run
コマンドの実行時、何も引数を指定しなくても実行可能な Dockerfile
を作りたい場合は、 ENTRYPOINT
か CMD
のどちらか、あるいは両方の指定が必要です。
ENTRYPOINT
の指定があれば、これを単独のコマンドとして設定します。多くの公式 Docker イメージは、ENTRYPOINT`
に/bin/sh
または/bin/bash
を指定しています。ENTRYPOINT
を指定しなければ、Dockerfile のFROM
キーワード指定されているベースイメージの設定を継承します。実行時にENTRYPOINT
を上書きしたい場合は、--entrypoint
を使えます。次の例はエントリーポイントを/bin/ls
に置き換え、CMD
を-l /tmp
に指定します。$ docker run --entrypoint=/bin/ls ubuntu -l /tmp
CMD
はENTRYPOINT
に追加されます。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 イメージは コンテナ の基礎(土台)です。イメージとは、ルートファイルシステムに対する変更と、コンテナ実行時に使う実行パラメータに相当するものを並べ集めたものです。一般的にイメージには、ファイルシステムをレイヤー化した集合が、お互いに積み重なって入っています。イメージは状態を保持せず、変更もできません。
レイヤ ¶
イメージ内部において、イメージに対する変更箇所がレイヤであり、つまり Dockerfile 内における命令を意味します。ベースイメージから最終的なイメージを作成するまで、レイヤは順番に重なります。イメージの更新や再構築をする場合には、更新が必要なレイヤのみを変更し、ローカルでキャッシュ済みのレイヤは変更しません。これが Docker イメージはなぜ高速かつ軽量なのかという理由の1つです。各レイヤの容量の合計が、最終的なイメージの容量と同じです。
libcontainer ¶
libcontainer は Go 言語のネイティブな実装であり、名前空間・cgroup・機能・ファイルシステムへのアクセス管理を持つコンテナを作成します。コンテナを作成後、コンテナに対してライフサイクル上の追加操作を可能にします。
libnetwork ¶
libnetworkは Go 言語のネイティブな実装であり、コンテナのネットワーク名前空間や他のネットワーク・リソースを作成・管理します。コンテナを作成後、コンテナに対してライフサイクル上の追加操作を可能にします。
リンク機能 ¶
リンク機能は同じホスト上で実行している Docker コンテナ間を接続するための、レガシーな(古い)インターフェースです。リンク機能を使うと、ホスト側のネットワークポートを開く必要がありません。現在は、この機能の替わりに Docker ネットワーク機能を使います。
Machine ¶
Machine は Docker ホストを簡単に作成できるようにするツールであり、クラウドプロバイダ上やデータセンタでも利用できます。Machine はサーバを作成し、そこに Docker をインストールし、Docker クライアントで通信できるように設定します。
別名: docker-machine
名前空間 ¶
Linux 名前空間(namespace;ネームスペース) は Linux カーネルの net
(ネットワーク機能)、 mnt
(ストレージ)、 pid
(プロセス)、 uts
(ホスト名の制御)、 user
(UID 割り当て)です。名前空間に関する詳しい情報は、 Docker run リファレンス と ユーザ名前空間でコンテナ隔離 をご覧ください。
ノード ¶
ノード とは、 swarm モード 上における Docker Engine が動作している物理または仮想マシンで動作する実体(インスタンス)を指します。
Manager ノード(マネージャ node) は swarm(クラスタ)管理とオーケストレーションの責務を処理します。デフォルトでは、managerノードは worker ノードも兼ねます。
Worker ノード(ワーカ node) はタスクを実行します。
overlay ネットワークドライバ ¶
overlay ネットワークドライバは、クラスタ内の Docker コンテナに対して、複数ホスト間で、簡単なネットワーク接続性を提供します。
overlay ストレージドライバ ¶
OverlayFS は、他のファイルシステムに対する ユニオンマウント を Linux に実装するもので、 ファイルシステム 向けのサービスです。
親イメージ ¶
イメージの 親イメージ とは、対象イメージの Dockerfile 中にある FROM
命令で指定したイメージです。以降に続く全てのコマンドは、この親イメージに基づきます。Dockerfile で FROM scratch
命令を使うと、親イメージを持たない ベースイメージ(base image) を作成します。
持続的ストレージ ¶
持続的ストレージやボリュームストレージは、実行中コンテナのファイスシステム上で、持続的なレイヤ(persistent layer)をユーザに対して提供します。持続的なレイヤは、コンテナのホスト上や外部デバイスに残り続けます。この持続的なレイヤのライフサイクルは、コンテナのライフサイクルとはつながっておらず、ユーザは状態を維持できます。
レジストリ ¶
レジストリとは イメージ を保管する リポジトリ を預かるサービス(ホステッドサービス)であり、レジストリ API に応答します。
デフォルトのレジストリにアクセスするには、ブラウザで Docker Hub を開くか、 docker search
コマンドを使います。
リポジトリ ¶
リポジトリとは Docker イメージの集まりです。リポジトリは レジストリ サーバに送信すると、共有されるようにできます。リポジトリの中では、イメージの違いを タグ でラベル付けします。
共有 Nginx リポジトリ と タグ の例です。
SSH¶
SSH(secure shell;安全なシェル)はリモート・マシンやアプリケーションに接続するための安全なプロトコルです。インターネットのような安全ではないネットワーク越しに、認証や暗号データ通信を行います。SSH はログイン認証にあたって公開鍵/秘密鍵のペアを使います。
サービス ¶
サービスは、 swarm 上でアプリケーション・コンテナをどのように実行するかの定義です。最も基本的なレベルのサービス定義とは、swarm 上でどのコンテナ・イメージを実行するか、そして、どのコマンドをコンテナで実行するかです。オーケストレーションの目的は
時々、巨大なアプリケーションという文脈において、マイクロサービスのことをサービスとも呼びます。サービスとは HTTP サーバやデータベースかもしれません。これは、分散環境において実行したい、あらゆる種類の実行可能なプログラムです。
サービスディスカバリ ¶
Swarm モードの サービス・ディスカバリ は、swarm クラスタ内部における DNS コンポーネントです。これは、オーバレイ・ネットワーク上の各サービスに対し、VIP と DNS エントリを自動的に割り当てます。ネットワーク上のコンテナは
サービスごとにポートを公開する必要がないため、同じオーバレイ・ネットワーク上で他のサービスが動いているかどうかを確認する必要はありません。アクティブなタスクごとサービス用の VIP を持ち、swarm の内部ロードバランサはリクエストごとにアクセスを分散します。
swarm¶
Docker Swarm¶
Docker Swarm と Docker Engine の swarm モードを混同しないでください。
Docker Swarm は Docker 用に独立したネイティブなクラスタリング・ツールです。Docker Swarm は複数の Dcker ホストを一緒にまとめ(プールし)、1つの仮想的な Docker ホストのように装います。Swarm は標準 Docker API を提供するため、既に Docker で使えるツールであれば、複数のホスト上で透過的にスケールさせることができます。
別名:docker-swarm
swarm モード¶
Swarm モード とは、 Docker Engine 内蔵で、クラスタ管理とオーケストレーション機能拡張を指します。新しい swarm(クラスタ)を初期化するか、あるいはノードが swarm に加わると、Docker Engine は swarm モードで稼働します。
タグ ¶
タグ(tag)は リポジトリ 上の Docker イメージに割り当てるラベルです。タグを使い、リポジトリ上のイメージを互いに識別します。
注釈
ここでのラベルとは、docker デーモン用のキー・バリューで設定するラベルとは関係がありません。
タスク ¶
タスクは swarm 内でスケジューリングする最小単位です。タスクは Docker コンテナを運び、コンテナ内部にあるコンテナを実行します。ノードへのタスク管理を管理し、サービスをスケールするために、ワーカ・ノードに複数のレプリカを割り当てます。
下図はサービスにおけるタスクとコンテナの関係性を示します。
ユニオンファイルシステム ¶
ユニオン・ファイル・システム(Union file system)は ユニオン・マウント の実装であり、レイヤ作成時に処理するものです。Docker はユニオン・ファイル・システムで結語するために 技術を使い、非常に軽量かつ高速なコンテナ用のブロックを構築します。
Docker 及びユニオン・ファイル・システムの詳細は、 AUFS ストレージ ドライバの使用 、Btrfs ストレージ・ドライバの使用 、 OverlayFS ストレージの使用 をご覧ください。
仮想マシン ¶
仮想マシン(Virtual Machine)とは、コンピュータと疑似専用ハードウェアの全体をエミュレートするプログラムです。他のユーザと物理ハードウェアのリソースを共有しますが、オペレーティングシステムからは隔離されています。エンドユーザは専用ハードウェアと同じように仮想マシンを操作できます。
コンテナと比べると、仮想マシンの実行は重たいものですが、更なる隔離を提供し、自身でリソースを持っており、共有は最低限です。
別名:VM
ボリューム ¶
ボリュームとは、複数のコンテナ内で用いる特別なディレクトリのことであり、ユニオンファイルシステムを通して利用します。ボリュームはデータを保持する目的で設計されており、コンテナのライフサイクルには影響されません。したがって、コンテナを削除したとしても、Docker はボリュームを自動的に削除しません。たとえコンテナから参照されなくなったボリュームであっても、「ガベージコレクト」により失われることもありません。これは
ボリュームには、
x86_64¶
x86_64 (または x86-64) は、インテルの x86 アーキテクチャの AMD による 64 ビット拡張命令のセットです。AMD は自身のアーキレクチャを x86_64 アーキテクチャ、 AMD64 と呼び、インテルはこの実装を Intel 64 と呼びます。
参考
- Docker Glosary.rst