本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
最佳實務：管理和部署應用程式與技術指南
重要
該 AWS OpsWorks Stacks 服務於 2024 年 5 月 26 日終止使用壽命，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載移轉至其他解決方案。如果您對移轉有任何疑問，請透過 AWS Re: post
AWS OpsWorks Stacks 會從遠端儲存庫將應用程式和食譜部署到每個新執行個體。在執行個體的生命週期內，您必須經常更新堆疊的線上執行個體應用程式或技術指南，以新增功能、修正錯誤等等。有多種方法可以管理堆疊的應用程式和技術指南，但您使用的方法應該滿足下列一般要求：
-
所有生產堆疊執行個體應具有相同的應用程式和自訂技術指南程式碼，但某些有限的例外用於 A/B 測試等用途。
-
即使發生問題，部署更新也不應中斷網站的操作。
本節說明管理和部署應用程式與自訂技術指南的建議實務。
維持一致性
通常，您需要維持嚴格控制在生產堆疊上執行的應用程式或技術指南程式碼。一般而言，所有執行個體應執行目前已核准版本的程式碼。更新應用程式或技術指南以及因應特殊情況 (例如執行 A/B 測試) 時會出現例外情況，如稍後所述。
應用程式和技術指南程式碼會以兩種方式從指定來源儲存庫部署到堆疊的執行個體：
-
當您啟動執行個體時， AWS OpsWorks Stacks 會自動將目前的應用程式和食譜程式碼部署到執行個體。
-
對於線上執行個體，您必須透過執行部署命令 (適用於應用程式) 或更新自訂技術指南命令 (適用於技術指南) 來手動部署目前的應用程式或技術指南。
因為有兩種部署機制，所以仔細管理來源碼以避免在不同執行個體上無意中執行不同程式碼非常重要。例如，如果您從 Git 主分支部署應用程式或食譜， AWS OpsWorks Stacks 會當時部署該分支中的內容。如果您更新主分支中的程式碼，然後啟動新執行個體，該執行個體會將具有比舊執行個體的更新版程式碼。較新的版本甚至可能不受批准用於生產。
- 推薦：Amazon S3 檔案
-
為確保所有執行個體都具有核准的程式碼版本，建議您從 Amazon Simple Storage Service (Amazon S3) 檔部署應用程式和說明書。這可保證程式碼是必須明確更新的靜態人工因素 (.zip 或其他封存檔案)。此外，Amazon S3 非常可靠，因此您很少會無法存取存檔。為了進一步確保一致性，請使用命名慣例或使用 Amazon S3 版本控制來明確地對每個存檔檔案進行版本化，此版本提供了稽核追蹤，以及還原為舊版的簡單方法。
例如，您可以使用像是 Jenkins
的工具來建立部署管道。在您要部署的程式碼已認可和測試之後，請建立一個存檔檔案並將其上傳到 Amazon S3。所有應用程式部署或技術指南更新，都會在該封存檔案和安裝程式碼的每個執行個體中具有相同程式碼。 - 建議：Git 或 Subversion 儲存庫
-
如果您希望使用 Git 或 Subversion 儲存庫，請不要從主要分支部署。反之，請標記已核准版本並指定該版本為應用程式或技術指南來源。
部署程式碼到線上執行個體
AWS OpsWorks 堆疊不會自動將更新的程式碼部署到線上執行個體。您必須手動執行該操作，這會有下列挑戰：
-
有效部署更新，而不影響網站在部署程序中處理客戶請求的能力。
-
處理不成功的部署，可能是因為部署的應用程式或技術指南問題，也可能是部署程序本身的問題。
最簡單的方法是執行預設的部署命令 (適用於應用程式) 或更新自訂技術指南命令 (適用於技術指南)，會同時部屬每個執行個體的更新。這種方法非常簡單且快速，但沒有錯誤的餘地。若部署失敗或更新的程式碼發生任何問題，每個您生產堆疊中的執行個體都會受到影響，可能中斷或停用您的網站，直到您修正問題或是還原至先前版本為止。
建議：使用穩健的部署策略，可讓執行舊版本程式碼的執行個體繼續處理請求，直到您成功驗證部署並可以放心地傳輸所有傳入流量到新的版本。
下列各節提供兩個穩健部署策略的範例，接著會討論如何在部署期間管理後端資料庫。為簡潔起見，僅說明應用程式更新，但您也可以對技術指南使用類似的策略。
使用滾動部署
滾動部署會以多個階段更新堆疊之線上應用程式伺服器執行個體的應用程式。對於每個階段，您將更新線上執行個體的子集合，並在下一階段開始之前驗證更新是否成功。如果您遇到問題，仍在執行舊應用程式版本的執行個體可以繼續處理傳入流量，直到您解決問題為止。
下列範例假設您使用的建議做法，是跨多個可用區域分發堆疊的應用程式伺服器執行個體。
執行滾動部署
-
在部署應用程式頁面上，選擇 Advanced (進階)，然後選擇單一應用程式伺服器執行個體，並將應用程式部署到該執行個體。
如果您想要謹慎行事，您可以在部署應用程式之前從負載平衡器移除該執行個體。這可確保使用者不會遇到更新的應用程式，直到您驗證其正確運作。如果您使用 Elastic Load Balancing，請使用 Elastic Load Balancing 主控台、CLI 或 SDK 從負載平衡器移除執行個體。
-
請驗證更新的應用程式是否正常運作，以及執行個體是否具有可接受的效能指標。
如果您從 Elastic Load Balancing 負載平衡器移除執行個體，請使用 Elastic Load Balancing 主控台、CLI 或 SDK 來還原執行個體。更新的應用程式版本現在會處理使用者請求。
-
將更新部署到可用區域中的其餘執行個體，並驗證其是否正確運作並具有可接受的指標。
-
對堆疊的其他可用區域重複步驟 3，一次進行一個區域。如果您想要特別小心，請重複步驟 1-3。
注意
如果您使用 Elastic Load Balancing 負載平衡器，則可以使用其健康狀態檢查來確認部署是否成功。但是，請將 ping 路徑設定為檢查相依性並驗證一切是否正常運作的應用程式，而不是僅確認應用程式伺服器正在執行的靜態檔案。
使用單獨的堆疊
管理應用程式的另一種方法，是為應用程式生命週期的每個階段使用單獨的堆疊。不同的堆疊有時稱為環境。此模式可讓您對不可公開存取的堆疊進行開發和測試。當您準備好部署更新時，請將使用者流量從託管目前應用程式版本的堆疊，切換到託管更新版本的堆疊。
使用開發、暫存和生產堆疊
最常見的方法使用下列堆疊。
- 開發堆疊
-
使用開發堆疊執行任務，例如實作新功能或修正錯誤。開發堆疊實質上是一個原型生產堆疊，包含在生產堆疊中的相同 layer、應用程式、資源等等。由於開發堆疊通常不必處理與生產堆疊相同的負載，因此通常可以使用較少或較小的執行個體。
開發堆疊不公開；您可以控制存取，如下所示：
- 預備堆疊
-
使用預備堆疊來測試和完成更新生產堆疊的候選。當您完成開發，請透過複製開發堆疊來建立預備堆疊。然後在預備堆疊上執行測試套件，並將更新部署到該堆疊，以修正發生的問題。
預備堆疊也不公開；您可以像控制開發堆疊一樣控制堆疊和網路存取。請注意，當您複製開發堆疊以建立預備堆疊時，您可以複製 St AWS OpsWorks acks 權限管理授予的權限。不過，複製並不影響使用者的 IAM 政策所授予之許可。您必須使用 IAM 主控台、CLI 或軟體開發套件來修改這些許可。如需詳細資訊，請參閱 管理使用者許可。
- 生產堆疊
-
生產堆疊是公開堆疊，可支援您目前的應用程式。當預備堆疊通過測試，您可將其提升為生產堆疊，並淘汰舊的生產堆疊。如需如何執行此作業的範例，請參閱 使用藍/綠部署策略。
注意
您可以為每個堆 AWS OpsWorks 疊建立 AWS CloudFormation 範本，而不是使用「堆疊」主控台手動建立堆疊。這種方法具有下列優勢：
-
速度和便利性 — 當您啟動範本時， AWS CloudFormation 會自動建立堆疊，包括所有必要的執行個體。
-
一致性 — 將每個堆疊的範本儲存在原始碼儲存庫中，以確保開發人員針對相同用途使用相同的堆疊。
使用藍/綠部署策略
「藍/綠」部署策略的常見方法，是有效使用單獨堆疊來部署應用程式更新到生產堆疊。
-
藍色環境是生產堆疊，託管目前的應用程式。
-
綠色環境是預備堆疊，託管更新的應用程式。
當您準備好將更新的應用程式部署到生產環境，請將使用者流量從藍色堆疊切換到綠色堆疊，此綠色堆疊將成為新的生產堆疊。然後淘汰舊的藍色堆疊。
下列範例說明如何搭配 Route 53 和 E lastic Load Balancing 負載平衡器集區，使用 Stacks AWS OpsWorks 堆疊執行藍綠色部署。進行切換之前，您應該先確保下列各項：
-
綠色堆疊上的應用程式更新已通過測試，並準備好用於生產。
-
綠色堆疊與藍色堆疊相同，差別在於其包含已更新的應用程式且不公開。
兩個堆疊在每個 layer 中具有相同的許可、數目以及執行個體類型，相同以時間為基礎和以負載為基礎的組態等等。
-
所有綠色堆疊的全年無休執行個體、排定之以時間為基礎的執行個體都是在線。
-
您有一個 Elastic Load Balancing 負載平衡器集區，可以動態連接到任一堆疊中的層，並且可以預先加熱
以處理預期的流量量。 -
您已使用 Route 53 加權路由功能，在包含集區負載平衡器的託管區域中建立記錄集。
-
您已為負載平衡器指派了非零權重，該負載平衡器連接至藍色堆疊的應用程式伺服器 layer，並且為未使用的負載平衡器指派了零權重。這可確保藍堆疊的負載平衡器處理所有傳入流量。
將使用者切換至綠色堆疊
-
連接集區中其中一個未使用的負載平衡器到綠色堆疊的應用程式伺服器 layer。在某些情況下，例如，當您預期出現瞬間流量或如果您無法設定負載測試以逐步增加流量，請預先培養
負載平衡器以處理預期的流量。 -
在所有綠色堆疊的執行個體都通過 Elastic Load Balancing 健康狀態檢查之後，請變更 Route 53 記錄集中的權重，以便綠色堆疊的負載平衡器具有非零權重，而藍色堆疊的負載平衡器具有相應減少的權重。我們建議您先讓綠色堆疊處理一小部分請求，比方說 5%，而藍色堆疊處理其餘請求。您現在有兩個生產堆疊，綠色堆疊處理一些傳入請求，藍色堆疊處理其餘請求。
-
監控綠色堆疊的效能指標。如果可接受，請增加綠色堆疊的權重，以便其可以處理約 10% 的傳入流量。
-
請重複步驟 3，直到綠色堆疊處理約一半的傳入流量。此時任何問題都應已浮現，因此如果綠色堆疊的表現令人滿意，您可以透過將藍色堆疊的權重減少到零來完成程序。綠色堆疊現在是新的藍色堆疊，並處理所有傳入的流量。
-
從舊藍色堆疊的應用程式伺服器 layer 分離負載平衡器並傳回到集區。
-
雖然舊的藍色堆疊不再處理使用者請求，但我們建議保留一段時間，以防新藍色堆疊出現問題。若發生該情況，您可以透過反轉程序來復原更新，以將傳入流量引導回舊的藍色堆疊。當您確信新藍色堆疊的運作可接受，請關機舊藍色堆疊。
管理後端資料庫
如果您的應用程序依賴於後端數據庫，則需要從舊應用程序轉換為新應用程序。 AWS OpsWorks 堆棧支持以下數據庫選項。
- Amazon RDS 層
-
使用 Amazon Relational Database Service (Amazon RDS) 層，您可以分別建立 RDS 資料庫執行個體，然後將其註冊到堆疊中。您可以一次只用一個堆疊來註冊 RDS 資料庫執行個體，但您可以將 RDS 資料庫執行個體從某個堆疊切換到另一個堆疊。
AWS OpsWorks Stacks 會在您的應用程式伺服器上安裝含有連線資料的檔案，這種格式可讓您的應用程式輕鬆使用。 AWS OpsWorks 堆棧還將數據庫連接信息添加到堆棧配置和部署屬性中，這些屬性可以通過配方進行訪問。您也可以使用 JSON 提供應用程式的連線資料。如需詳細資訊，請參閱 連線至資料庫。
更新依賴於資料庫的應用程式會帶來兩個基本挑戰：
-
請確保在轉換期間正確記錄每個交易，同時避免新舊應用程式版本之間的競爭條件。
-
以限制對網站效能影響的方式執行轉換，並最大限度減少或排除停機時間。
使用本主題中說明的部署策略時，您不能僅從舊應用程式分離資料庫，再將其重新連接到新的應用程式。兩個版本的應用程式在轉換期間會平行執行，並且必須能夠存取相同的資料。下列說明了兩種管理轉換的方法，這兩種方法各自有其優點和挑戰之處。
- 方法 1：讓兩個應用程式連線到相同的資料庫
-
- 優點
-
-
在轉換期間沒有停機時間。
一個應用程式會逐漸停止存取資料庫，而另一個應用程式會逐漸接管。
-
您不需要同步兩個資料庫之間的資料。
-
- 挑戰
-
-
兩個應用程式都存取相同的資料庫，因此您必須管理存取以防止資料遺失或損壞。
-
如果您需要遷移到新的資料庫結構描述，則舊的應用程式版本必須能夠使用新的結構描述。
-
如果您使用不同的堆疊，此方法可能最適合 Amazon RDS，因為執行個體不會永久綁定到特定堆疊，而且可以由在不同堆疊上執行的應用程式存取。但是，您無法一次註冊具有多個堆疊的 RDS 資料庫執行個體，因此您必須向兩個應用程式提供連線資料，例如使用 JSON。如需詳細資訊，請參閱 使用自訂配方。
如果您使用滾動式升級，舊版和新的應用程式版本會託管在相同的堆疊上，因此您可以使用 Amazon RDS 或 MySQL 層。
- 方法 2：為每個應用程式版本提供自己的資料庫
-
- 優點
-
-
每個版本都有自己的資料庫，所以結構描述不需相容。
-
- 挑戰
-
-
在轉換期間同步兩個資料庫之間的資料，而不遺失或損壞資料。
-
確保您的同步程序不會導致嚴重停機時間，或大幅降低網站效能。
-
如果您使用單獨的堆疊，每個堆疊都有自己的資料庫。如果您使用滾動部署，則可以將兩個資料庫連接至堆疊，每個應用程式一個。如果舊應用程式和更新應用程式沒有相容的資料庫結構描述，則此方法更佳。
建議：一般而言，我們建議使用 Amazon RDS 層做為應用程式的後端資料庫，因為它更靈活，可用於任何轉換案例。如需有關如何處理轉換的詳細資訊，請參閱 Amazon RDS 使用者指南。
