【メモ帳】Docker基礎用語まとめ

# 基礎用語
Docker学習に際し、基礎的な理解が足りていなかったため用語集としてまとめました。
かなりシンプルな内容なので、Dockerの概要を用語で把握・確認するためのものになります。

## Dockerイメージ
<b>Dockerコンテナを作成するための雛形になるもの。</b>
親子関係を持つ、複数のイメージ・レイヤによって構成されており、アプリケーション、ライブラリ、設定ファイルなどのアプリケーション実行に必要なもの一式をまとめたもの。
<b>主にDockerfileがイメージを作成するための指示書にあたる。</b>

## Dockerコンテナ
<b>Dockerイメージをもとに作成されるコンテナ型仮想環境のこと。</b>
Dockerコンテナまたは、単にコンテナと呼ばれることがある。

## Dockerエンジン
<b>コンテナ型仮想環境構築などの機能を提供するDocker内部のコアとなる機能。</b>

> Docker Engine … 軽量かつ強力なオープンソースによりコンテナ化（containerization）を行う技術。アプリケーションの構築とコンテナ化を行うワークフローを実現します。

[Docker Engine について](https://docs.docker.jp/engine/index.html)

## Dockerデーモン
<b>ユーザーからのDockerコマンドによる命令を実行し、コンテナの起動や再起動、停止などの管理をしているDockerの常駐型プログラム。</b>

> Docker デーモン
上図で見たように、Docker デーモンはホストマシン上で動きます。ユーザは直接デーモンと通信せず、Docker クライアントを通して行います。

[Docker概要](http://docs.docker.jp/v1.12/engine/understanding-docker.html)

## Dockerクライアント
<b>利用者がDockerに指示を出すためのクライアントソフトのことを指す。</b>
一般的にはDockerコマンドを用いて、Dockerに指示を出し、コンテナの実行・構築・配布などを行う。


> Docker クライアント は Docker デーモン と通信することで、Docker コンテナの構築・実行・配布といった力仕事をします。 Docker クライアントとデーモンのいずれも同じシステム上でも実行できます。 あるいは、Docker クライアントはリモートの Docker デーモンに接続することも可能です。

[アーキテクチャの理解](https://docs.docker.jp/engine/introduction/understanding-docker.html#:~:text=Docker%20%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%20%E3%81%AF%20Docker%20%E3%83%87%E3%83%BC%E3%83%A2%E3%83%B3,%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%82%82%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99%E3%80%82)


## Docker Hub
<b>Dockerイメージを保存、管理しているサービス。</b>
公開されているイメージをダウンロードすることで、イメージをもとにしたコンテナ型仮想環境を構築することができる。
このようにDockerイメージを管理している場所を`レジストリ`と言う。
同様のサービスではDocker Hubの他にQuay.ioなどがある。

[Quay.io](https://quay.io/)

## リポジトリ
<b>Dockerイメージを保管するための入れ物。</b>
このリポジトリの作成など、リポジトリを管理するサービスを`レジストリ`と言う。

## ビルド(build)
<b>Dockerfileからイメージを作成すること</b>

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

https://docs.docker.jp/glossary.html#build


## ビルドコンテキスト
<b>Dockerイメージをビルドする際に、Dockerデーモンに送信されるホストOSのディレクトリのことを指す。</b>
> docker buildコマンドを実行したときの、カレントなワーキングディレクトリのことを ビルドコンテキスト（build context）と呼びます。 デフォルトで Dockerfile は、カレントなワーキングディレクトリにあるものとみなされます。 ただしファイルフラグ（-f）を使って別のディレクトリとすることもできます。 Dockerfileが実際にどこにあったとしても、カレントディレクトリ配下にあるファイルやディレクトリの内容がすべて、ビルドコンテキストとして Docker デーモンに送られることになります。

##

[Dockerfile ベストプラクティス](https://matsuand.github.io/docs.docker.jp.onthefly/develop/develop-images/dockerfile_best-practices/#:~:text=docker%20build%20%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E5%AE%9F%E8%A1%8C,%E3%82%82%E3%81%AE%E3%81%A8%E3%81%BF%E3%81%AA%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82)

注意点として、<b>Dockerデーモンに送信されるビルドコンテキスト上のファイルは必要最低限に留めておく必要があります。</b>

ビルドコンテキスト上のファイルはビルド時に全てDockerデーモンに送信されてしまうため、ファイルサイズが大きいとビルドの時間が長くなってしまうからです。

## ビルドキャッシュ
<b>Dockerイメージをビルドした際に一時保存されるキャッシュ。</b>

このビルドキャッシュのおかげで、<b>Dockerfileを元にしたビルド内容に差がない場合には、2回目以降は初回よりも早くビルドが完了する。</b>

なお Dockerfileや関連ファイルに変更があった場合には、ビルドキャッシュが使用されずに再度ビルドが行われます。

## aufs
<b>Dockerイメージをどのようにストレージに保存するかを管理するソフトウェア</b>

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


https://docs.docker.jp/glossary.html#aufs

# アーキテクチャ

こちらにかなりわかりやすいイラストがあったので引用させていただきました。
全体の流れや機能ごとの関係性を理解できると思います。
[Docker のアーキテクチャとは？](https://docs.docker.jp/engine/introduction/understanding-docker.html)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594063/dabd46f5-4d3c-42c6-9c7a-5e625143c0e8.png)

> Docker はクライアント・サーバ型のアーキテクチャです。Docker クライアント が Docker コンテナの構築・実行・配布といった力仕事をするには、 Docker デーモン と通信します。 Docker クライアントとデーモンは、どちらも同じシステム上でも実行できます。あるいは、Docker クライアントはリモートの Docker デーモンに接続するのも可能です。Docker クライアントとデーモンは、お互いにソケットもしくは RESTful API を経由して通信します。

### 終わりに
かなり基礎的な内容になりますが、学習の参考になれば幸いです。