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
INFRASTRUCTURE
JONAS 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 introduce
Immutable Infrastructure

A strategy for managing services in
which infrastructure is divided into
DATA and EVERYTHING ELSE

EVERYTHING ELSE is replaced
at 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
App
v2.3
Java App
v1.4

ScaleIO 2.0
CentOS 7
Python
App
v10.2
Ruby
App
v2.3
Java App
v1.4

ScaleIO 2.0
CentOS 7
Python
App
v10.3
Ruby
App
v2.4
Java App
v1.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 you
use 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
VM
Template
AWS
Image
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 World
Wednesday 3PM
Joshua Bernstein
VP of Technology for ETD
Tobi Knaup
CEO & Co-Founder of Mesosphere
Guru Session

@EMCcode
@jonasrosland
emccode.com
community.emccode.com
Come visit us at
Booth #1044
or in the vLab
Questions?

EMC World 2016 - code.02 Introduction to Immutable Infrastructure

EMC World 2016 - code.02 Introduction to Immutable Infrastructure

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a EMC World 2016 - code.02 Introduction to Immutable Infrastructure

Semelhante a EMC World 2016 - code.02 Introduction to Immutable Infrastructure (20)

Mais de {code}

Mais de {code} (8)

Último

Último (20)

EMC World 2016 - code.02 Introduction to Immutable Infrastructure

Notas do Editor