/ govuk-infrastructure Public
Refactor content store #109
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
This refactors the app task definition for content-store (and draft-content-store) from:
The configuration in main.tf is the same in both draft and live stacks. Mostly it loads stuff from remote state (from the govuk-test deployment, the mongo deployment from govuk-aws) and AWS data sources (for secrets manager).
draft.tf and live.tf call the app-task-definition and envoy-settings modules using the locals from main.tf, overriding them with anything that's different in this stack (e.g. by using
merge()to override a couple of entries in the environment variables hash).
Chris and I discussed merging the app-task-definition and envoy-settings modules - we're on the fence about whether to do that. They're kind of separate, but in practice every govuk app is going to call both, so it might save some boilerplate if we merged them.
draft.tf and live.tf each create the aws_ecs_task_definition resource directly. In my view this is easier to follow than creating the resource inside a module (you can look at this deployment in isolation and know exactly what it's going to create, without having to open all of its modules too). It also means that modifying the task definition for an individual app is easier - things that are defined at the top level (like CPU) don't need to be exposed as variables in the module and passed down. That said, this is a bit of an unusual approach - we might decide that this is also too confusing.
The symlinked common.tf, outputs.tf and variables.tf files are not used in this deployment. I've also removed the hardcoded backend bucket for the test environment. That means that instead of:
The process for applying terraform is now:
For now, this breaks the concourse pipeline for content-store and draft-content-store, as they've not been updated to use this module yet. I'm going to address that in a future PR, so I've paused those jobs in the pipeline.
I've already run terraform destroy on the old content-store and draft-content-store deployments, and I've run terraform apply for the new one.