📋 Agenda

🤔 What is Configuration as Code?

• ✅ Reproducible — same result every time
• ✅ Versionable — Git history, pull requests, rollbacks
• ✅ Auditable — who changed what, and when
• ✅ Scalable — apply to 1 or 10 000 servers identically
• ✅ Collaborative — code review, CI/CD pipelines

🌍 The IaC Landscape

Three main problem spaces:

🐾 Puppet Configuration Management

• Born: 2005 — one of the oldest IaC tools
• Language: Puppet DSL (Ruby-based) or YAML (Hiera)
• Model: Pull — agents poll a central Puppet Server every 30 min
• Approach: Declarative — you describe the desired state
• Agent required: Yes (puppet-agent on each node)

🐾 Puppet — Example

# manifests/webserver.pp
class webserver {
  package { 'nginx':
    ensure => installed,
  }

  file { '/etc/nginx/nginx.conf':
    ensure  => file,
    content => template('webserver/nginx.conf.erb'),
    notify  => Service['nginx'],
  }

  service { 'nginx':
    ensure  => running,
    enable  => true,
  }
}
    

🔁 Run again → idempotent: only changes what diverged from the desired state

⚡ Ansible Automation & Orchestration

• Born: 2012, acquired by Red Hat in 2015
• Language: YAML (Playbooks)
• Model: Push — the control node connects via SSH
• Approach: Procedural (tasks run in order) with idempotent modules
• Agent required: No — agentless, just Python + SSH

⚡ Ansible — Example

# playbook/webserver.yml
- name: Configure web server
  hosts: webservers
  become: true

  tasks:
    - name: Install nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Copy nginx config
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx

    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted
    

🏗️ Terraform Infrastructure Provisioning

• Born: 2014 by HashiCorp (open-source fork: OpenTofu)
• Language: HCL (HashiCorp Configuration Language)
• Model: Plan → Apply — preview changes before applying
• Approach: Declarative — describe your infrastructure graph
• Agent required: No — uses provider APIs (AWS, GCP, Azure, etc.)

🏗️ Terraform — Example

# main.tf
terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" { region = "eu-west-3" }

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = { Name = "meetup-webserver" }
}

output "public_ip" {
  value = aws_instance.web.public_ip
}
    

🗺️ terraform plan shows a diff · terraform apply creates resources · terraform destroy removes them

📊 Comparison at a Glance

🎯 When to Use What?

🤝 They Work Together!

A common real-world stack:

1. Terraform provisions the VM on AWS/Azure/GCP
2. Ansible bootstraps the OS, installs base packages, deploys the app
3. Puppet continuously enforces compliance and manages config drift

→ Right tool for the right layer of the stack

💡 Key Takeaways

• Configuration as Code → reproducible, auditable, scalable infrastructure
• Puppet — continuous compliance on large server fleets (pull, agent)
• Ansible — agentless automation & orchestration (push, YAML)
• Terraform — cloud infrastructure provisioning (plan/apply, HCL)
• They complement each other — choose based on the layer of your stack