歡迎光臨
每天分享高質量文章

如何使用 Docker 高效部署前端應用

Docker 變得越來越流行,它可以輕便靈活地隔離環境,進行擴容,方便運維管理。對開發者也更方便開發,測試與部署。
最重要的是,當你面對一個陌生的專案,你可以照著 Dockerfile,甚至不看文件(文件也不一定全,全也不一定對)就可以很快讓它在本地跑起來。
現在很強調 DevOps 的理念,我把 DevOps 六個大字放在電腦桌面上,格物致知了一天。豁然開朗,DevOps 的意思就是寫一個 Dockerfile 去跑應用(開玩笑)。
這裡介紹如何使用 Docker 部署前端應用。千里之行,始於足下,足下的意思就是,先讓它能夠跑起來。
先讓它跑起來

 

首先,簡單介紹一下一個典型的前端應用部署流程:
  • npm install,安裝依賴

  • npm run build,編譯,打包,生成靜態資源

  • 服務化靜態資源

 

介紹完部署流程後,簡單寫一個 Dockerfile:
  1. FROM node:alpine
  2. # 代表生產環境
  3. ENV PROJECT_ENV production
  4. WORKDIR /code
  5. ADD . /code
  6. RUN npm install && npm run build && npm install -g http-server
  7. EXPOSE 80
  8. 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
  1. FROM node:alpine
  2. ENV PROJECT_ENV production
  3. WORKDIR /code
  4. ADD . /code
  5. RUN npm install --production && npm run build && npm install -g http-server
  6. EXPOSE 80
  7. CMD http-server ./public -p 80

 

好像是快了那麼一點點。
我們註意到,相對於專案的源檔案來講,package.json 是相對穩定的。如果沒有新的安裝包需要下載,則再次構建鏡像時,無需重新裝包。則可以在 npm install 上節省一半的時間。
利用鏡像快取

 

對於 ADD 來講,如果需要添加的內容沒有發生變化,則可以利用快取。把 package.json 與源檔案分隔開寫入鏡像是一個很好的選擇。目前,如果沒有新的安裝包更新的話,可以節省一半時間:
  1. FROM node:alpine
  2. ENV PROJECT_ENV production
  3. # http-server 不變動也可以利用快取
  4. RUN npm install -g http-server
  5. WORKDIR /code
  6. ADD package.json /code
  7. RUN npm install --production
  8. ADD . /code
  9. RUN npm run build
  10. EXPOSE 80
  11. CMD http-server ./public -p 80

 

關於利用快取有更多細節,需要特別註意一下,如 RUN git clone的快取此類。
參考官方文件: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/
  1. FROM node:alpine as builder
  2. ENV PROJECT_ENV production
  3. # http-server 不變動也可以利用快取
  4. WORKDIR /code
  5. ADD package.json /code
  6. RUN npm install --production
  7. ADD . /code
  8. RUN npm run build
  9. # 選擇更小體積的基礎鏡像
  10. FROM nginx:alpine
  11. 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,並加上永久快取,不需要打入鏡像。

 

  1. FROM node:alpine as builder
  2. ENV PROJECT_ENV production
  3. # http-server 不變動也可以利用快取
  4. WORKDIR /code
  5. ADD package.json /code
  6. RUN npm install --production
  7. ADD . /code
  8. # npm run uploadCdn 是把靜態資源上傳至 cdn 上的腳本檔案
  9. RUN npm run build && npm run uploadCdn
  10. # 選擇更小體積的基礎鏡像
  11. FROM nginx:alpine
  12. COPY --from=builder code/public/index.html code/public/favicon.ico /usr/share/nginx/html/
  13. COPY --from=builder code/public/static /usr/share/nginx/html/static
原文鏈接:https://blog.xiange.tech/post/deploy-frontend-with-docker/

赞(0)

分享創造快樂