本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 部署策略
<a name="deployment-strategies"></a>

 除了選擇正確的工具來更新您的應用程式程式碼和支援基礎設施之外，實作正確的部署程序是完整、功能良好的部署解決方案的關鍵部分。您選擇更新應用程式的部署程序，取決於您想要的控制、速度、成本、風險承受能力和其他因素平衡。

 每個 AWS 部署服務都支援多種部署策略。本節將概述可與部署解決方案搭配使用的一般用途部署策略。

# 預製與引導 AMIs
<a name="prebaking-vs.-bootstrapping-amis"></a>

 如果您的應用程式高度依賴於將應用程式自訂或部署到 Amazon EC2 執行個體，則您可以透過*引導*和*預先封裝*實務來最佳化部署。

 每當啟動 Amazon EC2 執行個體時，安裝您的應用程式、相依性或自訂稱為*引導*執行個體。如果您有複雜的應用程式或需要大量下載，這可能會降低部署和擴展事件的速度。

 [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (AMI) 提供啟動執行個體 （作業系統、儲存磁碟區、許可、軟體套件等） 所需的資訊。您可以從單一 AMI 啟動多個相同的執行個體。每當啟動 EC2 執行個體時，您都會選取要用作範本的 AMI。*Prebaking* 是在 AMI 中嵌入大部分應用程式成品的程序。

 將應用程式元件預先封裝到 AMI 可以加快啟動和操作 Amazon EC2 執行個體的時間。在部署過程中可以結合預製和引導實務，以快速建立針對目前環境自訂的新執行個體。

# 藍/綠部署
<a name="bluegreen-deployments"></a>

藍/綠部署是一種部署策略，您可以在其中建立兩個不同但相同的環境。一個環境 （藍色） 正在執行目前的應用程式版本，一個環境 （綠色） 正在執行新的應用程式版本。使用藍/綠部署策略可提高應用程式可用性，並在部署失敗時簡化復原程序，進而降低部署風險。在綠色環境中完成測試後，即時應用程式流量會導向綠色環境，並取代藍色環境。

 許多 AWS 部署服務支援藍/綠部署策略，包括 Elastic Beanstalk、OpsWorks、CloudFormation、CodeDeploy 和 Amazon ECS。如需為應用程式實作[藍/綠部署程序的詳細資訊和策略，請參閱 AWS 上的](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html)藍/綠部署。

# 滾動部署
<a name="rolling-deployments"></a>

 滾動部署是一種部署策略，透過完全取代應用程式執行所在的基礎設施，將舊版應用程式慢慢取代為新版應用程式。例如，在 Amazon ECS 的滾動部署中，執行舊版應用程式的容器將one-by-one取代為執行新版應用程式的容器。

 滾動部署通常比藍/綠部署更快；但是，與藍/綠部署不同，在滾動部署中，舊應用程式和新應用程式版本之間沒有環境隔離。這可讓滾動部署更快完成，但也會增加風險，並在部署失敗時使復原程序複雜化。

 滾動部署策略可與大多數部署解決方案搭配使用。如需使用 [CloudFormation 滾動部署的詳細資訊，請參閱 CloudFormation 更新政策](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html)；[使用 Amazon ECS 滾動更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html)，以取得使用 Amazon ECS 滾動部署的詳細資訊；[Elastic Beanstalk 滾動環境組態更新](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.rollingupdates.html)，以取得使用 Elastic Beanstalk 滾動部署的詳細資訊；以及在 [中使用滾動部署 AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/best-deploy.html#best-deploy-rolling)，以取得使用 OpsWorks 滾動部署的詳細資訊。 CloudFormation 

# Canary 部署
<a name="canary-deployments"></a>

 [Canary 部署](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html#canary-deployments)是一種藍/綠部署策略，風險更大。此策略涉及分階段方法，其中流量會以兩個增量轉移到應用程式的新版本。第一個增量是一小部分的流量，稱為 Canary 群組。此群組用於測試新版本，如果成功，流量會以第二個增量轉移到新版本。

 Canary 部署可以透過兩個步驟或線性方式實作。在兩步驟方法中，會部署並公開新的應用程式程式碼以供試用。接受時，它會以線性方式推展到環境的其餘部分。線性方法涉及逐漸增加應用程式新版本的流量，直到所有流量流向新版本為止。

# 就地部署：
<a name="in-place-deployments"></a>

 [就地部署](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/in-place-deployments.html)是一種部署策略，可在不取代任何基礎設施元件的情況下更新應用程式版本。在就地部署中，會停止每個運算資源上先前的應用程式版本、安裝最新的應用程式，並啟動和驗證應用程式的新版本。這可讓應用程式部署以對基礎基礎設施的最小干擾繼續。

 就地部署可讓您在不建立新基礎設施的情況下部署應用程式；不過，在這些部署期間可能會影響應用程式的可用性。此方法也會將與建立新資源相關的基礎設施成本和管理開銷降至最低。

 如需搭配 CodeDeploy 使用[就地部署策略的詳細資訊，請參閱就地部署的概觀](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-in-place)。

# 結合部署服務
<a name="combining-deployment-services"></a>

 AWS 上沒有適合所有部署解決方案的「單一大小」。在設計部署解決方案的情況下，請務必考慮應用程式的類型，因為這可以決定最適合的 AWS 服務。若要提供完整功能來佈建、設定、部署、擴展和監控您的應用程式，通常需要合併多個部署服務 

 AWS 應用程式常見的模式是使用 CloudFormation （及其擴充功能） 來管理一般用途的基礎設施，並使用更專業的部署解決方案來管理應用程式更新。在容器化應用程式的情況下，CloudFormation 可用於建立應用程式基礎設施，而 Amazon ECS 和 Amazon EKS 可用於佈建、部署和監控容器。

 AWS 部署服務也可以與第三方部署服務結合。這可讓組織輕鬆將 AWS 部署服務整合至其現有的 CI/CD 管道或基礎設施管理解決方案。例如，OpsWorks 可用來同步內部部署和 AWS 節點之間的組態，而 CodeDeploy 可與許多第三方 CI/CD 服務搭配使用，做為完整管道的一部分。