Closed MikeTheCanuck closed 6 years ago
After having implemented PR 44, I am confident that the only two places where "2018-staging" would have to appear are in the master.yaml
and service.yaml
, and once those two entries are removed, we should be able to remove the staging-2018 DNS entry as well.
Rather than complicating things with another alias, I am choosing to consolidate this down so that there is only one URL to reach the 2018 frontend routing site: http://civicplatform.org. If someone in the future wishes to migrate that content to 2018.civicplatform.org and/or 2018.civicpdx.org, they can deal with whatever decisions are necessary then.
I have consolidated the Host/Host2 and ListenerRule/ListenerRule2 entries down in service.yaml
. The only question that remains is whether the LIstenerRule > Properties > Conditions array requires both host-header
and path-pattern
or just one or the other? I'll leave them both in for now, and hope that doesn't mess things up.
Implemented as PR 45.
Having implemented the CloudFormation change, I am confident that the URL http://staging-2018.civicpdx.org is now gone (it's now receiving a 503 error from the load balancer) and that http://civicplatform.org is still answering correctly, so I deem this a success.
I have now removed the DNS record, which for posterity was:
staging-2018.civicpdx.org.
dualstack.hacko-integration-658279555.us-west-2.elb.amazonaws.com.
at Alias Hosted Zone ID Z1H1FL5HABSF5
Question: now that we have a stable deploy of the http://civicplatform.org site, what is the best method for deprecating and removing the http://staging-2018.civicpdx.org site? Is this something controlled by the civic CI/CD pipeline, or is it entirely in the hands of the CloudFormation pipeline? (Yes I could trace this through myself, but I figured I could save myself a couple of hours’ spelunking if someone knows off the top of their head)
Ian responds
Then Michael replies
Now to sort out the specific steps they implied:
.travis.yml
, or in a Travis repo environment variable?civic-201*-service
entries under here https://github.com/hackoregon/hackoregon-aws-infrastructure/tree/master/services?I'm definitely on board with using the same naming for the ECR repository and the ECS service - it's confusing enough to chase down all the similar objects that have "civic" in their name - see #192, #191, #190, #188, #187, #186 and #183 for the fun of trying to stay on top of the spray.