Download pdf - CNA2563BU Navigating the Container Ecosystem or distribution · 2019-06-27 · • Not only is the container ecosystem changing, Docker itself is rapidly evolving – Container runtime

Scott LoweEngineering Architect, VMware, Inc.

CNA2563BU

#VMworld #CNA2563BU

Navigating the Container Ecosystem

VMworld 2017 Content: Not fo

r publication or distri

bution

Scott LoweEngineering Architect, VMware, Inc.

CNA2563BU

#VMworld #CNA2563BU

Containers and Stuff



bution

• This presentation may contain product features that are currently under development.

• This overview of new technology represents no commitment from VMware to deliver these features in any generally available product.

• Features are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind.

• Technical feasibility and market demand will affect final delivery.

• Pricing and packaging for any new technologies or features discussed or presented have not been determined.

Disclaimer

#CNA2563BU CONFIDENTIAL 3



bution

Why Are You in this Session Anyway?

4

“…. trying to make vIC [vSphere Integrated Containers] and OpenStack work together in Nova as a first-

class citizen hypervisor and with the Magnum project to provision Kubernetes clusters directly from

OpenStack using vIC as the Docker backend…”

Me [WTF?]: “What's the use case? What pain point does this "stack" solve?”

“Well there is a bit of "because I can" I will not lie to you. I love OpenStack, and since Docker is "the new

great thing that will save IT" playing with both looked like an interesting science project ;)”

#CNA2563BU CONFIDENTIAL



bution

An Agenda We’ll Try to Follow

5#CNA2563BU CONFIDENTIAL



bution

How We Used to Buy




bution

How We Buy Today




bution

What We Buy Today

Farmers buy this because of this

People buy this because of this




bution

How Is That Possible? Why Is That?

“Software is eating the world”

(aka: the value is in the software)

(And it’s giving people and organizations an edge!)




bution

What Does All This Have to Do with Cloud Native Apps & DevOps?

If software gives you an edge….

…then the time from “business/developer idea” to when it hits the user should tend to zero.

In other words:

Time(user enjoying experience) – Time(developer idea of said experience) 0




bution

How Software Value Gets Created (in the Old Model)

Monolithic application

“Time to user”: months / years

Very heavy manual

integrations




bution

How Software Value Gets Created (in the New Model)

“Time to user”: hours / days

Small independent

components…

End-to-end (hands off) automation

…. with different

release cycles




bution





bution


Templates / Blueprints

Production

Enterprise “Cloud”

HA / Placement / Optimization / Monitoring / Scheduling / App Life Cycle etc.

Application

Code

“Magic”

(i.e. manual

integration)




bution



Production

Enterprise “Cloud”

HA / Placement / Optimization / Monitoring / Scheduling / App Life Cycle etc.

Application

Code

“Magic”

(i.e. manual

integration)

This is where the <beep> hits

the fan




bution


Production

“Infrastructure as code”

Development Staging

+Application

Code

HA / Placement / Optimization / Monitoring / Scheduling / App Life Cycleetc.

PublicClouds

PrivateCloud

Dev


Ops




bution


Production

“Infrastructure as code”

Development Staging

+Application

Code

HA / Placement / Optimization / Monitoring / Scheduling / App Life Cycleetc.

PublicClouds

PrivateCloud

Dev


Ops

Continuous

Integration Continuous

Delivery

Continuous

Deployment




bution

If You Are Feeling Stupid and/or Behind, Please Don’t




bution





bution

Infrastructure Capacity

Data and State

Typical “Pet” Application Pattern




bution

Instance State Data

Implementation of Typical “Pet” Applications




bution

Stateless

Ephemeral

Transient

Poorly Reliable

Stateful

Persistent

Available

Durable

Resilient

Typical Cloud-native (“Cattle”) Application Pattern

Infrastructure Capacity

Data and State




bution

SQLObject

Store

NO

SQL

Infrastructure

State

These consume these

Implementation of Typical Cloud-native (“Cattle”) Applications




bution

SQLObject

Store

NO

SQL

Infrastructure

State

These consume these





bution

SQLObject

Store

NO

SQL

Infrastructure

State

In public clouds this domain is often consumed by users and provided as a managed service by the CSP (e.g. S3,

RDS/Aurora, DynamoDB, etc)

Debating how this domain is implemented on-premises is out of

scope for this presentation





bution





bution

Basics of Containers (Too Basic?)

Hardware Hardware

Hypervisor

App

OS

OS

App AppOS

App App

container container

container container

VM

VM

The focus of this session isn’t“containers in VMs” versus “containers on bare metal”

Hardware

App

OS




bution

But We Do Need to Talk (Briefly) about VMs versus Bare Metal

• Containers/Docker are pivoting towards optimizing application life cycle

– “Docker is Microsoft Installer (aka MSI) without DLL hell” (Massimo Re Ferrè)

• Hypervisors master infrastructure optimization

• Some people see these two things as “and” (complementary)

• Some folks see them as “or” (mutually exclusive)




bution

Docker != Containers

Docker Engine

Container

Registry

$ docker build...

$ docker push...

$ docker pull...

$ docker run...

Docker (Engine) provides

application life cycle capabilities

Containers provide a mechanism to instantiate the code (shipped as a Dockerimage)

Container is just a collection of kernel functions (cgroups, namespaces, etc.)




bution


rkt

Container

Image

store

$ rkt fetch...

$ rkt run...

$ rkt list...

$ rkt run...




bution


systemd

Container

Filesystem

image

$ systemd-nspawn...

$ machinectl...

$ systemctl...

$ systemd-nspawn...




bution


LXD

Container

Image

remote

$ lxc image...

$ lxc launch...

$ lxc list...

$ lxc stop...




bution

Dockerfile (the Magic of Docker)

FROM alpine:3.2

MAINTAINER Massimo Re Ferrè [email protected]

#created from sample: https://blog.codeship.com/build-minimal-docker-container-ruby-apps/

RUN apk update && apk upgrade && apk add curl wget bash

RUN rm -rf /var/cache/apk/*

RUN wget https://github.com/vmware/govmomi/releases/download/v0.6.0/govc_linux_amd64.gz

RUN gzip -d govc_linux_amd64.gz

RUN chmod +x govc_linux_amd64

RUN mv govc_linux_amd64 /usr/local/bin/govc

COPY vicinstallershell.sh /

RUN chmod +x /vicinstallershell.sh

CMD source '/vicinstallershell.sh';'bash'




bution

mailto:[email protected]

https://blog.codeship.com/build-minimal-docker-container-ruby-apps/

https://github.com/vmware/govmomi/releases/download/v0.6.0/govc_linux_amd64.gz

SQLObject

Store

NO

SQL

Infrastructure

State

These consume these


The Dockerfile is usually checked in into source control (Git or

Github)#CNA2563BU CONFIDENTIAL 34



bution

Why Are Containers (& Docker, Specifically) Gaining Momentum?

• Fast to start (sub-second)

• Lean/small self-contained environments

• DevOps-oriented self-service authoring (e.g. Dockerfile)

• Ease of sharing (public/private registries)

• Infrastructure agnostic (move transparently from laptop to on-premises topublic cloud)

• 1 container = 1 process (ideal to de-construct the monolith)


These characteristics are a great fit for a) cloud-native apps, and b) DevOps



bution

However, this is a really fast-moving space…




bution

Moving Away from “Monolithic” Docker

• Not only is the container ecosystem changing, Docker itself is rapidly evolving

– Container runtime (runC) spun out in 2015 as part of Open Container Initiative (OCI)

– Container daemon (containerd) spun out in 2017, picked up by CNCF

• Docker open source project renamed to Moby

– Docker CE (Community Edition) and Docker EE (Enterprise Edition) are now “downstream” projects of Moby




bution

But Wait, there’s More…

• New standards are emerging (OCI image spec and OCI runtime spec both recently released 1.0)

• Alternative container runtimes are emerging

– rkt, originally introduced by CoreOS

– Railcar (OCI-compliant runtime) recently released by Oracle

• Distinction between VMs and containers is blurring

– runV (OCI-compliant hypervisor-based container runtime)

– Intel Clear Containers

– Support for Hyper-V isolation in Docker (using --isolation hyper-v flag)




bution

Hypervisor Isolation for Containers

• Is it a container, or is it a VM? Both!

• Numerous examples emerging:

– rkt has a KVM-based Stage1 image that leverages KVM when launching a container

– runV supports the use of KVM, Xen, and VirtualBox for enhanced isolation of OCI-compliant containers

– HyperContainer is a Docker-specific implementation of runV

– Support for Hyper-V isolation for Docker containers on Windows (via the --isolation hyper-v flag)

– vSphere Integrated Containers (VIC) Engine leverages vSphere isolation for containers

– Intel Clear Containers brings Intel VT support for Linux containers

– The “virtcontainers” project aims to build a common Go library for adding hypervisor isolation to container runtimes (unifying Clear Containers, runV, rkt’s KVM Stage1, for example)

• The distinction between container and VM is becoming less and less clear




bution

Speaking of VIC…

• VIC Engine IS NOT ABOUT “Should I run Docker Hosts on VMs or on bare metal?”

– This is totally another discussion (orthogonal to VIC Engine)

• VIC Engine IS NOT ABOUT “VMs are better than containers!”

– As evidenced by all the projects, the rest of the industry clearly recognizes the value of hypervisor isolation for containers

• VIC Engine IS ABOUT “What’s the provisioned element of docker run?”




bution

Docker != Containers (simplified view)

Docker Engine

Container

Registry

$ docker build...

$ docker push...

$ docker pull...

$ docker run...

Unikernel VM




bution





bution

What Do Container Management Solutions (Attempt to) Do?

43https://twitter.com/mfdii/status/697532387240996864




bution

A Picture of the Container Management Industry Landscape

44

Docker Engine




bution

Some (but not All of the) Random Names You May Have Heard

• VMware Admiral

• Kubernetes

• Mesos/Marathon

• Docker Enterprise Edition (EE)

• Rancher

• AWS ECS (EC2 Container Service)

• Google Container Engine (GKE)

• Microsoft Azure Container Service

Software users can deploy on-premises or off-premises (managed by the users)

Proprietary solution delivered as a service (partially managed by AWS)

Kubernetes delivered as a service (managed by Google)

Automated Mesosphere/Swarm deployment (managed by the users)




bution

Peak of Confusion? What Confusion?

https://twitter.com/joyent/status/697549725319483392




bution

These Tools Are also Evolving Quickly

• Take Kubernetes, for example

• CRI (Container Runtime Interface) aims to “decouple” Kubernetes from Docker and rkt

– CRI-O (CRI plugin for OCI-compliant runtimes, like runC)

– rktlet (CRI plugin for rkt)

– Docker CRI shim (CRI plugin for Docker)

– Frakti (CRI plugin for HyperContainer)

• KubeVirt project aims to allow Kubernetes to manage VMs




bution

Container Management Complexity just Got Squared

As if “x is better than y” was not enough…

…welcome to the saga of “You can run y on top of x”




bution

Swarm on Mesos




bution

Kubernetes on Mesos




bution

Marathon on Swarm




bution

This Is the Gold Rush




bution





bution

In Conclusion…

• In the last 60 minutes we just scratched the surface

– Skipping lots of stuff and details

• Yes it is complicated (and messy)

– But it’s also an opportunity to innovate within your organization

– Be that champion!

• Our job (at VMware) is to try to make all this as easy as possible

– Your job is to break out of your comfort zone

• Don’t panic…this is a marathon, not a sprint

– That being said, you should start sooner rather than later!




bution



bution



bution