To make the ALB understand the type of traffic it is handling, we can use the concept oflisteners. They identify the protocol, port, and actions to take when packets are received. Listeners also map to a target group, which is where the matching traffic needs to be forwarded:
Target groups are the entities where EC2 instances are registered by the Auto Scaling groups. We are using the !Ref keyword here to reference other resources within the same template.
All CloudFormation resources have a specific return value. It could be an ARN, ID, name, or something else. When authoring templates, you need to validate these details in the respective docs’ sections. If you need to extract a value other than the default, CloudFormation offers a Fn::GetAtt function, which can help you extract a specific attribute.
Auto Scaling groups and launch templates
These are the components that are responsible for configuring and maintaining the compute fleet at any given point. Auto Scaling groups define a minimum, maximum, and desired number of instances in the compute fleet. It also maps to a target group, where instances can be deployed.
The configurations of the instances are taken care of by launch templates. They define the AMI, instance family, instance type, and so on:
Deploying the application stack
A complete version of the application stack template can be found at https://github.com/PacktPublishing/AWS-DevOps-Simplified/blob/main/chapter-4/ cfn-templates/application-stack.yml.
Similar to how we deployed the infrastructure stack, we will now use the Docker toolbox to roll out application resources. This stack expects two parameters to be injected – the AMI ID and the network stack’s name:
After a successful deployment, we can retrieve the stack outputs, which should give us the ALB domain name where the application can be accessed:
aws-devops-simplified:~/environment/chapter-4/$ aws cloudformation describe-stacks –stack-name application-stack –region eu-central-1
Since two EC2 instances are running in the background, you will see random instance IDs being returned in the browser, as seen in Figure 4.5:
Figure 4.5: ALB requests randomly forwarded to both instances
Summary
In this chapter, we discussed the benefits of using IaC. Applying the DevOps principles of software engineering to infrastructure management has a lot of benefits. This allows you to focus on the application needs and, at the same time, increases the reliability and confidence of rolling out infrastructure changes at scale.
We started by providing a basic understanding of AWS CloudFormation constructs and discussed its capabilities, and then concluded this chapter with hands-on activities around deploying infrastructure and application stacks. This should give you a strong start to managing your AWS resources with confidence. The best practices we covered were mainly aligned around organizational challenges when dealing with multiple teams and accounts. Adhering to these guidelines will improve the agility of your teams and promote reusability – which are critical pillars of the DevOps journey.
In Chapter 5, Rolling Out a CI/CD pipeline, we’ll discuss how to automate the build, test, and deployment activities for your application stack.
Further reading
To learn more about the topics that were covered in this chapter, take a look at the following resources:
- Sample CloudFormation templates targeting common use cases: https://docs.aws. amazon.com/AWSCloudFormation/latest/UserGuide/cfn-sample-templates.html
- Identify insecure infrastructure patterns with cfn-nag: https://github.com/ stelligent/cfn_nag
- Validate CloudFormation templates against a resource specification: https://github. com/aws-cloudformation/cfn-lint