FAQ

Cloud Compliance & Management with Terraform - Modules and Private Registry, Creating a Workspace with Modules

See examples of using workspaces and the Terraform Enterprise private module registry.

Speakers

  • Corrigan Neralich
    Corrigan NeralichSolutions Engineer, HashiCorp

Transcript

Hi, I'm Corrigan Neralich, a solutions engineer at HashiCorp, and I'm here today to talk to you about why enterprises turn to HashiCorp's Terraform Enterprise to help solve cloud compliance and management challenges.

We typically decompose this into multiple components, but to start with, let's talk about modules.

As you already know, the traditional adoption pathway when it comes to Terraform is starting with monolithic configuration files and then looking to modularize where possible, creating reusable templates for your organization.

This is very effective but can oftentimes become quite challenging from both a discoverability and a consumption perspective. Your users face a new challenge: How do I find these modules, and how do I consume them?

The private module registry in Terraform Enterprise

I'm here to talk about the private module registry within Terraform Enterprise. The private module registry is a centralized module catalog where you can publish all of your organization's modules in a highly discoverable way.

As an example, one of your users, one of your developers or code consumers can come into your own module registry, and at a glance understand exactly which modules exist, what those modules do, and ultimately how to consume them. I'll walk you through what that looks like.

Here's an example. You see on the screen a private module registry. In this case, I only have a few modules, each of which represents a different set of configuration files that a potential consumer of this code can incorporate into their project.

Drilling deeper into this, as an example, I have this full-stack, multi-region module. A user can easily come in and have a quick understanding of exactly what this module does, what those potential required or optional inputs may be, any available outputs that they can consume in other modules as an example, and any dependencies or resources that are getting created.

All in one single place, they can come and find exactly what they need.

The module consumption challenge

Once they've discovered exactly what they need, the next challenge becomes consumption. What we've seen across organizations is not every user or consumer has the same level of familiarity when it comes to Terraform. You want to move away from a steep learning curve when it comes to users utilizing this very powerful tool. Within the UI, we provide a very effective turnkey way of doing this.

We've created what we call the design configuration tool. This is an ability for users to not only discover what modules your organization has created, but select them from right here within the GUI itself. They can even customize them so that they can walk through this workflow, provide whatever required information, such as a few sample values.

After they've finished this configuration, what they'll receive is a preformatted block of Terraform code, which they can now go use within their project.

Without really having to know where these things live or what is happening under the scenes in terms of the Terraform code and the underlying configurations, they've just very quickly been able to select what they need. Now they can go build the infrastructure without facing this bottleneck when it comes to providing a ticket, say, to a team that acts as the gatekeeper to deploying infrastructure for your team.

This is tremendously powerful in terms of enablement, agility, efficiency, and security. By adopting and using modules that your team has created and that have best practice baked into them, users are not doing anything that they shouldn't be doing or that they don't necessarily fully understand. They can leverage these pre-created templates that your team has produced for them.

What does this mean in terms of consumption? Say you have a developer who has discovered which modules they need. They've selected those modules, they've configured those modules, and now they have a set of Terraform code that they can go use to deploy this set of infrastructure.

On the screen is an illustration of what historically users may have faced versus this new paradigm. It shows an example of underlying Terraform configuration files, which as you can see might be many different files. These files might define thousands of resources, and that can be very difficult for new users, or even experienced users, to understand and incorporate into their project.

The next step here is, Let's let them consume this module configuration that they have defined.

As an example, rather than having all of this code defined in their project, they can simply take that piece of code that was produced through the design configuration tool, place it in a repository, and this block of code will now go deploy a very large set of infrastructure in a very little amount of time.

This user, without having to be intimately familiar with the underpinnings, can leverage these tools that your team has created for them.

Using modules within workspaces

The way that this works within the Enterprise solution is within workspaces. Workspaces represent that unit of management where you can manage and control access to a given configuration along with the corresponding state and all of the variables and credentials that are needed to deploy that infrastructure.

Just to quickly orient you here, on the screen is an example of a Terraform Enterprise organization with several workspaces already configured. I'm going to show you a quick example of how this works. As a theoretical developer who needs to deploy a full Hashi stack—Vault, Consul, Nomad clusters—they can select that module your team has created, customize it using variables, and plug it into version control, which they then connect directly to their own workspace.

Now they can just as easily queue a run here from within the GUI. If they're not comfortable using the CLI or the API, they can do it right here from within the Terraform Enterprise GUI. As you can see, in a very turnkey fashion, this user has been able to discover best practice modules, configure them, and consume them, all within this control plane in the workspace.

The security factor

The next challenge becomes: We've given great power to these individuals. We've enabled them to start using these tools and discovering and consuming our code. How do we make sure that we do this securely?

With that, in the next video we'll discuss the next feature and the next solution within the Enterprise suite, which is Sentinel, our policy-as-code tool for automated guardrails and enforcement.

More resources like this one

  • 3/15/2023
  • Presentation

Advanced Terraform techniques

  • 2/3/2023
  • Case Study

Automating Multi-Cloud, Multi-Region Vault for Teams and Landing Zones

  • 2/1/2023
  • Case Study

Should My Team Really Need to Know Terraform?

  • 1/20/2023
  • Case Study

Packaging security in Terraform modules