DevOps engineers are usually responsible for operating infrastructure software like Terraform, but what if we could change that and help developers to build even faster? What if the DevOps teams think about coding standards and best practices for Terraform as Pull requests, code reviews, CI / CD pipelines? I will show you how we can easily run Terraform from CI/CD pipelines by bringing a Terraform workflow to pull requests.

1. hugs@hashicorp.com | learn.hashicorp.com | discuss.hashicorp.com

3. Tal Hibner
o Proud owner of this gentleman
o Geek
o Maccabi Tel Aviv Basketball fan
o Master Scuba Diver
o Developer in the past, Devops Engineer in the present
o AWS Community Builder - Dev Tools
o AWS re/Start program mentor - Appleseeds

5. ● Infrastructure is described using a high-level configuration
syntax.(HCL)
● This allows a blueprint of your infrastructure to be versioned, shared,
re-used, and treated as you would any other code.
● For example, This code declares that we want an AWS EC2 instance.
Infrastructure as code

7. Terraform helps you being both cloud-agnostic and enabling
multiple providers and services to be combined and composed.

8. Terraform is a universal tool to manage anything that has an API:
https://registry.terraform.io/browse/providers

9. It enables Terraform to
represent and manage the
entire infrastructure with its
supporting services, instead
of only the subset that exists
within a single provider.

10. Terraform has a
"planning" step where it
generates an execution
plan showing what
Terraform will do to
reach the desired state.
Once the execution plan
looks good, It executes it
to build the described
infrastructure.
Plan
Apply

12. ● What’s the best way to collaborate on Terraform in a team setting?
● When writing Terraform, there are a number of workflows you can follow.
The simplest workflow is just using master:
● In this workflow, you work on master and run terraform locally.
First Problem - Effective Collaboration

13. ● The problem with this workflow is that there is no collaboration or code
review.
● So we start to use pull request. We still run terraform plan locally, but once
we’re satisfied with the changes we create a pull request for review.
● When the pull request is approved, we run apply locally.
First Problem - Effective Collaboration

14. The first problem is that it’s hard to review just the diff on the pull request.
To properly review a change, you really need to see the output from
terraform plan. What looks like a small change can have a big plan
This workflow is an improvement,
but there are still problems.

15. ● The second problem is that now it’s easy for master to get out of sync with
what’s actually been applied.
● This can happen if you merge a pull request without running apply or if the
apply has an error halfway through, you forget to fix it and then you merge to
master. Now what’s in master isn’t actually what’s running on production.
● At best, this causes confusion the next time someone runs terraform plan.
● At worst, it causes an outage when someone assumes that what’s in master
is actually running, and depends on it.

16. ● Terraform usually starts out being used by the Ops team.
● As a result of using Terraform, the Ops team becomes much faster at making
infrastructure changes.
● But the way developers request those changes remains the same.
Second Problem - Developers Writing Terraform

17. Second Problem - Developers Writing Terraform
● Soon however, the Ops team starts to realize that it’s possible for developers
to make some of these small changes, Devs understand code (surprise!)
● Devs can see exactly what is required to make the change. This means
there’s less back and forth over a ticket.

18. ● Developers don’t have the credentials to actually run Terraform commands.
● If you give them credentials, it’s hard to review what is actually being applied.
● It’s often difficult to do seemingly simple things (think adding a security group rule
that also requires peering VPCs). This means that just having access sometimes
isn’t enough. Devs might need help from an expert to get things done.
Third Problem - Developers are locked out!

20. ● Atlantis is an open source tool for Terraform collaboration that’s
been originally created at Hootsuite by Anubhav Mishrar and
maintained by Luke Kysow.
● Atlantis is an application for automating Terraform via pull
requests.
● It is deployed as a standalone application into your infrastructure.
● No third-party has access to your credentials. Access is controlled
through pull request approvals.
What Is Atlantis?

21. Atlantis listens for GitHub, GitLab or Bitbucket webhooks about Terraform
pull requests.
How does it work?

22. Step 0 — Generating an Access
Token
● First, Create a new GitHub User named @atlantis so all the comments
that Atlantis writes will come from that user.

23. A developer creates a pull request with their change
to add a security group rule.
Step 1 — Create a Pull Request

24. Atlantis automatically runs terraform plan and comments back
on the pull request with the output. Now developers can fix
their Terraform errors before asking for a review.
Step 2 — Create a Pull Request

25. The developer pushes a
new commit that fixes
their error and Atlantis
comments back with the
valid terraform plan
output. Now the
developer can verify that
the plan output looks
good.
Step 3 — Fix The Terraform

26. Here the developer tried to apply without getting the pull
request approved, and failed.
Step 4 — Get Approval

27. Here two changes are
being made to the same
repo.
If I run atlantis plan here,
Atlantis is going to tell me
that someone else is
already working on this
repo.
Step 4 — Get Approval

28. You can go to Atlantis UI and see your Locks for troubleshooting.
Step 4 — Get Approval

29. You can go to Atlantis UI and Discard Terraform Plan and Unlock!
Step 4 — Get Approval

30. An Ops can now come along and review the changes and the output of
terraform plan. It’s easy for the operator to review the changes because
they can see the output of terraform plan.
Step 4 — Get Approval

31. Conftest Policy Checking

32. Conftest Policy Checking

33. To apply the changes, the developer or operator comments
“atlantis apply”.
Step 5 — Apply

34. Atlantis Binaries

35. Atlantis with Terragrunt
If you don't want to create/manage
the repo's atlantis.yaml file
yourself, you can use the tool
terragrunt-atlantis-config to
generate it.

36. Atlantis Deployment

37. There is an official Atlantis Docker image

38. Terraform Module for running Atlantis on
AWS Fargate by Anton Babenko

39. Terraform Module for running Atlantis on
AWS Fargate by Anton Babenko

40. At Lyft, they manage their own Kubernetes stack
which they leveraged to run Atlantis as well.

41. Alternatives
https://learn.hashicorp.
com/tutorials/terraform/
automate-
terraform#pre-installed-
plugins

50. Thank You
hugs@hashicorp.com | learn.hashicorp.com | discuss.hashicorp.com