Terminology

• Infrastructure as code (IaC) - Approach which treats infrastructure similarly to code and supports version control, can be easily reproducible, reviewed, reused etc [1].
• Indempotency - Is a characteristic of an operation which guarantees, that repeating the same action over again has the same effect [2].
• Agent / Agent-less solution - Difference between these two is that the approach with agents requires some sort of related software to be installed on managed nodes.
• Declarative / Procedural - Procedural approach specifies the steps on how to reach the desired state. Declarative approach only specifies the desired state and it is up to the framework how it gets to the state.

Existing solutions:

CoreOS

It is a automatically updating, minimal, monolithic, container-focused operating system. System's configuration is stored in Ignition file and the system is configured only once during the first boot. After the boot user can modify only files in /etc and /var directories. Applications can be run in containers e.g. docker.

CoreOS is a successor of Fedora Atomic Host.

Ansible

Platform consists of:

• Control node - Ansible installed here and contains configuration files.
• Managed node - Remote system

Ansible is a agent-less solution, which means that no ansible specific software needs to be installed on managed nodes. Access to the nodes is solved using ssh, therefore ssh key must be established on the managed node. Ansible Inventory contains list of managed nodes, usually list of IPs.

Configuration unit structure

Top level configuration unit is Playbook, collection of plays. Play is a grouping of tasks to achieve a particular goal. Task is an action applied to the managed host.

Puppet

Another tool which for configuration management which, unlike Ansible, uses agents on managed nodes. The Puppet platform consists of these parts [6]:

• Server - Server contains infrastructure in Puppet code DSL and controls configuration for managed agent nodes.
• Agent - Agent reports state of a host to the server request configuration and applies changes to the state of the host.
• Database (optional) - DB contains all the data generated by Puppet, which can be further used e.g. in infrastructure discovery, compliance reporting, vulnerability assessment etc.

Chef

The platform consists of:

• Chef Infra Client - Client runs on systems managed by Chef Infra.
• Chef Infra Server - Server contains configuration data and metadata about clients.
• Chef Workstation - It is a developer interface to communicate with Chef Infra. It comes with handy tool for testing like Chef InSpec, Test Kitchen.

Terraform

A tool for defining cloud infrastructure using declarative approach. Users specifies resources or a state they need and Terraform creates and executes a plan to provision the resources.

It is used in cloud environment to define an infrastructure. Compatibility with a cloud platform is guaranteed by Terraform component called provider. Each provider is tailored for a particular platform, e.g AWS, GCP provider, etc.

Infrastructure is described in *.tf configuration files using Terraform domain specific language (DSL). Since configuration might change, Terraform needs to store mapping between managed infrastructure and configuration. For this purpose, there exists a Terraform state which maps resources defined in configuration files to real world objects, e.g. resource "aws_instance" "foo" is mapped to the instance with id abcd1234 [4].

Terraform example

To use Terraform you need:

• Account at one of the cloud providers (Google, GCP, Azure, ...).
• Terraform provider for given cloud (all major cloud providers have one).

After you satisfied prerequisites, initiate the Terraform directory and repeat the following stages until you obtain desired infrastructure:

1. Write - Define resources you need.
2. Plan - Create execution plan to create, update, delete resources.
3. Apply - After reviewing the play you confirm the changes.

Sample *.tf file:

provider "aws" {
  region = "us-east-1"
}

resource "aws_lambda_function" "test_lambda" {
  # If the file is not in the current working directory you will need to include a
  # path.module in the filename.
  filename      = "lambda_function_payload.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"

  runtime = "nodejs16.x"

  environment {
    variables = {
      foo = "bar"
    }
  }
}

Example source.

When creating resources Terraform can figure out the correct order, e.g. before creating aws_lambda_function, the aws_iam_role must be created. It works the similar way when deleting resources. In other words, Terraform manages resource dependecies itself.

Next steps

Course at faculty: PV282 Designing and building infrastructure in public cloud

References

[1] Puppet - Infrastructure-as-code

[2] Puppet - Indempotency

[3] CoreOS

[4] Ansible

[5] Puppet

[6] Puppet components

[7] Chef

[8] Terraform

[4] Terraform - state