Merge pull request aws-samples#1 from awslabs/feature/feedback-approv…

…al-action

Feature/feedback approval action

README.md

@@ -1,6 +1,6 @@
 # Blue/Green deployments on ECS
 
-This reference architecture is in reference to blog post on [blue green deployments on ECS](https://aws.amazon.com/blogs/compute/bluegreen-deployments-with-amazon-ecs/). It creates a continuous delivery by leveraging AWS CloudFormation templates. The templates creates resources using Amazon's Code* services to build and deploy containers onto an ECS cluster as long running services. It also includes a manual approval step facilitated by lambda function that discovers and swaps target group rules between 2 target groups, promoting the green version to production and demoting the blue version to staging. 
+This reference architecture is in reference to blog post on [blue green deployments on ECS](https://aws.amazon.com/blogs/compute/bluegreen-deployments-with-amazon-ecs/). It creates a continuous delivery by leveraging AWS CloudFormation templates. The templates creates resources using Amazon's Code* services to build and deploy containers onto an ECS cluster as long running services. It also includes a manual approval step facilitated by lambda function that discovers and swaps target group rules between 2 target groups, promoting the green version to production and demoting the blue version to staging.
 
 ## Pre-Requisites
 This example uses [AWS Command Line Interface](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) to run Step-3 below.
@@ -64,25 +64,24 @@ Count | AWS resources
 
 
 ## Implementation details
-During first phase, the parent template (ecs-blue-green-deployment.yaml) kicks off creating VPC and the resources in deployment-pipeline template. This creates CodePipeline, CodeBuild and Lambda resources. Once this is complete, second phase creates the rest of resources such as ALB, Target Groups and ECS resources. Below is a screenshot of CodePipeline once all CloudFormation templates are completed
-
+During first phase, the parent template (ecs-blue-green-deployment.yaml) kicks off creating VPC and the resources in deployment-pipeline template.
+This creates CodePipeline, CodeBuild and Lambda resources. Once this is complete, second phase creates the rest of resources such as ALB,
+Target Groups and ECS resources. Below is a screenshot of CodePipeline once all CloudFormation templates are completed
 
 ![codepipeline](images/codepipeline.png)
 
-
-
-The templates create two services on ECS cluster and associates a Target Group to each service as depicted in the diagram. Blue Target Group is associated with Port 80 that represents Live/Production traffic and Green Target Group is associated with Port 8080 and is available for new version of the Application. During initial rollout, both Blue and Green service serve same application versions. As you introduce new release, CodePipeline picks those changes and are pushed down the pipeline using CodeBuild and deployed to the Green service. In order to switch from Green to Blue service (or from beta to Prod environment), you have to **Approve** the release by going to CodePipeline management console and clicking **Review** button. Approving the change will trigger Lambda function (blue_green_flip.py) which does the swap of ALB Target Groups. If you discover bugs while in Production, you can revert to previous application version by clicking and approving the change again. This in turn will put Blue service back into Production. To simplify identifying which Target Groups are serving Live traffic, we have added Tags on ALB Target Groups. Target Group **IsProduction** Tag will say **true** for Production application. 
-
+The templates create two services on ECS cluster and associates a Target Group to each service as depicted in the diagram.
+Blue Target Group is associated with Port 80 that represents Live/Production traffic and Green Target Group is associated with Port 8080 and is available for new version of the Application.
+The new version of the application can be tested by accessing the load balancer at port 8080, example http://LOAD_BALANCER_URL:8080 .If you want to restrict the traffic ranges accessing beta version of the code, you may modify the Ingress rules [here](https://github.com/awslabs/ecs-blue-green-deployment/blob/master/templates/load-balancer.yaml#L30).
+During initial rollout, both Blue and Green service serve same application versions.As you introduce new release, CodePipeline picks those changes and are pushed down the pipeline using CodeBuild and deployed to the Green service. In order to switch from Green to Blue service (or from beta to Prod environment), you have to _Approve_** the release by going to CodePipeline management console and clicking _Review_** button. Approving the change will trigger Lambda function (blue_green_flip.py) which does the swap of ALB Target Groups. If you discover bugs while in Production, you can revert to previous application version by clicking and approving the change again. This in turn will put Blue service back into Production. To simplify identifying which Target Groups are serving Live traffic, we have added Tags on ALB Target Groups. Target Group **IsProduction** Tag will say **true** for Production application.
 
 ![bluegreen](images/ecs-bluegreen.png)
 
-
-
 Here is further explaination for each stages of Code Pipeline.  
 
-<u>**Build stage**</u>
+**During Build stage**
 
-* During first phase of build stage, CodeBuild builds the docker container image and pushes to [Amazon ECR](https://aws.amazon.com/ecr/).
+* During first phase, CodeBuild builds the docker container image and pushes to [Amazon ECR](https://aws.amazon.com/ecr/).
 
 * During second phase, Codebuild executes scripts/deployer.py which executes the following scripted logic
 
@@ -100,10 +99,10 @@ Here is further explaination for each stages of Code Pipeline.
   If the load balancer does not exists (as found in step-2), this would imply that the stack is executed for the first time, and the values of "CONTAINER_TAG1" and CONTAINER_TAG2" will be the same and default to the
   value retrieved from build.json in step-1
 
-<u>**Deploy stage**</u>
+**During Deploy stage** 
 CodePipeline executes templates/ecs-cluster.yaml. The CloudFormation input parameters with KeyName as "Code1" and "Code2" are overwritten with the values as written in the build.json, retrieved from the second phase of Build Stage.
 
-<u>**Review stage**</u>
+**During Review stage** 
 The pipeline offers manual "Review" button so that the approver can review code and Approve new release.
 Providing approvals at this stage will trigger the Lambda function (blue_green_flip.py) which swaps the Green Target Group to Live traffic. You can checkout sample app to see new release change. blue_green_flip.py has the following logic scripted
 

templates/deployment-pipeline.yaml

@@ -359,7 +359,7 @@ Resources:
               OutputArtifacts:
                 - Name: DiscoveryOutput
               RunOrder: 2
-        - Name: Deploy
+        - Name: Deploy-Approve-Swap
           Actions:
             - Name: Deploy
               ActionTypeId:
@@ -391,36 +391,29 @@ Resources:
                 - Name: Template
                 - Name: DiscoveryOutput
               RunOrder: 1
-        -
-          Name: approve-blue-green-swap
-          Actions:
-          -
-            Name: approve-blue-green-swap
-            ActionTypeId:
-              Category: Approval
-              Owner: AWS
-              Version: 1
-              Provider: Manual
-            Configuration:
-              CustomData: "Continue with blue-green swap ?"
-            RunOrder: 1
-        -
-          Name: swap-target-group
-          Actions:
-          -
-            Name: swap-target-group
-            ActionTypeId:
-              Category: Invoke
-              Owner: AWS
-              Version: 1
-              Provider: Lambda
-            Configuration:
-              FunctionName: !Ref BlueGreenFlipLambda
-              UserParameters: !Sub |
-                {
-                  "ElbName": "${GitHubRepo}"
-                }
-            RunOrder: 1
+            - Name: approve-blue-green-swap
+              ActionTypeId:
+                Category: Approval
+                Owner: AWS
+                Version: 1
+                Provider: Manual
+              Configuration:
+                CustomData: "Continue with blue-green swap ?"
+              RunOrder: 2
+            - Name: swap-target-group
+              ActionTypeId:
+                Category: Invoke
+                Owner: AWS
+                Version: 1
+                Provider: Lambda
+              Configuration:
+                FunctionName: !Ref BlueGreenFlipLambda
+                UserParameters: !Sub |
+                  {
+                    "ElbName": "${GitHubRepo}"
+                  }
+              RunOrder: 3
+
 
 
 Outputs:

templates/load-balancer.yaml

@@ -27,7 +27,8 @@ Resources:
           IpProtocol: "TCP"
           FromPort: 80
           ToPort: 80
-        - CidrIp: !Ref VpcCIDR
+        - CidrIp: "0.0.0.0/0"
+        # Change above to !Ref VpcCIDR, if you want to restrict the beta version of the traffic to VPC CIDRs only
           IpProtocol: "TCP"
           FromPort: 8080
           ToPort: 8080