Infrastructure as code (IaC) uses DevOps methodology and versioning with a descriptive model to define and deploy infrastructure, such as networks, virtual machines, load balancers, and connection topologies. Just as the same source code always generates the same binary, an IaC model generates the same environment every time it deploys.
There are many tools available for managing your infrastructure using declarative definition files such as:
- Repeatable proven process - we will always get the same output
- Automation - we can apply/deploy IaC using Ci/CD pipelines
- Alterations can be made in separate branches, allowing peers to review any changes using Pull Requests, before merging to the main branch and applying to production
- Abstractions - Most tools have their own definition structure to define IaC, allowing DevOps to work on both AWS and Azure resources without knowing the exact API's/CLI tools for these cloud providers. (partially true)
We'll discuss terraform in this meeting as we also use this for the Ivenza platfom deployment in Azure.
Create resource group Create storage account (unique name) Create container within the storage account
Setup of Terraform easy, it's available on all platforms. You could either download the binary, or install using the package manager for your OS (Homebrew, APT, Chocolatey, DNF, etc).
Personally, I run this in a container/toolbox, so my Host OS doesn't know anything about Terraform, keeping my OS nice and clean.
Make sure, when using the azurerm resources, you also have the azure cli installed, logged in and set to the proper storage account. Terraform will translate your files to Azure API calls using the azure cli tooling.
az login
az account set --subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
terraform init
terraform validate
terraform plan
terraform fmt
terraform apply
terraform output
terraform destroy
01 - create resource, creates a resource to the
Highlight why state files should not be locally stored or kept in a version control system.
Remote state / state file / definition files...they should be aligned.
- Create a tag in the portal to the resource...terraform will remove it.
- For loops
- Validation
- Complex types
Tell about modules, and how they can be re-used.
- Tell how to re-use outputs
- Sensitive outputs
During our development life cycle, we often encounter the following environments:
- Development
- Staging
- Production
Ideally, we want to work and tweak each environment separately from each other. There are 2 ways we can do this:
- Terraform workspaces
- Different working directories
When using terraform workspaces, you'll have to create workspaces from the CLI tooling:
terraform workspace new example
Created and switched to workspace "example"!
You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.
As pointed out by the Terraform docs, alternate methods for working with different environments are preferred (re-useable modules with own state files).
Biggest downsides:
- No visual indication which workspace you're working in.
- Workspaces are a local thing, and not shared across development machines
- Workspaces work well when using conditional statements
resource "aws_instance" "example" { count = "${terraform.workspace == "default" ? 5 : 1}" # ... other arguments }
I'd rather work with separate environment directories:
- Shared across development machines because these are actual files in your version control system (Git).
- You can't forget to switch switch away from an environment you had left open,
because you have to
cd
to your environment. There is always a visual indicator on your terminal prompt, indicating which environment you're working in. - Each environment has it's own state file, meaning you can work on various environments simultaneously. I would refer to this as horizontal scaling.
- No fuzzy conditional statements in the lower modules, being dependent on workspaces from upper levels.
Development | Staging | Production |
---|---|---|
Deployment | Deployment | Deployment |
Why is it needed? Additional benefits
- Scoped layers
- Smaller state files
- Allows for teams to concurrently work on IaC
- Vertical and horizontal scaling for development
Development | Staging | Production |
---|---|---|
Network | Network | Network |
Kubernetes | Kubernetes | Kubernetes |
Databases | Databases | Databases |
Application | Application | Application |