IaC (Infrastructure-As-Code) is a widely accepted and industry-standard best practice because it treats infrastructure as code making it repeatable and immutable and setup as a software development project.
Instead of manually configuring servers, databases, networks, and other infrastructure components, you write code to define and manage these elements, and this code can be version-controlled, tested, shared, and reused, just like any other software code.
Adopting IaC allows for the automation of infrastructure deployment, which significantly reduces the risk of human error and increases efficiency.
It also promotes consistency and predictability across environments since the infrastructure is defined by code, which can be executed in the same way every time.
Terraform is one of the most widely used IaC tools adopted by most organizations due to its simple to use language format, and ability to use modules with large community support, and being cloud agnostic making it a very powerful tool for all development organizations.
Most infrastructure as code projects follow this path.
- Create a base module and deploy it.
- Further changes are made to local and checked with terraform plan.
- Once the developer is comfortable with the changes, those are applied via a terraform apply.
Now translate that to a large organizational structure. There can be multiple developers working on a single project and change management control must be in-place.
Most companies have a source control software in place (GitHub; GitLab or Bitbucket etc) and use the automation tools to create change workflows, for example:
- Changes are created and pushed to a separate branch.
- Peer review is created, and changes approved.
- Changes are applied via “terraform apply” and the branch is merged into main.
While the above does seem like an improvement, it has multiple avenues which can be optimized.
- Even if source control is being used, the actual apply is still being done locally. This poses issues if the apply fails midway and the branch is still merged. Or if someone forgets to apply the changes after the branch is approved, this results in different terraform states between whats actually deployed and what is set in the main branch.
- Terraform change sets can be massive for even a slight change. A simple change in the AMI ID can cause a whole host of changes in the infrastructure. Such changes are not easy to review in a simple merge request, developers require a terraform plan to be present to easily understand what is going to change to improve there ability to review and accept the changes.
- Long surviving branches, if developer A “branches-out” from main and applyes changes without merging to main another developer (developer B) can merge changes that will override settings, this will cause your infrastructure to be in a dangerous inconsistent state.
Atlantis enhances Terraform by providing a unified, collaborative workflow for infrastructure projects.
- It integrates with version control systems, and automates multiple Terraform workflows concurrently.
- Locks infrastructure state to prevent conflicts.
- Through these capabilities, Atlantis streamlines Terraform operations, increasing efficiency and safety for teams working at scale.
Imagine the usecase described above, but now instead of just reviewing a change list in the new commit, a reviewer has the ability to comment atlantis plan and get the terraform plan directly in the pull request comments. The use has the ability now to fully understand what infrastructure changes are taking place, giving much greater confidence in the ability to review and accept changes.
And that is not all. But typing “Atlantis Apply”, the reviewer can directly apply the changes to the main branch and merge the branch.
How Atlantis for terraform accomplish this?
At its core, Atlantis provides a unified workflow for collaborating on Terraform projects. It integrates with version control systems like GitHub, GitLab, and Bitbucket, and utilizes pull requests as the primary mechanism for proposing infrastructure changes. This allows for code reviews and team discussions to occur directly within the context of the proposed changes, leading to more informed decision-making.
In addition, Atlantis can concurrently execute multiple Terraform workflows, enabling teams to work on separate infrastructure components simultaneously without conflict. It also maintains a detailed history of all actions, providing a clear audit trail that can be invaluable for troubleshooting and compliance purposes.
Finally, Atlantis automatically locks the state of the infrastructure components being modified, preventing conflicting modifications and ensuring consistency. This state-locking mechanism is a crucial feature for teams, as it helps avoid the pitfalls associated with manual coordination, especially in large, dynamic environments.
Setup
You can setup atlantis for terraform on your AWS account in multiple different ways. For the purpose of this blog, lets consider a simple deployment on AWS EC2.
Before we begin, you will require the following prerequisites.
- A Github Access Token: Navigate to your GitHub settings and create a personal access token
- Github Webhook Secrets: Atlantis uses these to validate the webhooks it receives from your Git host. You can create your own using any random string generator.
- Terraform Backend: For this guide, we’re using s3 as the Terraform backend. Atlantis supports all the backends except the local backend.
Easy Setup on a EC2 Instance:
We must create and prep the EC2 instance on which the Atlantis binary will run and execute.
Navigate to the AWS Management Console and go to the EC2 dashboard.
- Click on “Launch Instance” and select an OS (Amazon Linux 2 or Ubuntu are recommended).
- Choose an instance type (t2.micro is sufficient for demo purposes).
- Configure the instance details, add storage, and configure security groups to allow HTTP/HTTPS traffic.
- Review and launch the instance.
Depending on the OS you choose, update and install the required binaries and dependencies. We will require git, wget and unzip.
sudo yum update
sudo yum install -y git unzip wget
Next download the atlantis binary from the official git source and install it on the EC2 instance here
Configuring Atlantis
Now that the EC2 is prepped and ready, we need to configure atlantis. Atlantis requires a configuration.yaml file which lets it know the github ID to listen to, along with a setting up a webhook in the github account.
Create the a atlantis configuration file on the EC2 instance.
repos:
- id: git_url/your_id/repo
workflow: custom_workflow
allow_custom_workflows: true
workflows:
custom_workflow:
plan:
steps:
- init
- plan
Add the webhook to the github profile (the public IP of the EC2 on which Atlantis is setup) and then finally start atlantis by executing.
atlantis server --config atlantis.yaml
Note: If you run into a repo-allowlist error, simply add the –repo-allowlist flag with the link to the repo and it should work fine.
And that is it! You have an atlantis server listening to pull requests on the repo you have created. Whenever there is a pull request, you should see a atlantis plan in the comments of the pull request.
Conclusion
Atlantis for Terraform is a pivotal tool that enhances your Infrastructure as Code (IaC) practices by integrating code reviews into Terraform deployments. By following our walkthrough, you’re now equipped to set up Atlantis on AWS, enabling more secure and collaborative Terraform workflows.
Atlantis is not just a tool; it’s an essential component for any DevOps pipeline aiming to use Terraform effectively. It streamlines deployments and fosters a culture of best practices, making it indispensable for modern infrastructure management.
