this is actually a surprisingly big question.
we’ve deployed atlantis now many times in many different configurations
our current best practice is to deploy it as an ECS fargate task with an ALB configured with OIDC
@Erik Osterman (Cloud Posse) - Any hints how we can do this with terragrunt + atlantis ?
to use terragrunt you just need to define your own workflow in the
don’t depend on the built-in
apply steps of atlantis
we define a
make workflow that you can borrow
then you just define the steps in your
Makefile for the project
Got it ! We used to use a lot of makefiles before terragrunt but I got what you are saying. Use makefiles + terragrunt on atlantis
Example Terraform Reference Architecture that implements a Geodesic Module for an Automated Testing Organization in AWS - cloudposse/testing.cloudposse.co
workflows: make: plan: steps: - run: "make reset deps" - run: "set -o pipefail; make plan | tfmask | scenery --no-color" apply: steps: - run: "set -o pipefail; make apply | tfmask"
so a project just defines a
Makefile with a
Makefile looks like this
so we don’t need a wrapper like terragrunt
Any clues to do a dry run before apply ?
the terraform plan doesn’t necessarily succeed
Like for eg. you define a wrong instance type in terraform plan and it will succeed but it will fail when you actually apply it
haha, yea, too true
but IMO this is a lost cause with terraform
instead, practice “git flow” and only merge upon successful apply -> “the atlantis way”
apply is sometimes dangerous
Always practice plan apply workflow
Write plan to out file
Do code review
This is enforced by Atlantis
Require approvals before apply
tflint can help with some of this, even checking your Ami type is available in the region you run in AFAICR
Yeah but the solutions are in bits and pieces. I have seen some complex issues where terraform plan only validates the value type, i.e. string, list, map etc and doesn’t actually do a dry run by hitting the aws api.
yup, there’s no substitute for “doing” :smiley: just gotta apply it in the end when it comes to terraform. this is another reason I don’t advocate running
terraform apply after merge, but instead running it before merge the way atlantis does it.
Doing terraform apply before the merge can be good if there are no tfstate dependencies
we have tons of tfstate dependencies using the terraform remote state provider.
but each tfstate has it’s own SDLC
Same practice that we follow we try to avoid using cross-project tfstate dependencies however some base tfstates are being used by all the projects. For eg. vpc
@Erik Osterman (Cloud Posse) what would be the difference between https://github.com/cloudposse/terraform-root-modules/tree/master/aws/ecs and https://registry.terraform.io/modules/terraform-aws-modules/atlantis/aws/1.17.0 ?
what is the best way to setup
atlantis in AWS ?