Managing infrastructure changes across large teams can lead to inconsistencies, deployment delays, and unexpected changes. This is exactly what you don't want when operating infrastructure.

To tackle these issues, teams can use Terraform to define infrastructure as code and GitOps for managing their deployment workflows. The combination of these two creates a strong foundation for automated and version-controlled infrastructure management. Terraform's declarative approach naturally aligns with GitOps.

Terraform code describes the desired infrastructure state:

resource "google_compute_instance" "staging_compute_instance" {
  name         = "staging-compute-instance"
  machine_type = "e2-small"
  zone         = "us-central1-a"
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
  network_interface {
    network = "default"
  }
}

The Terraform CLI managing live infrastructure:

bender@ringo:~/gcp/staging$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # google_compute_instance.staging_compute_instance will be created
  + resource "google_compute_instance" "staging_compute_instance" {
      + can_ip_forward       = false
      + cpu_platform         = (known after apply)
      + creation_timestamp   = (known after apply)
      + current_status       = (known after apply)
      + deletion_protection  = false
      + effective_labels     = {
          + "goog-terraform-provisioned" = "true"
        }
      + id                   = (known after apply)
      + instance_id          = (known after apply)
      + label_fingerprint    = (known after apply)
      + machine_type         = "e2-small"
      + metadata_fingerprint = (known after apply)
      + min_cpu_platform     = (known after apply)
      + name                 = "staging-compute-instance"
      + project              = "terrateam-sandbox"
      + self_link            = (known after apply)
      + tags_fingerprint     = (known after apply)
      + terraform_labels     = {
          + "goog-terraform-provisioned" = "true"
        }
      + zone                 = "us-central1-a"

      + boot_disk {
          + auto_delete                = true
          + device_name                = (known after apply)
          + disk_encryption_key_sha256 = (known after apply)
          + kms_key_self_link          = (known after apply)
          + mode                       = "READ_WRITE"
          + source                     = (known after apply)

          + initialize_params {
              + image                  = "debian-cloud/debian-11"
              + labels                 = (known after apply)
              + provisioned_iops       = (known after apply)
              + provisioned_throughput = (known after apply)
              + resource_policies      = (known after apply)
              + size                   = (known after apply)
              + type                   = (known after apply)
            }
        }

      + network_interface {
          + internal_ipv6_prefix_length = (known after apply)
          + ipv6_access_type            = (known after apply)
          + ipv6_address                = (known after apply)
          + name                        = (known after apply)
          + network                     = "default"
          + network_ip                  = (known after apply)
          + stack_type                  = (known after apply)
          + subnetwork                  = (known after apply)
          + subnetwork_project          = (known after apply)
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

bender@ringo:~/gcp/staging$

Terraform can easily be designed in a way that supports creating reusable infrastructure components that teams can version and share across projects. This modular design allows team members that aren't very familiar with infrastructure as code confidently manage live infrastructure with existing and vetted modules.

Understanding GitOps Principles

Git repositories act as the source of truth in a GitOps workflow. Every change to your infrastructure begins with a commit and a pull request. Once this pull request is created, the feature branch will automatically go through your other standard automated validations (e.g. GitHub status checks, approvals, etc.) before any deployment. This process comes with many benefits out of the box, like traceability, peer reviews, and continuous integration checks before changes reach your environments.

One of the main benefits of GitOps when it comes to infrastructure as code, is its nature of describing what infrastructure should be, and having automated systems ensure that desired state. When live infrastructure drifts from your reposistory, these discrepancies are automatically surfaced.

Conclusion

The combination of Infrastructure as Code and GitOps provides a strong system of workflows for managing live infrastructure. Terraform enables teams to define their desired state of infrastructure, while GitOps principles ensure these definitions remain version-controlled and consistently deployed. The result of combining these tools is a familiar and reliable workflow that includes enhanced security, traceability, and increased velocity when deploying infrastructure.

If you're looking for an open-source solution that combines Terraform with the benefits of GitOps, head on over to the Terrateam repository to get started with docker-compose up.

Features

Learn More

Learn

Connect