#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

Example Terraform service catalog of “root module” blueprints for provisioning reference architectures - cloudposse/terraform-root-modules

@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

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 plan
and apply
target

Example Terraform service catalog of “root module” blueprints for provisioning reference architectures - cloudposse/terraform-root-modules

our Makefile
looks like this

fwiw, we use https://github.com/cloudposse/tfenv
Transform environment variables for use with Terraform (e.g. HOSTNAME
⇨ TF_VAR_hostname
) - 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
TFLint is a Terraform linter for detecting errors that can not be detected by terraform plan
- 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

Example Terraform service catalog of “root module” blueprints for provisioning reference architectures - cloudposse/terraform-root-modules

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 ?
Example Terraform service catalog of “root module” blueprints for provisioning reference architectures - cloudposse/terraform-root-modules

@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.