emc world 2016 - code.02 introduction to immutable infrastructure

1© Copyright 2016 EMC Corporation. All rights reserved. 1© Copyright 2016 EMC Corporation. All rights reserved.

INTRODUCTION TO IMMUTABLE INFRASTRUCTUREJONAS ROSLAND, EMC {code}

4© Copyright 2016 EMC Corporation. All rights reserved.

• What are we trying to solve?• How is immutable infrastructure different?• Tools and processes• Demo• Questions

AGENDA


• Updating an application means:– Shutting it down– Taking a backup of the app and its settings– Upgrading using packages and scripts– Starting the app and verify functionality

• Costly and error-prone• Rolling back is hard and time-consuming

TRADITIONAL APPROACH FOR APPLICATIONS


• Updating an infrastructure part means:– Taking a backup of its settings– Shutting it down– Upgrading using packages and scripts– Starting the system and verify functionality

• Costly and error-prone• Rolling back is hard and time-consuming

TRADITIONAL APPROACH FOR INFRA


There must be a better way!


Let’s introduceImmutable Infrastructure


A strategy for managing services in which infrastructure is divided into

DATA and EVERYTHING ELSE


EVERYTHING ELSE is replacedat every deployment rather than being

updated in-place


• Use layers for your infrastructure and applications• Each layer needs to be versioned• Versioning enables verification/control and rollback• Smart tools enables automated code checks,

inventory management, deployments and rollbacks

SO HOW WOULD THIS WORK?


• Full control over every version that gets deployed• No more snowflake servers• No more “I wonder if this has the right Java version”

AVOID CONFIGURATION DRIFT


ScaleIO

CentOS

Python App

Ruby App Java App


ScaleIO 2.0

CentOS 6.5

Python App

v10.2

Ruby Appv2.3

Java Appv1.4


ScaleIO 2.0

CentOS 7

Python App

v10.2

Ruby Appv2.3

Java Appv1.4


ScaleIO 2.0

CentOS 7

Python App

v10.3

Ruby Appv2.4

Java Appv1.5


• Use standardized methods for packaging applications with their requirements– Containers– PaaS systems– Configuration management systems

• They are all being used in production environments world-wide, there’s no reason for you to not use them

LAYERS – APPLICATIONS


• You need something to run your app on• Handle the OS as a static binary• Got a new Windows/Linux update?

Update the template you’re using!• Create OS images for all your needs

– VM templates– Vagrant boxes– AWS AMIs– OpenStack images

LAYERS – OPERATING SYSTEM


• Tools like Puppet, Chef, Ansible etc are used to “bake” the OS images• Can be used to create immutable objects such as

container images with your applications• Not used to modify running systems

CONFIGURATION MGMT CAVEAT


• Firmware/software plus configuration• If you have to click somewhere to enable settings

that cannot be pushed onto it, the system isn’t ready• Most physical appliances are not built for this, yet• Use DHCP as much as possible for easy network

management

LAYERS – SOFTWARE-DEFINED INFRA


RackHD


• Always create new versions when you’re changing something• Otherwise you have nothing to roll back to• Only roll out versioned changes!• For real, don’t even think of adding that small little

change to a live system• Store all changes in a version control system!

VERSIONING


• Write the small change somewhere, creating a new version• Test it• If it passes, roll it out in the correct way depending

on the layer in question• If it fails, try again with another incremental small

change

VERSIONING, CONTINUED


• App A requires Java, doesn’t specify version• You bake a CentOS 6.5 OS with Java 1.7• Deploy the app, it fails• You create a new version, CentOS 7 with Java 1.8• Deploy the app, it works• Roll out CentOS 7 with Java 1.8

EXAMPLE OF VERSIONING AND TESTING


• App A is in a container• You bake a CentOS 7 OS with Docker• Deploy the containerized app, it works• You create a new version of the app• A new container is built• Deploy the container, it works

EXAMPLE OF CONTAINER BASED DEPLOYMENT


• Knowing what’s deployed at all times is critical when lowering deployment failure rates• No one likes to be stuck at work for an entire

weekend and then roll back on Sunday night because of unforeseen issues• Having version control lets you know exactly what’s

deployed

CONTROL


So what tools can youuse to accomplish this?


• Containers (Docker, Rkt, LXC)– Put an application and its requirements in a container, then

you can deploy it thousand fold with consistent result• PaaS systems (Cloud Foundry, Deis, Heroku)

– Takes your code and automatically adds the defined versions of requirements, then runs it for you

• Configuration management systems– Puppet, Chef, Ansible, Salt– Can be used to create container images (remember the

caveat)

TOOLS - APPLICATIONS


FROM python:2.7.11

RUN mkdir /app

WORKDIR /app

COPY * .

RUN pip install -r requirements.txt

EXPOSE 5000

CMD [ "python", "./simple.py" ]

EXAMPLE – PYTHON APP IN A CONTAINER


• “Baking” images is critical to make sure you don’t have configuration drift (Packer)• Configuration management systems

– There to make sure services and OS settings are correctly applied in the baked image

• Deployment (RackHD, Terraform, Vagrant)– Deploying an OS is now seen as standard fare, not

something just done once

TOOLS – OPERATING SYSTEM


EXAMPLE – BAKING WORKFLOW

ISO Packer

VMTemplate

AWSImage

OpenStack ImageConfig Puppet

Terraform

VMware

AWS

OpenStack

Version controlledVersion controlled

Version controlled

Version controlled

Version controlled

Version controlled Version controlledVersion controlled

Version controlled

Version controlled

Version controlled


resource "vsphere_virtual_machine" ”docker-host-12" { name = “docker-host-01“ domain = “corp.local“ datacenter = “DC-02" cluster = “Cluster-03" vcpu = 4 memory = 32768 disk { datastore = “XTREMIO-04" template = "templates/docker-1.10-centos-7.0-x86_64” iops = 10000 } gateway = “192.168.1.1" network_interface { label = “CORP-LAN" ip_address = “192.168.1.112" subnet_mask = “255.255.255.0" }}

EXAMPLE – DEPLOYMENT OF DOCKER 1.10


resource "vsphere_virtual_machine" ”docker-host-12" { name = “docker-host-01“ domain = “corp.local“ datacenter = “DC-02" cluster = “Cluster-03" vcpu = 4 memory = 32768 disk { datastore = “XTREMIO-04" template = "templates/docker-1.11-centos-7.0-x86_64” iops = 10000 } gateway = “192.168.1.1" network_interface { label = “CORP-LAN" ip_address = “192.168.1.112" subnet_mask = “255.255.255.0" }}

EXAMPLE – DEPLOYMENT OF DOCKER 1.11


• Deployment– RackHD, Puppet, Chef, Ansible– VMware Auto Deploy, Arista Zero Touch Provisioning

• Monitoring– Sensu, Prometheus, Zabbix, Nagios

• Logging– Logstash, Splunk, Fluentd

TOOLS – SOFTWARE-DEFINED INFRA


• Immutable infrastructure lets you version control your datacenter• Rollbacks are now really just new deployments• Enables you to create layers and use the best tools

for different purposes• Testable and reliable, no more snowflakes

SUMMARY


Before opening up for questions


• Hands-on lab with Docker, Mesos and REX-Ray• Free stickers at our booth• Join our community at community.emccode.com• See all our projects at emccode.com• And follow us on Twitter @EMCcode

CONTINUE THE DISCUSSION


Data Persistence in the New Container WorldWednesday 3PM

Joshua BernsteinVP of Technology for ETD

Tobi Knaup CEO & Co-Founder of Mesosphere

Guru Session


@EMCcode@jonasrosland

emccode.comcommunity.emccode.com

Come visit us at Booth #1044 or in the vLab

Questions?