Containerization: The DevOps Revolution

Why do we need containers?

Shipping Containers• Standardized dimensions• Mechanized handling system• Remote sorting and packing• Remote customs services• Greatly decreases cost and

speed of international trade

Software Container is like a VM• Own Process Space• Can run commands• Packages can be installed• Can run services/daemons• Isolated root privileges• Shell access

Software Container is not like a VM• Uses host kernel• Restricted to host OS• Can’t have it’s own kernel modules• Is plain user-space process

VM vs Container

Containers Chronology• 1982 - chroot• 2000 - FreeBSD Jail• 2001 – Linux VServer• 2004 – Solaris Containers• 2007 – HP-UX Containers• 2008 – LXC (Linux Containers)• 2013 - Docker

Linux cgroups (control groups)• Resource limiting• Prioritization• Accounting• Control

• Used by• LXC• libvirt• systemd• Docker• Kubernetes• Mesos

Linux namespaces• Isolate and virtualize resources• Every process (group) has its own

view of the system• 6 kinds of namespaces:

• mnt – mount points• pid – process IDs• net – network stack• ipc – POSIX mq filesystem• uts - hostname• user – users and groups

• Resource Metering and Limiting• CPU and CPUSet• Memory• Network• Block I/O• /dev/*

cgroups (control groups):

• Provides containers with their own view of the system

• Limits what you can see (and use)• Multiple namespaces: pid, net, mnt,

uts, ipc, user

Namespace:

• Create new container instantly instead of copying whole system

• Storage keeps tracking of what has change (AUFS, ZFS, etc)

• Reduces footprint and overhead• Decreases boot time

Copy-on-write storage:

• LXC• systemd-nspawn• Docker Engine• rkt/runC• OpenVZ• Jails (FreeBSD), Zones (Solaris)

Container Runtimes:

• Uses the same kernel features => Performance will be the same

• What matters is:DesignFeaturesEcosystem (e.g. 100.000+ apps in Docker

Hub)Support

What’s the difference between them?

The Story of Success

Problem & Opportunity• Rapid innovation in computing and application

development services

• No single service is optimal for all solutions

• Customers want to run multiple services in a single cluster and run multiple clusters in Intercloud environment

...to maximize utilization ...to share data between services

Datacenter and solution todayVM7 VM8

VM4 VM5 VM6

VM1 VM2 VM3

VM1 VM2 VM2

Visualization Service

Data Ingestion Service

Analytics Service

• Configuration and management

of 3 separate clusters

• Resources stay idle if service

is not active

• Need to move data between

clusters for each service

What do we want to do?

Data Ingestion Service

Analytics Service

Visualization Service

….to maximize utilization...to share data between services

Shared clusterMultiple clusters

Shared Cluster

AWS

VM1 VM2 VM3 VM4 VM5

What is in it for customers?

Maximize utilizationDeliver more services with smaller footprint

Shared clusters for all servicesEasier deployment and management with unified service platform

Shared data between servicesFaster and more competitive services and solutions

How does this work?

Mesos Slave

Spark Task Executor Mesos Executor

Mesos Slave

Docker Executor Docker Executor

Mesos Master

Task #1 Task #2 ./python XYZ java -jar XYZ.jar ./xyz

Mesos Master Mesos Master

Spark Service Scheduler Marathon Service Scheduler Zookeeper quorum

How does this work? Mesos provides fine grained resource isolation

Mesos Slave Process

Spark Task Executor Mesos Executor

Task #1 Task #2 ./python XYZ

Compute Node

ExecutorContainer(cgroups)

How does this work? Mesos provides scalability

Mesos Slave Process

Spark Task Executor

Task #1 Task #2 ./ruby XYZ

Compute Node

Python executor finished,more available resourcesmore Spark

Container(cgroups)

Task #3 Task #4

How does this work? Mesos has no single point of failure

Mesos MasterMesos MasterMesos Master

VM1 VM2 VM3 VM4 VM5

Services keep running if VM fails!

How does this work? Master node can failover

Mesos MasterMesos MasterMesos Master

VM1 VM2 VM3 VM4 VM5

Services keep running if Mesos Master fails!

How does this work? Slave process can failover

Tasks keep running if Mesos Slave Process fails!

Mesos Slave Process

Spark Task Executor

Task #1 Task #2 ./ruby XYZ

Compute Node

Task #3 Task #4

How does this work? Can deploy in many environments Get orchestrated by Openstack, Ansible (scripts), Cloudbreak

True Hybrid Cloud deployment: AWS, CIS, UCS, vSphere, other

AWS

VM5VM1 VM2 VM3 VM4

Terraform

REST API(policy, auto-scaling)

REST API(direct provisioning)

Scripted provisioning

Containers: Service Product

Cloud/VirtualizationAWS/CIS/vSphere/Metacloud/UCS…

Provisioning Terraform Automation Ansible Clustering & Resource Management Mesos, Marathon, Docker Load Balancing Avi Networks ETL & Data Shaping StreamSets Log Data Gathering Logstash Metrics Gathering CollectD, Avi Networks Messaging Kafka, Solace Data Storing (Batch) HDFS Data Storing (OLTP/Real-time) Cassandra Data Storing (Indexing) Elastic search Data Processing Apache Spark Visualization Zoomdata*Subset example

Issues• Service Discovering• Networking for Containers• Persistent Storage• Docker Performance

More Details

https://mantl.io