Implement Terraform #512
Implement Terraform #512
Conversation
| #TODO Using this as an example of the possibility. Given we populate from a docker-compose command, | ||
| # I don't know if this will be super useful for us, vice utilising the Default values found in variables.tf | ||
| # See: https://learn.hashicorp.com/tutorials/terraform/azure-variables |
There was a problem hiding this comment.
I would suggest to add a Bash or PowerShell script to the repo that runs after terraform apply which takes the output from terraform output -json -no-color and converts it to dotenv format required by .github.env or azure.env. The encryption key can be stored as a Github Actions secret. The benefit of keeping the dotenv file as an interface is that the rest of the code doesn't have to be changed with the addition of Terraform as it only assumes secrets stored in dotenv.
Encryption can be done via gpg or openssl. Here's an example for openssl:
# encryption
echo "${password}" | openssl enc -aes-256-cbc -md sha512 -pass stdin -in .env -out .env.enc
# decryption
echo "${password}" | openssl enc -aes-256-cbc -md sha512 -pass stdin -in .env.enc -out .env -dYou can see an example of gpg decryption in makefile.
There was a problem hiding this comment.
I am a little unclear on this point. Is the intention to store the output of the terraform apply in the secrets folder as an encrypted .env? So:
Steps:
- terraform apply
- terraform output -json -no-color => azure.env (encrypted) stored in the secrets
Is there anything additional needed for this, that I missed?
There was a problem hiding this comment.
To clarify a little further, is the intention to use the terraform output to populate the values of:
RESOURCE_GROUP=${RESOURCE_GROUP_NAME}
LOKOLE_EMAIL_SERVER_APPINSIGHTS_KEY=$(jq -r .properties.outputs.appinsightsKey.value /tmp/deployment.json)
LOKOLE_CLIENT_AZURE_STORAGE_KEY=$(jq -r .properties.outputs.clientBlobsKey.value /tmp/deployment.json)
LOKOLE_CLIENT_AZURE_STORAGE_NAME=$(jq -r .properties.outputs.clientBlobsName.value /tmp/deployment.json)
LOKOLE_CLIENT_AZURE_STORAGE_HOST=
LOKOLE_CLIENT_AZURE_STORAGE_SECURE=True
LOKOLE_EMAIL_SERVER_AZURE_BLOBS_KEY=$(jq -r .properties.outputs.serverBlobsKey.value /tmp/deployment.json)
LOKOLE_EMAIL_SERVER_AZURE_BLOBS_NAME=$(jq -r .properties.outputs.serverBlobsName.value /tmp/deployment.json)
LOKOLE_EMAIL_SERVER_AZURE_BLOBS_HOST=
LOKOLE_EMAIL_SERVER_AZURE_BLOBS_SECURE=True
LOKOLE_EMAIL_SERVER_AZURE_TABLES_KEY=$(jq -r .properties.outputs.serverTablesKey.value /tmp/deployment.json)
LOKOLE_EMAIL_SERVER_AZURE_TABLES_NAME=$(jq -r .properties.outputs.serverTablesName.value /tmp/deployment.json)
LOKOLE_EMAIL_SERVER_AZURE_TABLES_HOST=
LOKOLE_EMAIL_SERVER_AZURE_TABLES_SECURE=True
LOKOLE_EMAIL_SERVER_QUEUES_NAMESPACE=$(jq -r .properties.outputs.serverQueuesName.value /tmp/deployment.json)
LOKOLE_EMAIL_SERVER_QUEUES_SAS_NAME=$(jq -r .properties.outputs.serverQueuesSasName.value /tmp/deployment.json)
LOKOLE_EMAIL_SERVER_QUEUES_SAS_KEY=$(jq -r .properties.outputs.serverQueuesSasKey.value /tmp/deployment.json)
which will be stored in the azure.env similar to setup.sh?
| resource_group_name = "tstate" | ||
| storage_account_name = "tstate31414" | ||
| container_name = "tstate" | ||
| key = "terraform.tfstate" |
There was a problem hiding this comment.
Thoughts on making the key dynamic, e.g. based on branch name via the GITHUB_REF environment variable, so that we can run this potentially for multiple deployments (e.g. for work-in-progress code) without risking to override the production resources.
There was a problem hiding this comment.
Sure can! That makes a lot of sense.
Codecov Report
@@ Coverage Diff @@
## master #512 +/- ##
==========================================
+ Coverage 76.71% 76.77% +0.05%
==========================================
Files 45 47 +2
Lines 2766 2829 +63
==========================================
+ Hits 2122 2172 +50
- Misses 644 657 +13
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
This will need to be integrated with the setup scripts, see #528 and the changes in setup.sh for reference.
|
There is a Lokole meeting 10:30AM Pacific Daylight Time tomorrow (Friday May 14th) that everyone is welcome to join. @sbathgate: how should this PR #512 fit into the general prioritization of what comes next? Thanks much for clarifying / suggesting in advance of that call, if at all possible, to help everyone pull together! Ref: #546 |
|
Hi @holta, sorry for the delay this comment got lost within my GH notifications. This PR had a couple of final touches as noted by Clemens above. I am admittedly struggling to find extra time to complete this. It's ultimate objective was to move the setup scripts from the current bash based configurations to improve future growth and contributions. As it stands the current bash scripts obviously work so it isn't a Tier 1 concern but I do think it would have value. The big thing that remained outstanding was configuring the terraform output so the newly generated resources can be used by the lokole application. |
This PR introduces Terraform to Lokole. This will replace the bash based setup.sh configuration.
Fixes #272