Slide deck for OpenStack Austin Summit vBrownBag TechTalk

1. Anthony Chow
Twitter: @vCloudernBeer
Blog: http://cloudn1n3.blogspot.com/
April 25, 2016
OpenStack Austin Summit vBrownBag TechTalk

3.  Blog posts
 Books
 Ecosystem announcements
 Webinar
 Conferences
 Local Meetups
 Your boss wants to deploy container related
technologies.
 You want to get into this technology for more
$$$$ or a “better” job.

8.  FreeBSD Jails (back in 2000)
 Imctfy (Google’s version of container)
 LXC (technology that Docker build upon)
 Docker: “Build Ship Run”

9.  Namespaces
 Current view of PID, network, IPC, MNT and UTS
 Linux namespaces provides isolations for each container. Applications
or process inside a container do not have access outside of the
namespaces that the container is in.
 Control groups/cgroups
 Kernel function used to control access rights.
 While namespaces provides access isolation, the control groups limits
the hardware resources that the container can access. One example of
control groups is to limit the memory available for the container for say
256 MBs.
 AUFS
 This is how containers are made to be light weighted. Linux kernel first
mounts the root system read-only and then change to read-write. With
the union mount, instead of changing from read-only to read-write, a
read-write file system is layered on top of the read-only based
Filesystem. Union mean to layer read-write with read-only layers.

10.  Docker Client
 Accept commands from the user and communicate with the server/daemon
 Docker Server/Daemon
 Building the Docker container from the images that are stored in the Docker Registry
 Docker container
 Base unit where the application runs on
 Similar to a Virtual Machine
 Default base moving from Ubuntu to Alpine for smaller footprint
 Dockerfile
 a configuration file with build instructions for Docker images
 Docker image
 Building block of container
 Docker Registry
 Location where the Docker images are stored
 Public registry – access by everyone
 Private registry – access by specific team or organization.

11.  Docker Hub
 Quay Container Registry
 Amazon Container Registry
 Google Container Registry

12.  Container image format
 Docker – appC
 CoreOS – Rocker (rkt)

13.  CoreOS
 RacherOS
 Ubuntu Snappy
 Red Hat Atomic
 VMware photon
 Microsoft Nano Server

14.  Open Container Initiative
 OCI Runtime Specification
 OCI Image Format Specification

15.  Microservices
 Container runs in groups and on distributed hosts
as service
 Containers “come and go”
 Not practical to hardcode port number.
 Distributed key-value store
 Common tool for service discovery
 Zookeeper
 Etcd
 Consul

16.  Containers needs network traffic isolation for
multi-tenants
 Number of addressable end-point drastically
increases
 Immutable infrastructure – container is created
and destroyed on different hosts constantly
 Networking solutions for containers
 Libnetwork (since rev 1.9)
 Weave
 Flannel (CoreOS)
 IPvlan

17.  A new security requirements created by
container based infrastructure.
 Docker container used to run as “root”
 Common form of security solutions for
containers:
 Discretionary Access Control (DAS)
 Seccomp
 SELinux (Mandatory Access Control – MAC)
 Microsegmentation solution from VMware
and Cisco

18.  Stateless container
 Stateful container
 Persistent Storage
 Default: data reside inside the container
 Docker Volume Driver (rev 1.8)
 Convoy: a Docker storage driver
 Flocker: container data volume manager

19.  “To deploy container is one thing, architect
a container solution is not so simple?
 Common container orchestration tools:
 Docker Swarm
 Kubernetes
 Apache Mesos
 Redhat Atomic
 CoreOS Fleet

20.  Provides an Docker container orchestration
platform using OpenStack as a infrastructure
 Key concept: Container Orchestration Engine
 Docker Swarm
 Kubernetes
 Apache Mesos
 Able to interface with Docker client and
Kubernetes client

21.  “provides production-ready containers and
deployment tools for operating OpenStack
clouds that are scalable, fast, reliable, and
upgradable using community best
practices.” – OpenStack Wiki
 running OpenStack service as a container

22.  “bring containers and Docker networking
specifically to use and leverage solutions
and services in Neutron” –
superuser.openstack.org
 Kuryr is Czech for "courier."

23.  “a distributed control plane implementation of Neutron” –
superuser.openstack.org
 Dragonflow is going to support use cases of nested
containers inside a VM without the need to introduce
another layer of overlay abstraction. We are going to
support various different modes to deploy this and have
full integration with project Kuryr.

24.  Container technology is here to stay along
with virtual machines
 More and more OpenStack project is
embracing this container technology to
solve different problems.
 We need to stay relevant and keep up with
the container technology.
 Get a clearer picture of the container
landscape.

25. Have a joyful and fruitful conference
@vCloudernBeer