This short series of posts will be our first look at using the Nutanix Docker Machine and the Nutanix volume driver plugin to configure “stateful” or “pet” type containers (as contrasted with “stateless” or “cattle” type containers). In the original pets vs. cattle analogy, pets were the two-node failover clusters that ran large databases on big iron systems, while cattle were the more cloud-aware, horizontal scale-out applications designed to handle failure.
As the popularity of containers has risen recently—as has the use of Docker to deliver them—these categories have been reassigned. Now, many in the container community believe that only ephemeral or stateless apps are suited to running in containers, while, somewhat ironically, the applications previously defined as cattle have become today’s pet workloads.
Otherwise, where’s the audit trail when things go wrong? Although long-lived pet-like applications, or services, are more complex than cattle when it comes to production-ready deployment, they similarly require persistent storage that can exist both outside and independent of a container runtime.
Consider the fact that containers allow us to roll out an application as an immutable image, handling versioning and dependencies implicitly. Why would we not want the same convenient unit of deployment for our longer-running services? These services are still just applications, after all, and have similar dependencies and environment requirements, easily satisfied by running in a container.
The major hurdle to overcome when trying to containerize pet applications is figuring out how to put data volumes on backend storage subsystems. Running persistent volumes that containers in virtual machines (VMs) can consume is another step toward production deployment of containerized cloud-native application services.
Dockerized VMs with Persistent Volumes
Since Nutanix released both a Docker Machine driver and a persistent volume driver plugin earlier this summer with Acropolis 4.7, I have been keen to look at how we can support more stateful deployments. Rather than look at more readily containerized frontend cattle apps (such as nginx or apache), in this series I want to go over deploying a cloud-native database, like MongoDB, to showcase some of the Docker ecosystem integration work that Nutanix has been doing.
MongoDB, a NoSQL database that scales horizontally, can take full advantage of the Nutanix web-scale architecture. The I/O intensive nature of a database workload can mean that you need to write directly to specialized storage. If that storage is distributed, the service can take advantage of stateful failover between hosts. Stateful failover in turn facilitates faster recovery by shortening the period of potential downtime.
For the purposes of this article, pet or stateful containers are simply long-running services that require the data persistence provided by the Nutanix volume driver and the mobility afforded by running the service as a VM on AHV. To provision such VMs, the Nutanix Docker Machine driver preinstalls the Docker Engine and configures secure certificate access for SSH.
The prospect of spinning up a containerized database has been a bit controversial, but vendors and ultimately end users are coming around to the idea. For one thing, it’s been considered something that’s hard to do. For another, there seems to be some general reluctance to run a production database in a container, in much the same way that we saw resistance to running databases in VMs lingering until the last few years.
Nutanix Acropolis Container Services
Just so we’re all on the same page, let’s describe the implications of the Docker Machine driver and the persistent volume driver plugin in conjunction with the rest of the Nutanix Enterprise Cloud Platform. Docker Machine spins up VMs running the Docker Engine on desktop VMs and on public and private cloud provider targets, like AWS, Digital Ocean, and so on. Now, with the Docker Machine driver for Nutanix, we can also use the Nutanix platform as an on-premise backend target.
This option means that we can provision and remotely manage CentOS-based VMs with a preinstalled Docker Engine. From your laptop or workstation, you can now build out virtual environments to form clusters of Docker hosts—the first step in any orchestration play going forward. In addition, the Nutanix driver takes care of all security certificates (TLS) for remote SSH access.
The Nutanix persistent volume driver plugin uses a sidekick container pattern. This sidekick container calls the Docker Volume API to create a block storage (iSCSI) volume in a Nutanix volume group (VG) within the Nutanix Distributed Storage Fabric (DSF). The resulting iSCSI volume attaches to the sidekick or data-only container.
When you create application containers that require persistent storage volumes, they can map the volumes already created on the container host to their own container runtime. Subsequently, when you need to rebuild or destroy the application for any reason, the iSCSI volume in the VG on the Nutanix storage container preserves all data. When you rebuild an application container that needs that data, the volume is available for reuse.
In the next post, we’ll cover the installation and setup of both the Nutanix driver for Docker Machine, and the Nutanix volume plugin.
If you’re working on stateful services that run in a hybrid cloud environment, we would love to talk more and share experiences. Get in touch with us via our social media channels or the Nutanix Community Forums.
Disclaimer: This blog contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites, and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.