Capstone (1): Building the Target Infrastructure via CLI
The past fourteen articles built each service separately. The capstone assembles them all into one complete thing: a pipeline that carries code from commit to production on an elastic fleet, via blue/green, with approval and rollback. The capstone splits into two articles β this one (15) builds the target infrastructure, the next one (16) wires up the pipeline that runs into it. Splitting it this way makes the two parts clear: where the application runs, and the chain that delivers it there.
π° Cost
This infrastructure has one ALB and one ASG of two t3.micro instances; during a blue/green deploy (Article 16) there will temporarily be four instances. This is the expensive part β Article 16 tears it all down right after the run. Don't leave it overnight.
Goal
Assemble launch template + ASG + ALB + blue/green deployment group into a target environment ready for the pipeline, and understand how the pieces fit together.
Target architecture
Internet
β HTTP :80
ββββββββΌββββββββ
β ALB β awscicd-cap-alb (2 AZ)
ββββββββ¬ββββββββ
β target group awscicd-cap-tg
ββββββββΌββββββββββββββββββββ
β ASG awscicd-cap-asg β 2Γ t3.micro, each: httpd + CodeDeploy agent
β (launch template) β
βββββββββββββββββββββββββββββ
β²
CodeDeploy DG awscicd-cap-dg (BLUE_GREEN, rollback on)
β on deploy: copy ASG to green, shift traffic via ALB
The ALB receives traffic and routes it to healthy instances in the target group; the ASG keeps enough machines and replaces dead ones; the blue/green deployment group will (in Article 16) stand up a green fleet in parallel and shift traffic via the ALB.
Launch template and ASG
The launch template is the mold for creating instances: Amazon Linux 2023 AMI, t3.micro, an instance profile (read S3 β Article 8), a security group that opens HTTP, and user-data that installs httpd + the CodeDeploy agent:
#!/bin/bash
dnf install -y ruby wget httpd
systemctl enable --now httpd
cd /tmp && wget -q https://aws-codedeploy-ap-southeast-1.s3.ap-southeast-1.amazonaws.com/latest/install
chmod +x ./install && ./install auto
systemctl enable --now codedeploy-agent
$ aws ec2 create-launch-template --launch-template-name awscicd-cap-lt \
--launch-template-data file://lt.json
$ aws autoscaling create-auto-scaling-group --auto-scaling-group-name awscicd-cap-asg \
--launch-template "LaunchTemplateName=awscicd-cap-lt,Version=1" \
--min-size 2 --max-size 2 --desired-capacity 2 \
--vpc-zone-identifier "subnet-aaa,subnet-bbb"
ALB, target group, listener
$ aws elbv2 create-load-balancer --name awscicd-cap-alb --type application \
--subnets subnet-aaa subnet-bbb --security-groups <sg>
$ aws elbv2 create-target-group --name awscicd-cap-tg --protocol HTTP --port 80 \
--vpc-id <vpc> --health-check-path / --target-type instance
$ aws elbv2 create-listener --load-balancer-arn <alb> --protocol HTTP --port 80 \
--default-actions Type=forward,TargetGroupArn=<tg>
$ aws autoscaling attach-load-balancer-target-groups \
--auto-scaling-group-name awscicd-cap-asg --target-group-arns <tg>
Blue/green deployment group
The deployment group under application awscicd-demo (already exists) targets the ASG and target group, blue/green type, with rollback enabled on deploy failure:
$ aws deploy create-deployment-group --application-name awscicd-demo \
--deployment-group-name awscicd-cap-dg \
--service-role-arn arn:aws:iam::111122223333:role/awscicd-codedeploy-role \
--auto-scaling-groups awscicd-cap-asg \
--deployment-style deploymentType=BLUE_GREEN,deploymentOption=WITH_TRAFFIC_CONTROL \
--load-balancer-info '{"targetGroupInfoList":[{"name":"awscicd-cap-tg"}]}' \
--blue-green-deployment-configuration '{"terminateBlueInstancesOnDeploymentSuccess":{"action":"TERMINATE","terminationWaitTimeInMinutes":1},"deploymentReadyOption":{"actionOnTimeout":"CONTINUE_DEPLOYMENT"},"greenFleetProvisioningOption":{"action":"COPY_AUTO_SCALING_GROUP"}}' \
--auto-rollback-configuration enabled=true,events=DEPLOYMENT_FAILURE
(Remember: the CodeDeploy service role needs ec2:RunInstances/ec2:CreateTags/iam:PassRole permissions for blue/green with a launch template β added in Article 11.)
Confirm the infrastructure
$ aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names awscicd-cap-asg \
--query "length(AutoScalingGroups[0].Instances[?LifecycleState=='InService'])"
2
$ aws elbv2 describe-load-balancers --names awscicd-cap-alb --query 'LoadBalancers[0].DNSName'
"awscicd-cap-alb-1647114948.ap-southeast-1.elb.amazonaws.com"
Two instances InService, the ALB has a DNS name. At this point the instances run httpd with the default page β no application of ours yet. The pipeline in Article 16 will deploy the app onto them via blue/green. The target infrastructure is ready to serve as "production" for the chain.
π§Ή Cleanup
This infrastructure is used in Article 16, so keep it through the end of the capstone. Article 16 tears it all down (ASG, ALB, TG, launch template, deployment group). Because of the ALB + multiple EC2, don't leave it running overnight β if you pause between Articles 15 and 16, delete the ASG (delete-auto-scaling-group --force-delete) and the ALB first.
Summary
The capstone's target infrastructure wraps up exactly what Part IV taught: a launch template as the mold, an ASG keeping an elastic fleet behind an ALB, and a blue/green deployment group with rollback. Everything built via the CLI, each piece fitting the next β the ALB points at the target group, the ASG registers into the target group, the deployment group targets both the ASG and the target group to orchestrate blue/green. Two instances are running, waiting for an application.
The final article wires up the rest: a CodePipeline that carries code from CodeCommit, through build and test, through an approval gate, then blue/green deploys onto this very infrastructure β running end-to-end for real, then tearing everything down and wrapping up the whole series.