Generate multiple master.yaml files for Staging and Production

[MikeTheCanuck]

Summary

Creating multiple master.yaml templates to separate the DNS and other configuration values for the staging vs production environments.

Impact

Enables us to scale the number of deployed environments, as well as to test continued CloudFormation evolution.

Impacts goals S5

Tasks

• [ ] Create master-staging.yaml and master-production.yaml
• [ ] Put the existing service.civicpdx.org and civicplatform.org domains into the production template
• [ ] Obtain staging DNS records from Route53 and insert those into the staging template
• [ ] reduce the number of containers deployed for each service in staging from 2 to 1
• [ ] add deployment tags to each services' Image URL to separate :staging from :latest or :production or whatever the tagged docker images for each stage of deployment will be

Definition of Done

Containerized apps on staging URLs are reachable from a browser. All existing production services are still reachable on existing URLs.

[DingoEatingFuzz]

When we do this we will also need to think about what needs to be duplicated between staging and production environments, both to be mindful of costs as well as only testing pieces that are subject to change or impact production services in the staging environment.

For instances, I don't think we need a second VPC for the staging environment. As long as the staging services are using a different ALB and different ECS cluster, there's no way we could bring down production services.

On the cost front, duplicating the entire stack just to test an experimental ecs task configuration is much more expensive than the isolation is worth.