November 4, 2015 | Written by: Lin Sun
Share this post:
Have you heard all the buzz around Docker? Have you ever tried to run a Docker container on your laptop or even in the Cloud like IBM Bluemix? Assuming you have, have you ever discovered that you need more than one Docker images in your application so that your Docker container can do more than “Hello World”? As you need to build more interesting cloud native applications, it is critical for you to have a “prescription” for building multi-container packaged applications and run these applications in the cloud. There is a growing container orchestration ecosystem that is dedicated to solving this!
What is Container Orchestration?
Container Orchestration allows users to define how to coordinate the containers in the cloud when the multi-container packaged application is deployed. For example, users can define a reliable and scalable Redis cluster that is composed of Redis master containers and Redis sentinel containers. Container orchestration defines not only the initial deployment of the containers, but also the management of the multi-containers as a single entity, such as availability, scaling and networking of the containers. For example, instead of managing individual containers in the Redis cluster, you can manage all the containers within the cluster together!
Four key players drive Container Orchestration forward
If you are familiar with OpenStack HOT document or IBM Pure Application System pattern definition, or AWS cloud formation document, you know those are key definitions to allow you to orchestrate multiple VMs in the cloud. Likewise, we need similar container orchestration definition, ideally in a standard open format so it is portable among multiple container cloud providers.
Luckily, the Cloud Native Computing Foundation (CNCF) was formed in July 2015 to create and drive the standards and adoption of container packaged application, with Kubernetes as the seeding technology. I had the privilege to play with some of the open technology in container orchestration ecosystem lately and wanted to share the few key players with you!
Docker Swarm and Compose
When you first start learning Docker, you probably use Docker CLI to interact with your Docker Daemon on your local machine to execute Docker commands. What if you want to run multiple Docker containers among different machines in the cloud? Docker Swarm provides native clustering capabilities to turn a group of Docker engines into a single, virtual Docker Engine. As a user, you can use your same Docker CLI commands to run your containers on a group of machines, after a simple configuration to set your DOCKER_HOST to point to your Swarm manager. Docker Compose is a tool for defining and running multi-container applications with Docker. With Compose, you define a multi-container application in a single file, then spin your application up in a single command which can stand up multiple containers with the declared relationship. Production-ready Swarm 1.0 was just released in early Nov for you to deploy your applications in production!
How many times have you used google search engine within a single day? Did you know that with every single search off google search engine, Google spins a container under the cover?! Envision you need to deploy a cloud native application that has multiple components (UI, Catalog, Cart, and Database) and each is represented as Docker containers, you can write Kubernetes pod and/or service definition to help you orchestrate these containers! Kubernetes is an open source orchestration system for Docker containers, based on Google’s internal container-oriented cluster-management system, Borg. Kubernetes has incorporated a few key features from Borg, such as Pods, Services, Replication Controllers, and Labels. I am happy to see Kubernetes as the seeding technology for CNCF given the history of Borg and widely use of Borg within Google, including its famous search engine!
Envision you need to run a few different frameworks, and each framework need at least a couple of dedicated hosts. Wouldn’t it be better if these few different frameworks share the same hosts as a single resource pool? Apache Mesos is designed to help with this! Mesos is a resource manager for all frameworks installed onto Mesos. A common misperception is that Mesos is also a scheduler but it is actually not, the framework itself handles the scheduling work among the certain hosts that is been designated by Mesos. Mesos has a Master and Agent architecture where Master handles agent and framework registration and monitors their status. Mesos Master also aggregates the resource from hosts and make resource distribution among registered frameworks such as Marathon, Swarm, Kubernetes, Hadoop, Spark, to name a few.
Assuming you are looking at Mesos and a few frameworks on top of Mesos, would you like to manage these frameworks yourself, even when you are sleeping? If not, Mesosphere Marathon is your answer! Marathon allows users to easily deploy and manage Docker containers on top of Mesos at scale. Marathon itself is installed as a framework on top of Mesos to run long-running applications including Docker based applications. You can define Marathon application or application group definition, and use Marathon’s simple API or UI or Mesosphere’s DCOS (Data Center Operating System) CLI to deploy and run the application. Marathon can launch anything that can be launched in a standard shell, including frameworks on top of Mesos, and ensure the Marathon application deployments survive machine failures.
I have been amazed at how relatively easy to install and configure these projects! There are tons of get started documentation from the communities. You can setup Swarm or Kubernetes standalone by itself, or you can run Swarm on Mesos or Kubernetes on Mesos so that you could have Mesos to manage resources for all the hosts among multiple frameworks you need such as Swarm or Kubernetes or Spark or others. You could even choose to have Swarm or Kubernetes deployed as Marathon application onto Apache Mesos, so that Marathon can help you monitor closely the health status of Swarm or Kubernetes and recover it as needed!
The Open Way is the only way!
I am excited to see the crazy container orchestration ecosystem as the community is taking users’ experience to beyond single container! Further, I’m even excited to see the common standards and foundation built around the container orchestration ecosystem, e.g. CNCF to drive an industry standard around container packaged application. I look forward to see where CNCF is taking this rapidly evolving community to! Jerry Cuomo, IBM Fellow and VP, said “The open way is the only way! Our users will thank us! :-)” at DockerCon 2014 keynote. IBM has been a key open technology adopter for many years, and 80% of IBM Cloud is based on open technology! I look forward to seeing IBM Bluemix Container service to adopt some of these open technologies!! I know “our users will thank us!”. 🙂