Open scottyhq opened 3 years ago
I think the Helm.yml
can be improved by having a pre-job that pull out the outputs from terraform for the values like cluster_name, region, etc. Since the helm depends on the infrastructure being there already anyways.
Agreed. tfvars files are very simple, so it would be nice if that were the only thing needed to edit. https://www.terraform.io/docs/language/values/variables.html#variable-definitions-tfvars-files
Alternatively, it might actually be simpler to just use a generic name for the cluster, namespace, and helm release like 'hackweek-jhub' and if needed set the environment variable AWS_DEFAULT_REGION
for actions
With terragrunt we can just modify everything within common.yml and pull values from there maybe. Also, could I create a whole test hackweek infrastructure for this on the pangeo-access account? I realized that the terraform CI actually perform an apply to AWS, so I cancelled it for now ... We'd have to do a plan and apply using terragrunt so that everything spins up all at once :)
With terragrunt we can just modify everything within common.yml and pull values from there maybe.
Also, could I create a whole test hackweek infrastructure for this on the pangeo-access account? I realized that the terraform CI actually perform an apply to AWS
yes feel free to apply and destroy at will!
If you need to bypass CI, I've been using the following setup (~/.aws/credentials)
[github]
aws_access_key_id=XXXXXXXXXXXXXX
aws_secret_access_key=XXXXXXXXXXXXXXXX
(~/.aws/config)
[profile github-eks]
role_arn = arn:aws:iam::XXXXXXXXXX:role/github-actions-role
source_profile = github
Anyone with access to the S3 backend currently (so I think anyone in the aws account 'admin' group) can obtain the github user access keys with terraform state pull | jq '.resources[] | select(.type == "aws_iam_access_key") | .instances[0].attributes'
...(or create a second set of keys)
I find copying and pasting credentials as environment variables from aws sts assume-role
very tedious (but probably best from a security standpoint https://blog.gruntwork.io/a-comprehensive-guide-to-managing-secrets-in-your-terraform-code-1d586955ace1)
the CI workflows have some hardcoded values and don't do much that is sophisticated. Some ideas for improvement
helm lint
orhelm upgrade --dry-run
in PRs to ensure yaml configuration is correct. ideally the PR would actually get deployed someplace like a staging environment for testing, but that's much more complicated to implement, so will leave for another day.terraform
has some options to post summaries directly in PR comments https://github.com/marketplace/actions/hashicorp-setup-terraform#usageonce initially setup, it would be good to enforce branch protection so that changes have to happen via PRs and can only be merged if PR tests pass.