#atlantis - October 2019

What was the thing that was like Atlantis, but not?

Can't find it in the archives

yea, i know what you mean.

it had a horrible name

@joshmyers ☝️

Awesome, thanks @Erik Osterman (Cloud Posse)

Oh, it's not OS, https://github.com/geopoiesis?tab=repositories

Oh... thought it was

Am I right in saying the Atlantis workflow is to deploy before the code is merged? Isn’t that a bit sketchy?

@oscar You can require the PR to be approved before changes can be applied, and I believe you can also adjust a setting to have Atlantis merge the code when planning/applying (locally on its side).

we open a PR and request reviews, atlantis runs plan automatically, the author and the reviewers review the plan, the reviewers approve the PR, we run atlantis apply, if everything is ok, merge to master

we want the master to reflect what is deployed, so we merge to master only if everything is ok

Thanks guys.
So really the workflow isnt to actually comment Atlantis apply until it has been merged?
Is there a way to enforce this?

So that someone cant comment and trigger the apply of the plan before merge etc

Yes Atlantis uses a planfile so even if you tried to apply before plan it would fail

With Atlantis you run apply before merge

I think there is also an option to auto merge on apply

So if apply fails it doesn’t merge

when you deploy atlantis, you provide a global atlantis-repo-config.yaml

where you can specify what users in the repo that atlantis provisions can do

(sure if atlantis-repo-config.yaml is in the same repo (as we have in testing), it does not solve the issue. But if the atlantis repo is different from the repo it operates on, then you can safely restrict)

You can also configure branch protection if you're using GitHub to ensure that the atlantis/plan and apply checks have passed before it'll allow someone to merge things.

Hey all, Im considering using atlantis but I've got a few questions(coming from a TFE environment triggered by jenkins).
1. How can you differentiate workspaces and credentials? For example, if I commit some changes to git, the terraform plan runs. How can I make the terraform plan and apply against a 'dev aws environment' and then have the terraform applied to a prod aws env? How would atlantis differentiate workspaces/secrets?

Id like to use a single repo for all modules/configurations but im a bit hazy on how that would look, for example

git-repo/
  module1/
  module2/

where would I store configurations for awsdev and awsprod accounts which call those modules? In seperate folders?

basically, im not sure how to setup atlantis/git for a multi-environment configuration

we deploy atlantis on ECS in each account (staging, prod, testing) https://github.com/cloudposse/terraform-aws-ecs-atlantis

we have a catalog of common modules which we use in all environments https://github.com/cloudposse/terraform-root-modules/tree/master/aws

in each particular environment, e.g. https://github.com/cloudposse/testing.cloudposse.co, we specify what the atlantis deployed in testing could do https://github.com/cloudposse/testing.cloudposse.co/blob/master/atlantis.yaml

so we open a PR, for example in staging, run atlantis plan, review and approve the PR, run atlantis apply and then merge the PR to master at <http://staging.cloudposse.co|staging.cloudposse.co>

then do the same for <http://prod.cloudposse.co|prod.cloudposse.co>

all secrets we store in SSM param store, and then atlantis in each environment reads it from SSM using chamber https://github.com/cloudposse/geodesic/blob/master/rootfs/etc/init.d/atlantis.sh#L44

when you say in staging you mean staging branch?

we have separate repos for each account

they use the same catalog of modules https://github.com/cloudposse/terraform-root-modules/tree/master/aws

oh so you have all your modules in a repo, then a repo for staging, prod etc?

but just provide settings related to the environment

so we separate code (logic) from settings/secrets