Giters

azavea / cac-tripplanner

Clean Air Council Circuit Trip Planner and Travelshed

Home Page:https://gophillygo.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Use DNS to avoid OTP host endpoint swap during releases

hectcastro opened this issue · comments

commented

There is a step in the deployment process that requires Ansible variables to be updated so that they point to the appropriate instance (blue/green) of OTP. We should attempt to use a consistent DNS endpoint for OTP such that we don't need this variable to change across deployments.

(This may require extending the existing deployment steps so that DNS records for OTP are updated for the most recent stack automatically.)

commented

I do not think that I have fully satisfied the requirements of this issue, but as incremental improvements:

  • I created a wildcard ACM certificate for *.otp.gophillygo.org
  • I associated with both the blue and green CloudFront distributions
  • I updated the production group vars to reference human-readable OTP FQDNs
# Uncomment one of the following depending on which color stack is to be launched
# otp_host: "https://blue.otp.gophillygo.org" # Blue
otp_host: "https://green.otp.gophillygo.org"  # Green

Previously, these were *****.cloudfront.net FQDNs, which made it slightly more difficult to map to stack colors.

The main challenge I ran into with trying to use otp.gophillygo.org consistently across stacks is that the otp.gophillygo.org domain alias can only be associated with one CloudFront distribution at a time. This means that we'd have to manipulate distribution origin DNS configuration to facilitate stack switching.

In this particular context, making those types of changes felt like a significant departure with how things work/are understood now. It seemed better to cut losses and focus on the minimal FQDN improvement outlined above.

cc: @rbreslow

commented

These are nice improvements.

In this particular context, making those types of changes felt like a significant departure with how things work/are understood now. It seemed better to cut losses and focus on the minimal FQDN improvement outlined above.

Yeah, I agree. I think those types of changes would require us to have a mechanism for threading through environment variables via CloudFormation (e.g. stateless AMIs) or via the user data approach we take in Model My Watershed.

I think these types of changes will generate less immediate value compared to things like automating the OTP graph generation process. Also, we could delegate the group vars to the Jenkins build configuration which would be a huge lift.