#atlantis (2019-10)
| Discuss the Atlantis (<http://runatlantis.io | runatlantis.io>) |
**Archive: ** https://archive.sweetops.com/atlantis/
2019-10-08
What was the thing that was like Atlantis, but not?
Can’t find it in the archives
yea, i know what you mean.
it had a horrible name
@joshmyers
Awesome, thanks @Erik Osterman (Cloud Posse)
Oh, it’s not OS, https://github.com/geopoiesis?tab=repositories
Oh… thought it was
2019-10-11
Am I right in saying the Atlantis workflow is to deploy before the code is merged? Isn’t that a bit sketchy?
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.
Ah perhaps I have my workflows wrong in my head (purely theoretical, no atlantis deployed yet)
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.
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).
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
we want the master to reflect what is deployed, so we merge to master only if everything is ok
Thanks guys.
So really the workflow isnt to actually comment Atlantis apply until it has been merged?
Is there a way to enforce this?
So that someone cant comment and trigger the apply of the plan before merge etc
Yes Atlantis uses a planfile so even if you tried to apply before plan it would fail
With Atlantis you run apply before merge
I think there is also an option to auto merge on apply
So if apply fails it doesn’t merge
Still if the atlantis.yaml file lives in your repo, you canc change it in the PR and skip the approval enforcement
that’s like one “security issue” i still don’t get
when you deploy atlantis, you provide a global atlantis-repo-config.yaml
where you can specify what users in the repo that atlantis provisions can do
# 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
(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)
Nice!!!
I’ll look into inplementing
thanks @Andriy Knysh (Cloud Posse)
2019-10-15
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.
2019-10-21
Hey all, Im considering using atlantis but I’ve got a few questions(coming from a TFE environment triggered by jenkins).
- 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?
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?
basically, im not sure how to setup atlantis/git for a multi-environment configuration
we deploy atlantis on ECS in each account (staging, prod, testing) https://github.com/cloudposse/terraform-aws-ecs-atlantis
Why not run in one place with assume role?
we almost always use separate AWS accounts for each environment (dev, staging, prod)
although more difficult to setup, it adds a lot of benefits including better security, better control, and complete isolation of environments
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?
yes
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:aws:iam::${var.aws_account_id}: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
it could be deployed in may diff ways for sure. And what you showed above will work as well
since we use separate AWS accounts for all environments, we deploy separate atlatis in each
it’s not that expensive to deploy an atlantis container on ECS fargate
but it simplifies management and security
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
Thanks, I’m a little on the fence, but I am leaning toward changing to this approach as well
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
instead of thinking about how to configure that for many repos for diff environments using just one atlantis
i’m not saying it’s the perfect solution, there is no one
it requires more settings and more deployments
but it simplifies management, security and all IAM stuff
plus, of cause, if something happens with one atlantis (container fails, bad deployment, etc.), it will not affect all the others
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
we have a catalog of common modules which we use in all environments https://github.com/cloudposse/terraform-root-modules/tree/master/aws
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
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)
then do the same for [prod.cloudposse.co](http://prod.cloudposse.co)
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
when you say in staging you mean staging branch?
we have separate repos for each account
they use the same catalog of modules https://github.com/cloudposse/terraform-root-modules/tree/master/aws
but just provide settings related to the environment
so we separate code (logic) from settings/secrets