Anyone using Amazon Web Services will hopefully start using the CloudFormation service early on to start templating and automating the creation of their infrastructure. Until recently, these templates had to be written using the .json file format – however, this week (Sept. 2016), AWS announced that the templates could now be written in .yaml.
Our project
We’ve been working on a project to move a website away from a monolithic app to a more loosely coupled set of services. As part of this, I created a CloudFormation template that created a SQS message queue, gave the queue permission to accept messages from S3 buckets and then created a S3 bucket which was configured to send notifications to the SQS when an upload occurs.
Moving cloudformation from json to yaml
I’d initially written the CloudFormation template in json with a fairly standard layout including parameters, resources and some outputs. For example, the parameter section looked like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
"Parameters" : { "BucketName" : { "Type": "String", "Default" : "s3bucket20160920", "Description" : "Enter the name for the S3 bucket - this must be global unique" }, "EventQueueName" : { "Type": "String", "Default" : "EventSQS", "Description" : "Enter the name for the SQS queue to receive events from the S3 Bucket" } }, |
But as I was finishing testing, the announcement about using yaml was made and I translated the json to yaml as below:
|
1 2 3 4 5 6 7 8 9 10 |
Parameters: BucketName: Type: String Description: Enter the name for the S3 bucket - this must be global unique Default: s3bucket20160920 EventQueueName: Type: String Description: Enter the name for the SQS queue to receive events from the S3 Bucket Default: EventSQS |
Each of the sections above creates two parameters which are used to pass parameters input when running the template to customise resource names.
The resource section had a number of entries such as
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
"UploadS3" : { "Type": "AWS::S3::Bucket", "DependsOn" : [ "S3EventQueue", "S3EventQueuePolicy" ], "Properties" : { "BucketName" : { "Ref" : "BucketName"}, "NotificationConfiguration" : { "QueueConfigurations" : [ { "Event" : "s3:ObjectCreated:*", "Queue" : { "Fn::GetAtt" : [ "S3EventQueue", "Arn" ] } } ] } } |
which creates the S3 bucket and gives it permission to send events to the SQS created earlier.
Rewriting this in YAML, leads to
|
1 2 3 4 5 6 7 8 9 10 11 12 |
UploadS3: Type: AWS::S3::Bucket DependsOn: - S3EventQueue - S3EventQueuePolicy Properties: BucketName: Ref: BucketName NotificationConfiguration: QueueConfigurations: - Event: s3:ObjectCreated:* Queue: !GetAtt S3EventQueue.Arn |
Personally (and I understand that this probably comes down to formatting you’re used to working with), the yaml looks much cleaner to me – the lack of braces and quotes means the template is much easier to follow (at least to me 🙂).
The big winner for me though is that the yaml syntax allows for comments. There have been several posts in the AWS forums asking for some method of allowing comments; the only suggestions until now were to use the ‘clunky‘ metadata sections to pass information – in yaml, the top of my resources section looks like:
|
1 2 3 4 5 6 |
# ------------------------------ # And now, define the resources # 1. S3EventQueue SQS to receive notifucation from S3 on upload # 2. S3EventQueuePolicy Give permission for S3s to add message to S3EventQueue # 3. UploadS3 S3 Bucket - send notification events to S3EventQueue Resources: |
If you’d like to see the full versions of the templates, click on the links to see the json version or the yaml one.
Things to watch out for.
If you’re not used to yaml, you do need to be careful with the indentation – I’d suggest if you have a json template already and are having problems, look at one of the online json->yaml converters (for example, http://www.json2yaml.com/)
Leave a Reply