Infrastructure as Code

What, Where, How, Why and we do it

Michael Schmid (he/him)

@Schnitzel

CTO amazee.io

What?

What?

  • Server, Infrastructure Configuration in Code
  • Scripts implement (provision) your configurations

basically:

Where?

Where?

Infrastructure

VMs / OS

Services

Application

VMs, Loadbalancers, Networking, Firewall, etc

OS configuration, SSH Keys, Tools, Monitoring, Services

Configs of Nginx, PHP, Varnish, etc. 

Performance Settings, Security Configs, Domains, etc

How?

How?

  • Configuration Management Tooling like
    • Ansible, Puppet, Chef, Pulumi, Otter, SaltStack, CF Engine, Terraform, DSC, Docker
  • Git repository for storage
  • Push vs. Pull
  • Declarative vs. Imperative
  • Updatable vs. Non-Updatable

Updatable

  • Most cfg mgmt tools
  • Allows to update an already provisioned System
  • More complex to test, can sometimes lead to weird cases

Non-Updatable

  • Docker (Containers in general)
  • Always provision from scratch
  • No way to update an existing container
  • Create a new container and replace it
  • After Build done: much faster provisioned¬†

Why?

Why?

  • Recreatability
    • Super easy scaling
    • Broken? Just create again
  • Self documenting
    • Everybody can see what is installed

Why?

  • Change Management
    • Merge Requests for Review
    • Git blame for historical data
  • Automated Testing
    • Create complete separate stack for a test
    • Makes sure no changes on production have been missed

Containers

What?

  • Containers bring IoC to Application Level
  • Forces Developers to put everything into Git
  • Dislike at beginning
  • Understand benefits over time

IaC at amazee.io

Infrastructure

VMs / OS

Platform (Lagoon)

Application

Services

  • Puppet and Ansible
  • Weekly
  • No automated testing yet
  • Development Environments
  • Manual changes and then copied to Ansible

Infrastructure

VMs / OS

Platform (Lagoon)

Application

Services

  • OpenShift & Docker
  • Weekly
  • Open Source!
  • Separate OpenShift for Testing Lagoon and Base Images

Infrastructure

VMs / OS

Platform (Lagoon)

Application

Services

  • Docker
  • Developers
  • Lagoon Base Images
  • Same Images everywhere
  • Any adaptions possible
  • No changes in running containers¬†

Infrastructure

VMs / OS

Platform (Lagoon)

Application

Services

Pro

Con

Con

It takes time!

  • Configuration
    • 1 min for the fix
    • 2 hour to add to cfg mgmt
  • Testing
    • Lagoon: 1-2h for full test
    • Allow to run partial tests
  • Rollouts
    • easily 20min Ansible Run

Con

  • Needs additional knowledge
    • don't mix too many tools
  • Discipline needed :)

Pro

  • Super easy scaling
  • Less errors
  • Faster Rollouts
  • Higher Security
  • Self Documentation

and most important:

Made with Slides.com