docker 變得越來越流行，它可以輕便靈活地隔離環境，進行擴容，方便運維管理。對開發者也更方便開發，測試與部署。
最重要的是，當你面對一個陌生的項目，你可以照着 Dockerfile，甚至不看文檔(文檔也不一定全，全也不一定對)就可以很快讓它在本地跑起來。
現在很強調 devops 的理念，我把 devops 五個大字放在電腦桌面上，格物致知了一天。豁然開朗，devops 的意思就是寫一個 Dockerfile 去跑應用(開玩笑。
這裏介紹如何使用 Docker 部署前端應用。千里之行，始於足下，足下的意思就是，先讓它能夠跑起來。
- 原文地址: 如何使用 docker 高效部署前端
- 系列文章: 當我有一臺雲服務器時我做了什麼
如果對你能夠有所幫助，可以幫我在 shfshanyue/op-note 上點個 star。
先讓它跑起來
首先，簡單介紹一下一個典型的前端應用部署流程
-
npm install, 安裝依賴 -
npm run build，編譯，打包，生成靜態資源 - 服務化靜態資源
介紹完部署流程後，簡單寫一個 Dockerfile
FROM node:alpine
# 代表生產環境
ENV PROJECT_ENV production
# 許多 package 會根據此環境變量，做出不同的行爲
# 另外，在 webpack 中打包也會根據此環境變量做出優化，但是 create-react-app 在打包時會寫死該環境變量
ENV NODE_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/...
FROM node:alpine
ENV PROJECT_ENV production
ENV NODE_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
ENV NODE_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/devel...
多階段構建
得益於緩存，現在鏡像構建時間已經快了不少。但是，鏡像的體積依舊過於龐大，也會增加每次的部署時間
考慮下每次 CI 部署的流程
- 在構建服務器構建鏡像
- 把鏡像推至鏡像倉庫服務器，
- 在生產服務器拉取鏡像，啓動容器
顯而易見，鏡像體積過大造成傳輸效率低下，增加每次部署的延時。
即使，構建服務器與生產服務器在同一節點下，沒有延時的問題。減少鏡像體積也能夠節省磁盤空間
關於鏡像體積的過大，很大一部分是因爲node_modules 臭名昭著的體積
但最後我們只需要 public 文件夾下的內容，對於源文件以及node_modules下文件，佔用體積過大且不必要，造成浪費。
此時可以利用 Docker 的多階段構建，僅來提取編譯後文件
參考官方文檔 https://docs.docker.com/devel...
FROM node:alpine as builder
ENV PROJECT_ENV production
ENV NODE_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
ENV NODE_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歡迎關注公衆號山月行，我會定期分享一些前後端以及運維的文章，並且會有技術與生活上的每日回顧與總結，歡迎關注交流
