昨天寫了使用 Dockerfile 定制鏡像，其中構建背景關系這一塊沒有寫，今天把這一塊單獨拿出來寫一下，
Docker鏡像構建
簡單說下構建鏡像步驟：
-
cd Dockerfile 所在目錄;
-
執行 docker build 構建命令:
docker build -t imageName:imageTag .
通過上面的作業流，很容易形成這樣的理解誤區：
- docker build 后面的 . 為 Dockerfile 所在的目錄；
- Dockerfile 檔案名 必須為 Dockerfile；
其實上面這種理解是錯誤的，要想準確理解其含義，首先我們需要先了解下 Docker 的架構和 docker build 的作業原理，
Docker架構
Docker 使用C/S （客戶端/服務器）體系的架構，Docker 客戶端與 Docker 守護行程通信，Docker 守護行程負責構建，運行和分發 Docker 容器，Docker 客戶端和守護行程可以在同一個系統上運行，也可以將 Docker 客戶端連接到遠程 Docker 守護行程，Docker 客戶端和守護行程使用 REST API 通過UNIX套接字或網路介面進行通信，
docker build 的作業原理
- Client端執行 docker build . 命令 ;
- Docker 客戶端會將構建命令后面指定的路徑(.)下的所有檔案打包發送給 Docker 服務端;
- Docker 服務端收到客戶端發送的包，然后解壓，根據 Dockerfile 里面的指令進行鏡像的分層構建；
鏡像構建背景關系（Context）
當我們進行鏡像構建的時候，并非所有定制都會通過 RUN 指令完成，經常會需要將一些本地檔案復制進鏡像，比如通過 COPY 指令、ADD 指令等，而 docker build 命令構建鏡像，其實并非在本地構建，而是在服務端，也就是 Docker 引擎中構建的，那么在這種客戶端/服務端的架構中，如何才能讓服務端獲得本地檔案呢？
這就引入了背景關系的概念，當構建的時候，用戶會指定構建鏡像背景關系的路徑，docker build 命令得知這個路徑后，會將路徑下的所有內容打包，然后上傳給 Docker 引擎，這樣 Docker 引擎收到這個背景關系包后，展開就會獲得構建鏡像所需的一切檔案，如果在 Dockerfile 中這么寫：
COPY ./package.json /app/
這并不是要復制執行 docker build 命令所在的目錄下的 package.json，也不是復制 Dockerfile 所在目錄下的 package.json，而是復制 背景關系（context） 目錄下的 package.json，
因此，COPY這類指令中的源檔案的路徑都是相對路徑，這也是初學者經常會問的為什么 COPY ../package.json /app 或者 COPY /opt/xxxx /app 無法作業的原因，因為這些路徑已經超出了背景關系的范圍，Docker 引擎無法獲得這些位置的檔案，如果真的需要那些檔案，應該將它們復制到背景關系目錄中去，
示例1 ：
[root@192 test]# ls
Dockerfile
[root@192 test]# cat Dockerfile
FROM alpine:latest
ADD /root/mydocker/apache-tomcat-9.0.27.tar.gz /data/soft
[root@192 test]# ls /root/mydocker/apache-tomcat-9.0.27.tar.gz
/root/mydocker/apache-tomcat-9.0.27.tar.gz
[root@192 test]# docker build .
Sending build context to Docker daemon 3.072kB
Step 1/2 : FROM alpine:latest
---> 965ea09ff2eb
Step 2/2 : ADD /root/mydocker/apache-tomcat-9.0.27.tar.gz /data/soft
ADD failed: stat /var/lib/docker/tmp/docker-builder904012777/root/mydocker/apache-tomcat-9.0.27.tar.gz: no such file or directory
可以看出：
- 鏡像構建背景關系路徑并不是 Dockerfile檔案所在的路徑；
- Dockerfile 中指令的作業目錄是服務端解壓客戶端傳輸包的路徑，因為 ADD 指令失敗了，意味著當前目錄并沒有 apache-tomcat 檔案；
理解構建背景關系對于鏡像構建是很重要的，可以避免犯一些不應該的錯誤，比如有些初學者在發現 COPY /opt/xxxx /app 不作業后，于是干脆將 Dockerfile 放到了硬碟根目錄去構建，結果發現 docker build 執行后，在發送一個幾十 GB 的東西，極為緩慢而且很容易構建失敗，那是因為這種做法是在讓 docker build 打包整個硬碟，這顯然是使用錯誤，
一般來說，應該會將 Dockerfile 置于一個空目錄下，或者專案根目錄下，如果該目錄下沒有所需檔案，那么應該把所需檔案復制一份過來，如果目錄下有些東西確實不希望構建時傳給 Docker 引擎，那么可以用 .gitignore 一樣的語法寫一個.dockerignore，該檔案是用于剔除不需要作為背景關系傳遞給 Docker 引擎的，
那么為什么會有人誤以為 . 是指定 Dockerfile 所在目錄呢？這是因為在默認情況下，如果不額外指定 Dockerfile 的話，會將背景關系目錄下的名為 Dockerfile 的檔案作為 Dockerfile，
這只是默認行為，實際上 Dockerfile 的檔案名并不要求必須為 Dockerfile，而且并不要求必須位于背景關系目錄中，比如可以用-f ../Dockerfile.php引數指定某個檔案作為 Dockerfile，
當然，一般大家習慣性的會使用默認的檔案名 Dockerfile，以及會將其置于鏡像構建背景關系目錄中，
示例2
[root@192 test]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
tomcat jdk8-adoptopenjdk-hotspot 1a2bfb3e6eee 15 hours ago 318MB
openjdk 8-jre-slim d0cfe439ce3d 13 days ago 184MB
btnguyen2k/oraclejdk8_jre-alpine latest fab475620d00 4 years ago 208MB
[root@192 test]# cat ../mynginx/test
FROM alpine:latest
[root@192 test]# ls
apache-tomcat-9.0.27.tar.gz
[root@192 test]# docker build -f ../mynginx/test -t test:v1 .
Sending build context to Docker daemon 10.99MB
Step 1/1 : FROM alpine:latest
latest: Pulling from library/alpine
89d9c30c1d48: Already exists
Digest: sha256:c19173c5ada610a5989151111163d28a67368362762534d8a8121ce95cf2bd5a
Status: Downloaded newer image for alpine:latest
---> 965ea09ff2eb
Successfully built 965ea09ff2eb
Successfully tagged test:v1
[root@192 test]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
tomcat jdk8-adoptopenjdk-hotspot 1a2bfb3e6eee 15 hours ago 318MB
alpine latest 965ea09ff2eb 11 days ago 5.55MB
test v1 965ea09ff2eb 11 days ago 5.55MB
openjdk 8-jre-slim d0cfe439ce3d 13 days ago 184MB
btnguyen2k/oraclejdk8_jre-alpine latest fab475620d00 4 years ago 208MB
可以看出：
Dockerfile 的檔案名并不要求必須為 Dockerfile，而且并不要求必須位于背景關系目錄中，比如可以用-f ../mynginx/test引數指定某個檔案作為 Dockerfile，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/158260.html
標籤：Linux