Automation of server management

Tomáš Biloš,


Existing solutions:


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.


Platform consists of:

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.


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


The platform consists of:


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:

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 = "" 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


[1] Puppet - Infrastructure-as-code

[2] Puppet - Indempotency

[3] CoreOS

[4] Ansible

[5] Puppet

[6] Puppet components

[7] Chef

[8] Terraform

[4] Terraform - state