如何使用 docker 部署前端應用
如何使用 docker 部署前端應用
docker 變得越來越流行,它可以輕便靈活地隔離環境,進行擴容,方便運維管理。對開發者也更方便開發,測試與部署。
最重要的是, 當你面對一個陌生的專案,你可以照著 Dockerfile,甚至不看文件(文件也不一定全,全也不一定對)就可以很快讓它在本地跑起來。
現在很強調 devops 的理念,我把 devops 五個大字放在電腦桌面上,格物致知了一天。豁然開朗,devops 的意思就是寫一個 Dockerfile 去跑應用(開玩笑。
這裡介紹如何使用 Docker 部署前端應用。千里之行,始於足下,足下的意思就是,先讓它能夠跑起來。
本文地址 http://shanyue.tech/post/depl...
先讓它跑起來
首先,簡單介紹一下一個典型的前端應用部署流程
npm install npm run build
介紹完部署流程後,簡單寫一個 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/...
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/devel...
多階段構建
得益於快取,現在映象構建時間已經快了不少。但是,映象的體積依舊過於龐大,也會增加每次的部署時間
考慮下每次 CI 部署的流程
- 在構建伺服器構建映象
- 把映象推至映象倉庫伺服器,
- 在生產伺服器拉取映象,啟動容器
顯而易見,映象體積過大造成傳輸效率低下,增加每次部署的延時。
即使,構建伺服器與生產伺服器在同一節點下,沒有延時的問題。減少映象體積也能夠節省磁碟空間
關於映象體積的過大,很大一部分是因為node_modules 臭名昭著的體積
但最後我們只需要 public 資料夾下的內容,對於原始檔以及node_modules下檔案,佔用體積過大且不必要,造成浪費。
此時可以利用 Docker 的多階段構建,僅來提取編譯後文件
參考官方文件 https://docs.docker.com/devel...
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 RUN npm run build # 選擇更小體積的基礎映象 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