I’ve been studying for the AWS Certified DevOps Engineer exam and CloudFormation is a big topic.
Understanding the more complex ways to configure interrelated stacks is a must know for this exam.
I like to learn by doing and I started to wonder if I could create a minimalist set of CloudFormation templates that could demonstrate all the ways of inter relating stacks.
This post is the result of that effort.
Architecture Heuristics: Requirements, Constraints, Desirements, Applicability, Limitations and Alternatives
I find it very helpful to enumerate architecture heuristics of a pattern as it helps with:
keeping track of the architecture that emerged from the ‘design by building’ effort.
my own recollection of the value of a pattern when examining past things I’ve done for a new solution.
others quickly understanding the all the points of value of an offered solution - helping guide whether they want to invest in learning how it works.
facilitating customization or refactoring of the code by distinguishing purpose designed elements versus incidental elements.
I specifically like the model of using Constraints, Requirements, Desirements, Serendipities, Applicability, Limitations and Alternatives as it helps indicate the optimization of the result without stating everything as a “requirement”. This model is also more open to emergent architecture elements that come from the build effort itself.
- Requirement: (Satisfied) Create a Working Reference Pattern.
- Requirement: (Satisfied) Demonstrate all major native methods of interconnecting CloudFormation templates / stacks.
- Constraint: (Satisfied) With the simplest possible stacks. (Exception: Reusing the ASG stack means it is not as simple as possible for this purpose - but makes the result easier to demonstrate and debug)
- Constraint: (Satisfied) With the smallest number of stacks.
- Desirement: (Satisfied) While providing configuration flexibility (e.g. overrides)
- Desirement: (Satisfied) Create stacks that work standalone and can also be interrelated - without any modifications (beyond providing parameters).
Option 1: Stacks Work Stand Alone
I started with the previously published CloudFormationRebootRequiredPatchinginASG.yaml, which can be deployed stand alone by populating it’s parameters and deploying it. CloudFormationELB.yaml also works in this way.
Create CloudFormationRebootRequiredPatchinginASG.yaml in CloudFormation Console
Option 2: Add The ELB Stack and Use Manual Parameter For ASG Stack
CloudFormationELB.yaml can be deployed and the resultant ELB Name can be fed to CloudFormationRebootRequiredPatchinginASG.yaml via the ELBName parameter. This integrates the two stacks and can be done manually or by automation calling the AWS CLI.
Create CloudFormationELB.yaml in CloudFormation Console
Option 3: Add The ELB Stack and Use Export => Import to the ASG Stack
The stack name for CloudFormationELB.yaml can be provided as the ParentStackName parameter to CloudFormationRebootRequiredPatchinginASG.yaml and the ASG stack will assume the ELBName is exported as “ParentStackName-ELBName” Naming consistency with the ELBName in parameters, exports and imports helps keep the data passing methods less confusing.
When the ELB stack is only creating one resource, the flexibility of passing a stack name to the ASG stack is not as obvious. But consider if the ELB stack was pre-creating a bunch of AWS resources that were utilitized by the ASG stack - with a single parameter between the stacks many references could be passed.
The parameters are optional (as shown by the stand alone deployment) or they can BOTH be provided. If both are provided, then the ELBName parameter takes precedent over ParentStackName-ELBName. The vision is that if the parent stack was creating a set of resources, you would have the flexibility to override just one of them when appropriate. This parameter structure and the conditions that back it demonstrate how to take a parent stack and also override specific parent stack parameters.
Option 4: Nested Stacks
The template CloudFormationUsingNestedStacks.yaml links together CloudFormationELB.yaml and CloudFormationRebootRequiredPatchinginASG.yaml as nested stacks and automatically handles the data passing between them via the ParentStackName parameter of the ASG stack.
Create CloudFormationUsingNestedStacks.yaml in CloudFormation Console
Wrap Up
To my eye I have satisfied the majority of the design heuristic - however, if you know of additional, native methods of interlinking cloudformation stacks - I’d love to hear from you!
Code for This Post
The repository below is where this code is updated with enhancements and bug fixes.
CloudFormationELB.yaml => [[Create Now]] (https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/create/review?templateURL=https://s3.amazonaws.com/missionimpossiblecode.io/files/CloudFormationELB.yaml)
CloudFormationRebootRequiredPatchinginASG.yaml => **[Create Now]**
CloudFormationUsingNestedStacks.yaml => **[Create Now]**
