如何使用 docker 部署前端應用

docker 變得愈來愈流行，它能夠輕便靈活地隔離環境，進行擴容，方便運維管理。對開發者也更方便開發，測試與部署。

最重要的是， 當你面對一個陌生的項目，你能夠照着 Dockerfile，甚至不看文檔(文檔也不必定全，全也不必定對)就能夠很快讓它在本地跑起來。

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

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

本文地址 shanyue.tech/post/deploy…

先讓它跑起來

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

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

介紹完部署流程後，簡單寫一個 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 裝包。

關於二者的區別能夠參考文檔 docs.npmjs.com/files/packa…

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> 的緩存此類

參考官方文檔 docs.docker.com/develop/dev…

多階段構建

得益於緩存，如今鏡像構建時間已經快了很多。可是，鏡像的體積依舊過於龐大，也會增長每次的部署時間

考慮下每次 CI 部署的流程

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

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

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

關於鏡像體積的過大，很大一部分是由於node_modules 臭名昭著的體積

但最後咱們只須要 public 文件夾下的內容，對於源文件以及node_modules下文件，佔用體積過大且沒必要要，形成浪費。

此時能夠利用 Docker 的多階段構建，僅來提取編譯後文件

參考官方文檔 docs.docker.com/develop/dev…

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 複製代碼

---

關注公衆號山月行，記錄個人技術成長，歡迎交流