Container Orchestration

Running containers on a single node is fine, but, in production, we need to run containers at scale. That is when we can see the real benefits of containers. To run containers in a multi-host environment at scale, we need to find solutions to numerous problems, which are summarized below:

Who can bring multiple hosts together and make them part of a cluster ?

Who will schedule the containers to run on specific hosts ?

How can containers running on one host reach out to containers running on different

hosts ?

Who will make sure that the container has the dependent storage, when it is

scheduled on a specific host ?

Who will make sure that containers are accessible over a service name, so that we

do not have to bother about container accessibility over IP addresses?

Container orchestration tools, along with different plugins (like networking and storage), help us address the problems mentioned above.

Container orchestration is an umbrella term which encompasses container scheduling and cluster management. Container scheduling allows us to decide on which host a container or a group of containers should be deployed. With the cluster management orchestrator we can manage the existing nodes, add or delete nodes, etc. Some of the available solutions for container orchestration are:

Docker Swarm

Kubernetes

Mesos Marathon

Cloud Foundry Diego

Amazon ECS

Azure Container Service.

we will provide more details on the options available.

By the end of this document you should be able to:

Describe different container orchestration tools: Docker

Swarm, Kubernetes, Mesos, Nomad, Amazon ECS, Google Container Engine,

and Azure Container Service.

Deploy sample applications using various container orchestration tools: Docker Swarm, Kubernetes, Mesos, Nomad, Amazon ECS, Google Container Engine, and Azure Container Service.

Introduction to Docker Swarm

Docker Swarm is a native container orchestration tool from Docker, Inc. It logically groups multiple Docker engines to create a virtual engine, on which we can deploy and scale applications.

The Swarm Cluster Figure below illustrates the major components of a Swarm cluster:

Swarm Manager

It accepts commands on behalf of the cluster and takes the scheduling decisions.

One or more nodes can be configured as managers, but they work in active/passive

modes.

Swarm Agents

They are hosts which run the Docker Engine and participate in the cluster.

Swarm Discovery Service The recommended way to do node discovery is using libkv, which abstracts out

multiple Key-Values like etcd, consul, zookeeper.

Overlay Networking Swarm uses libnetwork to configure the Overlay Network,

employing VxLAN between different hosts.

Features Next, we will focus on the characteristics of Docker Swarm:

It is compatible with Docker tools and API, so that the existing workflow does not

change much.

It provides native support to Docker networking and volumes.

It has a built-in scheduler support-flexible scheduling.

Filters:

- Node filters (constraint, health)

- Container filters (affinity, dependency, port)

Strategies: - spread

- binpack

- random

It can scale up to large numbers of nodes. For example, Docker Swarm has been

tested with 1000 nodes with 50000 containers.

It supports failover and High Availability for the cluster manager.

It supports the pluggable scheduler architecture, through which we can

use Mesos or Kubernetes as a scheduler.

Node discovery can be done via a hosted discovery service, a static file, a key-value store like etcd or consul.

Since we are illustrating the characteristics for Docker Swarm, we will also discuss briefly about Docker Machine and Docker Compose in the next few units.

Docker Machine

Docker Machine helps us configure and manage one or more Docker engines running locally or on cloud environments. With Docker Machinewe can start, inspect, stop, and restart a managed host, upgrade the Docker client and daemon, and configure a Docker client to talk to our host.

Docker Machine has drivers for Amazon EC2, Google Cloud, Digital Ocean, Vagrant, etc., to set up Docker engines. One can also add already running instances of the Docker engine to the Docker Machine:

Setting up the Docker engine using the Virtual Box driver: $ docker-machine create -d virtualbox dev1

Setting up the Docker engine using Digital Ocean:

$ docker-machine create --driver digitalocean --digitalocean-acc

ess-token=<TOKEN> dev2

We can also use Docker Machine to configure a Swarm cluster.

Docker Compose Docker Compose allows us to define and run multi-container applications trough a configuration file. In a configuration file we can define services, images or Dockerfiles to use, network, etc. Below we provide a sample of a compose file:

# Mongo DB

db:

image: mongo

expose:

- 27017

command: --smallfiles

# Python App

web:

image: nkhare/dockchat:v1

ports:

- "5000:5000"

links:

- db:db

With the above compose file, we would take the images mentioned in the image section and we would link them together to run the application. Instead of using existing images, we can also build them from the Dockerfile.

https://youtu.be/JktdtIYDkKU

Benefits of Using Docker Swarm Some of the benefits of using Docker Swarm are:

It provides native clustering for Docker.

It is well-integrated with the existing Docker tools and workflow.

Its setup is easy, straightforward and flexible.

It manages a cluster of containers as a single entity.

It provides scalability and supports High Availability.

Efficiency and productivity are increased by reducing deployment and management

time, as well as duplication of efforts.

https://www.docker.com/products/docker-swarms

https://docs.docker.com/swarm/

Introduction to Kubernetes Kubernetes is an Apache 2.0-licensed Open Source project for automating deployment, operations, and scaling of containerized applications. It was started by Google, but many other companies like Docker, Red Hat, and VMware contributed to it.

In March of 2016, Cloud Native Computing Foundation (CNCF), the nonprofit organization dedicated to advancing the development of cloud-native applications and services and driving alignment among container technologies, accepted Kubernetes as the first hosted project. The IP is transferred to the CNCF from Google.

As of now, Kubernetes supports Docker as container runtime, but it has a plan to support other container runtimes like rkt in the near future.

The Kubernetes Architecture

The Kubernetes architecture and its key components are illustrated in Figure

The Kubernetes Architecture - Key Components (Part I) Next, we will discuss the key components of the Kubernetes architecture.

Cluster The cluster is a group of systems (physical or virtual) and other infrastructure resources used by Kubernetes to run containerized applications.

Node The node is a system on which pods are scheduled and run. The node runs a daemon called kubelet, which allows it to communicate with the master node.

Master The master is a system that takes pod scheduling decisions and manages the replication and manager nodes.

Pod The pod is a co-located group of containers with shared volumes. It is the smallest deployment unit in Kubernetes. A pod can be created independently, but it is recommended to use the Replication Controller, even if only a single pod is being deployed.

Replication Controller The Replication Controllers manage the lifecycle of pods. They make sure that the desired number of pods is running at any given point in time. Below we provide an example of a replication controller, which makes sure that at least two copies of my pod are running:

apiVersion: v1

kind: ReplicationController

metadata:

name: frontend

spec:

replicas: 2

template:

metadata:

labels:

app: dockchat

tier: frontend

spec:

containers:

- name: chat

image: nkhare/dockchat:v1

env:

- name: GET_HOSTS_FROM

value: dns

ports:

- containerPort: 5000

Replica Sets According to the documentation provided by Kubernetes, "Replica Set is the next-generation Replication Controller. The only difference between a Replica Set and a Replication Controller right now is the selector support. Replica Set supports the new set-based selector requirements as described in the labels user guide whereas a Replication Controller only supports equality-based selector requirements."

Deployments With Kubernetes 1.2, a new object has been added, Deployment. According to

the Kubernetes documentation,

"A Deployment provides declarative updates for Pods and Replica Sets (the next-

generation Replication Controller). You only need to describe the desired state in a

Deployment object, and the Deployment controller will change the actual state to the

desired state at a controlled rate for you. You can define Deployments to create new

resources, or replace existing ones by new ones.

A typical use case is:

- Create a Deployment to bring up a Replica Set and Pods.

- Check the status of a Deployment to see if it succeeds or not.

- Later, update that Deployment to recreate the Pods (for example, to use a new

image).

- Rollback to an earlier Deployment revision if the current Deployment isn’t stable.

- Pause and resume a Deployment."

Below we provide a sample deployment:

apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 8

The Kubernetes Architecture - Key Components (Part II) We will continue discussing the key components of the Kubernetes architecture.

Service The service groups sets of pods together and provides a way to refer to them from a single static IP address and the corresponding DNSname. Below we provide an example of a service file: apiVersion: v1

kind: Service

metadata:

name: frontend

labels:

app: dockchat

tier: frontend

spec:

type: LoadBalancer

ports:

- port: 5000

selector:

app: dockchat

tier: frontend

Label The label is an arbitrary key-value pair which is attached to a resource like pod, replication controller, etc. In the example above we defined labels as app and tier.

Selector Selectors enable us to group resources based on labels. In the above example, the frontend service will select all pods which have the labels app==dockchat and tier==frontend.

Volume The volume is an external filesystem or storage which is available to pods. They are built on top of Docker volumes.

Namespace The namespace adds a prefix to the name of the resources, so that it is easy to

distinguish between different projects, teams, etc. in the same cluster.

Features Among the features of Kubernetes are the following:

It automatically places containers based on resource requirements and other constraints.

It supports horizontal scaling through CLI and UI. It can auto-scale based on the CPU load as well.

It supports rolling updates and rollbacks.

It supports multiple volume plugins like the GCP/AWS disk, NFS, iSCSI, Ceph, Gluster, Cinder, Flocker, etc. to attach volumes to Pods.

It automatically self-heals by restarting failed pods, rescheduling pods from failed nodes, etc.

It deploys and updates secrets for application without rebuilding the image.

It supports Batch execution.

https://youtu.be/O-E_4dS0LfE

Benefits of Using Kubernetes Some of the benefits of using Kubernetes are:

It is an Open Source system that packages all the necessary tools: orchestration,

service discovery, load balancing.

It manages multiple containers at scale.

It automates deployment, scaling, and operations of application containers.

It is portable, extensible and self-healing.

It provides consistency across development, testing, and production environments.

It is highly efficient in utilizing resources.

It is highly available.

References

http://kubernetes.io/

http://kubernetes.io/docs/

https://github.com/kubernetes/kubernetes

Introduction to Apache Mesos When we install and setup a physical machine, we generally use if for very specific purposes, such as running Hadoop, Spark, containers Jenkins, etc. Some of them might not be using all the system resources (e.g. CPU, memory) and some might be starving for more. Therefore, it would be helpful to have the ability to combine all the physical resources across all the machines and execute tasks on specific machines, based on the resource requirements. Apache Mesos was created with this in mind, so that we can optimally use the resources available, even if we are running disparate applications on a pool of nodes.

Apache Mesos helps us treat a cluster of nodes as one big computer, which manages CPU, memory, and other resources across a cluster. Mesosprovides functionality that crosses between Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). It is an Open Source Apacheproject.

Mesos Components Next, we will provide details on Mesos components, which are illustrated in Figure 7.4.

Master Master nodes are the brain of the cluster and provide a single source of truth for running tasks. There is one active master node at any point in time. The master node mediates between schedulers and slaves. Slaves advertise their resources to the master node, then the master node forwards them to the scheduler. Once the scheduler accepts the offer, it sends the task to run on the slave to the master, and the master forwards these tasks to the slave.

Slave

Slaves manage resources at each machine level and execute the tasks submitted

via the scheduler.

Frameworks

Frameworks are distributed applications that solve a specific use case. They consist

of a scheduler and an executor. The scheduler gets a resource offer, which it can

accept or decline. The executor runs the job on the slave, which the scheduler

schedules. There are many existing frameworks and we can also create custom

ones. Some of the existing frameworks

are: Hadoop, Spark, Marathon, Chronos, Jenkins, Aurora, and many more.

Executor

Executors are used to run jobs on slaves. They can

be SHELL scripts, Docker containers, and programs written in different languages

(e.g. Java).

Mesos Features Mesos has the following features:

It can scale to 10,000 nodes.

It uses ZooKeeper for fault-tolerant replicated master and slaves.

It provides support for Docker containers.

It enables native isolation between tasks with Linux Containers.

It allows multi-resource scheduling (memory, CPU, disk, and ports).

It uses Java, Python and C++ APIs for developing new parallel applications.

It uses WebUI for viewing cluster statistics.

Mesos ships binaries for different components (e.g. master, slaves, frameworks, etc.), which we can bind together to create our Mesos Cluster. The Apache Mesos website has detailed documentation to do the setup.

Mesosphere DC/OS Mesosphere offers a commercial solution on top of Apache Mesos. Mesosphere is one of the primary contributors to the Mesos project and to frameworks like Marathon. Their commercial product, Mesosphere Enterprise DC/OS, offers a one-click install and enterprise features like security, monitoring, user interface, etc. on top of Mesos.

DC/OS has recently been open-sourced by Mesosphere.

By default, DC/OS comes with the Marathon framework and others can be added as required.

The Marathon framework has the following features:

It starts, stops, scales, and updates applications.

It has a nice web interface, API.

It is highly available, with no single point of failure.

It uses native Docker support.

It supports rolling deploy/restart.

It allows application health checks.

It provides artifact staging.

Mesosphere DC/OS Architecture

We will now discuss the Mesosphere DC/OS architecture. There are two main components: the DC/OS Master and the DC/OS Agents.

The DC/OS Master has the following default components:

Mesos master process

It is similar to the master component of Mesos.

Mesos DNS

It provides service discovery within the cluster, so applications and services running

inside the cluster can reach to each other.

Marathon

It is a framework which comes by default with DC/OS and provides the "init system".

ZooKeeper

It is a high-performance coordination service that manages the DC/OS services.

Admin router

It is an open-source Nginx configuration created by Mesosphere, providing central

authentication and proxy to DC/OS services within the cluster.

The DC/OS Agent nodes have the following components:

Mesos agent process It runs the mesos-slave process, which is similar to the slave component

of Mesos.

Mesos containerizer

It provides lightweight containerization and resource isolation of executors,

using Linux-specific functionality, such as cgroups and namespaces.

Docker container

It provides support for launching tasks that contain Docker images.

DCOS has its own command line and web interfaces and comes with a simple packaging and installation.

https://youtu.be/IH6O051iC2I

Benefits of Using Mesos Some of the benefits of using Mesos are:

It is an Open Source solution, but it also has a commercial version.

It provides support for Docker containers.

It allows multi-resource scheduling.

It is highly available and scalable.

It provides service discovery and load balancing.

References

http://mesos.apache.org/

https://mesosphere.com/

https://docs.mesosphere.com/overview/architecture/

Introduction to Nomad Nomad is a cluster manager and resource scheduler from HashiCorp, which is

distributed, highly available, and scales to thousands of nodes. It is especially

designed to run micro-services and batch jobs. It supports different workloads, like

containers (Docker), VMs, and individual applications.

It is distributed as a single binary which has all of its dependency and runs in

a server and client mode. To submit a job, the user has to define it using a

declarative language called HashiCorp Configuration Language (HCL) with its

resource requirements. Once submitted, Nomad will find available resources in the

cluster and run it to maximize the resource utilization.

Below we provide a sample job file:

# Define the hashicorp/web/frontend job

job "hashicorp/web/frontend" {

# Run in two datacenters

datacenters = ["us-west-1", "us-east-1"]

# Only run our workload on linux

constraint {

attribute = "$attr.kernel.name"

value = "linux"

}

# Configure the job to do rolling updates

update {

# Stagger updates every 30 seconds

stagger = "30s"

# Update a single task at a time

max_parallel = 1

}

# Define the task group

group "frontend" {

# Ensure we have enough servers to handle traffic

count = 10

task "web" {

# Use Docker to run our server

driver = "docker"

config {

image = "hashicorp/web-frontend:latest"

}

# Ask for some resources

resources {

cpu = 500

memory = 128

network {

mbits = 10

dynamic_ports = ["http"]

}

}

}

}

}

which would use 10 containers from the hashicorp/web-

frontend:latest Docker image.

Features Among the characteristics of Nomad are the following:

It handles both cluster management and resource scheduling.

It supports multiple workloads, like containers (Docker), VMs, unikernels, and

individual applications.

It ships with just one binary for both the server and the client daemon, which reduces

the cost of operations.

It has multi-datacenter and multi-region support. We can have

a Nomad client/server running in different clouds, which form the same

logical Nomad cluster.

It bin-packs applications onto servers to achieve high resource utilization.

https://youtu.be/KJVKEzInfmU

Benefits of Using Nomad Some of the benefits of using Nomad are:

It is an Open Source solution that is distributed as a single binary for server and

agents.

It is highly available and scalable.

It maximizes resource utilization.

It provides multi-datacenter and multi-region support.

When maintenance is done, there is zero downtime to the datacenter and services.

It simplifies operations, provides flexible workloads, and fast deployment.

References

https://www.hashicorp.com/blog/nomad.html

https://nomadproject.io

Introduction to Amazon ECS Amazon ECS is part of the Amazon Web Services (AWS) offerings to provide container orchestration and management on top of the EC2instances, using Docker.

Amazon ECS Components

Next, we will discuss in more detail some of its components:

Cluster It is a logical grouping of container instances on which tasks are placed.

Container instance It is an EC2 instance with an ECS agent that has been registered with a cluster.

Task definition It specifies the blueprint of an application, which consists of one or more containers. Below, you can see an example of a sample task definition file (from docs.aws.amazon.com):

{

"containerDefinitions": [

{

"name": "wordpress",

"links": [

"mysql"

],

"image": "wordpress",

"essential": true,

"portMappings": [

{

"containerPort": 80,

"hostPort": 80

}

],

"memory": 500,

"cpu": 10

},

{

"environment": [

{

"name": "MYSQL_ROOT_PASSWORD",

"value": "password"

}

],

"name": "mysql",

"image": "mysql",

"cpu": 10,

"memory": 500,

"essential": true

}

],

"family": "hello_world"

}

Scheduler It places tasks on the container instances. The following scheduling options are provided on ECS: - Service scheduler. - RunTask action.

- StartTask action.

Service It allows one or more instances of tasks to run, depending on the task definition. Below you can see the template of a service definition (from docs.aws.amazon.com). If there is an unhealthy task, then the service restarts it again. One load balancer (ELB) is attached to each service.

{

"cluster": "",

"serviceName": "",

"taskDefinition": "",

"loadBalancers": [

{

"loadBalancerName": "",

"containerName": "",

"containerPort": 0

}

],

"desiredCount": 0,

"clientToken": "",

"role": "",

"deploymentConfiguration": {

"maximumPercent": 200,

"minimumHealthyPercent": 100

}

}

Task It is a running container instance from the task definition.

Container

It is a Docker container created from the task definition.

Amazon ECS Features Among the features of Amazon ECS are the following:

It is compatible with Docker, as each Amazon ECS instance runs the Docker

Daemon.

It provides a managed cluster, so that users do not have to worry about managing

and scaling the cluster.

Task definition allows the user to define the applications through a .json file.

Shared data volumes, as well as resource constraints for Memory and CPU can

also be defined in the same file.

It provides APIs to manage clusters, tasks, etc.

Amazon ECS scheduler places containers based on resource needs and availability

requirements. It also has provisions to integrate with third party schedulers,

like Mesos Marathon.

Amazon ECS allows easy updates of containers to new versions.

The Amazon ECS CLI is compatible with Docker Compose.

The monitoring feature is available through AWS CloudWatch.

The logging facility is available through AWS CloudTrail.

It supports third party Docker Registry or Docker Hub.

https://youtu.be/4krcmNidOik

Benefits of Using Amazon ECS Some of the benefits we can get from using Amazon ECS are:

It provides a managed cluster.

It is built on top of Amazon EC2.

It is highly available and scalable.

It leverages other AWS services, such as Cloud Watch Metrics

References

https://aws.amazon.com/ecs/details/

http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html

Introduction to Google Container Engine Google Container Engine (GKE) is a fully-managed solution for running Kubernetes on Google Cloud. As we learned earlier, Kubernetes is used for automating deployment, operations, and scaling of containerized applications.

GKE Features and Benefits Some of the features and benefits of the Google Container Engine are listed below:

It has all of Kubernetes' features.

It is a fully-managed service, so the users do not have to worry about managing and

scaling the cluster.

We can store images privately, using the private container registry.

Logging can be enabled easily using Google Cloud Logging.

It supports Hybrid Networking to reserve an IP address range for the container

cluster.

It enables a fast setup of managed clusters.

It facilitates increased productivity for Dev and Ops teams.

References

https://cloud.google.com/container-engine/

Introduction to Azure Container Service Azure Container Service (ACS) simplifies the creation, configuration, and management of containerized applications on Microsoft Azure.

It either uses Apache Mesos or Docker Swarm to orchestrate applications, which are containerized using the Docker runtime. For Mesos, ACSincludes the Marathon and Chronos frameworks by default. Apache Mesos and Docker Swarm clusters can be accessed by DC/OS CLI and Docker CLI respectively.

In Azure and Azure Stack, the Azure Resource Manager represents the management layer (API), which allows us to connect to our deploying resources. ACS has templates for both Mesos and Docker Swarm, which can be used to deploy the cluster on top of VMs.

ACS Features and Benefits Among the features and benefits of ACS, it is important to mention the ones below:

It can easily manage containerized applications on the Microsoft Azure platform.

It allows for an easy deployment of container orchestration tools: Apache Mesos

Marathon and Docker Swarm.

https://youtu.be/XITWnmAn83s

References

https://azure.microsoft.com/en-in/documentation/services/container-service

https://azure.microsoft.com/en-in/documentation/articles/container-service-

deployment/

Container as a Service These days we can notice the frequent use of a new as a Service model: Container as a Service (CaaS). Earlier, we talked about IaaS, PaaS, and SaaS, in which we provision infrastructure, application, and software on demand. If we follow the definition, then, with CaaS, we would get containers on demand. This brings CaaS closer to IaaS. However, containers are typically used to confine and deploy an application, which brings CaaS closer to PaaS.

As CaaS sits between IaaS and PaaS, it would have capabilities to support both Dev and Ops. With effective tooling and extensibility, CaaS could become the game changer. Currently, there are a few solutions labeled as CaaS, such as the following:

OpenStack Magnum

Docker Universal Control Plane.

Other solutions are labeled as CaaS enablers, like the following:

Kubernetes

AWS EC2 Container Service (ECS)

Tectonic (CoreOS + Kubernetes)

Rancher

and many more.

In this chapter we will look at the current CaaS solutions: OpenStack Magnum and Docker Universal Control Plane.

Learning Objectives

By the end of this chapter you should be able to:

Explain the concept of Container as a Service (CaaS) and see what its benefits

are for the software lifecycle.

Discuss current CaaS solutions: Docker Universal Control Plane and OpenStack

Magnum.

Introduction to Docker Universal Control Plane As the name suggests, the Docker Universal Control Plane (UCP) provides a centralized container management solution (on-premises or on a virtual private cloud), regardless of

where your applications are running. UCP is part of the RUN management of Docker.

UCP works with existing Docker tools, like Docker Machine and Docker Swarm, which makes adding or deleting nodes to UCP easy. UCP also integrates well with existing authentication mechanisms like LDAP/AD, which allows Ops teams to define fine-grained policies and roles. With fine-grained policies and roles, a developer has a limited view of the cluster, but he/she has full control of the deployment.

Features and Benefits Among the features and benefits of the Docker Universal Control Plane are the following:

It integrates well with authentication tools like LDAP/AD and SSO with Docker

Trusted Registry.

It integrates with exiting Docker tools like Docker Machine, Docker

Swarm, Docker Trusted Registry.

It is easy to setup and use.

It manages applications and containers from a central location through the web

Admin GUI.

It can be easily setup with High Availability.

With proper authentication, it can be operated from the CLI.

It provides a centralized container management solution (on-premises or on a virtual

private cloud).

Docker Datacenter

Docker has another project called Docker Datacenter, which is built on top of UCP and Docker Trusted Registry. Docker Datacenter is hosted completely behind the firewall.

With Docker Datacenter we can build an enterprise-class CaaS platform on-premises, as it is built on top of Docker Swarm and integrates well with Docker tools, Docker Registry. It also has other features, such as LDAP/AD integration, monitoring, logging, network and storage plugins.

https://youtu.be/iVxVxZv7_3E

References

http://www.docker.com/products/docker-universal-control-plane

https://www.docker.com/products/docker-datacenter

Introduction to Project Magnum OpenStack Magnum is a CaaS service provided on top of OpenStack. Containers are orchestrated and scheduled on clusters created by Kubernetes, Docker Swarm, or Mesos. OpenStack Magnum provides two services:

Server API

Magnum Client talks to this service.

Conductor

It manages the cluster lifecycle through Heat and communicates with the Cluster Container

Orchestration Engine (COE).

Magnum Components Next, we will talk about the building blocks of OpenStack Magnum:

Bay

Bays are nodes on which the Container Orchestration Engine sets up the

respective Cluster.

BayModels

It stores metadata information about Bays like the Container Orchestration

Engine, Keypairs, Images to use, etc.

Container Orchestration Engine (COE)

It is the Container Orchestrator used by Magnum. Currently, it

supports Kubernetes, Docker Swarm, and Mesos. COEs are on top of Micro

OSes, like Atomic Host, CoreOS, etc.

Pod

A pod is a co-located group of application containers that run with a shared context.

Service

It is an abstraction which defines a logical set of pods and a policy by which to

access them.

Replication Controller

It is an abstraction for managing a group of pods to ensure that a specified number

of resources are running.

Container

This is a Docker container.

Features and Benefits Some of the features and benefits of OpenStack Magnum are:

Magnum offers an asynchronous API that is compatible with Keystone.

It brings multi-tenancy by default, as it creates a Bay per tenant. This means that for

each tenant there would be a separate cluster, depending on the COE.

Magnum makes containers available as first-class citizens in OpenStack.

It enables High Availability and scalability.

It supports Kubernetes, Docker Swarm, and Mesos for container orchestration and

scheduling.

References

https://wiki.openstack.org/wiki/Magnum

Software Defined Networking and Networking for Containers Traditional networks cannot cope with the kind of demand mobile devices, cloud computing, and other similar technologies are generating. With the advancement in compute and storage virtualization, we can quickly meet compute and storage requirements. To connect devices, applications, VMs, and containers, we need a similar level of virtualization in networking. This will allow us to meet the end-to-end business requirements.

Software Defined Networking (SDN) decouples the network control layer from the layer which forwards the traffic. This allows SDN to program the control layer to create custom rules in order to meet the networking requirements.

Part of this course has covered containers extensively. Next, let's take a look at container networking and see how it is one of the use-cases for SDN.

Learning Objectives

By the end of this chapter you should be able to:

Define Software Defined Networking.

Discuss the basics of Software Defined Networking.

Discuss different networking options with containers.

SDN Architecture In Networking we have three planes defined:

Data Plane The Data Plane, also called the Forwarding Plane, is responsible for handling data packets and apply actions to them based on rules which we program into lookup-tables.

Control Plane The Control Plane is tasked with calculating and programming the actions for the Data Plane. This is where the forwarding decisions are made and where services (e.g. Quality of Service and VLANs) are implemented.

Management Plane The Management Plane is the place where we can configure, monitor, and manage

the network devices.

Activities Performed by a Network Device Every network device has to perform three distinct activities:

Ingress and egress packets

These are done at the lowest layer, which decides what to do with ingress packets and which

packets to forward, based on forwarding tables. These activities are mapped as Data

Plane activities. All routers, switches, modem, etc. are part of this plane.

Collect, process, and manage the network information

By collecting, processing, and managing the network information, the network device makes the

forwarding decisions, which the Data Plane follows. These activities are mapped by

the Control Plane activities. Some of the protocols which run on the Control Plane are routing

and adjacent device discovery.

Monitor and manage the network

Using the tools available in the Management Plane, we can interact with the network device to

configure it and monitor it with tools likeSNMP (Simple Network Management Protocol).

In Software Defined Networking we decouple the Control Plane with the Data Plane. The Control Plane has a centralized view of the overall network, which allows it to create forwarding tables of interest. These tables are then given to the Data Plane to manage network traffic.

The Control Plane has well-defined APIs that take requests from applications to configure the network. After preparing the desired state of the network, the Control Plane communicates that to the Data Plane (also known as the Forwarding Plane), using a well-defined protocol like OpenFlow.

We can use configuration tools like Ansible or Chef to configure SDN, which brings lots of flexibility and agility on the operations side as well.

Introduction to Networking for Containers Similar to VMs, we need to connect containers on the same host and across hosts. The host kernel uses the Network Namespace feature of the Linux Kernel to isolate the network from one container to another on the system. Network Namespaces can be shared as well.

On a single host, when using the Virtual Ethernet (veth) feature with Linux bridging, we can give a virtual network interface to each container and assign it an IP address. With Linux Kernel features, like IPVLAN, we can configure each container to have a unique and world-wide routable IP address. IPVLAN is a recent feature and support to different container runtimes is coming soon.

As of now, if we want to do multi-host networking with containers, the most common solution is to use some form of Overlay network driver, which encapsulates the Layer 2 traffic to a higher layer. Examples of this type of implementation are

the Docker Overlay Driver, Flannel, Weave, etc. Project Calico allows multi-host networking on Layer 3 using BGP (Border Gateway Protocol)

Container Networking Standards Two different standards have been proposed so far for container networking:

The Container Network Model (CNM)

Docker, Inc. is the primary driver for this networking model. It is implemented using

the libnetwork project, which has the following utilizations:

- Null - NOOP implementation of the driver. It is used when no networking is required.

- Bridge - It provides a Linux-specific bridging implementation based in Linux Bridge.

- Overlay - It provides a multi-host communication over VXLAN.

- Remote - It does not provide a driver. Instead, it provides a means of supporting drivers

over a remote transport, by which we can write third-party drivers.

The Container Networking Interface (CNI) Proposal

CoreOS is the primary driver for this networking model. It is derived from the rkt

Networking Proposal. Kubernetes has added support for CNI.

Service Discovery Now that we provided an overview on networking, let's take a moment to discuss about Service Discovery as well. This becomes extremely important when we do multi-host networking and use some form of orchestration, like Docker Swarm or Kubernetes.

Service Discovery is a mechanism by which processes and services can find each other automatically and talk. With respect to containers, it is used to map a container name with its IP address, so that we can access the container without worrying about its exact location (IP address).

Service Discovery has two parts:

Registration

When a container starts, the container scheduler registers the mapping in some key-

value store like etcd or Consul. And, if the container restarts or stops, then the

scheduler updates the mapping accordingly.

Lookup

Services and applications use Lookup to get the address of a container, so that they

can connect to it. Generally, this is done using some kind

of DNS (Domain Name Server), which is local to the environment. The DNS used

resolves the requests by looking at the entries in the key-value store, which is used

for Registration. SkyDNS and Mesos-DNS are examples of such DNS services.

Listing the Available Networks If we list the available networks after installing the Docker daemon, we should see something like the following:

$ docker network ls NETWORK ID NAME DRIVER 6f30debc5baf bridge bridge a1798169d2c0 host host 4eb0210d40bb none null

bridge, null, and host are different network drivers available on a single host. Next, we will take a closer look at them.

Bridge Like the hardware bridge, we can emulate a software bridge on a Linux host. It can forward traffic between two networks based on MAC (hardware address) addresses. By default, Docker creates a docker0 Linux Bridge. All the containers on a single host get an IP address from this bridge, unless we specify some other network with the --net= option. Docker uses the Linux's Virtual Ethernet (veth) feature to create two virtual interfaces, one end of which is attached to the container and other end to the docker0 bridge.

Looking at the network configuration after installing Docker on a single host, we can see the default bridge as illustrated below:

$ ifconfig docker0 Link encap:Ethernet HWaddr 02:42:A9:DB:AF:39 inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

We can create a new container doing the following:

$ docker run -it --name=c1 busybox /bin/sh / # ip a 1: lo: <LOOPBACK,UP,LOWE_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 7: eth0@if8: <BROADCAST,MULTICAST,UP, LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue

link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff inet 172.17.0.2/16 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::42:acff:fe11:2/64 scope link valid_lft forever preferred_lft forever

As we can see, the new container got the IP address from the private IP address range 172.17.0.0/16, which is catered by the bridge network.

Inspecting a Bridge Network We can inspect a network to get more information about it. In the example below, container c1 is a bridge network.

$ docker network inspect bridge [ { "Name": "bridge", "Id": "6f30debc5baff467d437e3c7c3de673f21b51f821588aca2e30a7db68f10260c", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.17.0.0/16" } ] }, "Internal": false, "Containers": { "613f1c7812a9db597e7e0efbd1cc102426edea02d9b281061967e25a4841733f": { "Name": "c1", "EndpointID": "80070f69de6d147732eb119e02d161326f40b47a0cc0f7f14ac7d207ac09a695", "MacAddress": "02:42:ac:11:00:02", "IPv4Address": "172.17.0.2/16", "IPv6Address": "" } }, "Options": { "com.docker.network.bridge.default_bridge": "true", "com.docker.network.bridge.enable_icc": "true",

"com.docker.network.bridge.enable_ip_masquerade": "true" "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0", "com.docker.network.bridge.name": "docker0", "com.docker.network.driver.mtu": "1500" }, "Labels": {} } ]

Creating A Bridge Network We can also create our own bridge network by doing the following: docker network create --driver bridge isolated_nw

which would create its own Linux Bridge on the host system. To create a container and have it use the newly created network, we have to start the container with the --net=isolated_nw option:

$docker run --net=isolated_nw -itd --name=c2 busybox

A bridge network does not support automatic service discovery, so we have to rely on the legacy --link option.

Null As the name suggests, NULL means no networking. If we attach a container to a null driver, then it would just get the loopback interface. It would not be accessible from the outside.

$ docker run -it --name=c3 --net=none busybox /bin/sh / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 1disc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet ::1/128 scope host valid_lft forever preferred_lft forever

Host Using the host driver, we can share the host machine's network namespace with a container. In doing so, the container would have full access to the host's network. We can see below that running an ifconfig command inside the container lists all the interfaces of the host system:

$ docker run -it --name=c4 --net=host busybox /bin/sh / # ifconfig docker0 Link encap:Ethernet HWaddr 02:42:A9:DB:AF:39

inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0 inet6 addr: fe80::42:a9ff:fedb:af39/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:536 (536.0 B) TX bytes:648 (648.0 B)

eth0 Link encap:Ethernet HWaddr 08:00:27:CA:BD:10 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:feca:bd10/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3399 errors:0 dropped:0 overruns:0 frame:0 TX packets:2050 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1021964 (998.0 KiB) TX bytes:287879 (281.1 KiB)

eth1 Link encap:Ethernet HWaddr 08:00:27:00:42:F9 inet addr:192.168.99.100 Bcast:192.168.99.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe00:42f9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:71 errors:0 dropped:0 overruns:0 frame:0 TX packets:46 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:13475 (13.1 KiB) TX bytes:7754 (7.5 KiB)

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:1021964376 (1.3 KiB) TX bytes:1376 (1.3 KiB)

vethb3bb730 Link encap:Ethernet HWaddr 4E:7C:8F:B2:2D:AD inet6 addr: fe80::4c7c:8fff:feb2:2dad/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:648 (648.0 B) TX bytes:1296 (1.2 KiB)

Sharing Network Namespaces among Containers Similar to host, we can share the network namespaces among containers. So, two or more containers can have the same network stack and reach each other by referring to localhost.

Let's take a look at its IP address:

$ docker run -it --name=c5 busybox /bin/sh / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever

10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff inet 172.17.0.3/16 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::42:acff:fe11:3/64 scope link valid_lft forever preferred_lft forever

Now, if we start a new container with the --net=container:CONTAINER option, we can see that the other container has the same IP address.

$ docker run -it --name=c6 --net=container:c5 busybox /bin/sh

/ # ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

12: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu

1500 qdisc noqueue

link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff

inet 172.17.0.3/16 scope global eth0

valid_lft forever preferred_lft forever

inet6 fe80::42:acff:fe11:3/64 scope link

valid_lft forever preferred_lft forever

Kubernetes uses the feature detailed above to share the same network

namespaces among multiple containers in a pod.

Introduction to Docker Multi-Host Networking

As mentioned previously in this course, most of the multi-host networking solutions for Docker are based on the Overlay network, in which we encapsulate the container's IP packet inside the host's packet, while sending it over the wire. While receiving, we decapsulate the whole packet and forward the container's packet to the receiving container.

Examples of multi-host networking solutions based on Overlay networks are:

Docker Overlay Driver

Flannel

Weave.

Project Calico uses the Border Gateway Protocol (BGP) to do IP-based routing instead of encapsulation. As it works on Layer 3, it requires some hardware support.

Docker Overlay Driver Next, we will take a closer look at the Docker Overlay Driver.

As mentioned in the Docker documentation, the Docker Overlay Network driver supports multi-host networking natively. This is accomplished with "libnetwork, a built-in VXLAN-based overlay network driver, and Docker’s libkv library".

To configure the Overlay network, we have to first configure a key-value store and connect it with the Docker Engine on each host, so that we can store all the network configurations in a central location. Docker uses libkv to configure the key-value store, which currently supportsConsul, etcd, and Zookeeper (distributed store

Once the key-value store is configured, we can create an Overlay network with the following command:

$docker network create --driver overlay multi-host-network

In the command above, multi-host-network is the network name, which we created.

To create a container which uses the multi-host Overlay network we created, we have to start the container with a command like the following:

$ docker run -itd --net=multi-host-network busybox

All the containers which we created on different hosts using the Overlay network are accessible to each other

https://youtu.be/o3gVzJXiD8I

Docker Networking Plugins We can extend the functionality of Docker with plugins. Docker provides plugins for Network and Volumes. Some of the Docker network plugins are:

Weave Network Plugin

Weave Net provides multi-host container networking for Docker. It provides service

discovery and does not require any external cluster store to save networking

configuration. Weave Net has the Docker Networking Plugin, which we can use

with Docker Deployment.

Kuryr Network Plugin

It is part of the OpenStack Kuryr project, which also implements Libnetwork's remote driver

API by utilizing Neutron, which is OpenStack's networking service.

We can also write our own driver with Docker Remote Driver APIs.

https://youtu.be/kda6dHjORDM

Software Defined Storage (SDS) and Storage Management for Containers Software Defined Storage (SDS) is a form of storage virtualization in which storage hardware is separated from the software, which manages it. By doing this, we can bring hardware from different sources and we can manage them with software. Software can provide different features, like replication, erasure coding, snapshot, etc. on top of the pooled resources. Once the pooled storage is configured in the form of a cluster, SDSallows multiple access methods like File, Block, and Object.

In this chapter, we will first look at some examples for Software Defined Storage and then dive into storage management for containers.

Some examples of Software Defined Storage are:

Ceph

Gluster

FreeNAS

Nexenta

VMware Virtual SAN.

Introduction to Ceph According to ceph.com:

"Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability."

Ceph is an Open Source defined and unified storage solution. It can deliver Object, Block and File system storage.

Ceph Architecture Everything in Ceph is stored as objects. Ceph uses the CRUSH (Controlled Replication Under Scalable Hashing) algorithm to deterministically find out, write, and read the location of objects.

Next, we will take a closer look at Ceph's architecture:

Reliable Autonomic Distributed Object Store (RADOS) It is the object store which stores the objects. This layer makes sure that data is always in a consistent and reliable state. It performs operations like replication, failure detection, recovery, data migration, and rebalancing across the cluster nodes. This layer has the following three major components: - Object Storage Device (OSD) - This is where the actual user content is

written and retrieved with read operations. One OSD daemon is typically tied to one physical disk in the cluster. - Ceph Monitors (MON) - Monitors are responsible for monitoring the cluster state. All cluster nodes report to Monitors. Monitors map the cluster state through the OSD, Place Groups (PG), CRUSH and Monitor maps. - Ceph Metadata Server (MDS) - It is needed only by CephFS, to store the file

hierarchy and metadata for files.

Librados It is a library that allows direct access to RADOS from languages like C, C++, Python, Java, PHP, etc. Ceph Block Device, RADOSGW, and CephFS are implemented on top of Librados.

Ceph Block Device This provides the block interface for Ceph. It works as a block device and has enterprise features like thin provisioning and snapshots.

RADOS Gateway (RADOSGW) This provides a REST API interface for Ceph, which is compatible with Amazon S3 and OpenStack Swift.

Ceph File System (CephFS) This provides a POSIX-compliant distributed filesystem on top of Ceph. It relies on Ceph MDS to track the file hierarchy.

https://youtu.be/RrJlLdaS3FI

Benefits of Using Ceph Among the benefits of using Ceph are:

It is an Open Source storage solution, which supports Object, Block,

and Filesystem storage.

It runs on any commodity hardware, without any vendor lock-in.

It provides data safety for mission-critical applications.

It provides automatic balance of filesystems for maximum performance.

It is scalable and highly available, with no single point of failure.

It is a reliable, flexible, and cost-effective storage solution.

References

ceph.com

docs.ceph.com

Introduction to Gluster According to gluster.org:

"GlusterFS is a scalable network filesystem. Using common off-the-shelf hardware, you can create large, distributed storage solutions for media streaming, data analysis, and other data- and bandwidth-intensive tasks. GlusterFS is free and open source software."

GlusterFS Volumes

To create shared storage, we need to start by grouping the machines in

a Trusted Pool. Then, we group the directories (called bricks) from those

machines in a GlusterFS volume, using FUSE (Filesystem in

Userspace). GlusterFS supports different kinds of volumes:

Distributed GlusterFS Volume

Replicated GlusterFS Volume

Distributed Replicated GlusterFS Volume

Striped GlusterFS Volume

Distributed Striped GlusterFS Volume.

GlusterFS does not have a centralized metadata server. It uses an

elastic hashing algorithm to store files on bricks.

The GlusterFS volume can be accessed using one of the following

methods:

Native FUSE mount

NFS (Network File System)

CIFS (Common Internet File System).

https://youtu.be/OrnuF18FjFk

Benefits of Using Gluster Among the benefits of using Gluster are:

It is an Open Source storage solution that supports Object, Block, and Filesystem storage.

It does not have a metadata server.

It is scalable, modular and extensible.

It is POSIX-compliant, providing High Availability via local and remote data replication.

References

https://www.gluster.org/

http://gluster.readthedocs.org/

Introduction to Storage Management for Containers Containers are ephemeral in nature, which means that whatever is stored inside the container would be gone as soon as the container is deleted. It is best practice to store data outside the container, which would be accessible even after the container is gone.

In a multi-host environment, containers can be scheduled to run on any host. We need to make sure the data volume required by the container is available on the node on which the container would be running.

In this section, we will see how Docker uses the Docker Volume feature to store persistent data and allows vendors to support their storage to its eco-system, using Docker Volume Plugins. We will start by looking

into different Storage Backends, which Docker supports in order to store images, containers, and other metadata.

Docker Storage Backends Docker uses Copy-on-write to start containers from images, which means

we do not have to copy an image while starting a container. All of the

changes done by a container are saved in a filesystem

layer. Docker images and containers are stored on the host system and

we can choose the storage backend for Docker storage, depending on

our requirements. Docker supports the following storage backends

on Linux:

AUFS (Another Union File System)

BtrFS

Device Mapper

Overlay

VFS (Virtual File System)

ZFS.

Docker Volumes According to the Docker Documentation:

"A data volume is a specially-designated directory within one or more containers

that bypasses the Union File System. Data volumes provide several useful features

for persistent or shared data:

Volumes are initialized when a container is created. If the container’s base image contains data at

the specified mount point, that existing data is copied into the new volume upon volume

initialization. (Note that this does not apply when mounting a host directory.)

Data volumes can be shared and reused among containers.

Changes to a data volume are made directly.

Changes to a data volume will not be included when you update an image.

Data volumes persist even if the container itself is deleted.

Next, we will take a closer look at a few examples of how to create volumes.

Creating a Container with Volumes To create a container with volume, we can use either the "docker run" or

the "docker create" commands, like the following:

$ docker run -d --name web -v /webapp nkhare/myapp

The above command would create a volume inside the Docker working directory (default to /var/lib/docker/) on the host system. We can get

the exact path via the "docker inspect" command:

$ docker inspect web

Creating a Named Volume We can give a specific name to a volume and then use it for different

operations. To create a named volume, we can run the following

command:

$ docker volume create --name my-named-volume

and then later mount it.

Mounting a Host Directory Inside the Container We can also mount a host directory inside a container using the volume's

feature:

$ docker run -d --name web -v /mnt/webapp:/webapp nkhare/myapp

which would mount the host's "/mnt/webapp" directory to "/webapp",

while starting the container.

Creating a Data Volume Container If we want to share persistent data across containers or share persistent

data with a non-persistent container, then we can use the Data Volume

Container. A Data Volume Container just creates a volume and does

nothing like the following:

$ docker create -v /dbdata --name dbstore busybox /bin/true

Now, let's share the volume dbstore container with other containers:

$ docker run --volumes-from dbstore --name=client1 centos /bin/sh

$ docker run --volumes-from dbstore --name=client2 centos /bin/sh

Introduction to Volume Plugins for Docker We can extend the functionality of the Docker Engine with the use of plugins. With plugins, third-party vendors can integrate their solutions with the Docker eco-system. Docker provides two kinds of plugins, Network and Volume Plugins. We have talked about Network Plugins in the previous chapter. Some examples of Volume Plugins are:

Flocker

GlusterFS

Blockbridge

EMC REX-Ray.

Volume plugins are especially helpful when we migrate a stateful container, like a database, on a multi-host environment. In such an environment, we have to make sure that the volume attached to a container is also migrated to the host where the container is migrated or started afresh.

Flocker Volume Plugin According to clusterhq.com,

"Flocker is an open-source container data volume manager for your

Dockerized applications."

A Flocker Docker Volume is referred to as a dataset, which can be

used with any of the containers in the cluster.

Flocker manages Docker containers and data volumes together. Your

volumes would follow the container while doing the migration, if the

container (micro-service) is managed by Flocker.

Flocker is designed to work with existing container tools like Docker

Compose, Docker Swarm, Kubernetes, and Mesos.

In this section we will present the basic use of the Flocker's volume plugin.

Supported Storage Options for Flocker ome of the supported storage options for Flocker are:

AWS Elastic Block Storage (EBS)

OpenStack Cinder with any supported backend

EMC ScaleIO, XtremeIO, VMAX

VMware vSphere and vSan

NetApp OnTap.

For a detailed list of supported storage options, please visit the ClusterHQ website.

https://youtu.be/tU-ovW3-sYg

Flocker References

https://github.com/ClusterHQ/flocker

https://clusterhq.com/flocker/introduction/

GlusterFS Volume Plugin Earlier in this chapter we saw how we can create a shared storage pool using GlusterFS. Docker provides a plugin for GlusterFS, which we can use to attach/detach storage to one or more containers on-demand.

In the following demo we will see how we can use the GlusterFS Volume Plugin for Docker to mount the Gluster Volume created on a remote machine to the container.

https://youtu.be/uxolSVtb6Xw