At FullStackS, we use Terraform for everything we do. We build VMs to deploy Kuberneters clusters, we install and configure Ranchers with it, sometimes we even use Terraform to configure Terraform Enterprise.
In short: There are many things where Terraform simplifies our work and we create great value for our customers. That's why everything we do as FullStackS is Infrastructure as Code. Because at the end of the day, it's about speed and innovation - these are real values for our customers.
But why do we use Terraform Enterprise
although Terraform is OpenSource?
Let's put it this way: For good reasons!
And it is precisely these reasons that we would like to address below.
Reason 1: Terraform Module and Private Registry
We like to write Terraform modules for our Terraform deployments. These modules help us to handle recurring tasks quickly and easily. For example, we have modules to create VMs at all possible cloud providers or virtualization platforms, because VMs are (almost) always needed.
Now, of course, you could store such a module locally in a subdirectory and call it in the Terraform root module, VM created, done.
But stop! We work as a team. Everybody needs these modules, and every now and then we change them, fix a bug, etc. Everyone should benefit from this.
Ultimately, enterprises can deploy your DevOpS and IT automation entirely according to your enterprise compliance and policy via your own Terraform modules.
That's why we use the Terraform Enterprise Registry. For each of our modules there is a separate repository in (e.g.) GitHub. The repo is linked to Terraform Enterprise. As soon as someone creates a new release in GitHub, Terraform Enterprise automatically fetches the new version and everyone can use it.
Another advantage of having our own module registry is, of course, enforcing standards. Because all VMs were created with the same modules, they are all built according to our standard and there are no surprises afterwards.
Reason 2: Terraform Enterprise Workspaces
Now we have our modules in the registry and we can use them in projects. We also do this with Terraform Enterprise. We create a so-called workspace for this purpose. Terraform Enterprise also offers the possibility to link a repository. If you push a change in Git, for example, a "terraform plan" can be executed automatically.
But now one after the other:
What is a Terraform Workspace?
In the workspace, all essential elements are combined and can be grabbed "by the scruff of the neck":
Terraform State
All variables
Access authorization (RBAC)
Workflows
Notifications (e.g. WebHooks, Slack, Teams, etc.)
First, we create a repository in Github and build our Terraform code in it. In the example, we'll use one of our modules from our Terraform Enterprise Registry right away.
Now we create a workspace in Terraform Enterprise of type "VCS" (Version Control System) and select our GitHub repository as source.
In addition to the "GitOps" VCS workflow, Terraform Enterprise offers other capabilities:
CLI Driven Workflow: with Terraform as Single "Go" Binary in a Shell
API Driven Workflow: Integration with existing systems, such as ServiceNow
We still have one small problem: "Where to put the variables?"
Locally this is not such a problem, e.g. writing the credentials for the vCenter in a terraform.tfvars file. But in GitHub we don't want to see them at all. Keep calm!
Terraform Enterprise can store values for variables. It comes with an internal vault in which our variables are even encrypted.
With that done, we can run our Terraform code. This is done with one 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 one click we confirm the plan and the "terraform apply" starts.
starts.
Reason 3 - X:
There are many more good reasons to use Terraform Enterprise. These are also good reasons for more blog posts - these include:
Cost Estimation for Cloud Ressources and Budgeting
Compliance and Approval
Auditing
Revisionssicherheit
Sentinel - Policy as Code - as a Framework for "highly compliant and regulated DevOps" in the Enterprise.
Guiding Principle & Vision: Self Service & Automation
Ultimately, Terraform Enterprise allows us to build end-to-end and above all "compliant" workload and lifecycle management in modern enterprises.
Naturally integrated into pipelines (CI/CD) and, if desired, completely secured - so that no one can get their hands on even one credential - e.g. with "Secure Infrastructure Pipelines" with Hashicorp Vault.
How does that work? Feel free to contact us!
Comments