#atlantis (2019-01)
Discuss the Atlantis (<http://runatlantis.io | runatlantis.io>) |
**Archive: ** https://archive.sweetops.com/atlantis/
2019-01-10


Any chance this will be live streamed or a recorded?

That’s a good question. I am not sure if it will be recorded.

I will find out.

Thanks

I’ll be giving a live demo of Atlantis


2019-01-11

Lots of content on your slides. Will it be an hour talk?

last I did it was ~30 minutes + 30 minute q&a

also, these are the old slides

going to revamp them before the conf

Good luck with this talk. It is great to share Atlantis with the community in any way. (I am about to be involved in getting it up and running in Azure… omg)

2019-01-23
2019-01-25

Hey, im always curious about Atlantis, kind of would like to use it, but we prefer to apply on merge. For the ones doing apply on PR, how do you work with it and lets say, ECS. We have our ECS service defined in terraform for the time being (yeah not the best I know, but this could be a DB change or something else) and if we applied on PR, the new container or service that should use this will not be deployed yet, unless you also build the container on PR. How do you handle that?

I have a lot of thoughts on why you don’t apply on merge for terraform

web apps, cool. they are usually stateless and easily rollback.

terraform does not rollback in the face of errors.

terraform errors all the time.

happened to me a couple of times yesterday

the plan
is very primitive. “in an ideal world, here’s what I plan to do”

so atlantis ensure we keep master
pristine of what was deployed

rather than what should have been deployed

Yeah, I do get that part of the flow, and doing full CI is super “expensive” for terraform, as you will have to A) deploy old version B) apply the new version on top, on an isolated environmant, which might take a while. But I wonder how is that tied in when your terraform requires the deployed version of the app or thing to already running, as the workflow makes it so you always have to do terraform first with atlantis

unless you do 2 PRs for the 1 change

I guess sometimes, its good as it enforces the app/infra to support the update in a “rolling” fashion, or you take the downtime which you would anyway if the merge of the infra “broke” something for the app

~EG: you are changing CORS and adding some DNS~ad example, you can do that one without requiring the app to be running with the new CORS

I keep wondering as I like the idea of the terraform part running on a completely detached part, with its own creds. It works sort of like Terraform Enterprise

Yea, it work similar to Terraform enterprise.

As for the workflow between your other apps and terraform, that is out of scope for atlantis

Yeah I know it is, but it is part of the same pipeline and have to coexist, so I’m wondering about the full story for it.

Fair enough!

@pecigonzalo by default we deploy a standard backing image with ECS

and then use an out of band CI/CD to deploy the actual app we want

Yeah, the docker part was just an example

but if you had certain DB change for example, it would be the same

Terraform module that implements a web app on ECS and supports autoscaling, CI/CD, monitoring, ALB integration, and much more. - cloudposse/terraform-aws-ecs-web-app

The container one was just an example because it makes clear the “problem” i see

but there might be other changes that should be insync with that is deployed

Too bad Atlantis closed the PR for apply
on merge, because that workflow would be sweet, atlantis saves plan from PR, which was approved in line, then on merge, it applies that plan
2019-01-30

hey hey

which atlantis repo should I be looking at to run atlantis in conjunction with the geodesic ref arch?

I mean I see ECS https://github.com/cloudposse/terraform-aws-ecs-atlantis & ECS fargate https://github.com/cloudposse/geodesic-aws-atlantis
Terraform module for deploying Atlantis as an ECS Task - cloudposse/terraform-aws-ecs-atlantis
Geodesic module for managing Atlantis with ECS Fargate - cloudposse/geodesic-aws-atlantis

wait and a helm chart?

Comprehensive Distribution of Helmfiles. Works with helmfile.d
- cloudposse/helmfiles

so ooooooo

I don’t recommend running atlantis in kubernetes

we started down that path and support it

yea I agree

I want atlantis to be managing my k8s clusters

But just remember, then you have a pod that someone can kubectl exec
into with admin

avoid the inception trap

So we have a nice e2e working story with ECS Fargate

im alright with that for now

later I might consider a locked down k8s or soemthing

@joshmyers finished updating our example here:

what The updates testing.cloudposse.co to use the latest Geodesic image with a host of new goodies like Atlantis support, tfenv, scenery, tfmask. Requires cloudposse/terraform-root-modules#107 to b…

We merged that this morning

something less AWS specific

unfortunately, not documented

All the ECS/Atlatnis stuff is demonstrated here: https://github.com/cloudposse/terraform-root-modules/tree/master/aws/ecs
Example Terraform service catalog of “root module” invocations for provisioning reference architectures - cloudposse/terraform-root-modules

haha you know I like my docs in the form of code

Currently, we don’t have an alpine package for atlantis
(our fork)

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

I should probably give you a demo of what the workflow looks like using Atlantis

B/c the docker multi-stage isn’t ideally suited for it.

Yeah, it took quite a bit of plumbing to get to work in this workflow

so I will need to get atlantis in place asap

have on-boarded 8 core team members to our version of geodesic + ref arch

pipelines are next up

and a few others


I can give you the low down so you can get started

won’t take long to deploy
