New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleaned up terraform and fixed backends #67
Conversation
Refactored all templators to use a config holder so we can extend them in the future if we need more data. Modified names of things in TF to reduce conflicts within the same AWS account. Fixed S3 backend. Wasn't working at all because it can't live in a module, and can't contain string interpolation. Still more to do to make everything fully repeatable, will probably do it in another ticket.
@@ -0,0 +1,24 @@ | |||
provider "aws" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To create the actual backend bucket and dynamo db. This will need to be run in a separate tf apply
before the tf init
of the rest of the infra. This will be an interesting piece to automate..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can move it to a seperate .tf
file and use terraform apply target to apply specifically only that portion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That wouldn't be a great workflow going forward though, because you wouldn't be able to run plan/apply in the main dir.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using the depends on
clause?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They have to be run separately, because one creates the global state and should never be run again, and the other one uses the global state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, does it make sense to enclose the backend init in a shell script then or boto3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That way we can both spin up and tear down the backend init based on tf apply
and tf destroy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gonna stick with this for now and we'll see how complex the process gets to see if it warrants adding helpers..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Refactored all templators to use a config holder so we can extend them in the future if we need more data.
Modified names of things in TF to reduce conflicts within the same AWS account.
Fixed S3 backend. Wasn't working at all because it can't live in a module, and can't contain string interpolation.
Still more to do to make everything fully repeatable, will probably do it in another ticket.