#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