#atlantis - December 2018

Hello. So i am thinking about using Atlantis and was wondering how to set it up

Also, is it possible to run terraform commands when we use atlantis ?

like for example, terraform workspace command

Yes, you can run any arbitrary commands

Atlantis understands workspaces too

@antonbabenko has module for it

https://github.com/terraform-aws-modules/terraform-aws-atlantis - I have not used it much since the release, so it may require some polishing.

awesome

so once atlantis is setup, do we run arbitrary commands in github ?

yes, in github PR comment users should be able to write everything atlantis can recognize - atlantis plan

nice

Hey all, I've been playing around with Atlantis and I'm at a point where I want proof of concept this in an actual workflow. My setup for AWS accounts one per environment (dev, stg, prd) with an instance of Atlantis in each account/environment. Dev teams will hook into Atlantis via an atlantis.yml and webhook. This is what my question revolves around, in this sort of setup, what does the webhook setup for a repository look like if you have 3 separate Atlantis instances?

So, it basically comes down to how you organize your infra. In our case, we have 1 repo per AWS account.

and then a terraform-root-modules that acts like a library we can pull from

so then in each of our account repos, we pull in the terraform root modules that we want to use

Do you treat application repos the same way? And how do you promote changes from one env to the other? For instance, in the case you're talking about, say i've made some changes to the vpc in the dev repo that needs to be reflected in stg and prd.

so all changes are made to terraform-root-modules and tagged

then you update the tag in the corresponding environment with a PR <-- which you can use atlantis to execute

@Arwin Tugade for my setup we have all of our terraform in a single repo with 3 folders, dev, prod, stg and a single atlantis that applies them all.

yea, I think that’s the most common approach and the use-case I think atlantis was originally built for

the part about that I struggle with is controlling access and reducing blast radius

this is why we forked atlantis to implement the basic ACLs

those ACLs are scoped to a particular instance of atlantis

then we can deploy atlantis into different AWS accounts and control who can do what based on GitHub team membership

we do that by using CODEOWNERS and requiring approval before an apply

has something changed?

Last I was aware, CODEOWNERS prevents merging, but mergability is not yet used to determine who can plan or apply

My understanding was that it linked into the approval process. I'll verify that requirement.

it does, but it only requires that one of the CODEOWNERS approves

but it doesn’t prevent anyone else from also approving

and atlantis only checks if it has been approved

but not if it can be merged

@Erik Osterman (Cloud Posse) ahh good catch

I guess I should put in some PRs

Anyone want to have a conversation around - https://github.com/runatlantis/atlantis/issues/43

I would like to implement it, but I want to get some opinions

@Shane let’s discuss that

we already added some security to our atlantis fork https://github.com/cloudposse/atlantis/releases/tag/0.1.0

and some other features https://github.com/cloudposse/atlantis/releases

@mumoshu would maybe also be interested in that flag

He got busy with Reinvent so couldn’t get back to his PR for custom stages

My prime interest is in using the merge able state and allowing github to do the logic on if it's safe to apply.

I think the interface laid out by Luke looks good by adding a parameter like the require-approval

Add require-mergability

I think it should be also available to “plan”

A user can execute any command as part of plan

In that case would it be better to create 2 separate flags or a flag that has a value and requires mergability for all steps below it in the chain

would we want to do plan even if the PR could not be merged for any reason?

So right now there are “apply_requirements”, then maybe “plan_requirements” for consistency

So if that's how that was designed how would you layout the flags

Would you do a flag per state?

“State” in this case refers to...?

stage as in plan, apply

we played a bit with the GitHub branch protection API in Go, something for reference https://github.com/cloudposse/github-status-updater/blob/master/main.go#L145

@Andriy Knysh (Cloud Posse) thanks I'll take a look

Stab at adding support for rebasing onto master - https://github.com/runatlantis/atlantis/pull/374

that’s cool!

I implemented it in the simplest way as possible that fits my use-case please let me know if you would like to see any tweaks.

makes sense - i hadn’t considered the fact we should be rebasing before running plan/apply, but agree since we always do that before merging.

dependabot does that - which is nice

anyone else see an issue with atlantis with multiple github hooks being processed

.... apparently the tool I'm using to display logs is the culprit...

with a stateful set whenever you have a new container it tails that container, but since it's the same name it tails it X amount of times where X is the amount of new containers that have started since you started the tail....

which tool are you using?

ktail - https://github.com/atombender/ktail

btw, if you’re not able to get your PR merged upstream in atlantis, we’ll accept it in cloudposse/atlantis 😃

@Shane ☝️

woohoo!

@Andriy Knysh (Cloud Posse) ☝️

Looks like it just got merged

That's a nice addition

@Shane what do you think about this?

so that would be a global setting for any terraform in that repo to allow for executing something prior aka in your example rebase?

That's likely helpful as you want to do it before plan and before apply so you would not want it to be part of the apply/plan chain

My understanding is that it's generalized settings for a particular repo

so in your case, it's that you want to rebase after checking out

in our case, we wanted to update submodules

i am thinking this could maybe be solved in the generalized way of adding commands

ya, that sounds reasonable

(not sure if there are global settings - which would also be nice)

basically any action that you wanted to fire off, before a command.

kind of a pre-hook for any action

yea, almost like a pre-hook indeed

maybe changing the name to something like pre-command would make more sense

or pre-actions

oh, so id is a regex, so it's possible to set globals

hi

just recently found out what atlantis is. holy cow this is coooool

Yea, atlantis is very sweeet!

@i5okie and others, I have just added Gitlab and SSM support into Atlantis AWS Fargate module - https://github.com/terraform-aws-modules/terraform-aws-atlantis/

Had some time to get back to coding?

Well, kind of. At the same time I need to do work for customers implementing Terraform while there are no conferences. My next travel will be in 39 days.

That’s almost like a vacation for you

ohh, yes, though I try to not mix work and vacation. Looking forward to my month off in July already 🙂

nice the atlantis chart was merged in - https://github.com/helm/charts/pull/8177#discussion_r241457448

@Shane just merged our helmfile for atlantis: https://github.com/cloudposse/helmfiles/blob/master/helmfile.d/0700.atlantis.yaml

we’re using our monochart though

also, only tested it against our flavor of cloudposse/atlantis

after using monochart i get frustrated using any other charts because it’s so standardized

what’s cool, is we package this helmfile with the container, so it works like a heroku Procfile

im rethinking my pr to add custom stages to atlantis
https://github.com/cloudposse/atlantis/pull/20

can't we just a write a webhook proxy server that sits in front of atlantis instead?

it should either (1) forward the webhook payload as-is to atlantis if it is atlantis plan blah or atlantis apply or (2) run preconfigured shell commands matching the pull request comment body.

this way, we have no need to scope-creep atlantis.

in theory, it will also allow extending atlantis without modifying it in some cases, like running multiple atlantis instances each for different branch.

also, you can add a mono-image containing both atlantis and the proxy then collocate it in the same fargate svc for easy integration/hosting.

maybe im getting crazy but wanted some feedback!

i mean, at this point is atlantis even in the picture?

i suppose you can choose

yea, like if we ultrageneralize this

webhook proxy that runs a command

if you bring atlantis in to the picture, you don't need to reimplement tf-project locking and plan/apply functionalities

that command could be a taskrunner

it could be make

aha, i see

@Shane how are your atlantis adventures going?

I have not touched Atlantis in at least a week. Playing with prometheus operator atm.

@mumoshu aha! I see what you’re staying now

basically, the proxy would look at the request and decide how to route it

and alternatively, be able to call out to some thing else

it’s like a github webhook router

yeah that's my point 👍️

Don't know if anyone has sway in helm/charts repo - https://github.com/helm/charts/pull/10256