docker 變得越來越流行，它可以輕便靈活地隔離環境，進行擴容，方便運維管理。對開發者也更方便開發，測試與部署。
最重要的是， 當你面對一個陌生的項目，你可以照著 Dockerfile，甚至不看文檔(文檔也不一定全，全也不一定對)就可以很快讓它在本地跑起來。

現在很強調 devops 的理念，我把 devops 五個大字放在電腦桌面上，格物致知了一天。豁然開朗，devops 的意思就是寫一個 Dockerfile 去跑應用(開玩笑。

這里介紹如何使用 Docker 部署前端應用。千里之行，始于足下，足下的意思就是，先讓它能夠跑起來。

先讓它跑起來

首先，簡單介紹一下一個典型的前端應用部署流程

1. npm install, 安裝依賴
2. npm run build，編譯，打包，生成靜態資源
3. 服務化靜態資源

介紹完部署流程后，簡單寫一個 Dockerfile

FROM node:alpine

# 代表生產環境
ENV PROJECT_ENV production
WORKDIR /code
ADD . /code
RUN npm install && npm run build && npm install -g http-server
EXPOSE 80

CMD http-server ./public -p 80

現在這個前端服務已經跑起來了。接下來你可以完成部署的其它階段了。一般情況下，以下就成了運維的工作了，不過，拓展自己的知識邊界總是沒錯的。

• 使用 nginx 或者 traefik 做反向代理
• 使用 kubernetes 或者 compose 等做編排。
• 使用 gitlab ci 或者 drone ci 等做 CI/CD

這時鏡像存在有兩個問題，導致每次部署時間過長，不利于產品的快速交付

• 構建鏡像時間過長
• 構建鏡像大小過大，1G+

從 dependencies 和 devDependencies 下手

陸小鳳說過，一個前端程序員若是每天工作八個小時，至少有兩個小時是白白浪費了的。一個小時用來 npm install，另一個小時用來 npm run build。

對于每次部署，如果能夠減少無用包的下載，便能夠節省很多鏡像構建時間。eslint，mocha，chai 等代碼風格測試模塊可以放到 devDependencies 中。在生產環境中使用 npm install --production 裝包。

關于兩者的區別可以參考文檔 https://docs.npmjs.com/files/package.json.html#dependencies

FROM node:alpine

ENV PROJECT_ENV production
WORKDIR /code
ADD . /code
RUN npm install --production && npm run build && npm install -g http-server
EXPOSE 80

CMD http-server ./public -p 80

好像是快了那么一點點。

我們注意到，相對于項目的源文件來講，package.json 是相對穩定的。如果沒有新的安裝包需要下載，則再次構建鏡像時，無需重新裝包。則可以在 npm install 上節省一半的時間。

利用鏡像緩存

對于 ADD 來講，如果需要添加的內容沒有發生變化，則可以利用緩存。把 package.json 與源文件分隔開寫入鏡像是一個很好的選擇。目前，如果沒有新的安裝包更新的話，可以節省一半時間

FROM node:alpine

ENV PROJECT_ENV production

# http-server 不變動也可以利用緩存
RUN npm install -g http-server

WORKDIR /code

ADD package.json /code
RUN npm install --production

ADD . /code
RUN npm run build
EXPOSE 80

CMD http-server ./public -p 80

關于利用緩存有更多細節，需要特別注意一下，如 RUN git clone <repo> 的緩存此類

參考官方文檔 https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache

多階段構建

得益于緩存，現在鏡像構建時間已經快了不少。但是，鏡像的體積依舊過于龐大，也會增加每次的部署時間
考慮下每次 CI 部署的流程

1. 在構建服務器構建鏡像
2. 把鏡像推至鏡像倉庫服務器，
3. 在生產服務器拉取鏡像，啟動容器

顯而易見，鏡像體積過大造成傳輸效率低下，增加每次部署的延時。

即使，構建服務器與生產服務器在同一節點下，沒有延時的問題。減少鏡像體積也能夠節省磁盤空間

關于鏡像體積的過大，很大一部分是因為node_modules 臭名昭著的體積

但最后我們只需要 public 文件夾下的內容，對于源文件以及node_modules下文件，占用體積過大且不必要，造成浪費。
此時可以利用 Docker 的多階段構建，僅來提取編譯后文件

參考官方文檔 https://docs.docker.com/develop/develop-images/multistage-build/

FROM node:alpine as builder

ENV PROJECT_ENV production

# http-server 不變動也可以利用緩存
WORKDIR /code

ADD package.json /code
RUN npm install --production

ADD . /code
RUN npm run build

# 選擇更小體積的基礎鏡像
FROM nginx:alpine
COPY --from=builder /code/public /usr/share/nginx/html

此時，鏡像體積從 1G+ 變成了 50M+

使用 CDN

分析一下 50M+ 的鏡像體積，nginx:alpine 的鏡像是16M，剩下的40M是靜態資源。

如果把靜態資源給上傳到 CDN，則沒有必要打入鏡像了，此時鏡像大小會控制在 20M 以下

關于靜態資源，可以分類成兩部分

• /static，此類文件在項目中直接引用根路徑，打包時復制進 /public 下，需要被打入鏡像
• /build，此類文件需要 require 使用，會被 webpack 打包并加 hash 值，并可以通過 publicPath 修改資源地址。可以把此類文件上傳至 cdn，并加上永久緩存，不需要打入鏡像

FROM node:alpine as builder

ENV PROJECT_ENV production

# http-server 不變動也可以利用緩存
WORKDIR /code

ADD package.json /code
RUN npm install --production

ADD . /code
# npm run uploadCdn 是把靜態資源上傳至 cdn 上的腳本文件
RUN npm run build && npm run uploadCdn


# 選擇更小體積的基礎鏡像
FROM nginx:alpine
COPY --from=builder code/public/index.html code/public/favicon.ico /usr/share/nginx/html/
COPY --from=builder code/public/static /usr/share/nginx/html/static

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。