nuxt&pm2：零停機部署
中文版：
nuxt是一個非常棒的vue.js框架，它使得建立ssr站點變得非常簡單。nuxt在引擎蓋下使用node.js服務器來呈現服務器端的頁面。
ssr有很多優點，在許多其他文章中都有深入的介紹，但是對于本文，我們將重點關注nuxt服務器的部署。
對于node.js應用程序來說，pm2是一個很好的進程管理器，它有許多很好的特性，包括通過“cluster mode”實現負載平衡。cluster mode創建node.js進程的多個實例，以便在不修改任何代碼的情況下跨多個cpu擴展應用程序。
除了利用多個cpu的性能優勢外，集群模式還允許通過一次重新加載一個實例來實現零停機部署。因此，如果您有4個實例在運行，您可以一次重新加載一個實例，而當一個實例正在重新加載時，其他3個實例將使服務器保持活動狀態。因此，服務器可以在不離線的情況下更新一秒。
對于大多數節點應用程序來說，設置和使用pm2集群模式非常容易，但是我們在嘗試將集群模式與nuxt服務器一起使用時遇到了一些問題。
首先，我們可以嘗試使用以下命令啟動nuxt服務器的單個實例：
pm2 start npm --name MyAppName -- start
但是，當嘗試啟動多個實例時，我們很快就會遇到問題。
例如，如果我們運行該命令兩次，就會遇到錯誤。
現在，雖然默認情況下是在“fork”模式下運行，但即使指定集群模式，也會遇到錯誤。
如果我們只使用一個實例并嘗試重新加載服務器呢？好吧，由于nuxt在幕后的工作方式，如果我們試圖在服務器運行時重建它，那么在刪除生成文件并為新的生成重新設置灰燼之后，我們將遇到404個錯誤。如果靜態文件夾中的文件發生更改，我們也會遇到問題。
因此，如果我們不能重建和重新加載服務器，并且不能運行多個實例，那么我們如何實現零停機部署？
正確配置PM2集群模式
我們之前遇到問題是因為我們試圖以“錯誤的方式”生成服務器的多個實例。在我們的實例中，我們讓pm2執行'npm run start'，實際上是啟動npm腳本執行的多個實例，而不是直接正確地啟動服務器。在啟動實例后，我們可以在控制臺中看到這一點：
[PM2] Starting /usr/bin/npm in fork_mode (1 instance)
如您所見，我們啟動npm，然后通過命令行參數告訴npm啟動服務器。相反，我們應該使用pm2直接調用服務器的啟動腳本。使用以下命令啟動nuxt服務器：
Nuxt start
但是，如果我們試圖告訴PM2啟動NUXT，它就不會起作用。相反，我們需要直接指向腳本nuxt調用，它位于
./node_modules/nuxt/bin/nuxt-start
現在用node_modules文件夾中的腳本啟動pm2會很乏味，必須有更好的方法。謝天謝地，有！pm2允許我們創建一個生態系統文件，它基本上是pm2命令的配置文件。我們可以指定諸如要運行的腳本、工作目錄、要生成多少實例以及別名等屬性。您可以在這里看到所有可用的屬性。
因此，現在我們知道需要運行什么腳本，并且知道需要使用什么設置來執行該腳本，我們可以通過運行以下命令來創建生態系統文件：
pm2 init
然后，我們將按如下方式配置此文件：
module.exports = {
apps : [{
name : 'MyAppName', // App name that shows in `pm2 ls`
exec_mode : 'cluster', // enables clustering
instances : 'max', // or an integer
cwd : './current', // only if using a subdirectory
script : './node_modules/nuxt/bin/nuxt-start', // The magic key
}]
};
您可能注意到我正在指定一個當前工作目錄（CWD）。我這么做是因為這允許我們在幕后交換服務器代碼，而不會遇到nuxt造成的限制。
我們通過創建如下文件結構來完成此操作：
/MyAppName
|--/releases
|----/v1.0.0
|----/v1.1.0
|----/v1.2.0
|----/...
|--/current -> /releases/v1.2.0 (symlink)
|--ecosystem.config.js
要啟動服務器，只需在/myappname目錄中運行以下命令：
pm2 start
現在要部署，我們只需將最新版本的repo克隆到“/releases”下的新文件夾，構建新版本（或者，您可以使用ci/cd服務提前構建該版本，并直接將這些構建文件上載到服務器）。然后我們將符號鏈接從/releases/v1.2.0更新到/releases/v1.3.0并運行：
pm2 reload MyAppName
成功！現在，您可以生成多個nuxt服務器實例以獲得更好的性能（在多線程系統上），并利用零停機部署在更新期間保持網站
希望這能幫助你充分利用你的項目！
英文版：
Nuxt & PM2: Zero Downtime Deployment
Nuxt is an awesome framework for Vue.js that makes setting up an SSR site super simple. Nuxt uses a Node.js server under the hood in order to render pages server side.
There are many advantages to SSR, which are covered in depth in many other posts, but for this post we are going to be focusing on the deployment of a Nuxt server.
PM2 is a great process manager for Node.js applications, with many great features including load balancing through “cluster mode.” Cluster mode creates multiple instances of a Node.js process in order to allow applications to be scaled across multiple CPUs without any code modifications.
Besides the performance advantage of utilizing multiple CPUs, cluster mode also allows for a zero downtime deployment by reloading the server process one instance at a time. Thus if you have 4 instances running, you can reload the server one instance at a time, and while one instance is reloading, the other 3 instances will keep the server alive. Thus a server can be updated without being taken offline for even a second.
Setting up and using PM2 cluster mode is extremely easy for most node applications, however we run into some issues attempting to use cluster mode with a Nuxt server.
First we can try starting a single instance of our nuxt server with the following command:
$ pm2 start npm --name MyAppName -- start
But we quickly run into issues when trying to start multiple instances.
For example, if we run that command twice, we’ll run into errors.
Now while that is by default running in “fork” mode, even if we specify cluster mode, we run into errors.
What if we only use 1 instance and attempt to reload the server? Well due to how Nuxt works under the hood, if we attempt to rebuild the server while it’s running, we’ll hit 404 errors after the build files are removed and rehashed for the new build. We also run into issues if files in our static folder are changed.
So if we can’t just rebuild and reload a server, and we can’t run multiple instances, then how do we achieve a zero downtime deployment?
Properly Configure PM2 Cluster Mode
We were running into issues previously because we were attempting to spawn multiple instances of our server in the “wrong way”. In our instance we are having PM2 execute npm run start which essentially is starting multiple instances of npm script executions, and not properly launching our server directly. We can see this in our console after starting an instance:
[PM2] Starting /usr/bin/npm in fork_mode (1 instance)
As you can see, we’re starting npm and then telling npm to start our server through it’s command line arguments. Instead of this, we should be using PM2 to call the server’s start script directly. Starting a Nuxt server is done with the following command:
Nuxt start
However, if we try to tell PM2 to start Nuxt, it won’t work. Instead, we need to point directly to the script Nuxt calls, which is located in
./node_modules/nuxt/bin/nuxt-start
Now starting PM2 with a script from the node_modules folder is going to be tedious, there has to be a better way. Thankfully, there is! PM2 allows us to create an Ecosystem File, which is basically a configuration file for our PM2 commands. We can specify properties such as the script to run, the working directory, how many instances to spawn, and an alias name. You can see all available properties here.
So now that we know what script we need to run, and we know what settings we need to execute that script with, we can create the ecosystem file by running the following command:
pm2 init
We’ll then configure this file as such:
module.exports = {
apps : [{
name : 'MyAppName', // App name that shows in `pm2 ls`
exec_mode : 'cluster', // enables clustering
instances : 'max', // or an integer
cwd : './current', // only if using a subdirectory
script : './node_modules/nuxt/bin/nuxt-start', // The magic key
}]
};
You may notice I’m specifying a current working directory (cwd). I’m doing this because this is what allows us to swap our server code behind the scenes without running into the limitations caused by Nuxt.
We do this by creating a file structure like this:
/MyAppName
|--/releases
|----/v1.0.0
|----/v1.1.0
|----/v1.2.0
|----/...
|--/current -> /releases/v1.2.0 (symlink)
|--ecosystem.config.js
To start our server, we just need to run the following command from within the /MyAppName directory:
pm2 start
Now to deploy we just clone the latest version of our repo to a new folder under ‘/releases’, build our new version (or alternatively, you can use a CI/CD service to build that version ahead of time, and directly upload those build files to the server). Then we just update the symlink from /releases/v1.2.0 to /releases/v1.3.0 and run:
pm2 reload MyAppName
Success! You’re now able to spawn multiple instances of your Nuxt server for better performance (on multi threaded systems), AND take advantage of zero downtime deployments to keep your website online during updates.
Hopefully this helps you make the most out of your project!
參考：
