"start": "node index.js"
}
}
你可以使用下面的Dockerfile來打包這個應用程序：
FROM node:8
EXPOSE 3000
WORKDIR /app
COPY package.json index.js ./
RUN npm install
CMD ["npm", "start"]
然後開始構建鏡像：
$ docker build -t node-vanilla .
然後用以下方法驗證它是否可以正常運行：
$ docker run -p 3000:3000 -ti --rm --init node-vanilla
你應該能訪問http://localhost:3000，並收到“Hello World!”。
Dockerfile中使用了一個COPY語句和一個RUN語句，所以按照預期，新鏡像應該比基礎鏡像多出至少兩個層：
$ docker history node-vanilla
IMAGE CREATED BY SIZE
075d229d3f48 /bin/sh -c #(nop) CMD ["npm" "start"] 0B
bc8c3cc813ae /bin/sh -c npm install 2.91MB
bac31afb6f42 /bin/sh -c #(nop) COPY multi:3071ddd474429e1… 364B
500a9fbef90e /bin/sh -c #(nop) WORKDIR /app 0B
78b28027dfbf /bin/sh -c #(nop) EXPOSE 3000 0B
b87c2ad8344d /bin/sh -c #(nop) CMD ["node"] 0B/bin/sh -c set -ex && for key in 6A010… 4.17MB /bin/sh -c #(nop) ENV YARN_VERSION=1.3.2 0B /bin/sh -c ARCH= && dpkgArch="$(dpkg --print… 56.9MB /bin/sh -c #(nop) ENV NODE_VERSION=8.9.4 0B
/bin/sh -c set -ex && for key in 94AE3… 129kB /bin/sh -c groupadd --gid 1000 node && use… 335kB /bin/sh -c set -ex; apt-get update; apt-ge… 324MB /bin/sh -c apt-get update && apt-get install… 123MB /bin/sh -c set -ex; if ! command -v gpg > /… 0B /bin/sh -c apt-get update && apt-get install… 44.6MB /bin/sh -c #(nop) CMD ["bash"] 0B /bin/sh -c #(nop) ADD file:1dd78a123212328bd… 123MB
但實際上，生成的鏡像多了五個新層：每一個層對應Dockerfile裡的一個語句。
現在，讓我們來試試Docker的多階段構建。
你可以繼續使用與上面相同的Dockerfile，只是現在要調用兩次：
FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM node:8
COPY --from=build /app /
EXPOSE 3000
CMD ["index.js"]
Dockerfile的第一部分創建了三個層，然後這些層被合併並複製到第二個階段。在第二階段，鏡像頂部又添加了額外的兩個層，所以總共是三個層。
現在來驗證一下。首先，構建容器：
$ docker build -t node-multi-stage .
查看鏡像的歷史：
$ docker history node-multi-stage
IMAGE CREATED BY SIZE
331b81a245b1 /bin/sh -c #(nop) CMD ["index.js"] 0B
bdfc932314af /bin/sh -c #(nop) EXPOSE 3000 0B
f8992f6c62a6 /bin/sh -c #(nop) COPY dir:e2b57dff89be62f77… 1.62MB
b87c2ad8344d /bin/sh -c #(nop) CMD ["node"] 0B/bin/sh -c set -ex && for key in 6A010… 4.17MB /bin/sh -c #(nop) ENV YARN_VERSION=1.3.2 0B /bin/sh -c ARCH= && dpkgArch="$(dpkg --print… 56.9MB /bin/sh -c #(nop) ENV NODE_VERSION=8.9.4 0B /bin/sh -c set -ex && for key in 94AE3… 129kB /bin/sh -c groupadd --gid 1000 node && use… 335kB /bin/sh -c set -ex; apt-get update; apt-ge… 324MB /bin/sh -c apt-get update && apt-get install… 123MB /bin/sh -c set -ex; if ! command -v gpg > /… 0B /bin/sh -c apt-get update && apt-get install… 44.6MB /bin/sh -c #(nop) CMD ["bash"] 0B /bin/sh -c #(nop) ADD file:1dd78a123212328bd… 123MB
文件大小是否已發生改變？
$ docker images | grep node-
node-multi-stage 331b81a245b1 678MB
node-vanilla 075d229d3f48 679MB
最後一個鏡像（node-multi-stage）更小一些。
你已經將鏡像的體積減小了，即使它已經是一個很小的應用程序。
但整個鏡像仍然很大！
有什麼辦法可以讓它變得更小嗎？
2. 用distroless去除容器中所有不必要的東西
這個鏡像包含了Node.js以及yarn、npm、bash和其他的二進制文件。因為它也是基於Ubuntu的，所以你等於擁有了一個完整的操作系統，其中包括所有的小型二進制文件和實用程序。
但在運行容器時是不需要這些東西的，你需要的只是Node.js。
Docker容器應該只包含一個進程以及用於運行這個進程所需的最少的文件，你不需要整個操作系統。
實際上，你可以刪除Node.js之外的所有內容。
但要怎麼做？
所幸的是，谷歌為我們提供了distroless。
以下是distroless存儲庫的描述：
“distroless”鏡像只包含應用程序及其運行時依賴項，不包含程序包管理器、shell以及在標準Linux發行版中可以找到的任何其他程序。
這正是你所需要的！
你可以對Dockerfile進行調整，以利用新的基礎鏡像，如下所示：
FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM gcr.io/distroless/nodejs
COPY --from=build /app /
EXPOSE 3000
CMD ["index.js"]
你可以像往常一樣編譯鏡像：
$ docker build -t node-distroless .
這個鏡像應該能正常運行。要驗證它，可以像這樣運行容器：
$ docker run -p 3000:3000 -ti --rm --init node-distroless
現在可以訪問http://localhost:3000頁面。
不包含其他額外二進制文件的鏡像是不是小多了？
$ docker images | grep node-distroless
node-distroless 7b4db3b7f1e5 76.7MB
只有76.7MB！
比之前的鏡像小了600MB！
但在使用distroless時有一些事項需要注意。
當容器在運行時，如果你想要檢查它，可以使用以下命令attach到正在運行的容器上：
$ docker exec -tibash
attach到正在運行的容器並運行bash命令就像是建立了一個SSH會話一樣。
但distroless版本是原始操作系統的精簡版，沒有了額外的二進制文件，所以容器裡沒有shell！
在沒有shell的情況下，如何attach到正在運行的容器呢？
答案是，你做不到。這既是個壞消息，也是個好消息。
之所以說是壞消息，因為你只能在容器中執行二進制文件。你可以運行的唯一的二進制文件是Node.js：
$ docker exec -tinode
說它是個好消息，是因為如果攻擊者利用你的應用程序獲得對容器的訪問權限將無法像訪問shell那樣造成太多破壞。換句話說，更少的二進制文件意味著更小的體積和更高的安全性，不過這是以痛苦的調試為代價的。
或許你不應在生產環境中attach和調試容器，而應該使用日誌和監控。
但如果你確實需要調試，又想保持小體積該怎麼辦？
3. 小體積的Alpine基礎鏡像
你可以使用Alpine基礎鏡像替換distroless基礎鏡像。
Alpine Linux是：
一個基於musl libc和busybox的面向安全的輕量級Linux發行版。
換句話說，它是一個體積更小也更安全的Linux發行版。
不過你不應該理所當然地認為他們聲稱的就一定是事實，讓我們來看看它的鏡像是否更小。
先修改Dockerfile，讓它使用node:8-alpine：
FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM node:8-alpine
COPY --from=build /app /
EXPOSE 3000
CMD ["npm", "start"]
使用下面的命令構建鏡像：
$ docker build -t node-alpine .
現在可以檢查一下鏡像大小：
$ docker images | grep node-alpine
node-alpine aa1f85f8e724 69.7MB
69.7MB！
甚至比distrless鏡像還小！
現在可以attach到正在運行的容器嗎？讓我們來試試。
讓我們先啟動容器：
$ docker run -p 3000:3000 -ti --rm --init node-alpine
Example app listening on port 3000!
你可以使用以下命令attach到運行中的容器：
$ docker exec -ti 9d8e97e307d7 bash
OCI runtime exec failed: exec failed: container_linux.go:296: starting container process caused "exec: "bash": executable file not found in $PATH": unknown
看來不行，但或許可以使用shell？
$ docker exec -ti 9d8e97e307d7 sh / #
成功了！現在可以attach到正在運行的容器中了。
看起來很有希望，但還有一個問題。
Alpine基礎鏡像是基於muslc的——C語言的一個替代標準庫，而大多數Linux發行版如Ubuntu、Debian和CentOS都是基於glibc的。這兩個庫應該實現相同的內核接口。
但它們的目的是不一樣的：
glibc更常見，速度也更快；
muslc使用較少的空間，並側重於安全性。
在編譯應用程序時，大部分都是針對特定的libc進行編譯的。如果你要將它們與另一個libc一起使用，則必須重新編譯它們。
換句話說，基於Alpine基礎鏡像構建容器可能會導致非預期的行為，因為標準C庫是不一樣的。
你可能會注意到差異，特別是當你處理預編譯的二進制文件（如Node.js C++擴展）時。
例如，PhantomJS的預構建包就不能在Alpine上運行。
你應該選擇哪個基礎鏡像？
你應該使用Alpine、distroless還是原始鏡像？
如果你是在生產環境中運行容器，並且更關心安全性，那麼可能distroless鏡像更合適。
添加到Docker鏡像的每個二進制文件都會給整個應用程序增加一定的風險。
只在容器中安裝一個二進制文件可以降低總體風險。
例如，如果攻擊者能夠利用運行在distroless上的應用程序的漏洞，他們將無法在容器中使用shell，因為那裡根本就沒有shell！
請注意，OWASP本身就建議儘量減少攻擊表面。
如果你只關心更小的鏡像體積，那麼可以考慮基於Alpine的鏡像。
它們的體積非常小，但代價是兼容性較差。Alpine使用了略微不同的標準C庫——muslc。你可能會時不時地遇到一些兼容性問題。
原始基礎鏡像非常適合用於測試和開發。
它雖然體積很大，但提供了與Ubuntu工作站一樣的體驗。此外，你還可以訪問操作系統的所有二進制文件。
再回顧一下各個鏡像的大小：
node:8 681MB
node:8 使用多階段構建為678MB
gcr.io/distroless/nodejs 76.7MB
node:8-alpine 69.7MB
文章很長，但是很實用，玩docker必會，覺得有用的話幫忙點贊轉發哦。
後面會分享更多關於自動化運維（devops）內容，感興趣的朋友可以關注下~
閱讀更多 波波說運維 的文章
