search

hackoregon / civic-devops

Master collection point for issues, procedures, and code to manage the HackOregon Civic platform
MIT License
11 stars 4 forks source link

Deprecate/remove staging-2018.civicpdx.org #193

Closed MikeTheCanuck closed 6 years ago

MikeTheCanuck commented 6 years ago

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

Both. Would need to change travis to change name from staging-2018 to something like 2018-civicplatform and update cloudformation to match (and only have the civicplatform load balancer target. Once the new named container appears in a properly named ecr repo and successfully deployed, the old staging-2018 container repo can be removed and if cloudformation does not stop/remove the old container, manually stop it and remove/delete the old task definition.

Then Michael replies

Technically only the load balancer rule needs to be removed, but it would be nice to have consistent naming for the ecr name and ecs service name.

Now to sort out the specific steps they implied:

  1. in which part of Travis do we change the name from "staging-2018" to "2018-civicplatform" - is that in a .travis.yml, or in a Travis repo environment variable?
  2. Where exactly in CloudFormation does the update need to be made to match this naming change - is that in the civic-201*-service entries under here https://github.com/hackoregon/hackoregon-aws-infrastructure/tree/master/services?
  3. Where exactly do we update the load balancer targets - is that in the EC2 console, or in one of the YAML files in https://github.com/hackoregon/hackoregon-aws-infrastructure?

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.

MikeTheCanuck commented 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.

MikeTheCanuck commented 6 years ago

Decision

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.

MikeTheCanuck commented 6 years ago

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.

MikeTheCanuck commented 6 years ago

Implemented as PR 45.

MikeTheCanuck commented 6 years ago

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: