Networking options for Docker

Docker is gaining popularity both in the new and in actual deployment.  Last time I talked about VMware is also embracing Docker technology.

Lets take a look at the different networking options for Docker.

Native Docker Networking

• On startup Docker creates a Ethernet Bridge docker0 on the Linux Kernel
• docker0 creates a virtual subnet on the Docker host
• Docker creates a pair of virtual Ethernet interface on each container
• One of the Ethernet interface is the eth0 in the container
• Another Ethernet interface will have a unique name in the form of veth* (e.g.vethABI3IC) and is bind to docker0
• User can customize docker0
• Advanced Docker networking can be found here

image source: http://www.infrabricks.de/assets/images/docker_network_basics1.png

Flannel

• reference articles An etcd backed overlay network for container, article1 and article2
• Used to be called Rudder
• An etcd backed overlay network for container
• flannel uses etcd for storage of both configuration data and subnet assignments.
• Upon startup, a flannel daemon will retrieve the configuration and a list of subnet already in use
• Select an available subnet (a randomly picked one) and attempt to register it by creating a key in etcd
• Works under Kubernetes
• Resolve the problem of native Docker networking where network address was hidden from the network outside of the Docker host machine
• It can work on any exiting network without changes to that network.

 

image source: https://github.com/coreos/flannel/blob/master/packet-01

Weave

• reference article
• An overlay networking system for Docker container
• Open source back by a commercial company Zettio
• The system consists of two components:
• Weaver - a virtual network switch and router implemented in Go that runs within a Docker container on each networked host.
• Weave - a script that wraps the Docker command line in order to start Weaver, connect containers to the Weave virtual network, and assign IP addresses to them.
• Zettio founder Alexis Richardson said "Weave makes the network fit the application, not the other way round"
• Can be think of as "a giant Ethernet switch to which all the containers are connected"
• Weave network can be encrypted
• Simplies the process of connecting containers together instead of using Open vSwitch

image source: http://www.infoq.com/resource/news/2014/09/zettio_releases_weave/en/resources/1Weave.png

Pipework

• reference article.
• Docker creates a special Linux bridge called docker0 on startup. 
• All containers are automatically connected to this bridge and the IP subnet for all containers is randomly set by Docker. 
• Currently, it is not possible to directly influence the particular IP address of a Docker container.  
• pipework is a shell script which user can use to add another interface to a container with a specified IP address.

SDN
SDN is an hot topic and Docker is another hot topic and what is going to happen when we put SDN and Docker together?

Recently a new startup SocketPlane has an idea of bringing Open vSwitch to the Docket host.  I read an article from SDN Central about SocketPlane:

• To have a container that is going to be able to manage the data path
• Also able to manage either overlays or underlays
• Will focus on network management and network services instead of the network system
• Will also address problems with DevOps with various Configuration Management Tools

When we go to SocketPlane's website you will see "Native to Docker", "Familiar to NetOps" and "Application Friendly".  I think this 3 phases summarize the product direction that this company is heading.  One thing to note is that the founders of this startup are all veterans of the OpenDayLight projects along with former executive from OpsCode/Chef.

I have another post on OpenDayLight previously, please take a look if you are interested. :)

Bring SDN to Docker can open up using a container for NFV or in this case NFD (Network Function Dockerization) <- a new name that I come up with based on the word "Dockerize"

Reference:
"CoreOS." CoreOS Blog ATOM. N.p., n.d. Web. 26 Oct. 2014.
"Coreos/flannel." GitHub. N.p., n.d. Web. 26 Oct. 2014.
"Zettio Releases Weave for Docker Networking." InfoQ. N.p., n.d. Web. 26 Oct. 2014.
"Docker Networking Made Simple or 3 Ways to Connect LXC Containers - Codecentric Blog." Codecentric Blog. N.p., n.d. Web. 26 Oct. 2014.
"OpenDaylight Coders Open Shop on a Docker Startup." SDNCentral. N.p., n.d. Web. 26 Oct. 2014.
"Docker Networking Made Simple or 3 Ways to Connect LXC Containers - Codecentric Blog." Codecentric Blog. N.p., n.d. Web. 26 Oct. 2014.

Docker – A Technology that VMware also embraces

Often time there is the notion that with Docker, the Linux Container technology is going to replace server virtualization.  The reasoning for this thought is that with Linux Container virtualize application on the operating system level in which the hypervisor is no longer needed. 

Another camp of thought is that container does not have the robustness and enterprise ready feature such as resource allocation management, high availability or even manageability that can be offered by VMware.

In VMworld 2014, VMware CEO Pat Gelsinger on his keynote session announced the collaboration of VMware, Google and Docker in the Software Defined Data Center (SDDC) sighting that running Docker on a virtual machine is the best of both world giving user a lot more flexibility and benefits.

What is Docker

Docker, Inc is the company behind the open source Docker platform.

Docker is an orchestration or packaging tool that allows applications and their dependencies to run on container technology. 

According to this article Docker consist of:

• Docker Engine – a portable, lightweight run time and packaging tool.
• Docker Hub – a cloud service for sharing application and automating workflow.

It is all about:  APPLICATION.

Before we dig deeper into Docker we have to look into the container technology.

Container

Container is not a new technology.  We can trace the origin to FreeBSD Jails back to year 2000 where programs are run in a sandbox.  Solaris (now part of Oracle) has this implemented as zones.

We can look at container as operating system level virtualization in which application in a container is isolated from each other but are running on the same operating system which is on a single host. 

Google has its own version of container – Imctfy and is being used heavily to support Google Search Engine, Gmail and other Google applications.

Native Linux has container build upon cgroup and namespaces but it is not so easy to deploy application with LXC and thus this technology is not popular in the enterprise space.  Docker is making this much easier both for developer and sys Admin to deploy application with the container technology. 

Once an application is “Dockerized”, it can be run on any platform as long as the OS is the same as the container is created.  Now we can deploy container on-premises (private cloud) or move it to the public cloud such as Amazon Web Services or Google Cloud Computing.

Recently Microsoft has announced support for Docker in their public cloud – Azure.

Popular Configuration Management Tools such as Puppet and Chef can work with Docker and this made the deployment process even easier and Docker a perfect fit for DevOps.

Docket support can also be found in OpenStack Nova.

Docker Components and Technologies

Docker operates on a client and server model.  The Docker client and server/daemon can be on the same host or different host. The Docker client communicates with the Docker server/daemon using REST API.

This diagram captures the core components of Docker:

Image source: http://blog.arungupta.me/wp-content/uploads/2014/07/docker-architecture-techtip39.png

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

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

Red Hat has a good description of Docker fundamental components:

·     Container – an application sandbox. Each container is based on an image that holds necessary configuration data. When you launch a container from an image, a writable layer is added on top of this image. Every time you commit a container (using the docker commit command), a new image layer is added to store your changes.

·      Image – a static snapshot of the containers' configuration. Image is a read-only layer that is never modified, all changes are made in top-most writable layer, and can be saved only by creating a new image. Each image depends on one or more parent images.

·      Registry – a repository of images. Registries are public or private repositories that contain images available for download. Some registries allow users to upload images to make them available to others.

·      Dockerfile – a configuration file with build instructions for Docker images. Dockerfiles provide a way to automate, reuse, and share build procedures.

Along with the components let’s take a look at the technologies that make Docker works:

Namespaces

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.  There are different namespaces and examples are pid, net, ipc, mnt or uts.

Control groups/cgroups

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.

UnionFS

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.

Image source: https://docs.docker.com/terms/images/docker-filesystems-multilayer.png

Containers

Linux container (LXC) is an essential technology that Dockers uses. 

VMware Project Fargo

So how does VMware embrace Docker?  If you want more information about how VMware uses Docker this blog post is a good start.

In VMworld 2014, VMware announced Project Fargo (currently in beta as of this posting).

Project Fargo according to the blog post from the blog post mentioned is “a technology to provide a fast, scalable differential clone of a running VM” and it is particular useful in a VDI environment.  In fact, it is to make Docker containers to run faster on a VM than they are running on a native Linux machine.   

This is how VMware is saying: VMware + Docker = Best of both worlds.

More information about Project Fargo can be found here, here and here.

Ingredients of OpenStack API

In VMworld 2014, VMware announced a new product VMware Integrated OpenStack.  Currently this product is still in beta and will be available in the first quarter of 2015.

OpenStack has been a popular technology for private cloud orchestration.  In this article OpenStack is described as a modular architecture that currently has eleven components: 

• Nova - provides virtual machines (VMs) upon demand.
• Swift - provides a scalable storage system that supports object storage.
• Cinder - provides persistent block storage to guest VMs.
• Glance - provides a catalog and repository for virtual disk images.
• Keystone - provides authentication and authorization for all the OpenStack services.
• Horizon - provides a modular web-based user interface (UI) for OpenStack services.
• Neutron - provides network connectivity-as-a-service between interface devices managed by OpenStack services.
• Ceilometer - provides a single point of contact for billing systems.
• Heat - provides orchestration services for multiple composite cloud applications.
• Trove - provides database-as-a-service provisioning for relational and non-relational database engines.

 Image Source: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/3/html/Installation_and_Configuration_Guide/images/2440.png

Each component needs to obtain an authentication token from the Keystone module and this is accomplished by API.  OpenStack APIs are used to create and manage resource of each of these modules.  If we want to dig deeper into OpenStack, it is essential that we know more about OpenStack APIs. 

This OpenStack Wiki page has a good description on OpenStack API.  It stated that OpenStack API is the Management and Control plane for a Cloud Infrastructure built using the various components (see above).  A few things were mentioned about OpenStack API:

• it is REST-ful
• JSON based
• Each core project will expose one or more RESTful interface for the purpose of interacting with the outside world.

Let’s look at some of the ingredients that make up of OpenStack API.

RESTful HTTP API

REST stands for Representational State Transfer and it is an architecture that generally runs over HTTP.  REST can be looked at as a light weighted web services

Good articles for REST can be found in here and here.

REST APIs are used by many “well known” applications such as PayPal, Twitter and Facebook, Google and mobile devices.  The list can go on and on.

In the context of OpenStack we can see that RESTful APIs has the following characteristics:

• Stateless
• Use of URI to expose resources
• Noun based protocol e.g. GET, POST, DELETE etc

Besides being used by the various OpenStack components for management and control, REST API is heavily used by the Swift component for operations such as creation, deletion and/or retrieval of the object storage elements.

JSON

JSON stands for JavaScript Object Notation and it is a lightweight data-interchange format.  The official website for JSON is here. It mentioned that JSON is built on 2 structures:

• A collection of name/value pairs
• An ordered list of values

Scott Lowe has a nice article on JSON as well as links to other useful page for getting to know JSON.

This picture shows how JSON is used in RESTful API

 image source: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgR9fOeuiLfeDczMm29hWeHOcSjeFDsY8qvD_PjCWH64ATDOSsB_ZM6SvyH-PYtLhxqTW8spTC9PWX_pk1ThvCm_0rnGpwtSZ8aZ_9COVT0pVHXQ6QBQZ_7m5NCYWHZXZBcn95Yoo3wcf8/s1600/json-rest3.png

WSGI

WSGI stands for Web Server Gateway Interface is a specification for simple and universal interface between web servers and web applications or frameworks for Pythons according to Wikipedia. 

OpenStack is written in Python and WSGI is a natural fit if an OpenStack component needs to implement a web based framework to handle the RESTful HTTP request and to provide the response.  It can be looked as a “Middle-ware” for the module.

This may not be directly related to OpenStack API, we can find WSGI modules in the Nova and Neutron component as well as the Swift component.

The Ceilometer components, however, used Flask instead of the WSGI framework.

Authentication

OpenStack API is a very powerful tool.  One aspect that we cannot ignore is security. 

At the very least for the RESTful HTTP based OpenStack API can be configured to use HTTPS instead of HTTP.

RESTful HTTP API has 3 kinds of message authentication method:

• Basic HTTP
• OAuth
• None

I have not looked at OAuth but this is used extensively in OpenStack.

In Keystone (OpenStack Identity Service), the identity-api is in fact the entry point for all service API in which Keystone issue a token to client and this token is used for any API calls to the OpenStack API end points such as nova-api, glance-api , neutron-api … etc.

OpenDaylight - an alternative to VMware NSX and Cisco XNC.

Before I worked on this blog post, I always think that OpenDaylight is a SDN Controller.  While it is correct to say that OpenDaylight is a SDN controller, it is in fact an Open Source project in which the controller is the core functionality.  In OpenDaylight wiki page, we can see a list of projects that is under the umbrella of OpenDaylight Project from the Linux Foundation. 

OpenDaylight Project is described by this web site as:

The OpenDaylight Project is a collaborative open source project that aims to accelerate adoption of Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) for a more transparent approach that fosters new innovation and reduces risk. Founded by industry leaders and open to all, the OpenDaylight community is developing a common, open SDN framework consisting of code and blueprints

According to Neel Jacques, executive director of OpenDaylight:

“The OpenDaylight community has taken on the monumental task of bringing together all the disparate technologies, thoughts and ideas around SDN and forming it into a cohesive platform. The community has made amazing progress in a short amount of time as you can see in this second release which integrates more functionality, apps and use cases. Helium brings us one step closer to having one common platform the entire industry can standardize on.”

OpenStack name its release by city or street name.  OpenDaylight name its release by elements in the Periodic Table.  The first release was Hydrogen and the second release was Helium.  The OpenDaylight Helium release was available for download as of September 29, 1014.

Image source: https://www.sdncentral.com/wp-content/uploads/2014/09/opendaylight-project-helium-diagram.jpg

From OpenDaylight’s announcement “OpenDaylight paves way for innovation in SDN with latest open source software release”, I have summarized what’s new in the Helium release:

• 11 new protocols, applications and technologies
• New User Interface
• Simpler and customizable installation process
• User can build on-demand combinations of components and features to customize their solutions
• Open vSwitch Database Integration Project that provides technology preview of advanced OpenStack features
• High Availability
• Clustering
• Security
• OpenFlow Table Type Patterns
• Service Function Chaining

There are 3 things that I would like to highlight and comment:

1. Apache Karaf

One good feature for the Helium release is that user can build on-demand combinations of components and features for OpenDaylight.  This is done by Apache Karaf which is a small OSGi (Open Service Gateway initiative) based run time lightweight container where different components and applications can be deployed.  The best feature in my opinion is the ability to check for component dependencies.  Remember the days how we install packages onto a Linux system before apt-get or yum?

2. Integration with OpenStack

I believe for OpenDaylight to have more integration with OpenStack will entice more commercial IT vendors to embrace OpenDaylight.  Both VMware and Cisco announced integration with OpenStack and there are quite a few companies such as Rackspace, Metacloud, Mirantis, Cloudscaling, IBM and Red Hat that provide value added and easy installation for the Open Source OpenStack.

Work is done for the OVSDB (Open vSwitch Database) driver to provide features such as:

• Distributed L3 Forwarding
• Distributed ARP handling
• Security Group
• Load Balancing as a Service
• Firewall as a Service

This makes OpenDaylight an attractive choice as a OpenStack Neutron back end.  Also, there is a new feature to provide VLAN networking in addition to the tunnel-based networking option when a virtual network is created in OpenStack Neutron.

Interface with OpenStack with Keystone via the OpenDaylight AAA project is a big step forward between OpenDaylight and OpenStack integration.

3. Security

In the Hydrogen release, there is the Defense4All project for mitigating Distributed DoS attacks.  In the Helium there are 2 new projects for security:

1. Authentication, Authorization and Accounting (AAA)
2. Secure Network Bootstrapping Infrastructure (SNBi) project.

In this article, author Sean Michael Kerner stated that “Security is a particular area of focus in the Helium release”.

Authentication, Authorization and Accounting

AAA has been around for some time and is a popular and widely used security architecture where user’s credential is authenticated and based on the outcome of the authentication process, access for resources are granted/authorized while accounting will record this process so as to provide an audit trail.

According to a Red Hat blog, AAA project provides:

1. The ability to provide fine-grained permissions for resource usage
2. The ability to share an external identity service with other platforms

In our case as mentioned on the previous section, the external identity service will be OpenStack Keystone.

Secure Network Bootstrapping Infrastructure

This feature helps to solve the problem of having to manually distribute keys for the different networking device to communicate with each other. 

This page has more information about how this works.

Conclusion:

Besides, OpenStack integration and security both High Availability and clustering are important feature for the enterprise. OpenDaylight Helium is a big step forward from the Hydrogen release and hopefully more vendors will embrace OpenDaylight and provide this as an alternative to 

• Cisco - Extensible Network Controller
• HP - Virtual Application Networks (VAN) Controller
• NEC - ProgrammableFlow PF6800 Controller
• Nuage Networks - Virtualized Services Controller  
• VMware - NSX Controller