Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Custom Route53 records in CloudFormation stack #399
Since Zappa already relies on CloudFormation, it would be wonderful if we could specify a hostname to use for a particular environment. CloudFormation works great with Route53 - AFAIK it won't overwrite an existing DNS record if one already existed, and it cleans up if you delete the stack of course.
We typically use CloudFormation for everything but as-is, I'd have to make a 2nd CloudFormation stack outside of Zappa automation just for the Route53 entry, or through other means like manually in the AWS console.
Any interest in this?
Ah I see - good question! Typically we prefer setting DNS entries via Troposphere. So it'd be an even more natural fit for us if we could extend the CloudFormation template itself rather than through an abstraction of it like the JSON configuration - that could cover wider use cases. But being able to set a hostname is probably a common use case (most people are probably just used to doing this by hand through the AWS console? - and possibly don't take automation to the degree we do).
Another current pain point is that it doesn't seem easy to script Zappa yet (so far as I've discovered, so I'm likely missing some things) - I plan to file another ticket about deployment automation, but the relevant part here is that if I wanted to set the Route53 record myself through out-of-band automation (e.g. as an awscli or Ansible playbook that runs alongside Zappa), I don't see a great way to extract the hostname that Zappa generated to use as a CNAME. I could try to pattern-match it from Zappa CLI output, or I could try to get a reference to the CloudFormation stack and get it from there.
For that latter point, I could see a couple nice ways to get that hostname programmatically - either have a way to get Zappa to use machine-readable output (undecided on best interface for this); and/or use CloudFormation's value outputs so that other stacks can import those relevant values into their stacks.
@Miserlou - As a more general solution to this problem, do you see any issue with adding a callback between the calls to
If we had a callback there similar to the 'settings', 'zip', and 'post' callbacks, we could write our own extensions to extend the stack however we like. This could be to point Route53 records at the ApiGateway, or massage the stack in other ways.