Skip to main content

CloudFormation Templates: Using Ref to Access Run Time Information

When working with AWS CloudFormation, many of the resource properties we reference in our stack template will not be available until the stack is built and creation of that particular resource has been initiated.

For example, suppose we're declaring an ECS service called MigrateDatabaseService to run and maintain a task based on the MigrateTask task definition. One of the required properties of the AWS::ECS::Service resource is a string containing the Amazon Resource Name (ARN) of the task definition (including the revision number) that we want to run on the cluster. The problem is that the task definition is declared in the same template, but the ARN will not be available until run time. So, how do we specify a run time value at design time?


CloudFormation provides eleven built-in, or intrinsic, functions that we can use to assign values to properties that are not available until run time.

The intrinsic function we need to use to populate the TaskDefinition property in the service resource declaration is the Ref function. Given the logical name of another resource declared in the template, Ref returns the value of the specified resource.

The AWSdocumentation provides an extensive list of the reference values returned by the Ref function for many different resource types, along with example return values. We can see that, for a TaskDefinition resource, Ref returns the task definition ARN, which is exactly what we need to declare the TaskDefinition property in the template:



Note that CloudFormation templates are required to be valid JSON, which means the TaskDefinition property requires a single value. So, while the call to Ref returns a single value, CloudFormation will see the call itself (“Ref”: “MigrateTask”) as another key/value pair, and will generate a template format error (“Expected ‘,’ instead of ‘:’”). Make the call to Ref  by enclosing it in curly brackets so that CloudFormation sees it as a single object, not a key/value pair.


Comments

Popular posts from this blog

Takeaways from the Continuous Automated Testing Tutorial at CAST2014

I had the opportunity to attend Noah Sussman's tutorial on Continuous Automated Testing last week as part of CAST2014. It was a great tutorial, with most of the morning spent on the theory and concepts behind continuous automated testing, and the afternoon spent with some hands-on exercises. I think that Noah really understands the problems associated with test automation in an agile environment, and the solutions that he presented in his tutorial show the true depth of his understanding of, and insight into, those problems. Here are some of the main highlights and takeaways that I got from his tutorial at CAST2014. Key Concepts Design Tools – QA and testing are design tools, and the purpose of software testing is to design systems that are deterministic Efficiency-to-Thoroughness-Trade-Offs – (ETTO) We do not always pick the best option, we pick the one that best meets the immediate needs Ironies of automation – Automation makes things more complex and, while tools can make

Mission Statement, Definition of Software Testing, and Goals of Software Testing

Why I blog? What’s the difference between a good tester and a great tester? I think the main thing is the ability to think for yourself and to be able to incorporate your experiences as a tester back into the context of your testing practices.  I think that if you look at the software testing community and pay attention to who has good ideas and who does not, you’ll find that the vast majority of people with good ideas emphasize their experience, what they have learned from it, and how they incorporate that back into their testing. Writing about my thoughts and experiences in software testing provides an opportunity for me to take a critical look at what I thought about a subject, assess it in the context of experience and information gained since I first came to think that way, and then update or reaffirm my thoughts on the subject. It also allows me to share my thoughts, experiences, successes and failures with others, creating an additional feedback loop. That, to me, is one

Let’s Continue to Drive Software Testing Education Forward

It’s Time to Embrace the Student Who Learns Differently Last in a series. In my last two posts I’ve written about enhancing the student and instructor experience in the AST’s BBST courses by focusing on updating the Fieldstones and making BBST courses more accessible by identifying some of the more common obstacles to BBST participation, and then working collectively to find ways to lower or remove those obstacles. In this post, I want to discuss the third and final area I would like to concentrate on if elected to the Board of Directors: researching and establishing alternate approaches to teaching that better suit different learning styles. As members of the AST, we have access to some of the best information and training available in the field of software testing. The AST hosts the Conference of the Association for Software Testing (CAST) each year, providing full-day tutorials, keynotes, and track sessions. They also offer four separate BBST courses:  Foundations, Bug