Introduction
Note
This document provides helpful recommendations for implementing Terraform infrastructure-as-code (IaC) as a shared service for your organization. The team responsible for this task may be called different names, such as the "Platform Team" or "Cloud Center of Excellence" (CCoE). Regardless of the name, this guide is designed to assist teams responsible for owning, implementing, and operating Terraform IaC in their organization. For more detailed information on Platform Teams, please refer to the Operating Guide.
Our objective in providing "HashiCorp Validated Designs" is to offer prescriptive guidance based on our experience partnering with hundreds of organizations. We understand that the industry is complex and that there are many permutations and combinations for implementing solutions. However, we believe that the most important thing is that you are able to safely provision and manage cloud resources at scale and experience the business benefits and value that automated Terraform Enterprise workflows provide.
This initial version focuses only on AWS and private cloud deployments and using Docker, not Kubernetes. Even though Terraform Enterprise Flexible Deployment Options can deploy on EKS, GKE and AKS as well as on Docker on GCP and Azure, recommendations for those will be added to this document in due course.
Note
The current version of this guide is focused on deploying Terraform Enterprise in AWS, Private cloud (e.g VM-based private clouds such as VMware or bare metal). Future versions will include terraform modules for automated installation on other major clouds including Azure and GCP.HashiCorp introduced the Validated Designs program to give enterprise customers and partners a set of recommendations to deliver a resilient, secure, and high-performance deployment of HashiCorp solutions. The purpose of this document is to provide the Platform Team with HashiCorp's validated design for deploying Terraform Enterprise, enabling your organization to embrace and accelerate infrastructure automation practices. By following this approach, you will eliminate ambiguity in deployment options and be able to make project-level decisions with confidence.
Audience
This document is intended for platform engineers, infrastructure architects, DevOps administrators, and cloud operators who want to design, deploy and administer a highly scalable, resilient infrastructure-as-code platform with Terraform Enterprise.
Document structure
Document section | Purpose |
---|---|
Architecture | An overview of Terraform Enterprise's logical architecture. Terraform Enterprise requirements, components, and deployment modes listed. |
People | Description of people skills and access required to accomplish the deployment. |
Automated Install (AWS) | Installation of Terraform Enterprise using our validated Terraform modules. Currently we provide a module for AWS and modules for Azure & GCP will be delivered in the future. |
Manual Install | Manual installation steps that can be used to install Terraform Enterprise in a VM/bare metal private cloud/datacenter environment. |
Security hardening | Guidance and recommendation to harden the Terraform Enterprise VM images used in the installation. |
Next steps | Configure the artifacts with the data collected from your environment, and use them for installing Terraform Enterprise. |
Supported versions
This guide has been validated with the following versions of Terraform Enterprise:
- Terraform Enterprise FDO v202309-1 and above
Language and definitions
HashiCorp is an enabler of multi-cloud strategies, and as such we take this into account when writing designs. While every attempt has been made to use technology-agnostic terminology, we primarily aim to support the three largest cloud service providers (CSPs) together with an on-premise/datacenter architecture. There are some terms which do not translate perfectly between the public cloud and the datacenter. For the sake of clarity, our definitions for these terms are included below.
Term | Definition |
---|---|
Availability zone | A separate failure domain within a logical datacenter. |
Region | A separate logical datacenter. |
Public subnet | A network accessible from the public Internet, containing publicly-addressable infrastructure. |
Private subnet | A network not accessible from the public Internet and whose infrastructural objects are either blocked from connecting to the public Internet or do through a NAT gateway. |