#atlantis (2019-04)
| Discuss the Atlantis (<http://runatlantis.io | runatlantis.io>) |
**Archive: ** https://archive.sweetops.com/atlantis/
2019-04-29
what is the best way to setup atlantis in AWS ?
2019-04-30
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 atlantis.yaml
don’t depend on the built-in plan and 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
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 plan and apply target
our Makefile looks like this
fwiw, we use https://github.com/cloudposse/tfenv
so we don’t need a wrapper like terragrunt
Interesting !
Any clues to do a dry run before apply ?
you mean terraform plan?
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
technically there’s https://github.com/wata727/tflint
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
Apply outfile
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 ?
@antonbabenko manages terraform-aws-modules/atlantis
it uses the #terraform-aws-modules which we (cloudposse) do not manage
Yeah, I am not very active in #terraform-aws-modules neither, but you can try to ask in public github. Maybe other can help you faster there.