#atlantis

Discuss the Atlantis (http://runatlantis.io|runatlantis.io) *Archive: * https://archive.sweetops.com/atlantis/

2019-10-24

2019-10-23

2019-10-22

2019-10-21

Brij S

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?
Brij S

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?

Brij S

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

aknysh

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

cloudposse/terraform-aws-ecs-atlantis

Terraform module for deploying Atlantis as an ECS Task - cloudposse/terraform-aws-ecs-atlantis

Why not run in one place with assume role?

cloudposse/terraform-aws-ecs-atlantis

Terraform module for deploying Atlantis as an ECS Task - cloudposse/terraform-aws-ecs-atlantis

aknysh

we almost always use separate AWS accounts for each environment (dev, staging, prod)

aknysh

although more difficult to setup, it adds a lot of benefits including better security, better control, and complete isolation of environments

aknysh

atlantis for provisioning account’s resources goes into the same account

Aren’t user management and logging exceptions to that?

I assume you have a separate TF state bucket in each account too, then?

aknysh

yes

aknysh

user management is done in a separate account, either root or identity

What I mean is that user management is centralized. You could have the same with Atlantis, where it’s running in a separate account but assumes roles and applies changes to individual accounts. That’s what the users do and Atlantis is just a “user” in a sense.

Example:

provider "aws" {
  region = var.region

  dynamic "assume_role" {
    for_each = [for s in [var.aws_role_name]: s if s != "EXTERNAL"]
    content {
      role_arn     = "arn<img src="/assets/images/custom_emojis/aws.png" class="em em-aws">iam:role/${var.aws_role_name}"
      external_id  = var.aws_external_id
      session_name = module.label.id
    }
  }
}

I’m curious what you believe the benefits of separation are for Atlantis

aknysh

it could be deployed in may diff ways for sure. And what you showed above will work as well

aknysh

since we use separate AWS accounts for all environments, we deploy separate atlatis in each

aknysh

it’s not that expensive to deploy an atlantis container on ECS fargate

aknysh

but it simplifies management and security

aknysh

for example, atlantis-repo-config.yaml file that describes what users could do https://github.com/cloudposse/testing.cloudposse.co/blob/master/conf/ecs/atlantis-repo-config.yaml

cloudposse/testing.cloudposse.co

Example Terraform Reference Architecture that implements a Geodesic Module for an Automated Testing Organization in AWS - cloudposse/testing.cloudposse.co

Thanks, I’m a little on the fence, but I am leaning toward changing to this approach as well

aknysh

since we have a separate atlantis for the testing environment (as we do for prod, staging, etc.), it’s just easier to do all those settings on just one repo

aknysh

instead of thinking about how to configure that for many repos for diff environments using just one atlantis

aknysh

i’m not saying it’s the perfect solution, there is no one

aknysh

it requires more settings and more deployments

aknysh

but it simplifies management, security and all IAM stuff

aknysh

plus, of cause, if something happens with one atlantis (container fails, bad deployment, etc.), it will not affect all the others

aknysh

so we could test new versions of atlantis in dev/testing first before rolling it to staging/prod

That’s a good one. Thanks again.

if you have a shared atlantis and that instance is breached, then the attacker would have access to all your accounts

aknysh

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

cloudposse/terraform-root-modules

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

aknysh

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

cloudposse/testing.cloudposse.co

Example Terraform Reference Architecture that implements a Geodesic Module for an Automated Testing Organization in AWS - cloudposse/testing.cloudposse.co

cloudposse/testing.cloudposse.co

Example Terraform Reference Architecture that implements a Geodesic Module for an Automated Testing Organization in AWS - cloudposse/testing.cloudposse.co

aknysh
cloudposse/testing.cloudposse.co

Example Terraform Reference Architecture that implements a Geodesic Module for an Automated Testing Organization in AWS - cloudposse/testing.cloudposse.co

aknysh

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>

aknysh

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

aknysh

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

cloudposse/geodesic

Geodesic is a cloud automation shell. It&#39;s the fastest way to get up and running with a rock solid, production grade cloud platform built on top of strictly Open Source tools. ★ this repo! h…

Brij S

when you say in staging you mean staging branch?

aknysh

we have separate repos for each account

Brij S

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

1
aknysh

but just provide settings related to the environment

aknysh

so we separate code (logic) from settings/secrets

2019-10-15

Andrew Jeffree

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.

1

2019-10-11

oscar

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

Erik Osterman

Isn’t it sketchy to have code in master that was never deployed? Terraform is crude tool for CRUD that doesn’t rollback in face of errors.

oscar

Ah perhaps I have my workflows wrong in my head (purely theoretical, no atlantis deployed yet)

Erik Osterman

So you are right that I that you should deploy on merge in most cases :-) just I think Atlantis is a good example of when maybe not to do that.

Michael Warkentin

Yep, atlantis definitely has a deploy-then-merge workflow. The locking helps with the normal issues you’d have with that type of flow (conflicts between multiple branches)

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

aknysh

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

aknysh

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

oscar

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

oscar

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

Erik Osterman

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

Erik Osterman

With Atlantis you run apply before merge

Erik Osterman

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

Erik Osterman

So if apply fails it doesn’t merge

AgustínGonzalezNicolini

Still if the atlantis.yaml file lives in your repo, you canc change it in the PR and skip the approval enforcement

AgustínGonzalezNicolini

that’s like one “security issue” i still don’t get

aknysh

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

aknysh
cloudposse/testing.cloudposse.co

Example Terraform Reference Architecture that implements a Geodesic Module for an Automated Testing Organization in AWS - cloudposse/testing.cloudposse.co

aknysh

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

aknysh
# allowed_overrides specifies which keys can be overridden by this repo in
    # its atlantis.yaml file
    allowed_overrides: [apply_requirements, workflow]

    # allow_custom_workflows defines whether this repo can define its own
    # workflows. If false (default), the repo can only use server-side defined workflows
    allow_custom_workflows: true
aknysh

(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)

AgustínGonzalezNicolini

Nice!!!

AgustínGonzalezNicolini

I’ll look into inplementing

AgustínGonzalezNicolini

thanks @aknysh

2019-10-08

joshmyers

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

joshmyers

Can’t find it in the archives

Erik Osterman

yea, i know what you mean.

Erik Osterman

it had a horrible name

Erik Osterman
Hello, Geopoiesis!

Turbocharging your infrastructure-as-code

Erik Osterman
Erik Osterman

@joshmyers

joshmyers

Awesome, thanks @Erik Osterman

joshmyers
geopoiesis

geopoiesis has 7 repositories available. Follow their code on GitHub.

Erik Osterman

Oh… thought it was

    keyboard_arrow_up