Why Terraform Enterprise?

Reason 1: Terraform Modules and Private Registry

We prefer to write Terraform modules for our Terraform deployments. These modules help us process recurring tasks quickly and easily. For example, we have modules to create VMs on all possible cloud providers or virtualization platforms, because VMs are (almost) always needed.

One could, of course, save such a module locally in a subdirectory and call it in the Terraform root module; the VM is created, and that’s it.

But hold on! We work in a team. Everyone needs these modules, and every now and then we change them, fix a bug, etc. Everyone should benefit from this.

Ultimately, companies can deploy their DevOps and IT automation according to their internal compliance and policy using their own Terraform modules.

That is why we use the Terraform Enterprise Registry. For each of our modules, there is a dedicated repository in (e.g.) GitHub. The repository is linked to Terraform Enterprise. As soon as someone creates a new release in GitHub, Terraform Enterprise automatically retrieves the new version, and everyone can use it.

Another advantage of having your own module registry is, of course, the enforcement of standards. Since all VMs were created with the same modules, they are all built according to our standard, ensuring no surprises afterward.

Reason 2: Terraform Enterprise Workspaces

Now we have our modules in the registry and can use them in projects. We also do this with Terraform Enterprise. For this purpose, we create a so-called Workspace. Here, too, Terraform Enterprise offers the option to link a repository. For example, if a change is pushed to Git, a “terraform plan” can be executed automatically.

But now, let’s take it one by one:

What is a Terraform Workspace?

In the Workspace, all essential elements are consolidated and can be managed centrally:

First, we create a repository in GitHub and develop our Terraform code within it. In this example, we immediately use one of our modules from our Terraform Enterprise Registry.

Now we create a Workspace in Terraform Enterprise of type “VCS” (Version Control System) and select our GitHub repository as the source.

In addition to the “GitOps” VCS Workflow, Terraform Enterprise offers further options:

We still have a small problem: “Where do the variables go?”

Locally, this is not such a problem, e.g., writing the credentials for vCenter into a terraform.tfvars file. However, we certainly do not want to see them in GitHub. Keep calm!

In Terraform Enterprise, values for variables can be stored. It includes an internal Vault where our variables are even encrypted.

With this, we have completed everything and can run our Terraform code. This can be done with a single click in the UI:

If there are changes in the Terraform code, i.e., a commit is pushed to the repository, Terraform Enterprise automatically executes a “terraform plan”. With a click, we confirm the plan, and the “terraform apply” starts.

Reason 3 – X:

There are many more good reasons that speak for Terraform Enterprise. These are also good reasons for further blog posts – including:

Guiding Principle & Vision: Self Service & Automation

Ultimately, Terraform Enterprise allows us to establish continuous and, above all, “compliant” workload and lifecycle management in modern enterprises.

Naturally integrated into pipelines (CI/CD) and, if desired, completely secured – ensuring that no one can get their hands on even a single credential – e.g., with “Secure Infrastructure Pipelines” using Hashicorp Vault.

How does that work? Please feel free to contact us!