Jack Roper is a highly experienced IT professional with close to 20 years of experience, focused on cloud and DevOps technologies. He specializes in Terraform, Azure, Azure DevOps, and Kubernetes.

All posts by Jack Roper - Infrastructure as Code Expert

Jack Roper

Author title

Spacelift's going to AWS re:Invent in Las Vegas 🚀 🚀

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Introducing Stack Dependencies v.2  🎉 🎉

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

In this article, we will discuss Terraform Providers. First, we will look at the purpose of a provider in Terraform, and how they can be used and referenced. We will then look at some of the available providers with examples.

A provider in Terraform is a plugin that enables interaction with an API. This includes Cloud providers and Software-as-a-service providers. The providers are specified in the Terraform configuration code. They tell Terraform which services it needs to interact with.
<h3>How many providers does Terraform have?</h3>
There are hundreds of available providers that can be used with Terraform, making it a hugely versatile tool. A lot of Terraform&#8217;s popularity stems from the fact that it is platform agnostic and can be used so widely, as opposed to languages that may be platform-specific, such as Microsoft Azure ARM templates or Bicep (which interact with the Azure API only).

<h3></h3>
Once a provider is specified, each provider makes a list of <code class="gs mq mr ms mt b">resources</code> and <code class="gs mq mr ms mt b">data</code> types available for use in the Terraform code. These are listed in the documentation which can be found on the <a class="au mk" href="https://spacelift.io/blog/terraform-registry" target="_blank" rel="noopener">Terraform Registry.</a>
Each provider is released independently from Terraform itself with each version providing additional features and bug fixes. Each provider has its own release cadence. Providers are usually managed by either Hashicorp, the dedicated teams from the company making the provider (e.g. Mongo for the <code class="gs mq mr ms mt b">mongodb</code> provider), or by community groups, users, and volunteers with an interest in the product or platform the provider utilizes.
<ul class="">
<li id="88b4" class="mu mv ip le b lf ml li mm kp mw kt mx kx my lu mz na nb nc gt" data-selectable-paragraph="">Providers maintained by Hashicorp are marked as ‘official’ on the documentation pages.</li>
<li id="6b34" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph="">Providers marked as ‘verified’ are owned by official third-party technology vendors. Vendors are also a member of the HashiCorp Technology Partner Program.</li>
<li id="d97c" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph="">Providers marked as ‘community’ are published by members or groups in the Terraform community.</li>
</ul>
You can develop a provider in the unlikely event that it doesn&#8217;t already exist for the infrastructure you are trying to provision using Terraform. Or you can develop it for your product. Providers are written in Go and utilize the Terraform Plugin SDK.

<h3>How to Download &amp; Install Terraform Provider?</h3>
Terraform providers are downloaded and installed during the <a href="https://spacelift.io/blog/terraform-init" target="_blank" rel="noopener"><code class="gs mq mr ms mt b">terraform init</code></a> stage of the Terraform workflow. They can be downloaded from the public registry, or a local registry or mirror. The provider is downloaded, when it&#8217;s not present in the .terraform subdirectory. When it is already present, it is not downloaded again. The version number is also checked. Changing the version number in the configuration files would cause that version of the provider to be downloaded.
To save bandwidth and speed up the runtime, however, the use of an optional plugin cache can be specified using  <code class="gs mq mr ms mt b">plugin_cache_dir</code> in the CLI configuration file which configures per user CLI behaviors (<code class="gs mq mr ms mt b">terraform.rc</code> or <code class="gs mq mr ms mt b">.terraformrc</code>). E.g.

Plugins are always downloaded in the case of runs in <a href="https://spacelift.io/blog/atlantis-terraform" target="_blank" rel="noopener">Terraform Cloud</a> or Terraform Enterprise.
<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Read more about the elements of Terraform architecture.&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Read more about the <a href="https://spacelift.io/blog/terraform-architecture" target="_blank" rel="noopener">elements of Terraform architecture</a>.

Provider configurations should be declared in the root module of your Terraform project. They can be declared in any <code class="gs mq mr ms mt b">.tf</code> file. I would recommend either putting them in the <code class="gs mq mr ms mt b">main.tf</code> , creating a <code class="gs mq mr ms mt b">providers.tf</code> file specifically for the Providers and nothing else, or alternatively a <code class="gs mq mr ms mt b">versions.tf</code> file which would include the <code class="gs mq mr ms mt b">required_providers</code> block and specify the Terraform version. Any child modules receive their provider configuration from the root module.
<h3>Terraform Provider Block Example</h3>
Providers are configured using a <code class="gs mq mr ms mt b">providers</code> block. Some providers require certain information to be configured such as endpoint URLs or cloud regions. Depending on which provider you need to use, the associated documentation should detail which settings you need to configure along with examples. To find this for each provider, click on the ‘use provider’ button top right of the documentation page.

use-provider-terraform-providers

use provider - terraform providers

how-to-use-this-provider-terraform-providers

how to use this provider - terraform providers

In the example shown above for the Microsoft Azure provider <code class="gs mq mr ms mt b">azurerm</code> , the provider source and version are specified in the <code class="gs mq mr ms mt b">required_providers</code> section. The <code class="gs mq mr ms mt b">providers</code> block then contains the configuration options required by the provider. For example, <code class="gs mq mr ms mt b">azurerm</code> includes <code class="gs mq mr ms mt b">features</code> , <code class="gs mq mr ms mt b">clientid</code> , <code class="gs mq mr ms mt b">subscription_id</code> , <code class="gs mq mr ms mt b">tenant_id</code> amongst others. Usually, provider configuration options include various ways to authenticate to the platform.
Two meta-arguments can also be specified in the Providers block, <code class="gs mq mr ms mt b">version</code> and <code class="gs mq mr ms mt b">alias</code> . <code class="gs mq mr ms mt b">version</code> is deprecated and should no longer be used, this should be specified in the <code class="gs mq mr ms mt b">required_providers</code> block instead. The <code class="gs mq mr ms mt b">alias</code> meta-argument is useful for using the same provider, but with different configuration options. Again using our <code class="gs mq mr ms mt b">azurerm</code> example, a classic case for this is when your Terraform code needs to reference multiple subscriptions.
Different <code class="gs mq mr ms mt b">subscription_id</code> values can be specified here, and the calling resource or module can reference the specific provider using the alias name. For example, the provider blocks could be configured like this:

The resource itself references the specific provider to access the different subscriptions:

If a child module requires a specific provider it can be referenced using the <code class="gs mq mr ms mt b">providers</code> meta-argument.
If a provider is configured without the <code class="gs mq mr ms mt b">alias</code> option, it is considered the default and is used by all configurations unless another provider is explicitly specified.

<ul>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

<h3>1. <a href="https://registry.terraform.io/providers/hashicorp/azurerm/latest" target="_blank" rel="nofollow noopener">Azure</a></h3>
A cloud computing platform and service provided by Microsoft. It offers a wide range of cloud-based services and solutions, including infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) that can be used for various computing, storage, analytics, databases, networking, machine learning, and application deployment needs.
Azure Resource Providers are components that Terraform uses to interact with Azure resources. Azure Resource Providers in Terraform correspond to different Azure services or resource types that you can manage and provision using Terraform configurations.
Each Azure service or resource type has its own resource provider in Terraform, and these providers are responsible for defining the Terraform resources and data sources that map to the corresponding Azure resources. The Azure provider for Terraform acts as the bridge between your Terraform configurations and the Azure API.

<h3>2. <a href="https://registry.terraform.io/providers/hashicorp/aws/latest" target="_blank" rel="nofollow noopener">AWS</a></h3>
Amazon Web Services (AWS) is a comprehensive and widely used cloud computing platform and service provided by Amazon.com. AWS offers a vast array of cloud-based computing resources, services, and tools that enable individuals, businesses, and organizations to build, deploy, and manage a wide range of applications, websites, and services in a highly scalable and cost-effective manner.
Each AWS service or resource type corresponds to a specific resource provider in Terraform. These providers define Terraform resources and data sources that map to the corresponding AWS resources. The <a href="https://spacelift.io/blog/terraform-aws-provider" target="_blank" rel="noopener">AWS provider for Terraform</a> acts as the intermediary between your Terraform configurations and the AWS API.

<h3>3. <a href="https://registry.terraform.io/providers/hashicorp/google/latest" target="_blank" rel="nofollow noopener">Google Cloud</a></h3>
Google Cloud, often referred to as Google Cloud Platform (GCP), is a comprehensive suite of cloud computing services provided by Google. It offers a wide range of cloud-based solutions for computing, storage, databases, machine learning, data analytics, and more.
The Google Cloud Terraform Provider is used to configure your Google Cloud Platform infrastructure. It is collaboratively maintained by the Google Terraform team at Google and the Terraform team at HashiCorp.

<h3>4. <a href="https://registry.terraform.io/providers/hashicorp/kubernetes/latest" target="_blank" rel="nofollow noopener">Kubernetes</a></h3>
Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform for automating the deployment, scaling, and management of containerized applications. It was originally developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF). Kubernetes provides a powerful and flexible framework for container management, making it easier to deploy and operate applications in a distributed and scalable manner.
The official <a href="https://spacelift.io/blog/terraform-kubernetes-provider" target="_blank" rel="noopener">Kubernetes Terraform provider</a> is provided by HashiCorp. This provider allows you to define Kubernetes resources in your Terraform configurations, such as deployments, services, and config maps.

<h3>5. <a href="https://registry.terraform.io/providers/oracle/oci/latest" target="_blank" rel="nofollow noopener">Oracle Cloud</a></h3>
Oracle Cloud, often referred to as Oracle Cloud Infrastructure (OCI), is a comprehensive cloud computing platform and infrastructure service offered by Oracle Corporation. It provides a wide range of cloud-based services, including infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).
This provider is managed by Oracle open source directly (not Hashicorp directly — hence the source being <code>oracle/oci</code>).

<h3>6. <a href="https://registry.terraform.io/providers/aliyun/alicloud/latest" target="_blank" rel="nofollow noopener">Alibaba Cloud</a></h3>
Alibaba Cloud, also known as Alibaba Cloud Computing or Aliyun, is the cloud computing and data intelligence arm of Alibaba Group, one of the world’s largest e-commerce and technology companies. Alibaba Cloud provides a comprehensive range of cloud-based computing services, data storage, artificial intelligence (AI), and machine learning (ML) capabilities, as well as big data analytics and more. It is one of the leading cloud service providers in China and has a growing global presence.
Alibaba Cloud, also known as Aliyun, has an official provider for HashiCorp Terraform called <code>alicloud</code>.

<ul class="">
<li id="c36f" class="mu mv ip le b lf lg li lj kp nu kt nv kx nw lu mz na nb nc gt" data-selectable-paragraph="">Azure <a class="au mk" href="https://registry.terraform.io/providers/hashicorp/azuread/2.25.0" target="_blank" rel="noopener ugc nofollow">Active Directory</a></li>
<li id="4bfb" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/providers/hashicorp/ad/0.4.4" target="_blank" rel="noopener ugc nofollow">Active Directory</a></li>
<li id="7422" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph="">Azure <a class="au mk" href="https://registry.terraform.io/providers/hashicorp/azurestack/0.10.0" target="_blank" rel="noopener ugc nofollow">Stack</a></li>
<li id="8c77" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/namespaces/CiscoDevNet" target="_blank" rel="noopener ugc nofollow">Cisco</a></li>
<li id="e4e9" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/providers/cloudflare/cloudflare/3.18.0" target="_blank" rel="noopener ugc nofollow">Cloudflare</a></li>
<li id="1d74" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/namespaces/CheckPointSW" target="_blank" rel="noopener ugc nofollow">Checkpoint</a></li>
<li id="119f" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/providers/DataDog/datadog/3.12.0" target="_blank" rel="noopener ugc nofollow">Datadog</a> (Read more about <a href="https://spacelift.io/blog/terraform-datadog" target="_blank" rel="noopener">Terraform Datadog Provider</a>.)</li>
<li id="2994" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/providers/hashicorp/helm/2.6.0" target="_blank" rel="noopener ugc nofollow">Helm</a></li>
<li id="8ce6" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph="">Hashicorp product providers — <a class="au mk" href="https://registry.terraform.io/providers/hashicorp/vault/3.7.0" target="_blank" rel="noopener ugc nofollow">Vault</a>, <a class="au mk" href="https://registry.terraform.io/providers/hashicorp/consul/2.15.1" target="_blank" rel="noopener ugc nofollow">Consul</a>, <a class="au mk" href="https://registry.terraform.io/providers/hashicorp/nomad/latest" target="_blank" rel="noopener ugc nofollow">Nomad</a>, <a class="au mk" href="https://registry.terraform.io/providers/hashicorp/boundary/1.0.9" target="_blank" rel="noopener ugc nofollow">Boundary</a></li>
<li id="248e" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/namespaces/F5Networks" target="_blank" rel="noopener ugc nofollow">F5</a></li>
<li id="3ba9" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/namespaces/PaloAltoNetworks" target="_blank" rel="noopener ugc nofollow">Palo Alto</a> — Panos</li>
<li id="fb02" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/namespaces/spacelift-io" target="_blank" rel="noopener ugc nofollow">Spacelift</a></li>
<li id="8927" class="mu mv ip le b lf nd li ne kp nf kt ng kx nh lu mz na nb nc gt" data-selectable-paragraph=""><a class="au mk" href="https://registry.terraform.io/providers/hashicorp/vsphere/latest" target="_blank" rel="noopener ugc nofollow">VMWare vSphere</a></li>
</ul>
The Spacelift Terraform provider is open source, and its README always contains the latest available documentation. It&#8217;s also distributed as part of our Docker runner image and available through our own provider registry. <a href="https://docs.spacelift.io/vendors/terraform/terraform-provider" target="_blank" rel="noopener">See how it can be used to incorporate Spacelift resources into your Infrastructure as Code</a>. You can also check out Spacelift for free by <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">creating a trial account</a>!

Understanding how providers work in Terraform and knowing how to make use of the available providers found in the Terraform Registry are fundamental concepts when learning Terraform.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu is not going to have its own providers and modules, but it is going to use its own registry for them.

Build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization and many more.

Initialize/ plan/ apply your IaC, manage modules, state, and more. 

frame-8479

Frame 8479

Terraform Cheat Sheet - 23 Terraform CLI Commands & Examples

20 Terraform Best Practices to Improve your TF workflow

5 Ways to Manage Terraform at Scale - Best Practices

Why do you need Terraform Providers? Learn how they can be used and referenced. Take look at some of the available providers with examples.

89-terraform-providers

Terraform providers

Terraform Providers Overview & How To Use Them

Which cloud deployment model is right for your business?

General | Spacelift Blog

General

In this article, we will discuss the different cloud deployment models, and look at how you can choose the best one for your business based on your requirements, as well as investigate the pros and cons of each model.

A cloud deployment model essentially defines where the infrastructure for your deployment resides and determines who has ownership and control over that infrastructure. It also determines the cloud&#8217;s nature and purpose.
The first port of call for any organization looking to adopt cloud services is to understand the available deployment models. Once these are understood, a better decision can be made about which routes the business should pursue. Each model will offer advantages and disadvantages in areas such as governance, scalability, security, flexibility, cost, and management.

Cloud deployment models can be divided into five main types
<ul class="">
<li id="605e" class="mq mr ip le b lf lv li lw kp ms kt mt kx mu lu mv mw mx my gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/cloud-deployment-models#public-cloud-model" rel="">Public Cloud</a></li>
<li id="9e50" class="mq mr ip le b lf mz li na kp nb kt nc kx nd lu mv mw mx my gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/cloud-deployment-models#private-cloud-model">Private Cloud</a></li>
<li id="0b1b" class="mq mr ip le b lf mz li na kp nb kt nc kx nd lu mv mw mx my gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/cloud-deployment-models#hybrid-cloud-model">Hybrid Cloud</a></li>
<li id="fd1a" class="mq mr ip le b lf mz li na kp nb kt nc kx nd lu mv mw mx my gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/cloud-deployment-models#multicloud-model">Multi-Cloud</a></li>
<li id="f3dc" class="mq mr ip le b lf mz li na kp nb kt nc kx nd lu mv mw mx my gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/cloud-deployment-models#community-cloud-model">Community cloud</a></li>
</ul>
Let&#8217;s take a look at each model in more detail.

Public cloud is a commonly adopted cloud model, where the cloud services provider owns the infrastructure and openly provides access to it for the public to consume.
As the service provider owns the hardware and supporting networking infrastructure, it is under the service provider&#8217;s full control. The service provider is responsible for the physical security, maintenance, and management of the data center where the infrastructure resides. The underlying infrastructure is, therefore, outside of the customer&#8217;s control and also away from the customer&#8217;s physical location.
The cloud service provider will share infrastructure between multiple customers whilst keeping data separate and isolated, offering many layers of security controls where this is a concern. Some services can be hosted on dedicated or isolated hardware if required, usually at an additional cost. Cloud providers go to huge lengths to ensure physical data centers are extremely secure and are highly regulated environments, almost always exceeding the standards a customer could achieve themselves.
Infrastructure is managed primarily using a web browser but can also be manipulated using an API, on the command line, or using infrastructure-as-code tools such as Terraform.
Commonly used public clouds include Microsoft Azure, Amazon AWS, Google Cloud, Oracle Cloud, and Alibaba Cloud.

public-cloud-cloud-deployment-models

public cloud - cloud deployment models

<h4>Advantages of the Public Cloud Model</h4>
<ul>
<li>Low initial capital cost (Move from Capex to Opex)</li>
<li>High Flexibility</li>
<li>High (almost unlimited) scalability</li>
<li>High Reliability</li>
<li>Low maintenance costs</li>
</ul>
<h4>Disadvantages of the Public Cloud Model</h4>
<ul>
<li>Data security concerns for strictly regulated businesses</li>
</ul>

A private cloud can be thought of as an environment that is fully owned and managed by a single tenant. This option is usually chosen to alleviate any data security concerns that might exist with the public cloud offering. Any strict governance requirements can also be more easily adhered to, and the private cloud can be more easily customized.
Full control of the hardware can lead to higher performance. A customer will typically run a private cloud within their own building (on-premises) or purchase rackspace in a data center in which to host their infrastructure.
However, the responsibility to manage the infrastructure also falls to the customer, creating a need for more staff with wider skills and increasing costs. A large initial investment may also be required to purchase the required hardware.
<h4>Advantages of the Private Cloud Model</h4>
<ul>
<li>Increased security and control</li>
<li>Dedicated hardware may improve performance</li>
<li>High flexibility</li>
</ul>
<h4>Disadvantages of the Private Cloud Model</h4>
<ul>
<li>High cost</li>
<li>Higher management overhead</li>
</ul>

The hybrid model combines both public and private cloud deployment models giving a single cloud infrastructure that is aimed at increasing flexibility and deployment options for the business.
For example, applications with strict governance and data security requirements may be hosted in the business private cloud, whereas applications without these concerns, which need to be scaled on demand, could be hosted in the public cloud.
The benefits of both the public and private cloud can be realized, as well as some of the disadvantages, such as increased management overhead and the initial challenge of setting up a hybrid infrastructure. Once realized, applications can be moved between infrastructure hosted in the public and private clouds, increasing flexibility and fault tolerance.
Typically businesses may have some presence on-premise, and utilizing this hardware until it has reached end-of-life in the private cloud will likely be an attractive option if the business already owns the hardware. In the hybrid model, this can be used to form part of the private cloud. Most businesses strive to alleviate the burden on the existing infrastructure, migrating to the public cloud where possible, and effectively utilizing the hybrid deployment model during the migration period.
<h4>Advantages of the Hybrid Cloud</h4>
<ul>
<li>Improved scalability</li>
<li>High control</li>
<li>Highly scalable</li>
<li>High fault tolerance</li>
<li>Cost-effective</li>
</ul>
<h4>Disadvantages of the Hybrid Cloud</h4>
<ul>
<li>Setup challenges</li>
<li>High management overhead</li>
</ul>

<ul>
<li><a href="https://spacelift.io/blog/devops-best-practices" target="_blank" rel="noopener">16 DevOps Best Practices to Follow</a></li>
<li><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener">Fixing Infrastructure Drift with IaC Tools</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
</ul>

The multi-cloud deployment model usually refers to the use of multiple public cloud providers to increase flexibility and fault tolerance, such as the use of Microsoft Azure, Amazon AWS, and Google Cloud. The private cloud can also be thrown into the mix to give extra reliability and flexibility.
Some services may be preferred on a certain cloud over another after evaluation by the business. For example, the GKE (Google Kubernetes Engine) hosted on the Google Cloud may be preferable over similar offerings on Azure, such as AKS (Azure Kubernetes Service) or Amazon EKS (Elastic Kubernetes Service). Workloads can be distributed selectively.
Adopting multiple clouds gives development teams a choice from a much wider pool of options and can actually aid the developer workflow. Some comparable services may be cheaper than others and so may also be preferable in certain scenarios. For example, AWS could be used for production, and Google Cloud used for testing.
Multi-cloud is also commonly used by businesses with critical workloads, such as government agencies or financial corporations. Spreading data and infrastructure between multiple cloud providers can increase fault tolerance should one cloud platform encounter service outages. The benefits of the multi-cloud model can also be leveraged when a business forms a disaster recovery and business continuity plan.
However, with each option that is introduced, management becomes more complex, and staff requires more skills to fully realize the benefits of a multi-cloud deployment model. Depending on the business objectives, multi-cloud has the potential to lower costs or raise them if increased fault tolerance is the goal.
As with anything in I.T., the trade-off between the application requirements and the budget should be weighed up. Larger businesses further along the road in their cloud journey are usually suited to the multi-cloud model, as typically, a business will adopt and single public cloud and adopt another public cloud when the business requirements can be justified.
<h4>Advantages of the Multi-Cloud Model</h4>
<ul>
<li>Very high reliability</li>
<li>Very high flexibility</li>
</ul>
<h4>Disadvantages of the Multi-Cloud Model</h4>
<ul>
<li>Increased management complexity</li>
<li>Increased staffing skills required</li>
</ul>
Learn more about <a href="https://spacelift.io/blog/multi-cloud-infrastructure-strategy" target="_blank" rel="noopener">multi-cloud benefits and best practices</a>.

A lesser-known and less-adopted deployment model, a Community cloud brings together infrastructure that is shared and jointly accessed by several organizations from a specific group that shares specific computing needs.
For example, the education sector could utilize a community cloud to enable a group of scholars and students to share academic content, making joint research easier.
<h4>Advantages of the Community Cloud Model</h4>
<ul>
<li>Sharing infrastructure lowers costs</li>
</ul>
<h4>Disadvantages of the Community Cloud Model</h4>
<ul>
<li>Reduced security</li>
<li>Not applicable to most SMEs (Small to Medium enterprises)</li>
</ul>

Below you can see the comparison table of previously mentioned cloud deployment models so you can make an informed decision when it comes time to take advantage of this modern infrastructure offering.

cloud-deployment-models-comparison

cloud deployment models comparison

Each organization will have its own requirements when making the shift or starting its journey to the cloud. In order to avoid costly and time-consuming bad decisions, it is critical to understand the organizational needs before embarking on the journey to the cloud. Making good decisions in the planning stage can help your business accelerate growth, help your business goals, and maintain competitiveness.
Most businesses in 2023 will already have some presence in the cloud, for example, commonly utilizing a mix of SaaS (Software-as-a-service) offerings, such as Azure Active Directory, Office 365, Gmail, or IaaS (Infrastructure-as-a-service) offerings, such as hosting infrastructure in Microsoft Azure or Amazon Web Services (AWS). Incorrect planning at the initial stages could put you at a disadvantage over your competitors, who may be at a more mature stage in their cloud journey.
The COVID-19 pandemic has accelerated business journeys to the cloud as workers connected to resources from home. During this process, different cloud deployment models had to be taken into account, with the speed of adoption commonly being the number one priority for many businesses.

Understanding the available cloud deployment models is key to positioning your business for success.
In the real world, new businesses and startups will commonly opt to fully adopt the public cloud where possible. Most existing businesses will have some existing infrastructure presence on-premise, and therefore bringing this into a private cloud and adopting the hybrid model may make more sense. Private cloud is a high-cost option with high overheads but is sometimes a requirement where data security regulation or concerns about data sovereignty are paramount. Multi-cloud can be considered where high reliability is a concern, such as in the financial industry.
And if you need an automation layer for your cloud resources, take a look at <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift’s self-service infrastructure</a>. It is a very powerful platform as it works with cloud-agnostic IaC technologies like Terraform and Pulumi, as well as cloud-specific IaC features like AWS CloudFormation and Azure ARM templates. No matter which IaC technology is used, Spacelift provides a common interface to manage the automated provisioning of multiple stacks in multiple cloud platforms.

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities s for infrastructure management.

Business Benefits of Infrastructure as Code

How Spacelift Can Improve Your Infrastructure as Code

16 DevOps Best Practices Every Developer Should Know

Learn about types of cloud deployment models. Check cloud deployment model examples with a detailed comparison.

86-cloud-deployment-modules

Cloud Deployment Models - Types, Comparison & Examples

How to use the Terraform join and split functions

The Hashicorp Configuration Language (HCL) that Terraform employs utilizes a number of beneficial <a href="https://spacelift.io/blog/terraform-functions-expressions-loops" target="_blank" rel="noopener">built-in functions</a>. These functions can be used to manipulate and transform values within a given expression. In this post, we will take a look at the operation of the <code class="gs kk kl km kn b">join</code> function and its counterpart, the <code class="gs kk kl km kn b">split</code> function for use with Strings.

The Terraform join function is a built-in function that allows you to concatenate a list of strings together. The <code>join</code> function is useful when you need to create a string from a list of elements and want to control the formatting of the resulting string.

HCL does not support user-defined functions, like some other classic languages, for example, C or SQL. Only built-in functions are available for use with Terraform. The current list of available built-in functions can be found in the Terraform documentation.

<h3>Using The Terraform Console To Experiment</h3>
A particularly useful way to experiment with the operation of functions is to use the <code class="gs kk kl km kn b">terraform console</code> command. This provides an interactive console to the user. To try it out, simply type <code class="gs kk kl km kn b">terraform console</code> on the command line, and then a simple join command:

terraform-console-join

terraform console - join

Note that <a href="https://spacelift.io/blog/terraform-console" target="_blank" rel="noopener"><code class="gs kk kl km kn b">terraform console</code></a> does not require a state file to exist or be created first. If there is a remote state file in the current working directory, Terraform will read the state for the current <a href="https://spacelift.io/blog/terraform-workspaces" target="_blank" rel="noopener">Terraform workspace</a> from the backend before evaluating any expressions.

According to the Terraform docs:
join produces a string by concatenating together all elements of a given list of strings with the given delimiter.
The syntax for the <code>join</code> function is as follows:

<ul>
<li style="font-weight: 400;" aria-level="1"><code>delimiter</code>: The string to be used between each pair of adjacent elements in the resulting string.</li>
<li><code>list</code>: The list of elements to be concatenated.</li>
</ul>
<h3>Terraform Join Example</h3>
Let&#8217;s take a look at the example:

Results in the following output:

terraform-join-example

terraform join example

In the following example, we have 3 Azure storage accounts defined as lists of strings in the variable <code>storage_account_names</code>. We then use the <code>join</code> function in the outputs to show the outputted resource IDs in one comma-separated string.

The output would look like this:

Terraform <code>split</code> performs the opposite operation: producing a list by separating a single string using a given delimiter.
<h3>Terraform Split Example</h3>
For example, the command below will split the three strings into a list:

terraform-console-split

terraform console - split

The <code class="gs kk kl km kn b">split function</code> can be useful to use in <a href="https://spacelift.io/blog/terraform-output" target="_blank" rel="noopener"><code class="gs kk kl km kn b">output</code> values</a> when a list of values exists. For example, for the creation of an Azure VNET gateway, the following configuration would split out the names of the Gateways with the “/” delimiter.

Note that <code class="gs kk kl km kn b">split</code> can be used with <a href="https://spacelift.io/blog/how-to-use-terraform-variables" target="_blank" rel="noopener">variables</a>, for example:

Lastly <code class="gs kk kl km kn b">join</code> and <code class="gs kk kl km kn b">split</code> can be useful when creating or manipulating configuration files for devices, appliances, or environment variables that are created or pulled into Terraform configuration. For example, to pull IP addresses from a list to pass into a file needed to configure a firewall. They are also useful to extract from a list of URLs or chop up parts of a URL.

There are many built-in functions available for use with Terraform. <code class="gs kk kl km kn b">join</code> and <code class="gs kk kl km kn b">split</code> can be used to transform a list of Strings as required.
For more information, check out <a href="https://www.terraform.io/language/functions" target="_blank" rel="nofollow noopener">the official documentation</a>.
And if you want more help managing your Terraform state file, building more complex workflows based on Terraform, and <a href="https://spacelift.io/blog/self-service-infrastructure-with-spacelift" target="_blank" rel="noopener">create self-service infrastructure</a>, <a href="https://spacelift.io/terraform-at-scale" target="_blank" rel="noopener">Spacelift</a> is a great tool for that.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu works with your existing Terraform state file, so you won’t have any issues when you are migrating to it.

If you are struggling with Terraform automation and management, check out Spacelift. It helps you manage Terraform state, build more complex workflows, and adds several must-have capabilities for end-to-end infrastructure management.

Grab our ultimate cheat sheet PDF for all the Terraform functions you need on hand.

How to Deploy Infrastructure in CI/CD Using Terraform (Pipeline)

There are many built-in functions available for use with Terraform. Learn what the join and split functions in Terraform do and see examples.

87-terraform-join

How to Use Terraform Join and Split Functions with Strings

In this post, I will explain what the <code class="gs kk kl km kn b">terraform apply</code> command is used for, what it does, the available options, and when to run it.

The <code class="gs kk kl km kn b">terraform apply</code> command executes the actions proposed in a <code class="gs kk kl km kn b">terraform plan</code>. It is used to deploy your infrastructure. Typically <code class="gs kk kl km kn b">apply</code> should be run after <a href="https://spacelift.io/blog/terraform-init" target="_blank" rel="noopener"><code class="gs kk kl km kn b">terraform init</code></a> and <code class="gs kk kl km kn b">terraform plan</code>.

If the <code class="gs kk kl km kn b">apply</code> command is run without any options it will run a <code class="gs kk kl km kn b">terraform plan</code> first, ask the user to confirm the planned actions, and then execute those changes once confirmed.
The <code class="gs kk kl km kn b">apply</code> command can also be used with a previously generated planfile, from the <code class="gs kk kl km kn b">terraform plan -out=&lt;path to file&gt;</code>.

<h3 id="8c1a" class="pw-post-body-paragraph jm jn ip jo b jp lz jr js jt ma jv jw jx mb jz ka kb mc kd ke kf md kh ki kj ii gt">1. <code class="gs kk kl km kn b">terraform apply</code></h3>
Creates or updates infrastructure depending on the configuration files. By default, a plan will be generated first and will need to be approved before it is applied.
<h3 id="56c0" class="pw-post-body-paragraph jm jn ip jo b jp jq jr js jt ju jv jw jx jy jz ka kb kc kd ke kf kg kh ki kj ii gt">2. <code class="gs kk kl km kn b">terraform apply -auto-approve</code></h3>
Apply changes without having to interactively type ‘yes’ to the plan. Useful in automation CI/CD pipelines.
<h3 id="d16c" class="pw-post-body-paragraph jm jn ip jo b jp jq jr js jt ju jv jw jx jy jz ka kb kc kd ke kf kg kh ki kj ii gt">3. <code class="gs kk kl km kn b">terraform apply &lt;planfilename&gt;</code></h3>
Provide the file generated using the <code class="gs kk kl km kn b">terraform plan -out</code> command. If provided, Terraform will take the actions in the plan without any confirmation prompts.
<h3 id="ed8d" class="pw-post-body-paragraph jm jn ip jo b jp jq jr js jt ju jv jw jx jy jz ka kb kc kd ke kf kg kh ki kj ii gt">4. <code class="gs kk kl km kn b">terraform apply -var="my_variable=test"</code></h3>
Pass in a variable value.
<h3 id="a0b9" class="pw-post-body-paragraph jm jn ip jo b jp jq jr js jt ju jv jw jx jy jz ka kb kc kd ke kf kg kh ki kj ii gt">5. <code class="gs kk kl km kn b">terraform apply -var-file="varfile.tfvars"</code></h3>
Pass in variables contained in a file.
<h3 id="0d85" class="pw-post-body-paragraph jm jn ip jo b jp jq jr js jt ju jv jw jx jy jz ka kb kc kd ke kf kg kh ki kj ii gt">6. <code class="gs kk kl km kn b">terraform apply -target=”module.appgw.0"</code></h3>
Apply changes only to the targeted resource. Read more about <a href="https://spacelift.io/blog/terraform-target" target="_blank" rel="noopener">Terraform target option</a>.
<h3 id="8c36" class="pw-post-body-paragraph jm jn ip jo b jp jq jr js jt ju jv jw jx jy jz ka kb kc kd ke kf kg kh ki kj ii gt">7. <code class="gs kk kl km kn b">terraform apply -lock=false</code></h3>
Do not hold a state lock during the Terraform apply operation. Use with caution if other engineers might run concurrent commands against the same workspace.
<h3 id="f2cf" class="pw-post-body-paragraph jm jn ip jo b jp jq jr js jt ju jv jw jx jy jz ka kb kc kd ke kf kg kh ki kj ii gt">8. <code class="gs kk kl km kn b">terraform apply -parallelism=&lt;n&gt;</code></h3>
Specify the number of operations run in parallel.
<h3>9. <code>terraform apply -compact-warnings</code></h3>
Condenses the warnings into a more concise format, which can be useful for improving the readability of Terraform output.
<h3>10. <code>terraform apply -input=false</code></h3>
Terraform will not prompt you for any input during the apply process, and it will proceed with the plan using the existing values specified in your Terraform configuration files. This can be useful in scenarios where you want to automate the Terraform apply process without any manual intervention, especially in scripted or automated workflows, or when running Terraform in non-interactive environments, such as CI/CD pipelines.
<h3>11. <code>terraform apply -json</code></h3>
 Provides a structured JSON output that includes the results of the operation, making it easier to parse and integrate into automated workflows or other tools.
<h3>12. <code>terraform apply -lock-timeout=DURATION</code></h3>
Set a duration for how long Terraform should wait to acquire a lock on the state file during an apply operation. DURATION should be specified in a format like &#8220;30s&#8221; (30 seconds), &#8220;5m&#8221; (5 minutes), &#8220;1h&#8221; (1 hour).
<h3>13. <code>terraform apply -no-color</code></h3>
 Disable colorized output in the console. By default, Terraform outputs information with color codes for better readability and to distinguish different types of messages (e.g., changes, warnings, and errors) with colors. This is useful when you are working in an environment that does not support or handle color codes properly or when you prefer plain text output for your specific use case.
For configurations using the local backend only, <code>terraform apply</code> also accepts the legacy options -state, -state-out, and -backup.

<ul>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">How to Improve Your Infrastructure as Code using Terraform</a></li>
<li><a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">20 Best Practices for Using Terraform</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
</ul>

If there are no changes in the configuration files compared to the current Terraform state, then no changes will be made to the infrastructure. Terraform is a declarative language, so it is absolutely safe to run the <code class="gs kk kl km kn b">apply</code> command multiple times.

In <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">automation</a> <code class="gs kk kl km kn b">terraform apply</code> can be run after the plan stage, passing in the plan output file. If there is no plan stage prior to the apply stage (not recommended), then the <code class="gs kk kl km kn b">terraform apply -auto-approve</code> option can be used. Another useful option to avoid encoding issues when running <a href="https://spacelift.io/blog/ci-cd-pipeline" target="_blank" rel="noopener">pipelines in some CI/CD systems</a>, i.e. <a href="https://spacelift.io/blog/what-is-azure-devops" target="_blank" rel="noopener">Azure DevOps</a>, is the <code class="gs kk kl km kn b">terraform apply -no-color</code> option, as the colored output is not handled correctly by the build agents.
A more robust approach to automating your Terraform workflows end-to-end would be to use <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>, a collaborative infrastructure delivery tool. Spacelift provides a more mature way of automating the whole infrastructure provisioning lifecycle. Its <a href="https://docs.spacelift.io/concepts/run/" target="_blank" rel="noopener">flexible and robust workflow</a> allows teams to get up to speed quickly and collaborate efficiently. Check out the <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Documentation</a> and <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">start automating your infrastructure delivery easily</a>!

<code class="gs kk kl km kn b">terraform apply</code> is a core command in the Terraform workflow, used for deploying infrastructure as described in your configuration files.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu works with your existing Terraform state file, so you won’t have any issues when you are migrating to it.

Destroy Command - How to Destroy Resources from Terraform

Terraform apply is a core command in the Terraform workflow. Learn what this command is used for, what it does, the available options, and when to run it.

77-terraform-apply

Terraform apply

When to Run Terraform Apply - Quick Usage Examples

In this post we will delve into the basics of CI/CD pipelines, outlining the benefits of using them. We will then look at each stage in the pipeline, and what makes up a good pipeline, along with some examples relating to Terraform.

A CI/CD pipeline is used to automate software or <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">infrastructure-as-code</a> delivery, from source code to production. It can be thought of as a series of steps that needs to be taken for code to be released.
CI stands for Continuous Integration, and CD stands for Continuous Delivery or Deployment. ‘Pipeline’ refers to the automation of the delivery workflow, consisting of build, test, delivery, and deployment stages. Although each of these steps can be executed manually, automating and orchestrating the stages maximizes the benefits of using CI/CD pipelines by minimizing human error and bringing consistency to each release.
CI/CD pipelines are commonly used by application delivery teams and operations teams (<a href="https://spacelift.io/blog/who-is-devops-engineer" target="_blank" rel="noopener">DevOps</a>). They are the backbone of adopting a DevOps methodology. Read more: <a href="https://spacelift.io/blog/devops-pipeline" target="_blank" rel="noopener">Building the DevOps Pipeline</a>.
CI/CD pipelines are themselves commonly configured in code, sometimes referred to as ‘pipelines-as-code’.
Typically a build server (or build agent) is used to enable CI/CD runs. Typically these take the form of self-hosted virtual machines in the cloud which can be fully configured but also have to be maintained, or virtual machines provided as part of the platform you are using, which are typically less flexible in terms of adding software and plugins to them.
Containers can also be used to enable consistent build environments, further removing the reliance on having to maintain a build server. Each step of the CI/CD pipeline can be run in its own container, allowing each step to be run inside a fully customized container. This also enables pipelines to make full use of all the benefits containerization orchestration affords, such as resilience and scaling where required.
<h3 id="aa7b" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">Continuous Integration (CI)</h3>
CI covers the build and test stages of the pipeline. Each change in code should trigger an automated build and test, allowing the developer of the code to get quick feedback.
<h3 id="03cb" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">Continuous Delivery / Deployment (CD)</h3>
The CD part of a CI/CD pipeline refers to Delivery and Deployment (CI/CDD anyone?!). CD takes place after the code successfully passes the testing stage of the pipeline. Continuous delivery refers to the automatic release to a repository after the CI stage. Continuous deployment refers to the automatic deployment of the artifact that has been delivered.

Starting with writing the source code, and ending up in production, these phases make up the development workflow and form the lifecycle of the CI/CD pipelines. Pipeline runs are usually triggered automatically by a change in the code, but can also be run on a schedule, run manually by a user, or triggered after another pipeline has run.
The four parts of the CI/CD pipeline are:
<ul>
<li>Build stage</li>
<li>Test stage</li>
<li>Deliver stage</li>
<li>Deploy stage</li>
</ul>
<h3 id="47f4" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">1) Build</h3>
The build stage involves the code being written. This is typically done by multiple people in a team, and for larger projects, multiple teams. Code is held in a version control system (VCS), and a Git-based workflow is commonly used to control code being added to the repository (also referred to as GitOps). When used in a pipeline, tools to regulate developer environments and standardize them are particularly useful in order to eliminate any differences between different authors&#8217; code. This will usually take the form of a docker container when using cloud-native software.
<h3 id="f401" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">2) Test</h3>
As greater resiliency is required and more varied infrastructure is introduced, testing code leads to greater confidence that the code will perform as expected. Testing of your code can be automated. In general, this is normally a repetitive, complex and sometimes tedious process to perform manually. A mistake that a lot of teams make is to skip the test stage or underuse it, as the benefits of properly testing code before delivery and deployment can be huge, contributing to a high-quality product.
Testing can be broken up into multiple types, using a combination of these with a combination of different tools will give the highest code coverage and result in a higher quality product. Where lots of different tests are used, these can be parallelized to reduce the pipeline run time.
Smoke testing — Perform quick sanity checks on the code.
Integration Testing — Integration tests are intended to test all the code, or system as a whole. They validate that newly introduced code does not break the existing code.
Unit Testing — Unit tests are intended to test a particular function, several functions together, or part of the code. Smaller parts of the infrastructure can be isolated, and tests can be run in parallel to shorten the feedback cycle.
Compliance Testing — Compliance testing is used to ensure the configuration follows the policies you’ve defined for the project.
End-to-end Testing (E2E) — E2E tests validate everything works together before deploying to production. It is the complete test of the whole process.
<h3 id="5674" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">3) Deliver</h3>
After the code has been tested, the code is packaged up as an artifact and committed to a repository.
<h3 id="3451" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">4) Deploy</h3>
The deploy stage allows the orchestration of the artifact release. Usually, teams will deploy to multiple environments, including environments for internal use such as development and staging, and Production for end-user consumption. Using this model, teams can automatically deploy to a staging environment when a pipeline is triggered. Once the staging environment has been reviewed and approved, the code can be merged into the main branch, and then automatically deployed to Production.
Below you can find a diagram of the CI/CD pipeline.

cicd-pipeline-diagram

cicd pipeline diagram

<ul>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">Top Most Useful CI/CD Tools for DevOps</a></li>
<li><a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Deploy your Infrastructure in CI/CD using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Deploy your Infrastructure in CI/CD using Terraform</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">10 Ways to Improve Your Infrastructure as Code</a></li>
</ul>

Adopting the use of CI/CD pipelines brings many benefits, including:
<ul class="">
<li id="c6f7" class="mn mo ip kg b kh ki kk kl kn mp kr mq kv mr kz ms mt mu mv gt" data-selectable-paragraph="">Reduced costs — Reducing the time it takes the app or infrastructure to get coded and deployed means less human resources are taken up.</li>
<li id="1cbd" class="mn mo ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph="">Reduced time to deployment — Time to deploy is reduced through automation. The entire process, from coding to deployment, is streamlined, reducing the total process length and making it more efficient. Deployments can be made more often. The rate of release can give companies a significant competitive business advantage over competitors. Deployments can also be rolled back easily, should there be a problem. Developers of the code can remain focused.</li>
<li id="623d" class="mn mo ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph="">Enabling continuous feedback — Enables teams to improve their code and workflow based on the feedback received. The testing stage highlights problems or faults and immediately gives feedback to allow code to be improved. Detecting errors earlier in the coding process means that these are easier and quicker to fix. Notifications can be set up to alert team members to failures or successes at each stage.</li>
<li id="f7aa" class="mn mo ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph="">Improving team collaboration — The team has visibility into problems, can view feedback, and make changes where appropriate.</li>
<li id="2c90" class="mn mo ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph="">Audit trails — Each stage of the pipeline generates logs and can enable accountability and traceability.</li>
</ul>
Check out <a href="https://spacelift.io/blog/scaling-ci-cd" target="_blank" rel="noopener">7 steps to optimize your CI/CD pipelines for scaling</a>.

A good pipeline should be reliable, accurate, and fast.
<h3 id="6cd4" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">Reliability</h3>
A pipeline should run reliably each time, without any errors, or unexpected intermittent errors. Broken pipelines can cause frustration and wasted time. When a pipeline is broken or throwing errors, it is recommended that the owner fix it as soon as possible before continuing work on the product. This approach should save other users from the same issues and aid the overall team. It is for this reason that many organizations have a specified ‘DevOps’ team, that will own the pipelines and monitor their success.
A reliable pipeline will produce the same result, given the same input.
Self-hosted build agents can often be the cause of unreliable pipeline runs, due to the required maintenance required on these (underlying infrastructure, patching, package management, security, etc). However, they are sometimes necessary as they offer greater flexibility when compared to platform-provided build agents.
<h3 id="2a9a" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">Accuracy</h3>
Ironing out errors in repetitive tasks is where CI/CD pipelines can really shine to improve the overall quality of a product.
<h3 id="5862" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">Speed</h3>
Optimizing a pipeline to run as quickly as possible ensures that the developer of the code can get feedback on the success or failure of the pipeline run quickly, making them more efficient, reducing the chance of distractions and ‘context switching’ (switching to another task/meeting/browsing the web).
Fast pipeline runs can also enable deployments more often. For example, if a pipeline takes 1 hour to run, and the working day is 8 hours long, then an absolute maximum of 8 deployments can be made per day. Reduce the pipeline run time down to 30 minutes, now 16 deployments can be made.
A common problem with pipeline runs is that they end up in a queued state, waiting for a build agent to process a previous run before the next can start. For this reason, multiple agents should be provisioned so different pipelines can be run in parallel. A serverless model or <a href="https://spacelift.io/blog/container-orchestration-tools" target="_blank" rel="noopener">container orchestration solution</a> is particularly useful here in order to scale the build agent capacity dynamically when demand is high.
Good pipelines are also quick to create. They should be written in code and kept in a VCS alongside the product code where appropriate. Base templates can be written by providing a common structure, which other templates can reference, speeding up the time required to create a new pipeline.
See our <a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">list of the most useful CI/CD tools</a> that define the state of today’s software automation.
And take a look at how <a href="https://spacelift.io/ci-cd-for-infrastructure" target="_blank" rel="noopener">Spacelift</a> provides a platform to manage IaC in an automated, easy, controlled, and secure manner. It goes above and beyond the support that is offered by the plain backend system. Spacelift is a sophisticated CI/CD platform for IaC that enables Gitops on infrastructure provisioning workflows. Check it out for free and create a <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">trial account</a>.

<h3 id="fbe2" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">1) Build</h3>
Write and store the Terraform Code in VCS.
<h3 id="7082" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">2) Test</h3>
Testing tools used with Terraform CLI-driven pipeline runs include <a href="https://spacelift.io/blog/what-is-tfsec" target="_blank" rel="noopener">Tfsec</a> and <a href="https://spacelift.io/blog/what-is-checkov" target="_blank" rel="noopener">Checkov</a>. Many infrastructure-as-code-specific CI/CD platforms enable policy as code such as <a href="https://spacelift.io/blog/what-is-terraform-cloud" target="_blank" rel="noopener">Terraform Cloud</a>, or better still, Spacelift, which uses the open-source <a href="https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works" target="_blank" rel="noopener">Open Policy Agent (OPA)</a>, meaning this testing language could be used across multiple projects using different tooling.
Learn <a href="https://spacelift.io/blog/terraform-test" target="_blank" rel="noopener">how to test your Terraform code</a>.
<h3 id="9836" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">3) Deliver</h3>
Prepare Terraform Execution Environment (could include things like getting secrets from a key vault, or setting environment variables).
<a href="https://spacelift.io/blog/terraform-init" target="_blank" rel="noopener">Terraform init</a>
Terraform plan (copy output file to a repository, ready to be used by the apply command in the deploy stage.
<h3 id="7d0b" class="nb lr ip bn ls nc nd ne lw nf ng nh ma kn ni nj mc kr nk nl me kv nm nn mg no gt">4) Deploy</h3>
<a href="https://spacelift.io/blog/terraform-apply" target="_blank" rel="noopener">Terraform apply</a>
See also best practices and techniques for managing <a href="https://spacelift.io/blog/kubernetes-ci-cd" target="_blank" rel="noopener">CI/CD pipelines with Kubernetes</a>.

<h3>1) Build</h3>
Developers write Kubernetes configuration files and push them to a Git repository in a VCS. YAML files could be added to define other components of the pipeline, such as ConfigMaps for configuration data or Secrets for sensitive information.
<h3>2) Test</h3>
The code is built, and tests are run on it. Kube-bench is a security tool that checks Kubernetes configurations against best practices and industry standards, including CIS benchmarks. Helm unit testing is a testing tool for Helm charts.
<h3>3) Deliver</h3>
Once the tests pass, the CI server creates a Docker container image of the application and pushes it to a container registry such as Docker Hub or Amazon ECR.
<h3>4) Deploy</h3>
Once the container image is available in the registry, Kubernetes can be used to deploy the application. The docker image can be tagged as appropriate.
For more details, check out &#8211; <a href="https://spacelift.io/blog/kubernetes-ci-cd" target="_blank" rel="noopener">Kubernetes CI/CD Pipelines – 7 Best Practices and Tools</a>.

<h3>1) Build</h3>
Developers write .NET code and push it to a Git repository in a VCS. The code is built when it is pushed, triggered by CI using a build tool such as MSBuild or dotnet CLI.
<h3>2) Test</h3>
The code is built, and tests are run on it. Unit testing can be done using a framework such as NUnit or xUnit.
<h3>3) Deliver</h3>
Once the tests pass, the CI server generates an artifact, such as a NuGet package or a self-contained executable that can be deployed.
<h3>4) Deploy</h3>
The artifact is deployed.

CI/CD pipelines are an important concept for the modern engineer to understand fully, especially in the current cloud-native world. CI/CD pipelines enhance the software delivery process by automating key stages such as building, testing, delivery and deployment. Adopting a pipeline-based workflow helps you ship more quickly by passing all code through a consistent set of steps.

Spacelift is an alternative to using homegrown solutions on top of a generic  CI solution. It allows you to automate, audit, secure, and continuously deliver your infrastructure.

Infrastructure Problems that Spacelift Solves

How to Implement GitLab CI/CD Pipeline with Terraform

CI/CD Security: What is It, Risks & Best Practices

What makes a good CI/CD pipeline? Take a closer look at the pipeline stages and some examples relating to Terraform.

74-cicd-pipeline

CI/CD Pipeline

CI/CD Pipeline : Everything You Need To Know

Want to level up your Kubernetes knowledge? Explore our tutorials and step-by-step guides written by Kubernetes experts. Learn Kubernetes best practices and solutions to the most difficult problems.

Kubernetes Guides and Tutorials | Spacelift Blog

Kubernetes

In this post, I will run through some best practices to use when using Kubernetes (K8s).
As the most popular container orchestration system, K8s is the de-facto standard for the modern cloud engineer to get to grips with. K8s is a notoriously complex system to use and maintain, so getting a good grasp of what you should and should not be doing, and knowing what is possible will get your deployment off to a solid start.
These recommendations cover common issues within three broad categories, application development, governance, and cluster configuration.
<h3 id="b48f" class="lq lr ip bn ls lt lu lv lw lx ly lz ma kn mb mc md kr me mf mg kv mh mi mj mk gt">Kubernetes Best Practices:</h3>
<ol class="">
<li id="d51a" class="ml mm ip kg b kh mn kk mo kn mp kr mq kv mr kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#1-use-namespaces" rel="">Use namespaces</a></li>
<li id="10ef" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#2-use-readiness-and-liveness-probes">Use readiness and liveness probes</a></li>
<li data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#3-use-autoscaling">Use autoscaling</a></li>
<li id="39ca" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#4-use-autoscaling">Use resource requests and limits</a></li>
<li id="b033" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#5-deploy-your-pods-as-part-of-a-deployment-daemonset-replicaset-or-statefulset-across-nodes">Deploy your Pods as part of a Deployment, DaemonSet, ReplicaSet or StatefulSet across nodes.</a></li>
<li id="257b" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#6-use-multiple-nodes">Use multiple nodes</a></li>
<li id="3469" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#7-use-rolebased-access-control-rbac">Use Role-based access control (RBAC)</a></li>
<li id="3bde" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#8-host-your-kubernetes-cluster-externally-use-a-cloud-service">Host your Kubernetes cluster externally (use a cloud service)</a></li>
<li id="8020" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#9-upgrade-your-kubernetes-version">Upgrade your Kubernetes version</a></li>
<li id="aceb" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#10-monitor-your-cluster-resources-and-audit-policy-logs">Monitor your cluster resources and audit policy logs</a></li>
<li id="1c77" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#11-use-a-version-control-system">Use a version control system</a></li>
<li id="5eae" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#12-use-a-gitbased-workflow-gitops">Use a Git-based workflow (GitOps)</a></li>
<li id="00e8" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#13-reduce-the-size-of-your-containers">Reduce the size of your containers</a></li>
<li id="5459" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#14-organize-your-objects-with-labels">Organize your objects with labels</a></li>
<li id="8a71" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#15-use-network-policies">Use network policies</a></li>
<li id="eecf" class="ml mm ip kg b kh mw kk mx kn my kr mz kv na kz ms mt mu mv gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#16-use-a-firewall">Use a firewall</a></li>
<li data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-best-practices#16-use-declarative-configuration" rel="">Use declarative configuration</a></li>
</ol>

Namespaces in K8s are important to utilize in order to organize your objects, create logical partitions within your cluster, and for security purposes. By default, there are three namespaces in a <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">K8s cluster</a>, <code class="gs nl nm nn no b">default</code>, <code class="gs nl nm nn no b">kube-public</code> and <code class="gs nl nm nn no b">kube-system</code>.
RBAC can be used to control access to particular namespaces in order to limit the access of a group to control the blast-radius of any mistakes that might occur, for example, a group of developers may only have access to a namespace called <code class="gs nl nm nn no b">dev</code> , and have no access to the <code class="gs nl nm nn no b">production</code> namespace. The ability to limit different teams to different namespaces can be valuable to avoid duplicated work or resource conflict.
LimitRange objects can also be configured against namespaces to define the standard size for a container deployed in the namespace. ResourceQuotas can also be used to limit the total resource consumption of all containers inside a Namespace. Network policies can be used against namespaces to limit traffic between pods.
Check out our <a href="https://spacelift.io/blog/kubernetes-namespaces" target="_blank" rel="noopener">Working with Kubernetes Namespaces</a> tutorial.

Readiness and Liveness probes are essentially types of health checks. These are another very important concept to utilize in K8s.
Readiness probes ensure that requests to a pod are only directed to it when the pod is ready to serve requests. If it is not ready, then requests are directed elsewhere. It is important to define the readiness probe for each container, as there are no default values set for these in K8s.
For example, if a pod takes 20 seconds to start and the readiness probe was missing, then any traffic directed to that pod during the startup time would cause a failure. Readiness probes should be independent and not take into account any dependencies on other services, such as a backend database or caching service.
<a href="https://spacelift.io/blog/kubernetes-liveness-probe" target="_blank" rel="noopener">Liveness probes</a> test if the application is running in order to mark it as healthy. For example, a particular path of a web app could be tested to ensure it is responding. If not, the pod will not be marked as healthy and the probe failure will cause the <code class="gs nl nm nn no b">kubelet</code>to launch a new pod, which will then be tested again. This type of probe is used as a recovery mechanism in case the process becomes unresponsive.

Where it is appropriate, autoscaling can be employed to dynamically adjust the number of pods (horizontal pod autoscaler), the amount of resources consumed by the pods (vertical autoscaler), or the number of nodes in the cluster (cluster autoscaler), depending on the demand for the resources.
The horizontal pod autoscaler can also scale a replication controller, replica set, or <a href="https://spacelift.io/blog/kubernetes-statefulset" target="_blank" rel="noopener">statefulset</a> based on CPU demand.
Using scaling also brings some challenges, such as not storing persistent data in the container&#8217;s local filesystem, as this would prevent horizontal autoscaling. Instead, a PersistentVolume could be used. (Read more about <a href="https://spacelift.io/blog/kubernetes-persistent-volumes" target="_blank" rel="noopener">Kubernetes Persistent Volumes</a>).
The cluster autoscaler is useful when highly variable workloads exist on the cluster that may require different amounts of resources at different times based on demand. Removing unused nodes automatically is also a great way to save money!

Resource requests and limits (minimum and maximum amount of resources that can be used in a container) should be set to avoid a container starting without the required resources assigned, or the cluster running out of available resources.
Without limits, pods can utilize more resources than required, causing the total available resources to be reduced which may cause a problem with other applications on the cluster. Nodes may crash, and new pods may not be able to be placed corrected by the scheduler.
Without requests, if the application cannot be assigned enough resources, it may fail when attempting to start or perform erratically.
Resource requests and limits define the amount of CPU and Memory available in millicores and mebibytes. Note that if your process goes over the memory limit, the process is terminated, so it may not always be appropriate to set this in all cases. If your container goes over the CPU limit, the process is throttled.

<ul>
<li><a href="https://spacelift.io/blog/terraform-vs-kubernetes" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Terraform vs. Kubernetes : Key Differences and Comparison&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Terraform vs. Kubernetes Comparison</a></li>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;5 Most Useful CI/CD Tools for DevOps in 2022&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Top Most Useful CI/CD Tools for DevOps</a></li>
<li><a href="https://spacelift.io/blog/devops-best-practices" target="_blank" rel="noopener">16 DevOps Best Practices to Follow</a></li>
</ul>

A single pod should never be run individually. To improve fault tolerance, instead, they should always be part of a Deployment, DaemonSet, ReplicaSet or StatefulSet. The pods can then be deployed across nodes using anti-affinity rules in your deployments to avoid all pods being run on a single node, which may cause downtime if it was to go down.
See <a href="https://spacelift.io/blog/statefulset-vs-deployment" target="_blank" rel="noopener">StatefulSet vs. Deployment</a>.

Running K8s on a single node is not a good idea if you want to build in fault tolerance. Multiple nodes should be employed in your cluster so workloads can be spread between them.

<a href="https://spacelift.io/blog/kubernetes-security#1-use-rbac" target="_blank" rel="noopener">Using RBAC in your K8s cluster</a> is essential to properly secure your system. Users, Groups, and Service accounts can be assigned permissions to perform permitted actions on a particular namespace (a Role), or to the entire cluster (ClusterRole). Each role can have multiple permissions. To tie the defined roles to the users, groups, or service accounts, RoleBinding or ClusterRoleBinding objects are used.
RBAC roles should be set up to grant using the principle of least privilege, i.e. only permissions that are required are granted. For example, the admin&#8217;s group may have access to all resources, and your operator&#8217;s group may be able to deploy but not be able to read <a href="https://spacelift.io/blog/kubernetes-secrets" target="_blank" rel="noopener">Secrets</a>.

Hosting a K8s cluster on your own hardware can be a complex undertaking. Cloud services offer K8s clusters as platform as a service (PaaS), such as AKS (Azure Kubernetes Service) on Azure, or EKS (Amazon Elastic Kubernetes Service) on Amazon Web Services. Taking advantage of this means the underlying infrastructure will be managed by your cloud provider, and tasks around scaling your cluster, such as adding and removing nodes can be much more easily achieved, leaving your engineers to the management of what is running on the K8s cluster itself.

As well as introducing new features, new K8s versions also include vulnerability and security fixes, which make it important to run an up-to-date version of K8s on your cluster. Support for older versions will likely not be as good as newer ones.
Migrating to a new version should be treated with caution however as certain features can be depreciated, as well as new ones added. Also, the apps running on your cluster should be checked that they are compatible with the newer targeted version before upgrading.

Monitoring the components in the K8s control plane is important to keep resource consumption under control. The control plane is the core of K8s, these components keep the system running and so are vital to correct K8s operations. Kubernetes API, kubelet, etcd, controller-manager, kube-proxy and kube-dns make up the control plane.
Control plane components can output metrics in a format that can be used by <a href="https://spacelift.io/blog/prometheus-kubernetes" target="_blank" rel="noopener">Prometheus</a>, the most common K8s monitoring tool.
Automated monitoring tools should be used rather than manually managing alerts.
Audit logging in K8s can be turned on whilst starting the kube-apiserver to enable deeper investigation using the tools of your choice. The audit.log will detail all requests made to the K8s API and should be inspected regularly for any issues that might be a problem on the cluster. The Kubernetes cluster default policies are defined in the audit-policy.yaml file and can be amended as required.
A log aggregation tool such as Azure Monitor can be used to send logs to a log analytics workspace from AKS for future interrogation using Kusto queries. On AWS Cloudwatch can be used. Third-party tools also provide deeper monitoring functionality such as Dynatrace and Datadog.
Finally, a defined retention period should be in place for the logs, around 30–45 days is common.

K8s configuration files should be controlled in a version control system (VCS). This enables a raft of benefits, including increased security, enabling an audit trail of changes, and will increase the stability of the cluster. Approval gates should be put in place for any changes made so the team can peer-review the changes before they are committed to the main branch.

Successful deployments of K8s require thought on the workflow processes used by your team. Using a git-based workflow enables automation through the use of CI/CD (Continuous Integration / Continuous Delivery) pipelines, which will increase application deployment efficiency and speed. CI/CD will also provide an audit trail of deployments. Git should be the single source of truth for all automation and will enable unified management of the K8s cluster. You can also consider using a dedicated infrastructure delivery platform such as <a class="au lp" href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>, which recently introduced Kubernetes support.
Learn <span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;how to maintain operations around the Kubernetes Cluster&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}"><a href="https://spacelift.io/blog/how-to-maintain-operations-around-kubernetes-cluster" target="_blank" rel="noopener">how to maintain operations around the Kubernetes Cluster</a>.

Smaller image sizes will help speed up your builds and deployments and reduce the amount of resources the containers consumed on your K8s cluster. Uneccesery packages should be removed where possible, and small OS distribution images such as Alpine should be favored. Smaller images can be pulled faster than larger images, and consume less storage space.
Following this approach will also provide security benefits as there will be fewer potential vectors of attack for malicious actors.

K8s labels are key-value pairs that are attached to objects in order to organize your cluster resources. Labels should be meaningful metadata that provide a mechanism to track how different components in the K8s system interact.
Recommended labels for pods in the <a class="au lp" href="https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/" target="_blank" rel="noopener ugc nofollow">official K8s documentation</a> include <code class="gs nl nm nn no b">name, instance, version, component, part-of,</code> and <code class="gs nl nm nn no b">managed-by</code>.
Labels can also be used in a similar way to using tags in a cloud environment on resources in order to track things related to the business, such as object <code class="gs nl nm nn no b">ownership</code>, and the <code class="gs nl nm nn no b">environment</code>an object should belong to.
Also recommended is to use labels to detail security requirements, including <code class="gs nl nm nn no b">confidentiality</code> and <code class="gs nl nm nn no b">compliance</code>.

Network policies should be employed to restrict traffic between objects in the K8s cluster. By default, all containers can talk to each other in the network, something that presents a security risk if malicious actors gain access to a container, allowing them to traverse objects in the cluster. Network policies can control traffic at the IP and port level, similar to the concept of security groups in cloud platforms to restrict access to resources. Typically, all traffic should be denied by default, then allow rules should be put in place to allow required traffic.

As well as using network policies to restrict internal traffic on your K8s cluster, you should also put a firewall in front of your K8s cluster in order to restrict requests to the API server from the outside world. IP addresses should be whitelisted and open ports restricted.

Declarative configuration involves specifying the desired state of your resources in YAML or JSON files and then using tools like <code>kubectl apply</code> to apply these configurations to your cluster. 
You describe what your resources should look like rather than issuing imperative commands to achieve a specific state. Declarative configuration is idempotent, meaning that applying the same configuration multiple times results in the same desired state.

Following the best practices listed in this article when designing, running, and maintaining your Kubernetes cluster will put you on the path to success on your modern application journey! You can also check out <a href="https://spacelift.io/blog/kubernetes-challenges" target="_blank" rel="noopener">15 challenges and pitfalls to look for each time you use Kubernetes</a>.

Provisioning AWS EKS Cluster with Terraform - Tutorial

Infrastructure as Code : Best Practices, Benefits & Examples

Initial Availability of Kubernetes Integration in Spacelift

Follow the best practices for Kubernetes listed in this article for painless and efficient maintenance of your K8s cluster.

73-kubernetes-best-practices

Kubernetes Best Practices

17 Kubernetes Best Practices Every Developer Should Know

Flavius Dinu

Sometimes you just want to get straight to the commands you need to use with a particular tool, without having to trawl through all the documentation. In this post, I’ll highlight the commonly used commands used on the Terraform CLI so you can get straight into the action without the pain! You will also find here a Terraform Cheat Sheet PDF version to download.
This Terraform command reference guide was written using the <a href="https://spacelift.io/blog/terraform-version-upgrade" target="_blank" rel="noopener">latest version of Terraform</a> v.1.3.7. New commands and subcommands can be added and depreciated over time with different versions, but should not change too dramatically. You can get the latest version of Terraform <a href="https://www.terraform.io/downloads" target="_blank" rel="nofollow noopener">here</a>.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu works with your existing Terraform state file, so you won’t have any issues when you are migrating to it.

<ol>
<li><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#get-help">Get Help</a></li>
<li id="2b2a" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#show-your-terraform-version">Show your Terraform version</a></li>
<li id="4562" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#format-your-terraform-code">Format your Terraform code</a></li>
<li id="1ce2" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#initialize-your-directory">Initialize your directory</a></li>
<li id="f905" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#download-and-install-modules">Download and install modules</a></li>
<li id="dcb1" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#validate-your-terraform-code">Validate your Terraform code</a></li>
<li id="5649" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#plan-your-infrastructure">Plan your Infrastructure</a></li>
<li id="0ef2" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#deploy-your-infrastructure">Deploy your Infrastructure</a></li>
<li id="0701" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#destroy-your-infrastructure">Destroy your infrastructure</a></li>
<li id="e016" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#taint-or-untaint-your-resources">‘Taint’ or ‘Untaint’ your resources</a></li>
<li id="c1eb" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#refresh-the-state-file">Refresh the state file</a></li>
<li id="c6df" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#viewyour-state-file">View your state file</a></li>
<li id="60ea" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#manipulate-your-state-file">Manipulate your state file</a></li>
<li id="c28a" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#import-existing-infrastructure-into-your-terraform-state">Import existing Infrastructure into your Terraform state</a></li>
<li id="c203" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#get-provider-information">Get provider information</a></li>
<li id="0556" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#manage-your-workspaces">Manage your workspaces</a></li>
<li id="5c08" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#view-your-outputs">View your outputs</a></li>
<li id="4e3b" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#release-a-lock-on-your-workspace">Release a lock on your workspace</a></li>
<li id="aa3f" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#log-in-and-out-to-a-remote-host-terraform-cloud">Log in and out to a remote host (Terraform Cloud)</a></li>
<li id="3100" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#produce-a-dependency-diagram">Produce a dependency diagram</a></li>
<li id="bc46" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#test-your-expressions">Test your expressions</a></li>
<li data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#switch-working-directory">Switch Working Directory</a></li>
<li data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#shell-tabcompletion">Shell Tab-completion</a></li>
</ol>

<code class="gs od oe of og b">terraform -help</code> — Get a list of available commands for execution with descriptions. Can be used with any other subcommand to get more information.
<code class="gs od oe of og b">terraform fmt -help</code> — Display help options for the <a href="https://spacelift.io/blog/terraform-fmt" target="_blank" rel="noopener"><code class="gs od oe of og b">fmt</code> command</a>.

<code class="gs od oe of og b">terraform version</code> — Show the current version of your Terraform and notifies you if there is a newer version available for download.

This should be the first command you run after creating your configuration files to ensure your code is formatted using the HCL standards. This makes it easier to follow and aids collaboration.
<code class="gs od oe of og b">terraform fmt</code> — Format your Terraform configuration files using the HCL language standard.
<code class="gs od oe of og b">terraform fmt --recursive</code> — Also format files in subdirectories
<code class="gs od oe of og b">terraform fmt --diff</code> — Display differences between original configuration files and formatting changes.
<code class="gs od oe of og b">terraform fmt --check</code> — Useful in automation <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">CI/CD pipelines</a>, the check flag can be used to ensure the configuration files are formatted correctly, if not the exit status will be non-zero. If files are formatted correctly, the exit status will be zero.

<code class="gs od oe of og b">terraform init</code> — In order to prepare the working directory for use with Terraform, the <code class="gs od oe of og b">terraform init</code> command performs Backend Initialization, Child Module Installation, and Plugin Installation.
<code class="gs od oe of og b">terraform init -get-plugins=false</code> — Initialize the working directory, do not download plugins.
<code class="gs od oe of og b">terraform init -lock=false</code> — Initialize the working directory, don’t hold a state lock during backend migration.
<code class="gs od oe of og b">terraform init -input=false</code> — Initialize the working directory, and disable interactive prompts.
<code class="gs od oe of og b">terraform init -migrate-state</code> — Reconfigure a backend, and attempt to migrate any existing state.
<code class="gs od oe of og b">terraform init -verify-plugins=false</code> — Initialize the working directory, do not verify plugins for Hashicorp signature
See our <a href="https://spacelift.io/blog/terraform-init" target="_blank" rel="noopener">detailed rundown of the <code class="gs od oe of og b">terraform init</code> command</a>!

Note this is usually not required as this is part of the <code class="gs od oe of og b">terraform init</code> command.
<code class="gs od oe of og b">terraform get</code> — Download and installs <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">modules</a> needed for the configuration.
<code class="gs od oe of og b">terraform get -update</code> — Check the versions of the already installed modules against the available modules and installs the newer versions if available.

<code class="gs od oe of og b">terraform validate</code> — Validate the configuration files in your directory and does not access any remote state or services. <code class="gs od oe of og b">terraform init</code> should be run before this command.
<code>terraform validate -json</code> — To see easier the number of errors and warnings that you have.
Learn <a href="https://spacelift.io/blog/terraform-validate" target="_blank" rel="noopener">how to validate your configuration locally</a>.

<code class="gs od oe of og b">terraform plan</code> — Plan will generate an execution plan, showing you what actions will be taken without actually performing the planned actions.
<code class="gs od oe of og b">terraform plan -out=&lt;path&gt;</code> — Save the plan file to a given path. Can then be passed to the <code class="gs od oe of og b">terraform apply</code> command.
<code class="gs od oe of og b">terraform plan -destroy</code> — Create a plan to destroy all objects rather than the usual actions.

<code class="gs od oe of og b">terraform apply</code> — Create or update infrastructure depending on the configuration files. By default, a plan will be generated first and will need to be approved before it is applied.
<code class="gs od oe of og b">terraform apply -auto-approve</code> — Apply changes without having to interactively type ‘yes’ to the plan. Useful in automation CI/CD pipelines.
<code class="gs od oe of og b">terraform apply &lt;planfilename&gt;</code> — Provide the file generated using the <code class="gs od oe of og b">terraform plan -out</code> command. If provided, Terraform will take the actions in the plan without any confirmation prompts.
<code class="gs od oe of og b">terraform apply -lock=false</code> — Do not hold a state lock during the Terraform apply operation. Use with caution if other engineers might run concurrent commands against the same workspace.
<code class="gs od oe of og b">terraform apply -parallelism=&lt;n&gt;</code> — Specify the number of operations run in parallel.
<code class="gs od oe of og b">terraform apply -var="environment=dev"</code> — Pass in a variable value.
<code class="gs od oe of og b">terraform apply -var-file="varfile.tfvars"</code> — Pass in variables contained in a file.
<code class="gs od oe of og b">terraform apply -target=”module.appgw.0"</code> — Apply changes only to the targeted resource.

<code class="gs od oe of og b">terraform destroy</code> — <a href="https://spacelift.io/blog/how-to-destroy-terraform-resources" target="_blank" rel="noopener">Destroy</a> the infrastructure managed by Terraform.
<code class="gs od oe of og b">terraform destroy -target=”module.appgw.0"</code> — Destroy only the targeted resource.
<code class="gs od oe of og b">terraform destroy --auto-approve</code> — Destroy the infrastructure without having to interactively type ‘yes’ to the plan. Useful in automation CI/CD pipelines.
<code>terraform destroy -target="module.appgw.resource[\"key\"]"</code> — Destroy an instance of a resource created with for_each.

Use the <a href="https://spacelift.io/blog/terraform-taint" target="_blank" rel="noopener"><code class="gs od oe of og b">taint</code> command</a> to mark a resource as not fully functional. It will be deleted and re-created.
<code class="gs od oe of og b">terraform taint vm1.name</code> — Taint a specified resource instance.
<code class="gs od oe of og b">terraform untaint vm1.name</code> — Untaint the already tainted resource instance.

<code class="gs od oe of og b">terraform refresh</code> — Modify the state file with updated metadata containing information on the resources being managed in Terraform. Will not modify your infrastructure.

<code class="gs od oe of og b">terraform show</code> — Show the state file in a human-readable format.
<code class="gs od oe of og b">terraform show &lt;path to statefile&gt;</code> — If you want to read a specific state file, you can provide the path to it. If no path is provided, the current state file is shown.

<code class="gs od oe of og b">terraform state</code> — One of the following subcommands must be used with this command in order to manipulate the state file.
<code class="gs od oe of og b">terraform state list</code> — Lists out all the resources that are tracked in the current state file.
<code class="gs od oe of og b">terraform state mv</code> — Move an item in the state, for example, this is useful when you need to tell Terraform that an item has been renamed, e.g. <code class="gs od oe of og b">terraform state mv vm1.oldname vm1.newname</code>
<code class="gs od oe of og b">terraform state pull &gt; state.tfstate</code> — Get the current state and outputs it to a local file.
<code class="gs od oe of og b">terraform state push</code> — Update remote state from the local state file.
<code class="gs od oe of og b">terraform state replace-provider hashicorp/azurerm customproviderregistry/azurerm</code> — Replace a provider, useful when switching to using a custom provider registry.
<code class="gs od oe of og b">terraform state rm</code> — Remove the specified instance from the state file. Useful when a resource has been manually deleted outside of Terraform.
<code class="gs od oe of og b">terraform state show &lt;resourcename&gt;</code> — Show the specified resource in the state file.

<code class="gs od oe of og b">terraform import vm1.name -i id123</code> — Import a VM with id123 into the configuration defined in the configuration files under vm1.name.
See our <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">terraform import tutorial</a> for more details.
Btw. We created a comprehensive pdf version of Terraform Cheatsheet dedicated to those who want to learn and remember the key Terraform commands and have a quick reference guide in pdf form. You can get it below.

book

terraform_book

<code class="gs od oe of og b">terraform providers</code> — Display a tree of providers used in the configuration files and their requirements.

<code class="gs od oe of og b">terraform workspace</code> — One of the following subcommands must be used with the workspace command. Workspaces can be useful when an engineer wants to test a slightly different version of the code. It is not recommended to use Workspaces to isolate or separate the same infrastructure between different development stages, e.g. Dev / UAT / Production, or different internal teams.
<code class="gs od oe of og b">terraform workspace show</code> — Show the name of the current workspace.
<code class="gs od oe of og b">terraform workspace list</code> — List your workspaces.
<code class="gs od oe of og b">terraform workspace select &lt;workspace name&gt;</code> — Select a specified workspace.
<code class="gs od oe of og b">terraform workspace new &lt;workspace name&gt;</code> — Create a new workspace with a specified name.
<code class="gs od oe of og b">terraform workspace delete &lt;workspace name&gt;</code> — Delete a specified workspace.

<code class="gs od oe of og b">terraform output</code> — List all the <a href="https://spacelift.io/blog/terraform-output" target="_blank" rel="noopener">outputs</a> currently held in your state file. These are displayed by default at the end of a <code class="gs od oe of og b">terraform apply</code>, this command can be useful if you want to view them independently.
<code class="gs od oe of og b">terraform output -state=&lt;path to state file&gt;</code> — List the outputs held in the specified state file. -state option is ignored when the remote state is used.
<code class="gs od oe of og b">terraform output -json</code> — List the outputs held in your state file in JSON format to make them machine-readable.
<code class="gs od oe of og b">terraform output vm1_public_ip</code> — List a specific output held in your state file.

<code class="gs od oe of og b">terraform force-unlock &lt;lock_id&gt;</code> — Remove the lock with the specified lock ID from your workspace. Useful when a lock has become ‘stuck’, usually after an incomplete Terraform run.

<code class="gs od oe of og b">terraform login</code> — Grab an API token for Terraform cloud (app.terraform.io) using your browser.
<code class="gs od oe of og b">terraform login &lt;hostname&gt;</code> — Log in to a specified host.
<code class="gs od oe of og b">terraform logout</code> — Remove the credentials that are stored locally after logging in, by default for Terraform Cloud (app.terraform.io).
<code class="gs od oe of og b">terraform logout &lt;hostname&gt;</code> — Remove the credentials that are stored locally after logging in for the specified hostname.

<code class="gs od oe of og b">terraform graph</code> — Produce a graph in DOT language showing the dependencies between objects in the state file. This can then be rendered by a program called Graphwiz (amongst others).
<code class="gs od oe of og b">terraform graph -plan=tfplan</code> — Produce a dependency graph using a specified plan file (generated using <code class="gs od oe of og b">terraform plan -out=tfplan</code>).
<code class="gs od oe of og b">terraform graph -type=plan</code> — Specify the type of graph to output, either <code class="gs od oe of og b">plan, plan-refresh-only, plan-destroy,</code> or <code class="gs od oe of og b">apply</code>.
<code>terraform graph -draw-cycles</code> — You can see if there are any dependency cycles between the resources.

<code class="gs od oe of og b">terraform console</code> — Allow testing and exploration of expressions on the interactive console using the command line. e.g. 1+2 🙂
With the <code>terraform console</code> command, you have the ability to test different pieces of code. All you have to do is write <code>terraform console</code>, and then you can write HCL code.

You also have the ability to run Terraform from another directory if the need arises. This is particularly useful when you are using different automations and you don’t want to change directory. This is done by:
<code>terraform -chdir=”../dev” apply</code>

Terraform also comes with an optional Shell Tab-completion. It can be useful if you are just starting out with Terraform. However, Terraform CLI is pretty lightweight, and you won’t usually reach very long commands.
To install the Shell Tab-completion you will need to first run:
<code>terraform -install-autocomplete</code>
After that you will need to resource your profile. This is done by either closing and opening the terminal, or by running source path_to_your_profile.

Terraform is an infrastructure as code (IaC) tool developed by HashiCorp, which was initially open-source but recently switched to a BSL. It uses a declarative language called HashiCorp Configuration Language (HCL) to define infrastructure resources. Terraform supports a wide variety of cloud providers such as AWS, Microsoft Azure, Google Cloud, or Oracle Cloud Infrastructure, but it can also be used with Kubernetes, Helm, and many others. It is stateful, keeping track of the deployed infrastructure using a state file.
<h3>What is Terraform CLI?</h3>
The Terraform Command Line Interface (CLI), is a command-line tool that provides a simple way for users to interact with the infrastructure components defined in the Terraform configuration. It offers multiple commands, from initializing your terraform directory to planning, applying, and destroying infrastructure resources. With the Terraform CLI, you also have the ability to check outputs, do state-related operations, and even test different expressions.

Working in a team of Terraform developers can be challenging. <a href="https://spacelift.io">Spacelift</a> is built to provide a great CI/CD experience concerning IaC. It can be used for version control of the code, state management, and much more. Spacelift lets you customize the entire infrastructure life-cycle management by providing the ability to run pre and post commands at every stage, which can be very useful in keeping track of things. If you are interested in trying it, <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">create your free trial account</a>.

This guide should help you get straight to the command you need when using the Terraform CLI!
If you need more help with Terraform, I encourage you to check the following blog posts: <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments</a>, and <a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">12 Terraform Best Practices.</a>

What are Terraform Templates? Examples and Use Cases

Terraform Functions, Expressions, Loops (Examples)

This Terraform Cheat Sheet guide (+pdf) will help you get straight to the commands you need when using the Terraform CLI!

Jack Roper

Terraform Providers Overview & How To Use Them

Get the newsletter

Recent posts

Cloud Deployment Models – Types, Comparison & Examples

How to Use Terraform Join and Split Functions with Strings

When to Run Terraform Apply – Quick Usage Examples

CI/CD Pipeline : Everything You Need To Know

17 Kubernetes Best Practices Every Developer Should Know

Terraform Cheat Sheet – 23 Terraform CLI Commands & Examples

Terraform Init – Command Overview with Examples

Terraform Count vs. For Each Meta-Argument – When to Use It

Infrastructure as Code : Best Practices, Benefits & Examples