liveBook · Manning

Infrastructure as code

As explained in Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform

The practice of defining, provisioning, and managing infrastructure through machine-readable code.

Infrastructure as code means storing infrastructure configuration as executable code. Instead of creating cloud resources by hand in a portal, you edit and run that code to create, update, or recreate them. The configuration describes the infrastructure you want and serves as executable documentation. section 7.4 section 7.16

A declarative configuration specifies the resources and their settings rather than every step needed to build them. Terraform runs HashiCorp Configuration Language (HCL) files to create cloud resources. Provider plugins connect it to cloud platforms; this example uses Azure. You can run Terraform locally while the resulting resources appear in the cloud. section 7.4 section 7.7 section 7.3

Build and change the infrastructure incrementally:

  • Declare a small first resource, such as an Azure resource group, in a Terraform file. section 7.8.2
  • Run terraform init to initialize the project, then terraform apply to create the resources. Edit the configuration and apply again to make further changes. section 7.16 section 7.8.8
  • Use Terraform state to track what was created, variables to share configuration, and outputs to inspect results. Do not expose sensitive values through production outputs; fix provider versions to avoid surprises. section 7.16
  • Run terraform destroy when experimental resources are no longer needed. Review its plan before confirming; do not destroy infrastructure that people depend on. section 7.8.8 section 7.13
Listing 7.1 Creating an Azure resource group
resource "azurerm_resource_group" "flixtube" {   #1
  name = "flixtube"                              #2
  location = "eastus"                            #3
}

A three-line resource declaration sets the name and Azure location of the first piece of infrastructure. section 7.8.2

The same approach extends from a resource group to a container registry and Kubernetes cluster. Once those resources are defined in code, a configuration change can also resize a cluster node pool. Larger virtual machines cost more, so review operational and cost consequences before applying changes. section 7.0 section 7.11.4 section 12.3.1

How Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform covers it

How deep it goes
Works from a resource declaration through initialization, application, iteration, and destruction; leaves deeper Terraform study to further resources.
Examples
Uses an Azure resource group declaration, a Terraform-built Kubernetes cluster, and a node-pool virtual-machine size change.
What it assumes
Assumes context for cloud resources and Kubernetes, while introducing Terraform configuration through a minimal Azure resource group.
What you can do after
Build it from scratch with Terraform: create and revise Azure resources through code, then destroy experimental infrastructure when finished.
How it connects
Connects declarative configuration, executable documentation, Terraform state, provider plugins, evolutionary architecture, and Kubernetes infrastructure.

Also explained in

Compare how 14 books explain infrastructure as code →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform. The section links point to the parts of the book it draws on.