Use atlantis as a github action

[kishaningithub]

Problem

From a setup point of view atlantis requires an installation and maintenance of a server. I think there should be avenues that is explored to remove this overhead.

Proposed solution

This is very specific to github, i assume there must be similar things for other CI servers.

1. Given this a golang project, expose atlantis as a github action using go-githubactions
2. Given github actions are stateless i propose we add a new locking backend which makes use of actions cache to store the state

[nitrocode]

How would it work? We cannot host the server ourselves.

We would need perhaps a local subcommand to run workflows using repo atlantis.yaml file. See issue #671.

You may be interested in using github actions natively instead. See this project https://github.com/dflook/terraform-github-actions

[kishaningithub]

In my mind, atlantis holds it state in its backend which is currently either boltdb or redis. If we separate backend, then atlantis is a stateless component at a high level. Github actions are great for stateless things, in my mind github actions are like AWS Lambdas as they have the same execution flow which is

Trigger --> Perform tasks --> Terminate

For atlantis, the triggers are people typing terraform commands in their PR. Tasks are functionalities offered by atlantis(locking etc).

Given the ephermeral nature of this execution model, the current backends are not ideal (boltdb data will get purged as Github CI agent terminates, running redis involves runtime cost and maintenance overheads)

Hence i recommend adding github actions cache as a new backend to store state.

@nitrocode Also thanks a lot for recommending terraform-github-actions never knew that existed before your comment. Will give that a spin :-)

[kishaningithub]

I just checkout terraform-github-runners But there are some important differences like dflook/terraform-github-actions#151 (comment) which makes it very different than atlantis

[jamengual]

I'm guessing your design is assuming self hosted runners? where there is more control. of the cache storage?

…

On Tue, Jan 17, 2023, 9:27 p.m. Kishan B ***@***.***> wrote: In my mind, atlantis holds it state in its backend which is currently either boltdb or redis. If we separate backend, then atlantis is a stateless component at a high level. Github actions are great for stateless things, in my mind github actions are like AWS Lambdas as they have the same execution flow which is Trigger --> Perform tasks --> Terminate For atlantis, the triggers are people typing terraform commands in their PR. Tasks are functionalities offered by atlantis(locking etc). Given the ephermeral nature of this execution model, the current backends are not ideal (boltdb data will get purged as Github CI agent terminates, running redis involves runtime cost and maintenance overheads) Hence i recommend adding github actions cache <https://github.com/actions/cache> as a new backend to store state. @nitrocode <https://github.com/nitrocode> Also thanks a lot for recommending terraform-github-actions <https://github.com/dflook/terraform-github-actions> never knew that existed before your comment. Will give that a spin :-) — Reply to this email directly, view it on GitHub <#2994 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3ERFBKBQDDAYXOZJIBWTWS55L3ANCNFSM6AAAAAAT55RVHQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[kishaningithub]

Yes. More context here #2994 (reply in thread)

[kishaningithub]

Do you see any problems of doing the same with github public runners?

[kishaningithub]

@nitrocode @jamengual After giving it a more thought, i think the flexibility of the backend interface will be a huge advantage as people would be able to plug and play the desired backend as a parameter/input to the github action. The backend can be anything like Github Cache, Dynamodb Table (For AWS users), Cockroach DB etc which would be plugged in to to the github action as a parameter/input/env secret

[jamengual]

sounds very interesting and I'm looking forward to your PR

[danielgblanco]

Hi all, I've put something together as a PoC in https://github.com/danielgblanco/atlantis-gha-poc

There are some caveats to the approach, but hopefully that shows a way forward. Being able to forward GH events as a command, rather than having to start server and wait for it to complete, would make things simpler! Using an external Redis instance to manage locking is definitely an enabler for this sort of feature :)

[dimitar-hristov]

Hello 👋 As a follow up to Dan’s initial PoC, we managed to implement and get Atlantis to work in GitHub actions. The bullet point list below gives a high level overview of what we did:

• Atlantis runs as a container inside of a GitHub actions workflow on an ephemeral runner.
• The Atlantis backend resources (an S3 bucket, a dynamoDB table and an ElastiCache for Redis database) are deployed in the same account as our self-hosted GitHub actions runners. The reason for mentioning this is because setting up access to Redis in the same account is easier compared to if it is separate.
• We use an OIDC provider to authenticate with AWS from the runners.
• Using inline session policies and OIDC we ensure that only the owning repository has access to the Atlantis/Terraform backend resources preventing malicious actions.
• The Terraform stateful data is stored in an S3 bucket and dynamoDB table in AWS.
• The Atlantis planning data is stored in an S3 bucket and uploaded/downloaded using the aws s3 sync command.
  • We initially attempted to use GitHub cache to store the planning data, however, we were unable to get Atlantis auto planning enabled due to the structure of GitHub cache and what can access it.
• Used a GitHub app and creds instead of the GITHUB_TOKEN in order to enable auto merge and allowed commands in Atlantis.
• The Atlantis locks data is stored in ElastiCache for Redis database.

We have been using it for a couple of months now and haven’t seen any issues with it. If you are interested in more details, I can try and include some snippets as well.

There are also some improvements that we would like to implement, but haven’t had a chance yet:

• Using Atlantis CLI - currently Atlantis can only run as a Golang microservice service. However, with the separation of the Atlantis core functionality from the backend locking mechanism (External backend for Locking. #894), this looks more viable.
• Redis AUTH - the usual password based authentication. Following Redis 6.0, we also have access control list (ACL) allowing for multiple users and passwords with different permissions. However, it appears that Atlantis does not support configuring non-default users yet as can be seen here. The main drawback of the default Redis user is that it is not password protected - Improve Redis configuration options to allow the use of non default user or connection string #3610.

I hope it makes sense. If you have any questions, please let me know and I could try to clarify it. 🙂

[jamengual]

That is really cool, although there is a lot of craft needed to make it work, so I think improving this workflow by adding an Atlantis cli and such could make this easier.

If you could create a blog post or post in this discussion some of your scripts that could help other people to try it and drive contributions to the code.

Thanks a lot @dimitar-hristov

[HomegrownDev]

@dimitar-hristov I'm going to give this a try in my GH actions pipeline, and will forward any improvements.

[oleg-glushak]

@dimitar-hristov I wonder how you mitigate the risks related to the working directory locks described e.g. here (Problem 2.2 Repo level locking)

I can image race conditions when concurrently running multiple plan/apply commands for the same terraform directory (e.g. within the same pull request) resulting in applying outdated plans.

[psigen]

@oleg-glushak Can this be handled by using a concurrency key on the action?