Infrastructure as Code (IaC) is a combination of standards, practices, tools, and processes to provision, configure, and manage computer infrastructure using code and other machine-readable files.
For a long time, manual intervention was the only way of managing computer infrastructure. Servers had to be mounted on racks, operating systems had to installed, and networks had to be connected and configured. At the time, this wasn’t a problem as development cycles were so long-lived that infrastructure changes were infrequent.
Later, however, several technologies such as virtualization and the cloud, combined with the rise of DevOps and agile practices, shortened software development cycles dramatically. As a result, there was a demand for better infrastructure management techniques. Organizations could no longer afford to wait for hours or days for servers to be deployed.
Infrastructure as Code is one way of raising the standard of infrastructure management and time to deployment. By using a combination of tools, languages, protocols, and processes, IaC can safely create and configure infrastructure elements in seconds.
An organization using IaC experiences these benefits:
Infrastructure as Code can be explained from a high level in three simple steps and visualized with the diagram below.
There are four main types of IaC that developers can choose from:
To illustrate how IaC works by example, we’ll show you how to provision edge computing infrastructure on StackPath with the IaC tool Terraform. Terraform is an open source provisioning platform created by HashiCorp and supported by all major cloud providers including StackPath.
To get started with Terraform, download and install the Terraform command line. Then create a directory to store the infrastructure code.
mkdir my-workloadCreate a file with the provider configuration. (Terraform files have the .tf extension.)
provider.tf
provider "stackpath" {
client_id = "YOUR STACKPATH CLIENT ID"
client_secret = "YOUR STACKPATH CLIENT SECRET"
stack_id = "your-stackpath-stackid"
}
StackPath’s API keys can be found in the API Management section of the StackPath control panel.
The init action detects the provider and downloads any required plugins.
terraform init
Terraform uses a declarative configuration language known as HashiCorp Configuration Language (HCL):
resource "PROVIDER_TYPE" "RESOURCE_NAME" {
RESOURCE SPECIFICATION
}
For instance, the following code defines a container with an Nginx webserver:
# my-container.tf
resource "stackpath_compute_workload" "my-containers" {
name = "HTTP server"
slug = "ngnix-http"
network_interface {
network = "default"
}
labels = {
"role" = "webserver"
}
# container specification
container {
name = "app"
image = "nginx:latest"
resources {
requests = {
"cpu" = "1"
"memory" = "2Gi"
}
}
}
# where to deploy the containers
target {
name = "us"
min_replicas = 1
selector {
key = "cityCode"
operator = "in"
values = [ "JFK", "ATL", "LAX" ]
}
}
}
The workload’s main elements are:
Once the resource file is created, use the plan action to show what Terraform is about to do:
$ terraform plan
Terraform will perform the following actions:
# stackpath_compute_workload.my-workload will be created
+ resource "stackpath_compute_workload" "my-workload" {
+ annotations = (known after apply)
+ id = (known after apply)
+ labels = {
+ "role" = "web-server"
}
+ name = "ngnix-http"
+ slug = "ngnix-http"
. . .
Plan: 1 to add, 0 to change, 0 to destroy.
Use apply to create the containers:
$ terraform apply
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
stackpath_compute_workload.my-workload: Creating...
stackpath_compute_workload.my-workload: Creation complete after 1s [id=c52ea3b1-a9aa-4ff1-8d61-efaa58236cf0]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed
We can see that this was successfully applied by checking the “Instances” section of the StackPath control panel.
Terraform keep tracks of changes by storing the current state in the terraform.tfstate file.
Try modifying the target section in the container definition. For instance, change min_replicas from 1 to 2.
Terraform’s plan show what has changed:
. . .
~ min_replicas = 1 -> 2
. . .
After applying the new resource, you’ll find more instances of containers in your workload, or two containers per PoP:
The containers won’t be accessible from the Internet until a network policy resource is created.
Create a new file to define the network policy. The policy uses the instance_selector property to reference the containers with role = webserver.
# my-policy.tf
resource "stackpath_compute_network_policy" "http-policy" {
name = "Allow HTTP traffic to web servers"
slug = "allow-http"
description = "A network policy that allows HTTP access to instances with the web server role"
priority = 20000
instance_selector {
key = "role"
operator = "in"
values = ["webserver"]
}
policy_types = ["INGRESS"]
ingress {
action = "ALLOW"
description = "Allow port 80 traffic from all IPs"
protocol {
tcp {
destination_ports = [80]
}
}
from {
ip_block {
cidr = "0.0.0.0/0"
}
}
}
}
After applying the policy, the containers should be reachable using any of the public IPs.