NodeJS生產部署最佳實踐

Question

我正在尋找以一致且及時的方式將某些Web服務部署到生產中的方法。

我當前正在實施一個部署管道，該管道將以軟件的特定版本到Ansible所配置的多個虛擬機的手動部署操作結束。 想法是使用版本A設置x個實例，而已經有y個實例運行版本B。然后對流量進行鏡像和翻轉。 相同的機制應該允許我使用已經制作的映像在一組中擴展新的虛擬機。

我考慮過以下選項，但想知道是否有我忽略的事情：

1. TGZ

CI環境將從已經通過單元測試和集成測試的項目中構建一個tarball。 （可選）捆綁捆綁（消除了在生產計算機上運行npm install的需要，而依賴於與公共或私有npm存儲庫的網絡連接）。

我的主要問題是，依賴系統庫的所有依賴項都將構建在不同的機器上（盡管具有相同的映像）。 我不喜歡這樣

1. NPM

CI環境將發布到私有NPM存儲庫，而Ansible部署腳本將在配置后簽出特定版本。 同樣，當您要部署時，這又依賴於可用的外部服務。 我不喜歡這樣。

1. 混帳

作為供應的一部分，所有與系統相關的模塊都將被全局安裝，所有其他相關性都將檢入到存儲庫中。 這給了我靈活性，使其能夠執行差異部署，從而僅壓入增量，流程管理器幾乎可以立即自動重啟應用程序守護程序。 依賴關系然后被絕對鎖定。

這意味着除非擴大規模，否則就無需擴展新的VM。 部署可以直接推送到所有活動實例。

Answer 1

首先，無論采用哪種部署方法，都需要確保在部署新代碼時不要丟棄請求。 一種簡單的方法是在切換之前從負載均衡器中刪除節點。 在執行此操作之前，您可能還想嘗試評估是否有待處理的請求，打開的連接或其他任何因過早終止而帶來負面影響的東西。 或類似up模塊的東西。

大多數人不建議您對模塊進行源代碼控制。 似乎在使用package.json中的bundledDependencies聲明時，已經從npm install填充了node_modules的.tgz可能涵蓋了您的所有問題。 使用這種方法，您節點上的npm install將不會再次下載並安裝所有內容。 不過，它將重建node-gyp實現，這可能會涉及您的系統庫問題。

您還可以使用git標簽來更輕松地跟蹤具有特定依賴項和有效負載的版本。 手動部署代碼可能會很乏味，您可能需要考慮自動執行例程，同時從接口迭代數據庫中x數量的已知服務器條目。 docker.io可能很有趣。