Init access the data #44
Conversation
| @@ -0,0 +1,42 @@ | |||
| // Get configuration from the shared infrastructure | |||
There was a problem hiding this comment.
Projects wanting to copy from AtD should be able to copy this file verbatim. There's some boilerplate that should be the same for every project.
| @@ -0,0 +1,148 @@ | |||
| locals { | |||
There was a problem hiding this comment.
The contents of this file were designed to contain exactly what varies between projects. Other projects might crib from this, but expect to change basically every value.
| @@ -26,31 +26,72 @@ data "terraform_remote_state" "shared" { | |||
| } | |||
| } | |||
|
|
|||
| locals { | |||
| configuration = { | |||
There was a problem hiding this comment.
Prefer always to use the single shared configuration object - it reduces the coupling between modules, who only need to name the fields that they care about.
Each field is exported as an output separately, to support legacy use.
| @@ -0,0 +1,89 @@ | |||
| terraform { | |||
There was a problem hiding this comment.
Ideally, we would migrate to this to the complete exclusion of the DB lambda
| @@ -0,0 +1,208 @@ | |||
| locals { | |||
There was a problem hiding this comment.
This was copied from the existing ecs module and modified for use in MCS.
| health_check_path = each.value.health_check_path | ||
| log_group = aws_cloudwatch_log_group.cwlogs.name | ||
| container_port = each.value.port | ||
| container_env_vars = merge(each.value.env_vars, { |
There was a problem hiding this comment.
@nyarly I see a few formatting things like this w/ alignment...maybe run a final tf fmt?
This is as embarrassingly huge PR. Sorry for that.
Contained within are the additions and changes I needed to make in order to get Access the Data ready to deploy. Note well! AtD isn't successfully deployed yet, but that has to do with issues with CKAN, not the incubator platform.
Introduction
(yeah, it's that kind of PR)
As a rough guide to what's changed:
The headline is the
multi-container-servicemodule. It's designed with AtD in mind, but in general I suspect that being able to deploy e.g. a web backend and Redis (say) will be really valuable to Hack for LA. MCS also covers details like setting up public and private DNS. MCS covers a couple other outstanding Incubator issues, c.f. #18MCS also drives an
ecrmodule, to create container registries that developers can push to to update their services.Other new modules include
databasewhich uses thecyrilgdn/postgresqlprovider to provision postgres databases and roles within the shared RDS instance. All credentials are stored in SSM parameters asSecureStrings, so there's no toxic secrets to manage in IaC. (c.f. #1)Because that's such a useful pattern, there's also a
cheap-secretsmodule, which allows for purpose-agnostic secrets to be securely generated and stashed in SSM. This isn't 100% ideal, but the benefit is that managing secrets this way is free, as compared to using AWS SecretStore. The downside is that the secret material might be stored in terraform state files and would theoretically be extractable. The same personnel who could do that, though, could simply query SSM, or deploy a task that would forward secrets to them.The Terraform
shared_resourcesmodules have been fleshed out significantly, such that we can get data from all of them.Overall, I feel very good about these changes, and would recommend that future Incubator projects be built using
multi-container-serviceon AtD's pattern even if they only deploy a single container.