Sam Gabrail
President at TeKanAid
Let’s take a look at our setup.
TL;DR: You can find the main repo for here.
We will also make use of another repo for our Terraform module code.
Terraform Cloud is a hosted service developed by HashiCorp that provides a collaborative workspace for teams to use Terraform, an open-source Infrastructure as Code (IaC) software tool. It enables teams to manage infrastructure provisioning, compliance, and management across various cloud providers, data centers, and services.
Infrastructure as Code (IaC) is the process of managing and provisioning IT infrastructure through machine-readable definition files, rather than manual processes or interactive configuration tools. IaC allows teams to build, change, and manage infrastructure in a safe, consistent, and repeatable way. Automating infrastructure provisioning using IaC tools like Terraform Cloud improves productivity, reduces risk, and increases business velocity.
Infrastructure automation will almost always require teams to collaborate. Terraform Cloud enables teams to work together with role-based access controls and policy enforcement.
Terraform Cloud provides remote state management, which securely stores and manages the state of your infrastructure, enabling collaboration and preventing conflicts. The Terraform state files are encrypted at rest and you can enable certain teams and individuals to read these state files. Terraform state files may contain sensitive information and therefore need to be properly secured.
You can integrate with version control systems, allowing teams to manage infrastructure code alongside application code and track changes over time. Your version control system becomes your source of truth.
Terraform Cloud supports multi-cloud provisioning, allowing you to manage infrastructure across various cloud providers, including AWS, Azure, and Google Cloud Platform.
Terraform Cloud organizes infrastructure into workspaces and projects, providing a consistent environment for managing infrastructure resources.
A Terraform workspace is a logical environment where you can organize and manage your infrastructure configurations and state. Workspaces serve as isolated containers that hold the configuration files and state files for a specific project, application, or environment. They provide a way to separate and manage different sets of infrastructure resources and configurations within a single Terraform Cloud organization.
Each workspace has its own distinct state, variables, and settings. This isolation allows teams to work concurrently on different infrastructure projects without interference or conflicts. Workspaces also enable version control and collaboration features, facilitating collaboration and code review workflows.
You can then group a number of Terraform workspaces under one Terraform project.
Terraform Cloud offers role-based access control, allowing you to define and manage user permissions and access to infrastructure resources.
Single Sign-On (SSO) for Terraform Cloud is a powerful authentication feature that allows your users to access Terraform Cloud using their existing enterprise identity provider credentials. By integrating Terraform Cloud with an identity provider such as Okta, Azure Active Directory, or Google Workspace, organizations can streamline user management and enhance security. With SSO, users no longer need to maintain separate credentials for Terraform Cloud, simplifying the authentication process and improving user experience. Additionally, SSO enables centralized user access control and permissions management, making it easier to enforce consistent security policies across the organization. This is a feature that your security team will likely ask you to have when selecting a vendor.
Terraform Cloud supports policy enforcement and governance through Sentinel and Open Policy Agent (OPA), enabling you to establish guardrails for security, compliance, and cost management.
Terraform Cloud provides secure variable storage, allowing you to store sensitive data like API keys and passwords securely. The variables are encrypted at rest and are write-only.
Terraform Cloud integrates with continuous integration and continuous deployment (CI/CD) pipelines, streamlining the infrastructure provisioning process.
Terraform Cloud offers self-hosted agents, which allow you to run Terraform operations within your own infrastructure for enhanced security and control. Say you want to automate infrastructure that lives in VMware on-premises. Instead of opening your corporation's firewall inbound to allow Terraform Cloud to provision infrastructure in vSphere, you would use self-hosted agents that run in vSphere. These agents require port 443 to be opened outbound on your firewalls. This is a more secure solution and one that your security team will have a much better chance of approving.
The drift detection feature in Terraform Cloud is designed to identify and manage configuration drift in your infrastructure deployments. Configuration drift refers to any changes made to your infrastructure resources that are not managed by Terraform. By periodically scanning and comparing the desired state defined in your Terraform configuration with the actual state of your deployed resources, drift detection helps you identify inconsistencies. When a drift is detected, Terraform Cloud notifies you and provides a detailed report highlighting the specific resources and attributes that have deviated from the desired state. This feature enables you to quickly identify and address any unauthorized or unintended changes, ensuring the integrity and consistency of your infrastructure over time. By leveraging drift detection, you can maintain better control and visibility of your infrastructure deployments, helping to prevent configuration drift and its potential impact on your applications and services.
The Terraform Cloud private registry is a feature available to organizations using Terraform Cloud that allows them to share Terraform providers and Terraform modules internally within their organization. It functions similarly to the public Terraform Registry, offering support for versioning and a searchable list of available providers and reusable Terraform modules. The private registry uses the organization's configured Version Control System (VCS) integrations and defers to the VCS provider for most management tasks, such as releasing new versions. Private modules and providers are only accessible to members of the organization where they are added, ensuring that sensitive infrastructure code remains secure and accessible only to authorized users. By utilizing the Terraform Cloud private registry, organizations can streamline their infrastructure management processes and promote collaboration while maintaining control over their infrastructure code.
As of the writing of this post, this is the current Terraform Cloud and Terraform Enterprise pricing plans.
Terraform Cloud offers a free tier for small teams and paid plans for larger teams with additional collaboration and governance features. The Free and Standard plans are based on the number of managed resources. A "Managed Resource" refers to a resource within a Terraform Cloud managed state file that meets the following conditions: it is recorded in the state file starting from the initial execution of a terraform plan or terraform apply command. This definition excludes "Null Resources" and "terraform_data" from being considered Managed Resources.
The difference between Terraform Cloud and Terraform Enterprise is that Terraform Enterprise is self-managed, whereas Terraform Cloud is a SaaS offering by HashiCorp. Some organizations may require a Self-managed platform such as Terraform Enterprise for security and compliance purposes. Terraform OSS is the open-source version of Terraform.
HashiCorp has recently changed the pricing model for Terraform Cloud. The entry-level tiers used to be based on the number of users. Now HashiCorp is moving more towards consumption-based pricing for all its tiers. For a detailed comparison of features and pricing, refer to the official Terraform pricing page.
Terraform Cloud and Enterprise offer various support options, including community and premium support. Below is a table taken from their support site for their Enterprise support plans.
Let's take a look at an example that will make use of some of the features of Terraform Cloud's free tier.
To get started with Terraform Cloud, follow the "What is Terraform Cloud - Intro and Sign Up" tutorial provided by HashiCorp
Now let's build an EKS cluster in AWS with Terraform. We will make use of an existing terraform module called terraform-aws-modules/eks/aws. This is a public terraform module. We will create a simplified private terraform module that makes use of this public module. Some organizations do this to have more control over which modules are allowed to be used in their organization. They can enforce governance and compliance using Sentinel or OPA on what modules to be used.
Below is our root module directory:
.
├── LICENSE
├── README.md
├── main.tf
├── outputs.tf
└── variables.tf
The [.code]main.tf[.code] file calls our terraform module stored in the Terraform private module in Terraform cloud. To see the module code, take a look at this GitHub repo mentioned at the top of this post.
module "eks" {
source = "app.terraform.io/TeKanAid/eks/aws"
version = "0.0.5"
region = "us-east-1"
cluster_version = "1.27"
cluster_name = "env0_eks_cluster"
instance_types = ["t2.small"]
vpc_cidr = "10.0.0.0/16"
cluster_min_size = 1
cluster_max_size = 3
cluster_desired_size = 2
}
Here are our variables in the [.code]variables.tf[.code] file:
variable "region" {
description = "AWS region"
type = string
default = "us-east-1"
}
variable "cluster_version" {
description = "Kubernetes cluster version"
type = string
default = "1.27"
}
variable "cluster_name" {
description = "EKS cluster name"
type = string
default = "env0_eks_cluster"
}
variable "instance_types" {
description = "EC2 instances used for K8s nodes"
type = list
default = ["t2.small"]
}
variable "vpc_cidr" {
description = "The CIDR block for the VPC"
type = string
default = "10.0.0.0/16"
}
variable "cluster_min_size" {
description = "K8s Cluster minimum size"
type = number
default = 1
}
variable "cluster_max_size" {
description = "K8s Cluster maximum size"
type = number
default = 3
}
variable "cluster_desired_size" {
description = "K8s Cluster desired size"
type = number
default = 2
}
You can check our root module outputs in the [.code]outputs.tf[.code] file below:
output "cluster_endpoint" {
description = "Endpoint for EKS control plane"
value = module.eks.cluster_endpoint
}
output "cluster_security_group_id" {
description = "Security group ids attached to the cluster control plane"
value = module.eks.cluster_security_group_id
}
output "region" {
description = "AWS region"
value = var.region
}
output "cluster_name" {
description = "Kubernetes Cluster Name"
value = module.eks.cluster_name
}
Below is a list of the cloud resources that will get provisioned:
We first need to publish our module to the registry. As shown in the screenshot below, click on the publish button in the Private Registry.
Then select a repository of the format: [.code]terraform-<PROVIDER>-<NAME>[.code]
And finally, click the button to publish the module.
Notice the ability to have multiple versions of the module code:
To use the module, you can just use this snippet shown in the UI:
module "eks" {
source = "app.terraform.io/TeKanAid/eks/aws"
version = "0.0.7"
}
Now that we have our module uploaded to the private module registry, we can go ahead and create a project and a workspace.
When you create a new workspace, you can choose one of 3 workflows:
Go ahead and choose the version control workflow.
Then choose your repo from your Version Control System.
Finally, create the workspace.
In your workspace, you can add variables. These variables could be either Terraform variables or environment variables. In our case, we will add our AWS credentials as environment variables. You could add these variables per workspace or globally via a variable set. I chose to use a variable set so I could easily reuse these across workspaces. This might not be ideal in your case.
Now that everything is in place, we can trigger our first run from the UI.
Here is our plan
and here is the output after our terraform apply succeeded.
Now run the following command to update your kubeconfig and access the new EKS cluster:
aws eks --region <the-output-of-the-region-variable> update-kubeconfig \
--name <the-output-of-the-cluster_name-variable>
You can now interact with the EKS cluster using [.code]kubectl[.code].
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-10-0-1-198.ec2.internal Ready <none> 16h v1.27.1-eks-2f008fe
ip-10-0-2-230.ec2.internal Ready <none> 16h v1.27.1-eks-2f008fe
$ kubectl get namespaces
NAME STATUS AGE
default Active 16h
kube-node-lease Active 16h
kube-public Active 16h
kube-system Active 16h
Note: This version control workflow is close to a GitOps model. Whenever you make changes in Git, Terraform cloud will sense that and run a plan.
Env0 is a cost-effective alternative to Terraform Cloud that offers a powerful platform for managing Infrastructure as Code (IaC) environments, enforcing governance and policy, optimizing costs, automating deployment workflows, and supporting multi-cloud infrastructure. It provides enhanced collaboration, granular workflows and configurations, and advanced cloud cost measurement. Env0 supports not only Terraform but also other IaC frameworks such as Terragrunt, CloudFormation, Pulumi, Kubernetes, and Helm.
One of the major benefits of using env0 over Terraform Cloud is its support for self-service and unlimited concurrency, allowing teams to work simultaneously without any bottlenecks. Env0 also offers custom-defined policies and guardrails, ensuring that your infrastructure remains secure and compliant. Instead of relying on webhooks in Terraform Cloud, env0 allows you to integrate any tools you need into its flexible custom flows, using the tooling of your choice.
Env0 is designed to handle the complexities that arise as an organization scales, such as self-service, access control, customization, and cost management. Check out env0's pricing page where you'll find it an attractive option for organizations looking for a more cost-effective solution to manage their IaC environments.
In summary, env0 offers a powerful and cost-effective alternative to Terraform Cloud, with support for multiple IaC frameworks, enhanced collaboration, granular workflows, and advanced cloud cost measurement. By choosing env0, organizations can streamline their infrastructure management processes, promote collaboration, and maintain control over their infrastructure code while enjoying a more cost-effective solution. I wrote a detailed post about env0 as an alternative to Terraform Cloud with a demo video if you'd like to find out more.
In summary, Terraform Cloud offers numerous benefits and key features for managing infrastructure as code, such as collaboration, access control, remote state management, and multi-cloud provisioning. However, env0 serves as a compelling alternative, providing similar capabilities at a more cost-effective price point, along with support for multiple IaC frameworks and enhanced collaboration features. By adopting either Terraform Cloud or env0, teams can improve productivity, reduce risk, and increase business velocity in their infrastructure management processes, while choosing the solution that best fits their needs and budget.
Use custom workflows to model any process
Visualize all IaC changes pre and post-deployment
Gain code-to-cloud visibility and governance
Improve developer experience and collaboration
Use custom workflows to model any process
Visualize all changes pre and post-deployment
Gain code-to-cloud visibility and governance
Improve developer experience and collaboration
env0 is the best way to deploy, scale, and manage your Terraform and other Infrastructure as Code tools.
