Docker

During the VMworld 2016, one thing that struck me was the continued focus VMware appears to have on containerisation. I have been looking at containerisation over the last year and half with interest to understand the conept, current capabilities of the available platforms and the practical use for the typical customer. I was also naturally keen on what companies such as VMware and Microsoft have to offer on the same front. VMware annouced number of initiatives such as vSphere Integrated Containers & the Photon platform during VMworld 2015 as their answers to the containerisation and having been looking at their solutions, and also having seen & listened to various speakers / engineers / evagelists during the VMworld 2016 US event, it kind of emphesized the need for me to venture further in to containerisation and especially, VMware’s solutions to containerisation. So Im gonna begin with a quick intro blog post about one of VMware’s approach to containers and what my thoughts are on the solution. I will aim to provide future posts to dig deeper in to th architecture and the deployment apsect of it…etc.

On the front of containers, VMware’s strategy is focused on 2 key solution offerings, vSphere Integrated Containers and Photon platform. While the Photon solution is not yet quite ready for production deployment in my view, its aimed at all greenfield customers who currently do not have legacy vSphere deployments and are strating out afresh. VIC on the other hand is available today & specially aimed at existring vSphere customers hence the main focus of this post.

vSphere Integrated Containers (VIC)

This is the containerisation solution for existing VMware vSphere customers and has been designed for extending vSphere capabilities to the containerised world (or vise versa, depending on how you look at it). It is predominantly aimed at existing vSphere customers who are wanting to jump on to or explore containerised app development for production use.

For those of you who are new to VIC, here’s a quick intro.

In addiiton to typical vSphere components, VIC solution itself consist of 3 main components

1. VIC Engine – A container run time for vSphere which is deployed on to ESXi. This is an OpenSource development and is available on GitHub. This allows developpers familer wiyth Docker container developments to deploy them alongside existing VMs on an ESXi / vSphere platform and is directly manageable from using the vSphere UI (Web Client). VIC engine is referred to as VCH (Virtual Container Host) and is backed by a vSphere resource pool typically within a cluster. It also containes a copy of the conatainer images which are mapped as vmdk’s on tradiitonal vSphere components such as a VSAN datastore.                    
2. Harbour – An enterprise class registry service that stores & distributes Docker images that also include additional security, identity and management for the enterprise. Can be used as a lovcal, on-premise Docker repository so that enterprises using Docker containers won’t have to worry about the security concerns of using the public Docker repository over internet
3. Admiral – Scalable, lightweight container management playtform used to deploy and manage container based applications

Together with vSphere, VIC provide the customers the ability to deliver a containr based solution in a production environment without having to build a dedicated environment exclusively for the containers.

The main difference between a native container approach such as native Docker on Linux Vs VIC is that,

• Docker on Linux:  Docker outilises native Linux concept called namespaces. While more inforamtion can be found here, Docker on Linux relies on spewing multiple namespaces / containers within the same Linux server instance so spinning up an applicatiojn service 9that runs inside a container) is super fast (say, compared to powering on a VM with a full blown OS which takes time to load up and then launch the application). Same applies when you stop an application service (just stops the underlying container on th eLinux kerner). Both these operations are executed in memory.

• VMware Integrated Containers:  The container instance runs in a dedicated, micro OSE (Operating System Environment) called JeVM (Just Enough VM) which consist of a minimalistick version of Linux kernel that is just sufficient to run a container instance.. This kernal is derived from VMware’s project Photon. Photon platform itself is seperate to VIC solution and is supposed to be the second approach VMware are taking for conatiners and Cloud Native Applications, especifically aimed at greenfield deployments where you do not have an existing vSphere stack. in the case of VIC, it is important to remember that the Photon project code used within this micro VM consist of the minimal requirements to run a Docker container instance (Linux kernel and few addiitonal supporting resources giving it a minimum footprint). This Je VM instance is also using the instance clone feature available on vSphere 6.0 to quickly spin up Je VM’s for container instantiation (upon “docker run” for exmaple) so they strats up and closes down at near native speeds to that of a native container on Linux. In return for this fat client approach, customer gets a similar experience when it comes to managing these conatiner environments to that of thatier legacy infrastructure as the existing VMware tools such as vROPS, NSX…etc are all compatible with them (no such compatibility when runniong native Linux containers with Docker)

The typical VIC architecture looks like below

At the foundation of VIC is vSphere, the same infrastructure that customers have standardized on for all applications from test/dev to business critical apps. VIC adds a graphical plug in to the Web Client for management and monitoring. The Virtual Container Host provides a Docker API endpoint backed by a vSphere resource pool – beyond one VM or dedicated physical host. Instant Clone Template is running Photon OS Linux kernel. Developers interact from standard Docker command line interfaces or API clients. Docker commands are mapped to corresponding vSphere actions by the VCH. A request to run a new image invokes Instant Clone to rapidly fork new “just enough” VMs (Je VM) for execution of the container. Traditional apps can also run alongside containers on the VCH.

As for my thoughts, if you are an existing VMware customer, VIC gives you get the best of both worlds where you can benefit from the existing infrastructure while also benefiting from the agility available through the use of Docker container instances. For example, during the VMworld 2016 US event, VMware’s head of Cloud Native Applications BU, Kit Colbert demoed the integration of vSphere Integrated Containers with vROPS where even containerised apps can have the typical health and performance details shown via vROPS dashboards, much like legacy apps and such capabilities that are not natively available with vanila Docker instances. He also demoed the vRA integration which enables developers to self service containerised application storage placement through a policy change which automatically move the container VM / image content over from one VSAN storage tier to another. I believe such inter-operability and integration with th elegacy toolkit is very important for mass adoption of containerised apps going forward, especially for existing customers with legacy tools and apps. Furthermore, VIC solution also integrate with NSX for extending networking security components in to the container VMs / instance too which is totally cool.

Most importantly, VIC is available free as an opensource download for all VMware customers which makes the case for it even more appealing.

Cheers

Chan

P.S. Slide credit goes to VMware

#Cloud Native #VIC #Photon #VMware #VMworld