Express 教程第 7 部分:部署到生產環境
現在您已經建立(並測試)了一個很棒的 LocalLibrary 網站,您將希望將其安裝到公共 Web 伺服器上,以便圖書館工作人員和成員可以透過網際網路訪問。本文概述瞭如何找到主機來部署您的網站,以及為了使您的網站準備好投入生產,您需要做些什麼。
| 先決條件 | 完成所有之前的教程主題,包括 Express 教程第 6 部分:使用表單. |
|---|---|
| 目標 | 瞭解在哪裡以及如何將 Express 應用程式部署到生產環境。 |
概述
網站完成後(或完成“足夠”以開始公開測試),您需要將其託管在比您的個人開發計算機更公開、更易於訪問的地方。
到目前為止,您一直在 開發環境 中工作,使用 Express/Node 作為 Web 伺服器將您的網站共享到本地瀏覽器/網路,並使用(不安全)開發設定執行您的網站,這些設定會暴露除錯和其他私有資訊。在您可以在外部託管網站之前,您首先需要
- 選擇一個環境來託管 Express 應用程式。
- 對您的專案設定進行一些更改。
- 為您的網站設定生產級基礎設施。
本教程提供了有關選擇託管網站的選項的一些指導,簡要概述了為使您的 Express 應用程式準備好投入生產而需要做的事情,以及將 LocalLibrary 網站安裝到 Railway 雲託管服務的示例。
什麼是生產環境?
生產環境是由您將在其中執行您的網站以供外部使用的伺服器計算機提供的環境。該環境包括
- 執行網站的計算機硬體。
- 作業系統(例如 Linux 或 Windows)。
- 在您的網站編寫之上的程式語言執行時和框架庫。
- Web 伺服器基礎設施,可能包括 Web 伺服器、反向代理、負載均衡器等。
- 您的網站依賴的資料庫。
伺服器計算機可以位於您的場所,並透過快速連結連線到網際網路,但更常見的是使用託管在“雲”中的計算機。這實際上意味著您的程式碼在託管公司資料中心中的一些遠端計算機(或可能是“虛擬”計算機)上執行。遠端伺服器通常會以一定的價格提供一些保證的計算資源級別(例如 CPU、RAM、儲存記憶體等)和網際網路連線。
這種遠端可訪問的計算/網路硬體被稱為基礎設施即服務 (IaaS)。許多 IaaS 供應商提供在您必須安裝生產環境其他元件的選項,以預安裝特定作業系統。其他供應商允許您選擇功能更全面的環境,可能包括完整的 Node 設定。
注意: 預構建的環境可以使您的網站設定變得非常容易,因為它們減少了配置,但可用的選項可能會限制您使用不熟悉的伺服器(或其他元件),並且可能基於較舊版本的 OS。通常,最好自己安裝元件,以便您獲得所需的元件,以及當您需要升級系統的一部分時,您會知道從哪裡開始!
其他託管提供商支援 Express 作為平臺即服務 (PaaS) 產品的一部分。使用這種型別的託管時,您無需擔心大多數生產環境(伺服器、負載均衡器等),因為主機平臺會為您處理這些問題。這使得部署非常容易,因為您只需要專注於您的 Web 應用程式,而無需任何其他伺服器基礎設施。
一些開發人員會選擇 IaaS 提供的更高靈活性而不是 PaaS,而另一些開發人員會欣賞 PaaS 降低的維護開銷和更輕鬆的擴充套件。在您入門時,在 PaaS 系統上設定您的網站要容易得多,所以這就是我們將在本教程中所做的。
注意: 如果您選擇一個 Node/Express 友好的託管提供商,他們應該提供有關如何使用不同配置的 Web 伺服器、應用程式伺服器、反向代理等來設定 Express 網站的說明。例如,在 Digital Ocean Node 社群文件 中有許多針對各種配置的分步指南。
選擇託管提供商
有許多託管提供商被認為是積極支援或與Node(和Express)配合得很好。這些供應商提供不同型別的環境(IaaS、PaaS)以及不同價格的不同級別計算和網路資源。
注意: 託管解決方案很多,它們的服務和定價會隨著時間的推移而變化。雖然我們在下面介紹了一些選項,但值得在選擇託管提供商之前檢視這些選項和其他選項。
選擇主機時需要考慮的一些事項
- 您的網站可能有多忙以及滿足該需求所需的資料和計算資源的成本。
- 水平擴充套件(新增更多機器)和垂直擴充套件(升級到更強大的機器)的支援級別以及這樣做的成本。
- 供應商擁有資料中心的位置,以及訪問速度最快的位置。
- 主機歷史上的正常執行時間和停機時間表現。
- 用於管理網站的工具——它們是否易於使用以及它們是否安全(例如 SFTP 與 FTP)。
- 用於監控您的伺服器的內建框架。
- 已知限制。一些主機會故意阻止某些服務(例如電子郵件)。其他主機只在某些價格等級中提供一定數量的“即時”時間,或者只提供少量儲存空間。
- 其他好處。一些提供商將提供免費的域名和對 TLS 證書的支援,否則您需要付費才能獲得這些證書。
- 您所依賴的“免費”等級是否會隨著時間的推移而過期,以及遷移到更昂貴等級的成本是否意味著您一開始就應該使用其他服務!
好訊息是,當您入門時,有相當多的網站提供旨在用於評估和測試的“免費”計算環境。這些通常是資源相當有限的/有限的環境,您需要意識到它們可能會在某些介紹期後過期或具有其他限制。然而,它們非常適合在託管環境中測試低流量網站,並且可以在您的網站變得更繁忙時提供輕鬆的遷移到付費更多資源。
大多數提供商還提供一個“基本”或“愛好”等級,旨在用於小型生產網站,並提供更有用的計算能力級別和更少的限制。Railway、Heroku、Digital Ocean 和 Python Anywhere 是擁有相對便宜的基本計算等級(在每月 5 美元到 10 美元之間)的流行託管提供商的示例。
注意: 請記住,價格不是唯一的選擇標準。如果您的網站成功,您可能會發現可擴充套件性是最重要的考慮因素。
準備好您的網站以釋出
在釋出網站時要考慮的主要事項是 Web 安全性和效能。至少,您將希望修改資料庫配置,以便您可以使用不同的資料庫進行生產並保護其憑據,刪除在開發期間錯誤頁面上包含的堆疊跟蹤,整理您的日誌,並設定適當的標頭以避免許多常見的安全威脅。
在以下小節中,我們概述了您應該對您的應用程式進行的最重要的更改。
注意: Express 文件中還有其他有用的提示——請參閱 生產最佳實踐:效能和可靠性 和 生產最佳實踐:安全.
資料庫配置
到目前為止,在本教程中,我們已經使用了一個開發資料庫,其地址和憑據硬編碼到 app.js 中。由於開發資料庫不包含我們不介意被公開或損壞的任何資訊,因此洩露這些詳細資訊沒有特別風險。但是,如果您使用的是真實資料,尤其是個人使用者的資訊,那麼保護您的資料庫憑據非常重要。
因此,我們希望為生產使用與開發中不同的資料庫,並將生產資料庫憑據與原始碼分開,以便可以妥善保護它們。
如果您的託管提供商支援透過 Web 介面設定環境變數(就像許多提供商一樣),那麼一種方法是讓伺服器從環境變數中獲取資料庫 URL。下面,我們修改 LocalLibrary 網站以從名為 MONGODB_URI 的環境變數中獲取資料庫 URI(如果已設定,請使用您自己的資料庫 URL 而不是下面的佔位符)。
開啟 app.js 並找到設定 MongoDB 連線變數的行。它看起來像這樣
const mongoDB =
"mongodb+srv://your_user_name:your_password@cluster0.cojoign.mongodb.net/local_library?retryWrites=true&w=majority";
用以下程式碼替換該行,該程式碼使用 process.env.MONGODB_URI 從名為 MONGODB_URI 的環境變數中獲取連線字串(如果已設定,請使用您自己的資料庫 URL 而不是下面的佔位符)。
// Set up mongoose connection
const mongoose = require("mongoose");
mongoose.set("strictQuery", false);
const dev_db_url =
"mongodb+srv://your_user_name:your_password@cluster0.cojoign.mongodb.net/local_library?retryWrites=true&w=majority";
const mongoDB = process.env.MONGODB_URI || dev_db_url;
main().catch((err) => console.log(err));
async function main() {
await mongoose.connect(mongoDB);
}
注意: 另一種常見的將生產資料庫憑據與原始碼分開的方法是從一個單獨部署到檔案系統中的 .env 檔案中讀取它們(例如,它們可能使用 npm dotenv 模組讀取)。
將 NODE_ENV 設定為“production”
我們可以透過將 NODE_ENV 環境變數設定為 production 來刪除錯誤頁面中的堆疊跟蹤(預設情況下它設定為“development”)。除了生成不太詳細的錯誤訊息外,將變數設定為 production 還會快取從 CSS 擴充套件生成的檢視模板和 CSS 檔案。測試表明,將 NODE_ENV 設定為 production 可以將應用程式效能提高三倍!
此更改可以透過使用 export、環境檔案或 OS 初始化系統來完成。
注意: 這實際上是您在環境設定而不是您的應用程式中進行的更改,但在這裡值得注意!我們將在下面展示如何在我們的託管示例中設定它。
適當地記錄
日誌記錄呼叫會對高流量網站產生影響。在生產環境中,您可能需要記錄網站活動(例如跟蹤流量或記錄 API 呼叫),但您應該嘗試將為除錯目的新增的日誌記錄量降至最低。
在生產中減少“除錯”日誌記錄的一種方法是使用類似 debug 的模組,該模組允許您透過設定環境變數來控制執行哪些日誌記錄。例如,下面的程式碼片段展示瞭如何設定“author”日誌記錄。除錯變數以“author”命名,並且對於來自此物件的 所有日誌,將自動顯示字首“author”。
const debug = require("debug")("author");
// Display Author update form on GET.
exports.author_update_get = asyncHandler(async (req, res, next) => {
const author = await Author.findById(req.params.id).exec();
if (author === null) {
// No results.
debug(`id not found on update: ${req.params.id}`);
const err = new Error("Author not found");
err.status = 404;
return next(err);
}
res.render("author_form", { title: "Update Author", author: author });
});
然後,您可以透過在 DEBUG 環境變數中指定它們作為逗號分隔列表來啟用特定的一組日誌。您可以按照所示設定顯示作者和圖書日誌的變數(也支援萬用字元)。
#Windows
set DEBUG=author,book
#Linux
export DEBUG="author,book"
注意: 對 debug 的呼叫可以替換以前使用 console.log() 或 console.error() 進行的日誌記錄。將程式碼中的任何 console.log() 呼叫替換為透過 debug 模組進行日誌記錄。透過設定 DEBUG 變數來開啟和關閉開發環境中的日誌記錄,並觀察這對日誌記錄的影響。
如果需要記錄網站活動,可以使用 Winston 或 Bunyan 等日誌記錄庫。有關此主題的更多資訊,請參見:生產最佳實踐:效能和可靠性。
對響應使用 gzip/deflate 壓縮
Web 伺服器通常可以壓縮傳送回客戶端的 HTTP 響應,從而顯著減少客戶端獲取和載入頁面所需的時間。使用的壓縮方法將取決於客戶端在請求中宣告支援的解壓縮方法(如果客戶端不支援任何壓縮方法,則響應將以未壓縮形式傳送)。
使用 compression 中介軟體將此新增到您的網站。透過執行以下命令在專案的根目錄下安裝它。
npm install compression
開啟 ./app.js 並按所示要求壓縮庫。使用 use() 方法將壓縮庫新增到中介軟體鏈(這應該出現在您希望壓縮的任何路由之前——在本例中,是所有路由!)。
const catalogRouter = require("./routes/catalog"); // Import routes for "catalog" area of site
const compression = require("compression");
// Create the Express application object
const app = express();
// …
app.use(compression()); // Compress all routes
app.use(express.static(path.join(__dirname, "public")));
app.use("/", indexRouter);
app.use("/users", usersRouter);
app.use("/catalog", catalogRouter); // Add catalog routes to middleware chain.
// …
注意: 對於生產環境中的高流量網站,您不會使用此中介軟體。相反,您應該使用 Nginx 等反向代理。
使用 Helmet 防禦已知漏洞
Helmet 是一箇中間件包。它可以設定適當的 HTTP 頭,幫助保護您的應用程式免受眾所周知的 Web 漏洞(有關它設定的標頭和它防禦的漏洞的更多資訊,請參見 文件)。
透過執行以下命令在專案的根目錄下安裝它。
npm install helmet
開啟 ./app.js 並按所示要求 helmet 庫。然後使用 use() 方法將模組新增到中介軟體鏈。
const compression = require("compression");
const helmet = require("helmet");
// Create the Express application object
const app = express();
// Add helmet to the middleware chain.
// Set CSP headers to allow our Bootstrap and Jquery to be served
app.use(
helmet.contentSecurityPolicy({
directives: {
"script-src": ["'self'", "code.jquery.com", "cdn.jsdelivr.net"],
},
}),
);
// …
我們通常可能只插入 app.use(helmet()); 來新增對大多數網站有意義的安全相關標頭的 子集。但是,在 LocalLibrary 基礎模板 中,我們包含了一些 Bootstrap 和 jQuery 指令碼。這些指令碼違反了 helmet 的 預設 內容安全策略 (CSP),該策略不允許載入跨站點指令碼。為了允許載入這些指令碼,我們修改了 helmet 配置,以便它設定 CSP 指令以允許從指示的域載入指令碼。對於您自己的伺服器,您可以透過遵循 此處使用 helmet 的說明,根據需要新增/停用特定標頭。
向 API 路由新增速率限制
Express-rate-limit 是一箇中間件包,可用於限制對 API 和端點的重複請求。造成對您的網站進行過多請求的原因有很多,例如拒絕服務攻擊、暴力破解攻擊,甚至僅僅是行為異常的客戶端或指令碼。除了由於過多請求導致伺服器速度變慢而可能出現的效能問題外,您還可能因額外流量而被收費。此包可用於限制可以對特定路由或一組路由發出的請求數量。
透過執行以下命令在專案的根目錄下安裝它。
npm install express-rate-limit
開啟 ./app.js 並按所示要求 express-rate-limit 庫。然後使用 use() 方法將模組新增到中介軟體鏈。
const compression = require("compression");
const helmet = require("helmet");
const app = express();
// Set up rate limiter: maximum of twenty requests per minute
const RateLimit = require("express-rate-limit");
const limiter = RateLimit({
windowMs: 1 * 60 * 1000, // 1 minute
max: 20,
});
// Apply rate limiter to all requests
app.use(limiter);
// …
上面的命令將所有請求限制為每分鐘 20 次(您可以根據需要更改此值)。
注意: 如果您需要更高階的保護措施以防禦拒絕服務或其他型別的攻擊,也可以使用 Cloudflare 等第三方服務。
設定節點版本
對於包括 Express 在內的節點應用程式,package.json 檔案包含託管提供商確定應用程式依賴項和入口點檔案所需的一切。
我們當前 package.json 中唯一缺少的重要資訊是庫所需的節點版本。您可以透過輸入以下命令找到用於開發的節點版本。
>node --version
v16.17.1
開啟 package.json,並按所示新增此資訊作為 engines > node(使用系統上的版本號)。
"engines": {
"node": ">=16.17.1"
},
託管服務可能不支援指定的特定節點版本,但此更改應確保它嘗試使用具有相同主要版本號的版本,或更新的版本。
請注意,可能還有其他方法在不同的託管服務上指定節點版本,但 package.json 方法得到廣泛支援。
獲取依賴項並重新測試
在我們繼續之前,讓我們再次測試網站,並確保它沒有受到我們所做的任何更改的影響。
首先,我們需要獲取我們的依賴項。您可以在專案的根目錄下在終端中執行以下命令來執行此操作。
npm install
現在執行網站(有關相關命令,請參見 測試路由),並檢查網站是否按預期執行。
在 GitHub 中建立應用程式儲存庫
許多託管服務允許您從本地儲存庫或從基於雲的源版本控制平臺匯入和/或同步專案。這可以使部署和迭代開發變得更加容易。
在本教程中,我們將為庫設定一個 GitHub 帳戶和儲存庫,並使用 git 工具上傳原始碼。
注意: 如果您已經使用 GitHub 管理原始碼,則可以跳過此步驟!
請注意,使用原始碼管理工具是一種良好的軟體開發實踐,因為它允許您試用更改,並在需要時在實驗和“已知良好程式碼”之間切換!
步驟如下
- 訪問 https://github.com/ 並建立一個帳戶。
- 登入後,單擊頂層工具欄中的 + 連結,然後選擇 新建儲存庫。
- 填寫此表單中的所有欄位。雖然這些欄位不是強制性的,但強烈建議填寫。
- 輸入一個新的儲存庫名稱(例如 express-locallibrary-tutorial)和描述(例如“使用 Express(Node)編寫的 Local Library 網站”)。
- 在 新增 .gitignore 選擇列表中選擇 Node。
- 在 新增許可證 選擇列表中選擇您喜歡的許可證。
- 選中 使用 README 初始化此儲存庫。
警告: 預設的“公開”訪問許可權將使 所有 原始碼(包括您的資料庫使用者名稱和密碼)對網際網路上的任何人可見!確保原始碼 僅 從環境變數中讀取憑據,並且沒有任何硬編碼的憑據。
否則,選擇“私有”選項,僅允許選定的人員檢視原始碼。
- 按 建立儲存庫。
- 單擊新儲存庫頁面上的綠色 克隆或下載 按鈕。
- 從出現在對話方塊中的文字欄位中複製 URL 值。如果您使用了儲存庫名稱“express-locallibrary-tutorial”,則 URL 應類似於:
https://github.com/<your_git_user_id>/express-locallibrary-tutorial.git。
現在儲存庫 (“repo”) 已在 GitHub 上建立,我們要將其克隆(複製)到我們的本地計算機。
- 為您的本地計算機安裝 git(您可以在 此處 找到不同平臺的版本)。
- 開啟命令提示符/終端,並使用上面複製的 URL 克隆您的儲存庫。這將在當前目錄中建立儲存庫。bash
git clone https://github.com/<your_git_user_id>/express-locallibrary-tutorial.git - 導航到儲存庫資料夾。bash
cd express-locallibrary-tutorial
然後將您的應用程式原始檔複製到儲存庫資料夾中,使用 git 將它們作為儲存庫的一部分,並將它們上傳到 GitHub。
- 將您的 Express 應用程式複製到此資料夾(不包括 /node_modules,它包含您需要從 npm 獲取的依賴項檔案)。
- 開啟命令提示符/終端,並使用
add命令將所有檔案新增到 git。bashgit add -A - 使用
status命令檢查您即將commit的所有檔案是否正確(您要包含原始檔,而不是二進位制檔案、臨時檔案等)。它應該看起來有點像下面的列表。bashgit statusOn branch main Your branch is up-to-date with 'origin/main'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: ... - 滿意後,將檔案
commit到您的本地儲存庫。這相當於在更改上簽字,並將它們作為本地儲存庫的正式組成部分。bashgit commit -m "First version of application moved into GitHub" - 此時,遠端儲存庫尚未更改。最後一步是使用以下命令將您的本地儲存庫同步(
push)到遠端 GitHub 儲存庫。bashgit push origin main
此操作完成後,您應該能夠返回到您在 GitHub 上建立儲存庫的頁面,重新整理頁面,並看到您的整個應用程式現在已上傳。您可以使用此新增/提交/推送迴圈來繼續更新儲存庫,因為檔案會發生變化。
這是一個備份您的“普通”專案的最佳時機——雖然我們在以下部分中將要進行的一些更改可能對任何託管服務(或開發)上的部署有用,但其他更改可能沒有用。您可以使用命令列上的 git 執行此操作。
# Create branch vanilla_deployment from the current branch (main)
git checkout -b vanilla_deployment
# Push the new branch to GitHub
git push origin vanilla_deployment
# Switch back to main
git checkout main
# Make any further changes in a new branch
git pull upstream main # Merge the latest changes from GitHub
git checkout -b my_changes # Create a new branch
注意: Git 功能強大無比!要了解更多資訊,請參見 學習 Git。
示例:在 Glitch 上託管
本節提供了一個關於如何在 Glitch 上託管 LocalLibrary 的實用演示。
為什麼要選擇 Glitch?
我們選擇使用 Glitch 的原因有很多。
- Glitch 提供 免費入門計劃,該計劃是 真正 免費的,儘管有一些限制。它對所有開發人員來說都負擔得起,這一點對於 MDN 來說非常重要!
- Glitch 會處理基礎設施,因此您無需操心。不必擔心伺服器、負載均衡器、反向代理等等,這使得入門變得容易得多。
- 您在使用 Glitch 時將學習的技能和概念是可遷移的。
- 服務和計劃限制對我們使用 Glitch 進行教程沒有太大影響。例如
- 入門計劃每月僅提供 1000 個“專案小時”,該時間每月重置。當您正在積極編輯網站或有人訪問網站時,就會使用它。如果沒有人訪問或編輯網站,它將進入睡眠狀態。
- 入門計劃環境的容器 RAM 和儲存空間有限。對於本教程來說已經足夠了,特別是考慮到我們的資料庫託管在其他地方。
- 自定義域不受良好支援(截至撰寫本文時)。
- 您可以在 Glitch 技術限制頁面 中找到其他限制。
雖然 Glitch 適用於託管此演示,但您應該花時間確定它是否適合您自己的網站。
Glitch 如何工作?
Glitch 提供了一個基於 Web 的介面,您可以在其中從入門模板建立專案,或從 GitHub 匯入專案,然後新增和編輯專案檔案。當您進行更改時,專案將在其自己的隔離且獨立的虛擬化容器中構建和執行。
所有這些是如何“在幕後”工作的,這是一個謎——Glitch 沒有說明。很明顯,只要您建立一個相當標準的 nodejs web 應用程式(例如,使用package.json 來管理依賴項),並且不會消耗超過技術限制中列出的資源,您的應用程式應該“正常工作”。
應用程式執行後,可以使用私有資料(在.env 檔案中提供)進行生產配置。秘密資料中的值由應用程式以環境變數的形式讀取,正如您在上一節中所瞭解的那樣,這就是我們配置應用程式以獲取資料庫 URL 的方式。請注意,這些變數是秘密的:.env 不應包含在您的 GitHub 儲存庫中。
Glitch 編輯檢視還提供對 Web 應用程式環境的終端訪問,您可以使用它來處理 Web 應用程式,就好像它在您的本地機器上執行一樣。
這只是您入門所需的所有概述。接下來,我們將設定一個 Glitch 帳戶,從 GitHub 上傳 Library 專案,並將其連線到資料庫。
獲取 Glitch 帳戶
要開始使用 Glitch,您首先需要建立一個帳戶
- 訪問glitch.com,並點選頂部的工具欄中的註冊按鈕。
- 在彈出視窗中選擇 GitHub,使用您的 GitHub 憑據註冊。
- 然後您將登入到 Glitch 儀表盤:https://glitch.com/dashboard。
Node.js 版本故障排除
託管提供商通常支援某些最近釋出的 Node.js 版本的主要版本。如果您的package.json 檔案中指定的精確“次要”版本不受支援,它們通常會回退到它們支援的最近版本(而且通常這會正常工作)。
不幸的是,在撰寫本文時,Glitch 上支援的最高版本是 Node.js 16。如果您一直使用 Node.js 17 或更高版本進行開發,則應降低package.json 檔案中使用的版本,如所示。您還需要重新測試
"engines": {
"node": ">=v16"
},
Glitch計劃在未來更新 node 並使其保持更好的更新狀態——當您閱讀本文時,版本限制可能已經不存在。您可以上傳您的專案以檢視它是否可以構建,而不是降級node 版本。如果出現錯誤並且您的應用程式未載入,則應嘗試在 Glitch 編輯器中將package.json 中的node 版本設定為>=v16。
注意:您還可以透過在任何 Glitch 專案的終端中輸入以下命令來檢查支援的版本
ls -l /opt/nvm/versions/node | grep '^d' | awk '{ print $9 }'
從 GitHub 部署到 Glitch
接下來,我們將從 GitHub 匯入 Library 專案。首先從網站頂部選單中選擇儀表盤選項,然後選擇新建專案按鈕。Glitch 將顯示新專案的選項列表;選擇從 GitHub 匯入。
將出現一個彈出視窗。在彈出視窗中輸入您的 GitHub 庫儲存庫的 URL,然後按確定。下面,我們輸入了已完成專案的儲存庫。
然後,Glitch 將匯入專案,並顯示進度通知。完成後,它將顯示新專案的編輯檢視,如下所示。
您可以透過選擇分享按鈕來獲取即時站點 URL。
開啟一個新的瀏覽器選項卡,並將即時站點的連結複製到位址列中。本地圖書館網站應開啟並顯示來自開發資料庫的資料。
注意:此過程是從 GitHub 進行的一次性匯入。您還可以使用 GitHub 操作(例如glitch-project-sync)來保持 Glitch 和您的專案同步。
使用生產 MongoDB 資料庫
您應該為生產設定一個與開發不同的資料庫。雖然 Glitch 僅託管 SQLite 資料庫(並且我們已設定為使用 MongoDB),但許多其他站點提供 MongoDB 資料庫即服務。
一種選擇是按照教程前面部分中的設定 MongoDB 資料庫說明來設定一個新的生產資料庫。
要使生產資料庫可供庫應用程式訪問,請在專案的編輯檢視中開啟.env 檔案。輸入資料庫 URL 變數MONGODB_URI 和生產資料庫的 URL。當您在編輯器中輸入值時,網站會更新。
注意:我們沒有建立此檔案。它用於私有資料,並且在匯入到 Glitch 時自動建立。它永遠不會被匯出或複製。
其他配置變數
您會記得,在上一節中,我們需要將 NODE_ENV 設定為“production”才能提高效能並生成更少的詳細錯誤訊息。我們在設定MONGODB_URI 變數的同一檔案中執行此操作。
開啟.env 並新增一個值為production 的NODE_ENV 變數(請參閱上一節中的螢幕截圖)。
本地庫應用程式現在已設定並配置為生產使用。您可以透過網站介面新增資料,它應該像開發期間那樣工作(儘管對於無效頁面,公開的除錯資訊更少)。
注意:如果您只想新增一些測試資料,可以使用populatedb 指令碼(使用您的 MongoDB 生產資料庫 URL),如Express 教程第 3 部分:使用資料庫(使用 Mongoose)測試——建立一些專案部分所述。
在 Glitch 上除錯 Express 應用程式
Glitch 允許有效地進行除錯。您可以做的一些事情包括
- 選擇編輯檢視底部的日誌按鈕以檢視來自伺服器的日誌資訊,例如控制檯日誌輸出。
- 選擇編輯檢視底部的終端按鈕以在託管環境中開啟終端。您可以使用它在環境中執行命令和工具。例如,您可能使用
node -v來檢查 node 版本。 - 使用GLITCH 擴充套件 for VSCode 在 VSCode 中進行互動式除錯。
示例:在 Railway 上託管
本節提供了在Railway 上安裝LocalLibrary 的實用演示。
為什麼選擇 Railway?
警告:Railway 不再擁有完全免費的入門層。我們保留了這些說明,因為 Railway 有一些很棒的功能,對於某些使用者來說將是一個更好的選擇。
Railway 由於幾個原因而成為一個有吸引力的託管選項
- Railway 處理了大多數基礎設施,因此您無需這樣做。不必擔心伺服器、負載均衡器、反向代理等,可以更輕鬆地入門。
- Railway專注於開發和部署的開發人員體驗,這使得學習曲線比許多其他替代方案更快、更平滑。
- 使用 Railway 時將學習的技能和概念是可以轉化的。雖然 Railway 有一些出色的新功能,但其他流行的託管服務使用了許多相同的想法和方法。
- Railway 文件清晰完整。
- 該服務似乎非常可靠,如果您最終喜歡它,定價是可以預測的,並且擴充套件您的應用程式非常容易。
您應該花時間確定 Railway 是否適合您自己的網站。
Railway 如何工作?
每個 Web 應用程式都在其自己的隔離且獨立的虛擬化容器中執行。要執行您的應用程式,Railway 需要能夠設定適當的環境和依賴項,並瞭解如何啟動它。
Railway 使此操作變得容易,因為它可以根據“通用約定”的使用情況自動識別和安裝許多不同的 Web 應用程式框架和環境。例如,Railway 識別 node 應用程式,因為它們具有package.json 檔案,並且可以根據“鎖定”檔案確定用於構建的包管理器。例如,如果應用程式包含package-lock.json 檔案,Railway 知道使用npm 來安裝包,而如果它找到yarn.lock,它知道使用yarn。安裝完所有依賴項後,Railway 將在包檔案中查詢名為“build”和“start”的指令碼,並使用它們來構建和執行程式碼。
注意:Railway 使用Nixpacks 來識別用不同程式語言編寫的各種 Web 應用程式框架。您不需要了解有關本教程的更多資訊,但您可以在Nixpacks Node 中找到有關部署 node 應用程式的更多選項。
應用程式執行後,它可以使用環境變數中提供的資訊進行配置。例如,使用資料庫的應用程式必須使用變數獲取地址。資料庫服務本身可能由 Railway 或其他提供商託管。
開發人員透過 Railway 網站和使用特殊的命令列介面 (CLI) 工具與 Railway 互動。CLI 允許您將本地 GitHub 儲存庫與 railway 專案關聯,將儲存庫從本地分支上傳到即時站點,檢查正在執行的程序的日誌,設定和獲取配置變數等等。其中一個最實用的功能是,您可以使用 CLI 在與即時專案相同的環境變數下執行本地專案。
這只是您將應用程式部署到 Railway 所需的所有概述。接下來,我們將設定一個 Railway 帳戶,安裝我們的網站和資料庫,並試用 Railway 客戶端。
獲取 Railway 帳戶
要開始使用 Railway,您首先需要建立一個帳戶
- 訪問railway.app,並點選頂部的工具欄中的登入連結。
- 在彈出視窗中選擇 GitHub,使用您的 GitHub 憑據登入
- 然後您可能需要訪問您的電子郵件並驗證您的帳戶。
- 然後您將登入到 Railway.app 儀表盤:https://railway.app/dashboard。
從 GitHub 部署到 Railway
接下來,我們將設定 Railway 以從 GitHub 部署我們的庫。首先從網站頂部選單中選擇儀表盤選項,然後選擇新建專案按鈕
Railway 將顯示新專案的選項列表,包括從首先在您的 GitHub 帳戶中建立的模板部署專案的選項,以及許多資料庫。選擇從 GitHub 儲存庫部署。
在設定過程中與 Railway 共享的 GitHub 倉庫中的所有專案都將顯示。選擇你的 GitHub 倉庫作為本地庫:<user-name>/express-locallibrary-tutorial。
選擇**立即部署**確認你的部署。
Railway 隨後將載入並部署你的專案,在部署選項卡上顯示進度。部署成功完成後,你將看到如下所示的螢幕。
現在選擇*設定*選項卡,然後向下滾動到域名部分,並按下**生成域名**按鈕。
這將釋出網站並將域名替換按鈕,如下所示。
選擇域名 URL 開啟你的庫應用程式。注意,由於我們尚未指定生產資料庫,本地庫將使用你的開發資料開啟。
配置並連線 MongoDB 資料庫
接下來,讓我們建立一個生產 MongoDB 資料庫來替代使用我們的開發資料。我們將作為 Railway 應用程式專案的一部分建立資料庫,儘管你可以在單獨的專案中建立資料庫,或者使用MongoDB Atlas資料庫作為生產資料,就像你對開發資料庫所做的那樣。
在 Railway 上,從網站頂部的選單中選擇**儀表板**選項,然後選擇你的應用程式專案。在此階段,它僅包含一個用於應用程式的服務(可以選擇此服務來設定變數和服務的其他詳細資訊)。選擇**新建**按鈕,用於將服務新增到當前專案。
當提示新增服務的型別時,選擇**資料庫**。
然後選擇**新增 MongoDB**開始新增資料庫。
Railway 隨後將在同一專案中配置一個包含空資料庫的服務。完成後,你將看到專案檢視中的應用程式和資料庫服務。
選擇 MongoDB 服務以顯示有關資料庫的資訊。開啟*變數*選項卡並複製"Mongo_URL"(這是資料庫的地址)。
為了使庫應用程式能夠訪問此地址,我們需要使用環境變數將其新增到應用程式程序中。首先開啟應用程式服務。然後選擇*變數*選項卡並按下**新建變數**按鈕。
輸入變數名稱MONGODB_URI和複製的資料庫連線 URL(MONGODB_URI是環境變數的名稱,我們已使用它配置應用程式以讀取資料庫地址)。這將類似於下面顯示的螢幕。
選擇**新增**新增變數。
Railway 在更新變數時會重啟你的應用程式。如果你現在檢查主頁,應該會看到物件計數為零,因為上面的更改意味著我們現在使用的是一個新的(空的)資料庫。
其他配置變數
你將回憶起在前面部分中,我們需要將 NODE_ENV 設定為'production'以提高效能並生成更少的詳細錯誤訊息。我們可以在設定MONGODB_URI變數的同一螢幕中執行此操作。
開啟應用程式服務。然後選擇*變數*選項卡,你將看到MONGODB_URI已定義,並按下**新建變數**按鈕。
輸入NODE_ENV作為新變數的名稱,輸入production作為環境的名稱。然後按下**新增**按鈕。
本地庫應用程式現已設定並配置為生產使用。你可以透過網站介面新增資料,它應該像開發期間一樣工作(儘管對於無效頁面顯示的除錯資訊更少)。
**注意:**如果你只想新增一些資料進行測試,你可以使用populatedb指令碼(使用你的 MongoDB 生產資料庫 URL),如部分Express 教程第 3 部分:使用資料庫(使用 Mongoose)測試 - 建立一些專案中所述。
安裝客戶端
按照此處說明下載並安裝適用於本地作業系統的 Railway 客戶端。
客戶端安裝完成後,你將能夠執行命令。一些更重要的操作包括將計算機的當前目錄部署到關聯的 Railway 專案(無需上傳到 GitHub),以及在生產伺服器上使用相同設定在本地執行專案。
你可以在終端中輸入以下內容以獲取所有可能命令的列表。
railway help
除錯
Railway 客戶端提供 logs 命令以顯示日誌尾部(每個專案的網站上提供了更完整的日誌)
railway logs
總結
這是關於在生產環境中設定 Express 應用程式以及使用 Express 的一系列教程的結束。我們希望你發現它們有用。你可以在此處在 GitHub 上檢視原始碼的完整實現版本。
另請參閱
- 生產最佳實踐:效能和可靠性(Express 文件)
- 生產最佳實踐:安全性(Express 文件)
- Railway 文件
- Digital Ocean
- Heroku
- Heroku 上的 Node.js 入門(Heroku 文件)
- 在 Heroku 上部署 Node.js 應用程式(Heroku 文件)
- Heroku Node.js 支援(Heroku 文件)
- 最佳化 Node.js 應用程式併發(Heroku 文件)
- Heroku 的工作原理(Heroku 文件)
- Dynos 和 Dyno 管理器(Heroku 文件)
- 配置和配置變數(Heroku 文件)
- 限制(Heroku 文件)