#atlantis (2019-10)

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

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

aknysh avatar
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

imiltchman avatar
imiltchman

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 avatar
aknysh

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

aknysh avatar
aknysh

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

aknysh avatar
aknysh

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

imiltchman avatar
imiltchman

Aren’t user management and logging exceptions to that?

imiltchman avatar
imiltchman

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

aknysh avatar
aknysh

yes

aknysh avatar
aknysh

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

imiltchman avatar
imiltchman

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.

imiltchman avatar
imiltchman

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:aws:iam::${var.aws_account_id}:role/${var.aws_role_name}"
      external_id  = var.aws_external_id
      session_name = module.label.id
    }
  }
}
imiltchman avatar
imiltchman

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

aknysh avatar
aknysh

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

aknysh avatar
aknysh

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

aknysh avatar
aknysh

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

aknysh avatar
aknysh

but it simplifies management and security

aknysh avatar
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

imiltchman avatar
imiltchman

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

aknysh avatar
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 avatar
aknysh

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

aknysh avatar
aknysh

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

aknysh avatar
aknysh

it requires more settings and more deployments

aknysh avatar
aknysh

but it simplifies management, security and all IAM stuff

aknysh avatar
aknysh

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

aknysh avatar
aknysh

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

imiltchman avatar
imiltchman

That’s a good one. Thanks again.

zeid.derhally avatar
zeid.derhally

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

:100:1
aknysh avatar
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 avatar
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 avatar
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 avatar
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 [staging.cloudposse.co](http://staging.cloudposse.co)

aknysh avatar
aknysh

then do the same for [prod.cloudposse.co](http://prod.cloudposse.co)

aknysh avatar
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'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 avatar
Brij S

when you say in staging you mean staging branch?

aknysh avatar
aknysh

we have separate repos for each account

Brij S avatar
Brij S

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

:100:1
aknysh avatar
aknysh

but just provide settings related to the environment

aknysh avatar
aknysh

so we separate code (logic) from settings/secrets

2019-10-15

Andrew Jeffree avatar
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.

:100:1

2019-10-11

oscar avatar
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 avatar
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 avatar
oscar

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

Erik Osterman avatar
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 avatar
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)

imiltchman avatar
imiltchman

@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 avatar
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 avatar
aknysh

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

oscar avatar
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 avatar
oscar

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

Erik Osterman avatar
Erik Osterman

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

Erik Osterman avatar
Erik Osterman

With Atlantis you run apply before merge

Erik Osterman avatar
Erik Osterman

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

Erik Osterman avatar
Erik Osterman

So if apply fails it doesn’t merge

AgustínGonzalezNicolini avatar
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 avatar
AgustínGonzalezNicolini

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

aknysh avatar
aknysh

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

aknysh avatar
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 avatar
aknysh

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

aknysh avatar
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 avatar
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 avatar
AgustínGonzalezNicolini

Nice!!!

AgustínGonzalezNicolini avatar
AgustínGonzalezNicolini

I’ll look into inplementing

AgustínGonzalezNicolini avatar
AgustínGonzalezNicolini

thanks @aknysh

2019-10-08

joshmyers avatar
joshmyers

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

joshmyers avatar
joshmyers

Can’t find it in the archives

Erik Osterman avatar
Erik Osterman

yea, i know what you mean.

Erik Osterman avatar
Erik Osterman

it had a horrible name

Erik Osterman avatar
Erik Osterman
Hello, Geopoiesis!

Turbocharging your infrastructure-as-code

Erik Osterman avatar
Erik Osterman
Erik Osterman avatar
Erik Osterman

@joshmyers

joshmyers avatar
joshmyers

Awesome, thanks @Erik Osterman

joshmyers avatar
joshmyers
geopoiesis

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

Erik Osterman avatar
Erik Osterman

Oh… thought it was

    keyboard_arrow_up