一千萬個為什麽

搜索


我正在使用CodePipeline,CodeCommit,CodeDeploy和CloudFormation實現CICD管道(我跳過了管道的構建部分,目前我將提交構建的代碼)。

我已經有了一個CloudFormation模板,可以創建托管應用程序所需的基礎架構,CodeDeploy應用程序(在嵌套堆棧中)和從CodeCommit獲取源代碼的CodePipeline,通過CodeDeploy進行就地部署,最後發送批準電子郵件(在嵌套堆棧中)。

我想實現以下內容:

  1. In order to create the required infrastructure to host the application for the first time, I launch a CloudFormation template that creates (I already have this):

    • The required infrastructure to host the application (AutoScalingGroup and Launch Config, TargetGroup and ListenerRules, IAM roles)
    • CodeDeploy Application and DeploymentGroup (this will be in a nested stack)
    • CodePipeline pipeline pre-configured to carry out the next steps (this will be in a nested stack)
  2. When source code is committed to CodeCommit, CodePipeline launches a new CloudFormation stack containing the required infrastructure to host the application, then deploys the new version of the code to this stack, without affecting the existing stack for the old version of this application. The new stack will have a listener rule with a different host name, so I can test the application while users keep using the old version;

  3. Once the code has been deployed, CodePipeline sends an approval email (through an SNS topic and I already have this);

  4. If the email is approved, the old stack (created in step 1. ) is deleted

  5. I will manually swap the listener rules for the two stacks to direct users to the new stack created in step 2, then delete the old stack.

我正在努力實施第2步,目前正在嘗試使用部署操作與CloudFormation部署提供程序執行上面的第2步。我正在努力將輸出工件(新源代碼)從前一階段傳遞到新堆棧。

您能否就如何實施 第2步 提供一些指導?

轉載註明原文: AWS CodePipeline分階段部署

一共有 1 個回答:

我設法建立了一個完成上述描述的環境。以下是完整的詳細信息:

  1. 啟動一個模板,為其創建一個CodeCommit存儲庫 應用。此存儲庫將用於存儲兩個源 代碼和CloudFormation(CF)模板來創建所需的 應用程序的基礎結構;
  2. 啟動一個模板,為其創建CodePipeline管道 應用。管道將為基礎架構部署堆棧 一個用於通過CodeDeploy部署代碼(CodeDeploy stack將創建一個新的CodeDeploy應用程序和部署 group,並將最新代碼部署到創建的基礎架構中 先前)

管道有一個參數“StackBlueeGreen”,用於確定堆棧是綠色還是藍色版本。

當管道成功運行時,它將創建一個單獨的基礎架構

(NameOfTheApplication-B或NameOfTheApplication-G)

並在那裏部署代碼。第二個基礎結構將具有自己的負載均衡器偵聽器規則設置和暫存URL

(類似於URLOfTheApplication-staging.somedomain.co.uk)

這允許開發人員測試新版本的應用程序,而不會影響以前的版本。一旦開發人員對新版本感到滿意,就需要手動更改新舊基礎架構的監聽器規則,以便現在將用戶定向到新的基礎架構。如果新版本存在問題,則回滾就像再次交換負載均衡器偵聽器規則一樣簡單。

最後,需要更新管道堆棧:StackBlueGreen參數需要根據當前設置的方式切換到G/B.如果不這樣做,下次發生更改時,新版本將部署在同一基礎架構上。

[上述設置非常有效,符合OP中列出的所有要求。 我真正想要實現的一項改進是自動切換負載均衡器監聽器規則,刪除舊基礎架構和更新管道堆棧。如果我設法實現這一改進,我將添加這個問題。 同時,任何輸入將非常感激!]