こんにちは！ともわん（@TomoOne4）です。
僕は、IT企業でマーケティングやセールスをやっています。
Dockerについての第7回目投稿です。
今回は、「Dockerfileの理解の続編として、気にせず使っていたdocker buildとその裏にあったbuild context」を扱います。
概念的な感じの回になります。
今回のポイント
- docker build .の深堀り
- Docker daemon（どっかー・でーもん）とは？
- build context
- Dockerというものの設計について
ここで書く内容は、Udemy で受講できる、
かめ れおんさんの米国AI開発者がゼロから教えるDocker講座
で学んだ内容を自分の中で定着するために調べたり考えたりした内容を踏まえて進めていきます。
導入は文章より動画のほうがすっと入ってくる人も多いと思いますので、少し記事を読んでいただき
「Docker面白そうだし、簡単そう」
と思った人はぜひUdemyで米国AI開発者がゼロから教えるDocker講座を受けてみてください。
Dockerやコンテナ、仮想化については第1回、第2回、第3回、第4回、第5回、第6回がありますのでこちらをみてみてください！
docker build . はいったいなに？
docker build . については、以前の記事の「Dockerfileの流れ」で説明しました。改めてその時に使った流れ図を紹介します。
Dockerfileというものがあり、その記述に沿ってDocker Imageを作りたいという場合には、 docker buildコマンドを実行するんでした。
その時は、Dockerfileのあるディレクトリまでcdコマンドで移動して docker build . コマンドを実行していたわけですが、
. は、今いるカレントディレクトリを指定しているだけで、分かりやすいため一度移動して . で指定しているという感じです。
では、気になる人は気になるかもしれないのですが、
なぜDockerfileではなく、ディレクトリ自体を指定しているのでしょうか？？
確かに、docker build Dockerfileでもいいようなものを。。。
実は、
指定されたディレクトリ（docker build . であれば、カレントディレクトリ）は、
build contextというものになり、
それがDockerの中のDocker daemonに送られて処理され、
これをもとにDocker Imageを作成してくれる。
という流れになっているのです。
実際に$ docker build . が成功するとこのようなメッセージが出力されます。
$ docker build .
Sending build context to Docker daemon 2.048kBDocker daemonにbuild contextを送っていますというメッセージです。
ぜひ確認してみてください。
→指定されたディレクトリの中にあるファイルを利用することもできる。
では、何気なく出てきた、Docker daemonとは何なのでしょうか？
その前に、この記事の全体像を入れ込んだ図を共有します。（説明はおいおい）
Docker daemon
分かりやすい説明を引用してみます。
Dockerデーモンは Linux のデーモンプロセスで、Docker Engine API が呼び出されるのを待ち受けています。Dockerデーモンは、呼び出された Docker Engine API に応じて、イメージのビルドやコンテナの起動などを行います
さわって理解する Docker 入門「オブジェクトの広場」
デーモンというのは、
メモリ上でタスクを待機している常駐プログラムことです。
聖飢魔IIでは無いです。。
そして、Dockerっぽく言うと、
Docker daemonは、Docker objectを管理するもの
となります。
Docker のアーキテクチャ
Docker daemonを理解するには、Dockerの設計を見るのがよい！
ということで、Docker overviewのページに図が2つ載っかっています。
2枚めがアーキテクチャの話です。
あくまで、Client は命令を送るだけでコンテナやイメージは別のHostにあるという仕組みになっています。（例えばクラウドサーバや社内専用サーバ）
今回は、Client も Host（Docker daemon）もMac上でやっているのであまり気にすることはないのですが、
例えばHostがクラウドサーバ上にある場合など、Docker Daemonに命令を与える際にはDocker に対するREST APIを経由する。という方法をとります。
なので、今までコマンド操作をしていたことを振り返ってみると、こういうことが言えるわけです。
我々は、docker コマンドを使ってDocker daemonに命令を出し、Docker daemonはその命令をもとにDocker Imagesを作成したりコンテナの作成や立ち上げなどの操作を行っていた。
build contextについて
build contextはこのようなものです。
【build contextとは】
・buildをするときのcontext（環境・状況）
・Docker daemonは、build contextの中にあるファイルとDockerfileを使って、Docker Imageを作る
・buildに使わないファイルはなるべくbuild contextには入れない（通信の時間がかかるのと、次の項目で書いているように容量が増大する）
・ADDやCOPYというDocker Instructionでbuild contextの中のファイルをDocker Imageに持っていくことができる（が、大きいファイルはDocker Image自体の大きさが増大してしまうのでやめておこう）
docker buildのドキュメントを見ると、こう書いてあります。
By default the docker build command will look for a Dockerfile at the root of the build context. The -f, –file, option lets you specify the path to an alternative file to use instead. This is useful in cases where the same set of files are used for multiple builds. The path must be to a file within the build context. If a relative path is specified then it is interpreted as relative to the root of the context.
デフォルトでは、docker buildコマンドはbuild contextのルートにあるDockerfileを探します。f, –file, オプションを指定すると、代わりに使用する代替ファイルのパスを指定することができます。これは複数のビルドで同じファイルを使用する場合に便利です。パスは、build context内のファイルへのパスでなければなりません。相対パスを指定した場合は、コンテキストのルートからの相対パスとして解釈されます。
つまり、ここまで分かった上で改めてこの図を見てみます。
今回の記事をまとめます。
作業用ディレクトリ（今回だと、自分のMacのどこか）にDockerfileを作り、
docker buildコマンドを実行した場合には、
そこがbuild contextとなり、Host側のDocker daemonに送られます。
Docker daemonは受け取ったbuild contextを見て、Dockerfileの内容をもとにDocker Imageの作成を行います。
また、build context内に別のファイルがあった場合はそれも一緒にHost側のDocker daemonに送られるのでDockerfileの書き方次第でそこも含めてDocker Imageにすることも可能になります。
ε-(´∀｀*)ﾎｯ
まとめ：Dockerの理解には重要な概念
今回は、概念的なところを扱いました。docker buildのコマンドとはどういう意味なのか、またその裏ではDocker daemonというやつとbuild contextというやつがいたこと、全てが関連してDocker Imageが作られているということ。
概念や抽象論は理解が難しいのですが、原則に近い応用もききやすいところなのでしっかり抑えたいですね！
教材と参考資料
