Skip to content

Latest commit

 

History

History
634 lines (346 loc) · 42.2 KB

glossary.rst

File metadata and controls

634 lines (346 loc) · 42.2 KB

用語集

目次

AMD64 とは、インテルの x86 アーキテクチャの AMD による 64 ビット拡張であり、x86_64 (または x86-64) とも呼びます。

aufs (advanced multi layered unification filesystem;複数のレイヤを統合した、高度なファイルシステム、の意味)は Linux の :ref:`ファイルシステム <glossary-filesystem>` であり、ストレージ用のバックエンドとして Docker がサポートします。Linux ファイルシステムに対する ユニオンマウント(Union mount) の実装です。

ベースイメージ は Dockerfile で親イメージを指定しないものです。ベースイメージを作成するには、Dockerfile で FROM scratch 命令を使います。

btrfs (B-tree file system;ビーツリーファイルシステム)は、ストレージ用のバックエンドとして Docker がサポートする Linux の :ref:`ファイルシステム <filesystem>` です。これは :ref:`コピーオンライト <copy-on-write>` のファイルシステムです。

ビルド(build)とは、 :ref:`Dockerfile` を使って Docker イメージを構築する工程です。構築には、 Dockerfile と「コンテクスト」(内容物の意味)を使います。コンテクストとは、イメージ構築に必要なディレクトリに置いてあるファイル群です

cgroups とは、プロセスの集合が使うリソース(CPU、メモリ、ディスク I/O、ネットワーク等)を制限・計算・隔離(isolate)する Linux カーネルの機能です。リソース上限の管理と隔離をするため、Docker は cgroups に依存します。

cgroups の別名:control groups

クラスタとはマシンのグループであり、ワークロードの実行と高可用性を備えるために連携します。

:doc:`Compose </compose/index>` (コンポーズ)は、Docker を使い、複雑なアプリケーションの実行や定義をするツールです。Compose では、1つのファイルに複数のコンテナアプリケーションを定義します。それから、コマンドを1つ実行するだけで、アプリケーションを使うために必要な全てを素早く立ち上げます

Compose の別名: docker-compose、fig

Docker はイメージとコンテナのリソース最適化とスピード性能のために、 :ref:`コピーオンライト <the-copy-on-write-strategy>` 技術と :ref:`union-file-system` を使います。Docker コンテナや Docker イメージに、複数のコピーが存在するときは、実体である同じイメージレイヤを共有します。また、それぞれのレイヤに対する変更処理は、個々のレイヤにのみ反映します。

複数のコンテナは、同じイメージへのアクセスを共有できます。そして、特定のコンテナに対する変更とは、書き込み可能なレイヤに対して行いますが、そのコンテナを削除すると(コンテナ用の)レイヤも削除されます。これが、コンテナの開始時間とパフォーマンスの速度を向上します。

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

Docker の文脈におけるコピーオンライトの詳細は、 :doc:`イメージ、コンテナ、ストレージドライバの理解 </engine/userguide/storagedriver/imagesandcontainers>` をご覧ください。

:ruby:`コンテナ <container>`:ref:`docker イメージ <image>` で実行する実体(インスタンス)です。

Docker コンテナを構成するのは、次のものです。

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

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

用語としての Docker (ドッカー)は、次のことを指します。

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

:doc:`Docker Desktop for Mac </docker-for-mac/index>` はインストールが簡単で、Mac 向けに特化して設計された、軽量な Docker 開発環境です。Docker Desktop for Mac は Mac 固有のアプリケーションを実行するために、macOS ハイパーバイザーフレームワーク、ネットワーク機能、ファイルシステムを使います。Mac 上で Docker 対応アプリケーションの開発・構築・テスト、パッケージ化、移動するために、ベストな解決作です。

:doc:`Docker Desktop for Windows </docker-for-windows/index>` はインストールが簡単で、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 と自身のコンポーネントで動くリソースを集めた場所です。以下のサービスを提供します。

Dockerfile はテキスト形式のドキュメントであり、このファイルに含むのは、通常は Docker イメージを構築するために、手作業で実行する全ての命令です。Docker は Dockerfile の命令を読み込み、自動的にイメージを構築できます。

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

  • 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
  • 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 イメージは :ref:`コンテナ <container>` の基礎(土台)です。イメージとは、ルートファイルシステムに対する変更と、コンテナ実行時に使う実行パラメータに相当するものを並べ集めたものです。一般的にイメージには、ファイルシステムをレイヤー化した集合が、お互いに積み重なって入っています。イメージは状態を保持せず、変更もできません。

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

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

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

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

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

別名: docker-machine

Linux 名前空間(namespace;ネームスペース) は Linux カーネルの :ruby:`分離 <isolate>` と仮想システム・リソース機能です。名前空間によって制限されたプロセスは、同じ名前空間内のリソースやプロセスとしかやりとりできません。名前空間は Docker の分離モデルにおける重要な部分です。名前空間は各リソース・タイプごとに存在しています。リソース・タイプとは net (ネットワーク機能)、 mnt (ストレージ)、 pid (プロセス)、 uts (ホスト名の制御)、 user (UID 割り当て)です。名前空間に関する詳しい情報は、 :doc:`Docker run リファレンス </engine/reference/run>`:doc:`ユーザ名前空間でコンテナ隔離 </engine/security/userns-remap>` をご覧ください。

:doc:`ノード </engine/swarm/how-swarm-mode-works/nodes>` とは、 :ref:`swarm モード <swarm-mode>` 上における Docker Engine が動作している物理または仮想マシンで動作する実体(インスタンス)を指します。

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

Worker ノード(ワーカ node) はタスクを実行します。

overlay ネットワークドライバは、クラスタ内の Docker コンテナに対して、複数ホスト間で、簡単なネットワーク接続性を提供します。

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

イメージの 親イメージ とは、対象イメージの Dockerfile 中にある FROM 命令で指定したイメージです。以降に続く全てのコマンドは、この親イメージに基づきます。Dockerfile で FROM scratch 命令を使うと、親イメージを持たない ベースイメージ(base image) を作成します。

持続的ストレージやボリュームストレージは、実行中コンテナのファイスシステム上で、持続的なレイヤ(persistent layer)をユーザに対して提供します。持続的なレイヤは、コンテナのホスト上や外部デバイスに残り続けます。この持続的なレイヤのライフサイクルは、コンテナのライフサイクルとはつながっておらず、ユーザは状態を維持できます。

レジストリとは :ref:`イメージ <image>` を保管する :ref:`リポジトリ <repository>` を預かるサービス(ホステッドサービス)であり、レジストリ API に応答します。

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

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

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

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

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

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

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

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

:doc:`swarm </engine/swarm/index>` とは :ref:`swarm モード <glossary-swarm-mode>` で動作する Docker Engine のクラスタのことです。

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

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

別名:docker-swarm

:doc:`Swarm モード </engine/swarm/index>` とは、 Docker Engine 内蔵で、クラスタ管理とオーケストレーション機能拡張を指します。新しい swarm(クラスタ)を初期化するか、あるいはノードが swarm に加わると、Docker Engine は swarm モードで稼働します。

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

Note

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

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

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

/engine/images/services-diagram.png

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

Docker 及びユニオン・ファイル・システムの詳細は、 :doc:`/storage/storagedriver/aufs-driver`:doc:`/storage/storagedriver/btrfs-driver`:doc:`/storage/storagedriver/overlayfs-driver` をご覧ください。

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

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

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

別名:VM

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

ボリュームには、 :ruby:`ホスト <host>`:ruby:`匿名 <anonymous>`:ruby:`名前付き <named>` という3種類のタイプがあります。

x86_64 (または x86-64) は、インテルの x86 アーキテクチャの AMD による 64 ビット拡張命令のセットです。AMD は自身のアーキレクチャを x86_64 アーキテクチャ、 AMD64 と呼び、インテルはこの実装を Intel 64 と呼びます。

.. seealso::

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