摘要：而項目代碼會隨著需求變更而經常變化。項目啟動后一般會有兩個目錄會寫入文件。

其實這個話題很簡單，不是很想寫這篇文章。不過的確還是有很多朋友在打包構建部署上存在一些問題，恰巧最近使用 Docker 部署了幾個 ThinkJS 相關的項目，所以還是拿出來說說吧。需要提前說明的是本文并不是 Docker 的基礎教程，默認大家都是了解 Docker 的。然后我會分享一下我覺得 ThinkJS 項目構建和部署過程中可能需要注意的點，我們先說說如何構建鏡像，然后再說一下可能出現的問題。

FROM mhart/alpine-node:8.9.4

首先推薦大家基于 mhart/alpine-node 的鏡像來構建，因為真的很小（20M左右）！不過因為小有很多的構建工具都不是很全，如果遇上一些安裝時需要編譯的模塊時可能會缺少環境，這個時候你可以選擇手動去安裝環境，當然也可以選擇使用 Docker 官方的 library/node 鏡像（800M左右），為了省事推薦這種情況下還是使用后者比較好。

COPY package.json /animaris/package.json
RUN npm i --production --registry=https://registry.npm.taobao.org

選好了基礎鏡像之后下面就需要拷貝項目文件了。這里推薦大家先把 packge.json 文件 COPY 進來然后安裝依賴。因為依賴的變化比較小，可以認為一段時間內這部分的鏡像層都是穩定的。而項目代碼會隨著需求變更而經常變化。綜上所述，我們選擇讓不變的鏡像層優先打包保證鏡像層的最大可復用性。

一個正常的 ThinkJS 項目其實線上運行只需要以下幾個文件：

app/：項目原始碼文件夾，如果是未編譯項目的話對應的是 src/ 目錄

view/：前端模板文件夾

www/：前端靜態資源文件夾

production.js：ThinkJS 啟動腳本

所以只要按照順序把這些文件 COPY 進去就可以了。

大家平常都習慣使用 PM2 來啟動 NodeJS 項目，它最大的好處就是能夠幫我們守護項目進程，當進程被殺死的時候能幫我們自動重啟。不過 Docker 本身就是有自動重啟的特性的，所以在很多層面上 Docker 和 PM2 一塊使用都有點沖突。其實因為 Docker 充當了守護的角色，我們完全可以直接使用 node production.js 命令去啟動。以下是一個完整的 ThinkJS 項目 Dockerfile 示例：

FROM mhart/alpine-node:8.9.4

WORKDIR /animaris
COPY package.json /animaris/package.json
RUN npm i --production --registry=https://registry.npm.taobao.org

COPY src /animaris/src
COPY view /animaris/view
COPY www /animaris/www
COPY production.js /animaris/production.js

ENV DOCKER=true
EXPOSE 8360
CMD [ "node", "/animaris/production.js" ]

使用如下命令進行構建：

docker build -t lizheming/animaris ./Dockerfile

之后使用如下命令運行鏡像，即可使用 http://localhost:8360 訪問網站：

docker run -p 8360:8360 lizheming/animaris

使用 Docker 一定不能忘記的特性就是容器銷毀后容器內的所有資源都是會被銷毀的，下回會重新初始化，所以如果是需要持久化保存的應避免寫到容器中，需要選擇外部的持久化存儲，例如 Volume 共享卷或者 S3 等相關服務。

ThinkJS 項目啟動后一般會有 logs, runtime 兩個目錄會寫入文件。其中 logs 是用來存儲線上日志用的，這個最好使用共享卷的形式外載出來，方便之后排查問題。runtime 這個是 ThinkJS 運行時臨時文件的存儲地方，例如 cache 和 session 等。session 會話默認是使用文件類型存儲的，如果使用 Docker 的話推薦選擇 MySQL 等外部存儲。其它的功能有相關需求也可以參考 session 服務。當然如果懶得用直接把 runtime 共享卷出來也是可以的。

還有就是如果有用戶上傳類的需求會上傳到本地文件夾上也要記得共享出來，否則丟數據就完蛋叻！

ThinkJS 一直主張在生產環境中使用 Nginx 來處理靜態資源，這樣不需要經過 Node 層直接 Server 轉發性能會更高。不過這樣就給鏡像打包造成了一定的麻煩，因為靜態資源也被打包到項目鏡像里去了，而 Nginx 鏡像正常是沒辦法跨鏡像讀取到文件的，所以就死解了。

在 ThinkJS 中是利用 think-resource 這個中間件來處理靜態資源的訪問的，然后它在線上環境的狀態是 enabled: false。其實靜態資源過一層 Node 并消耗不了多少資源，除非對性能有嚴苛要求的，我建議都可以直接把這個功能打開。這樣所有的請求都統一成 Nginx 轉發到 Node 鏡像，解決了 Nginx 需要跨鏡像讀取文件的問題。具體可參考官方文檔的“為什么上線后靜態資源訪問不了？”

module.exports = [
  ...
  {
    handle: "resource",
    enable: true // 始終開啟，默認為 `enable: isDev` 表示只再開發環境下開啟
  },
  ...
]

當然如果真的要在打包成一個鏡像的情況下用 Nginx 處理靜態資源也不是沒有辦法，我們可以利用共享卷來操作。Node 鏡像通過將鏡像文件共享卷的形式映射到本地，然后 Nginx 鏡像通過共享卷的形式將之前本地映射的文件再映射到鏡像中。這樣通過本地的一層轉發即可實現 Nginx 的跨鏡像訪問靜態資源。

# ThinkJS 鏡像
docker run 
    -v ./www:/app/www 
    -p 8360:8360 
lizheming/animaris

# Nginx 鏡像
docker run 
    -v ./nginx.conf:/etc/nginx/conf.d/animaris.conf 
    -v ./www:/var/www/animaris/www 
    -p 80:80 
nginx

server {
    listen 80;
    server_name animaris.eming.li;
    root /var/www/animaris/www;

    location ~ /static/ {
        etag         on;
        expires      max;
    }
}

平常我們是使用 development.js 和 production.js 來區分開發環境和生產環境的，然鵝這么打包之后發現都是生產環境了。這樣有時候我們需要不同環境不同配置就不太好弄了。這里推薦大家使用環境變量來區分。

think.env = process.ENV.ENV;

docker run -e ENV=test -p 8360:8360 lizheming/animaris

有用戶提出疑問 #1106，說“網站500了為啥 logs 里沒看到日志？”。這是因為雖然 ThinkJS 內部的日志都是用 think-logger 模塊處理了，但是因為跨模塊或者啟動時機的問題，有一些日志沒辦法走日志模塊記錄并存儲到文件，會直接打到終端里。所以當沒有日志的時候我們可以考慮去 docker logs 中撈一下終端的日志，說不定有意外的驚喜。

雖然文字寫了很多，除了一些普適問題需要考慮一下之外，其實整體來看真個構建過程還是很簡單的。同時也歡迎大家有什么問題和疑問留言交流。