Two new, and extremely powerful, features have recently been added to
the SparkleFormation CLI (
sfn) tool. These new
features are focused on providing usable information around the changesets
applied to running infrastructure stacks (updates).
What will this update change?
One of the most important pieces of information when pushing updates is what the resulting state of the system will be after the updates have been applied. The importance of this information is increased when the context is shifted to infrastructure that is generated and maintained by code. An unintended resource update can easily cause a cascading effect, destroying and recreating numerous resources (in some cases within numerous related stacks). Preventing these situations requires an understanding of how resources behave within a given orchestration API, how (or even if) updates of specific resources are handled, and how those updates affect other dependent resources.
Just diff the templates
Providing changeset related information has been (and remains) an incremental process. Thus the starting point was providing the most straight forward information: Displaying difference of an existing stack template, and a new template staged to be applied:
$ sfn diff test-vpc --file vpc
diff command will perform the following steps:
test-vpcfrom the API
In this example, the existing stack consists of a single VPC instance. The local template has been modified to change the VPC resource name, and add a new SecurityGroup resource. The result:
diff command provides a clear list of resource modifications between
the existing template and the new template. This is useful for seeing what
changes exist at the template level between local development and existing
infrastructure. What this information lacks, however, are changes that
may occur at runtime that are not isolated to direct resource modifications.
But what is actually going to change?
diff command, being the first iteration, provided the initial first step
in the changeset related information. The next iteration started with what was
diff support and took a nice stride forward to provide
update planning. Plans are an extension of the
diff command, with one
important difference: planning evaluates the resulting runtime state. To
visualize the difference, lets walk through an example:
Using our updated template, lets assume our
test-vpc stack has been updated
and it now contains the updated resources:
This shows our stack contains two resources: a VPC resource and a SecurityGroup
resource. To continue on with the example, lets assume that the CIDR for the VPC
needs to be changed. This value is defined via a parameter within the template.
When we run the
diff command, there is no parameter usage:
There is no difference between the existing template and the new template to be applied thus our result shows no difference. Yet, if we change the CIDR parameter value, we know a change will occur. It is in this context that the planning support becomes extremely useful:
update command is run, a new planning stage is entered after all
parameters have been collected. The planning stage can be viewed like running
diff command. Since the updated parameters are now available
it is possible to generate a complete complete runtime diff. This is evident
in the output showing the replacement of the VPC resource due to the CIDR change.
It is important to note that not only are the the explicit resource changes
detected, but implicit changes are detected as well. Notice the plan also
includes the SecurityGroup resource in the replacement list. We made no direct
changes to that resource. Due to the replacement of the VPC resource, any usage
resource utilizing the ID of that VPC resource will also be modified. The
SecurityGroup resource uses that ID within its
VpcId property. Since updates
to the SecurityGroup
VpcId property cause the resource to be replaced, it is
also flagged within the plan and displayed within the replacement list.
What is the next iteration?
The next iteration is tightening up the planning integration within the upcoming SparklePRO(vision) service to allow better controls and feedback of infrastructure changes.