Posted on 11 Aug 2016 by Ray Heffer
For some time now I’ve been trying to free up some time to get stuck into the Photon Platform and gain a better understanding of Cloud Native Applications. Container technology (i.e. Docker) is starting to gain traction in production environments and it’s a popular topic amongst the developer community.
I am particularly interested in End User Computing solutions for developers, and multi-tenant platforms for Cloud Native Applications. As an architect at VMware, I have a lot in common with Sam. While I am comfortable in various scripting languages, technology like Docker is fairly new to me so the purpose of this post is to approach learning this topic from the perspective of a VMware architect.
Let’s break the ice and introduce our 8-bit friends!
On the left we have Jess, our developer with a cool Docker beanie hat. She wants to develop applications and package them using Docker on her laptop. The application containers she creates are shipped to her client for testing, and once her application is ready for production it gets deployed to the cloud. She doesn’t really care about cloud infrastructure… she just loves coding!
On the right we have Sam, our VMware infrastructure guy in a cool VMware Photon t-shirt. He wants to give developers in his organization, like Jess, the agility they need to develop awesome applications. He doesn’t know much about coding applications but he loves VMware infrastructure.
This is ‘kind of’ what DevOps is about, but I can’t do it justice without recommending The Phoenix Project. I’ve shared this on Twitter before as it’s a fantastic novel about Bill and his journey to the art of DevOps.
The whole purpose of containers is to wrap up application code, runtime, system tools, and its dependent libraries in order to deliver your server-side applications and make them extremely portable. In 1979, Unix introduced the concept of containers with chroot. Just search my site for chroot and you’ll find I use it to ‘jail’ Secure FTP and SSH user accounts to their home directory. For web servers it isolates the root directory of a process (e.g. Apache) as shown in this example below. It’s incredibly useful, especially for web hosting.
The reason I bring up chroot is critical here. Containers are more closely related to chroot than they are to virtual machines. You see, containers don’t virtualize any hardware like vSphere does, it simply contains the application process tree and directories. Like the old saying goes, you can’t compare apples to oranges.
Linux later introduced other container technologies such as LXC, but Docker really simplified the usage of containers and made them extremely portable, from the laptop to a private or cloud infrastructure.
|Docker Image||Images are created with the ‘build’ command and stored in a Docker Registry. When an image is ‘run’ it produces a container. Think of an image as a container snapshot|
|Docker Host||This is the Docker server host that runs your containers|
|Docker Client||Connects to a Docker host to manage your containers and search the registry for images|
|Docker Registry||This is where you store your Docker images|
|Docker Hub||This is a public Docker registry|
At the heart of VMware Cloud-Native Applications (CNA) is the VMware Photon Platform. This is the infrastructure required to run containers and your cloud-native applications. Before we look at what that actually looks like let’s address one burning topic. If containers are so portable and so damn cool, then why do we need VMware and the Photon Platform? Well, remember I said that containers are more closely related to chroot than they are virtual machines?
For starters, it’s no secret that the biggest concern with containers is security. We also know that our developer (Jess) wants to focus on coding, not host management, networking, firewalls, load-balancers, storage, and so on. Sam on the other hand loves that stuff, so he’s now implementing the Photon Platform and leveraging other VMware technologies such as NSX and Virtual SAN (VSAN).
If we take the Photon Platform components from this diagram we have the following:
I’ll dive into each of these in more detail, but before I do that, let me quickly introduce vSphere Integrated Containers (VIC). vSphere Integrated Containers
VIC is a container runtime for vSphere that provides develops access to the Docker command line interface. This is called the vSphere Container Host (VCH), and each container host is backed by a vSphere cluster or resource pool.
To manage vSphere Integrated Containers (container hosts), there is a new vSphere Web Client plugin that allows the administrator (our guy Sam!) to create container hosts for developer environments (e.g. Dev, UAT,QA, Production).
When the developer (Jess) uses the Docker command line interface to create a container, VIC will use vSphere Instant Clone technology to ‘fork’ and the Photon OS virtual machine. Jess see’s the pool of resources available, which is the vSphere cluster, but doesn’t have to worry about provisioning virtual machines.
I discuss Photon OS next, but for now think of these as lightweight VMs. Known as ‘Just Enough VM’, this brings the benefits of vSphere virtual machines to Docker containers.
Photon OS a lightweight open-source Linux distribution created by VMware. You can run it on VMware vSphere, Workstation, Fusion, or vCloud Air, and it supports popular container engines including Docker. You can download it from GitHub, and as of the time I write this blog post, it’s GA at version 1.0.
There are four installation options:
If you are creating your own containers and developing applications then you’ll want to select Photon Full. If you are simply running containers then just choose Photon Minimal. Full installation instructions are available on the GitHub page.
I’m a big fan of CentOS having used it since 2004, but when you want to run large scale container environments you will need a lightweight Linux host. Containers need the Linux kernel and only a few other packages to run, so Photon OS was built from scratch to be as lightweight as possible for container environments.
If you marry Photon OS with vSphere Integrated Containers, it leverages Instant Clone technology (VM Fork) to instantly clone container VMs running Photon OS. This is what we call JEVM (Just Enough VM).
Why on earth would they want a VM for every container they run? Well for one it addresses the security limitations of containers as each one is isolated in a forked VM running Photon OS. It doesn’t have the drawbacks of traditional virtual machines as they are forked or deleted when necessary. Now consider that containers need a Linux OS to run, well, now we can leverage the benefits vSphere gives with large clusters of ESXi hosts, NSX, Virtual SAN and so on.
The Photon Controller is an open-source distributed control plane that manages all of the ESXi hosts in the Photon Platform for large scale, multi-tenant deployments. It’s API driven which means you can automate operations using the REST API. If we go back to our DevOps team (Jess and Sam), they can now look even more awesome as they deploy to huge numbers of hosts. They might create the next Airbnb or Uber!
You may have heard of the term ‘Microvisor’, which is a new approach that is loosely based on the hypervisor, but is designed for micro-level virtual machines. In our case Photon Machine is based on ESXi, but integrates Photon OS and the Photon Controller.
In this article I have explained the new terminology associated with Cloud Native Applications and primarily the components of Photon Platform. If you haven’t deployed Photon OS yet then I urge you to start there. It’s a small download and doesn’t take much to get started. You can also follow Cormac Hogan’s journey into Cloud Native Applications on his blog, and in particular his getting started guide. He has no less than 25 blog posts on the subject, and probably more by the time you read this!
While I introduced vSphere Integrated Containers, at the time of writing this blog post it is still early in its release, currently version 0.4.0 (see latest release). You can track the current list of issues on GitHub.
Comments are closed for this post.