Phase 4: Infrastructure as Code & Cloud

Terraform Cloud & Atlantis

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

When you build something really cool with LEGOs, like a huge castle or a sprawling city, it's fun! But imagine trying to build that super-sized city with a whole team of friends. If everyone is building their own part in their own room, how do you make sure all the roads connect properly? What if someone accidentally builds over a park someone else already made, or uses the wrong color bricks for a building that's supposed to match? It can get messy and confusing really fast, and sometimes you just need an adult to approve that new dragon tower before you build it!

That's where special helpers like Terraform Cloud and Atlantis come in. Think of them as a super-organized, shared LEGO workshop. Instead of building your part of the city alone, you write down exactly what you want to build in a special instruction book (this is like your Terraform code). You then place your instruction book into a big, shared cabinet where all your friends' instruction books are also kept. This cabinet is called a Version Control System (VCS), which is just a fancy way of saying a smart, shared digital library for your building plans.

Now, here's the clever part: the workshop (Terraform Cloud or Atlantis) automatically grabs your instruction book from the cabinet. It doesn't start building right away! First, it looks at the entire city blueprint it keeps safe and then shows everyone a "plan" – like a detailed preview picture – of exactly what new pieces will be added or changed if your instructions are followed. Someone on the team, maybe a grown-up or a lead builder, can then look at this plan and say, "Looks good! Build it!" (this is the approval step). Only then does the workshop use its special tools to carefully and perfectly add your new section into the main, shared LEGO city model.

So, when you're dreaming up massive digital structures – like all the computers and databases that make your favorite online games or apps work – you can use this "shared workshop" idea. It means you and your friends can all contribute to building a huge, complex online world, knowing that everyone's work fits together perfectly, all the changes are approved, and no one accidentally breaks anything or builds in the wrong place. Everyone works together, safely and smoothly, to create amazing things!

When working with Terraform in a team, managing state files, ensuring consistent execution, and handling approvals can quickly become complex. Both Terraform Cloud and Atlantis tackle these challenges by providing platforms for remote Terraform operations, turning your version control system (VCS) into the control plane for your infrastructure deployments. They transform the manual terraform plan and terraform apply workflow into an automated, collaborative, and auditable process, crucial for scalable Infrastructure as Code (IaC) practices.

Terraform Cloud is a managed, SaaS offering by HashiCorp that extends Terraform's capabilities beyond your local machine. It handles remote state management, ensuring your state files are securely stored and versioned, and provides a consistent environment for running Terraform operations. Key features include a web UI for viewing runs, team management, policy as code (Sentinel) for governance, cost estimation, and robust integration with popular VCS providers. You configure your Terraform code to use the cloud block, push changes to your VCS, and Terraform Cloud automatically plans and, upon approval, applies them, centralizing your IaC workflow and enhancing security and collaboration.

Atlantis, on the other hand, is an open-source application that you self-host, designed specifically for a GitOps workflow with Terraform. It integrates directly with your VCS (like GitHub, GitLab, or Bitbucket) and listens for pull request (PR) events. When a PR is opened or commented on with commands like atlantis plan, it executes terraform plan on the changes within that PR, posting the output directly back as a comment. Similarly, atlantis apply triggers the deployment. This PR-centric workflow allows team members to review proposed infrastructure changes in a familiar environment before they are applied, offering fine-grained control and transparency, especially for teams who prefer to manage their own tooling infrastructure.

Key Takeaways

  • Both simplify collaborative Terraform workflows and manage remote state.
  • Terraform Cloud is a managed SaaS with advanced features like policy enforcement and cost estimation.
  • Atlantis is self-hosted and provides a lightweight, PR-driven GitOps workflow.
  • They ensure consistent Terraform execution and reduce manual errors by automating runs.
  • Choose based on need for a managed service versus self-hosting, and specific workflow preferences.

Code Example

hcl
terraform {
  # This block configures Terraform to use Terraform Cloud
  # for remote state and operations.
  cloud {
    organization = "my-devops-org" # Replace with your organization name

    workspaces {
      # This links your local Terraform configuration to a specific
      # workspace in Terraform Cloud.
      name = "application-backend-services"
    }
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

How this code works

This code establishes the foundational settings for a Terraform project, primarily configuring it to integrate with Terraform Cloud. Its main job in the lesson is to enable remote state management and remote operations through Terraform Cloud, which is essential for working with tools like Atlantis. The top-level terraform block contains a cloud configuration that specifies the Terraform Cloud organization name and links the local configuration to a particular workspaces.name. This setup means that instead of running terraform apply locally, operations will be executed remotely in Terraform Cloud, storing state there and leveraging its collaborative features.

The required_providers block declares that this project needs the aws provider, ensuring Terraform automatically fetches it from hashicorp/aws at a version compatible with ~> 5.0. A subtle point for beginners is that by simply including the cloud block, Terraform automatically shifts from local state and execution to remote state and execution in Terraform Cloud. This default behavior means that subsequent terraform commands will interact with the configured remote workspace, even if not explicitly specified on the command line, fundamentally changing how Terraform manages infrastructure.

Resources

Related Articles

Hand-picked reads to go deeper on infrastructure as code (terraform).

Back to DevOps Engineer Roadmap