Understanding Cattle, Swarm and Kubernetes in Rancher

*Note: Since publishing this post, we’ve created a guide comparing
Kubernetes with Docker Swarm. You can read the details in the blog post
here..*
Over the last six months, Rancher has grown very quickly, and now
includes support for multiple orchestration frameworks in addition to
Cattle, Rancher’s native orchestrator. The first framework to arrive
was Kubernetes, and not long
after, Docker Swarm was added. This week,
the team at Rancher added support
for Mesos.
For this article, I’m going to focus on Cattle, Swarm, and Kubernetes,
and as I gain experience with Mesos, I’ll share my thoughts in another
post. Rancher’s support for these different orchestration platforms is
delivered by creating isolated “environments.” When a user or admin
creates an environment, they select the orchestration platform he or
she wants to use, and which users will have access to the new cluster.
Rancher works with Active Directory, LDAP and GitHub, so you can grant
different access privileges to teams or individual on a per cluster
basis. Once you’ve created the environment, Rancher prompts you to add
“hosts,” which are just Linux physical or virtual machines that
running Docker and Rancher’s agent, which is a container. As soon as
the first hosts are added, Rancher begins deploying the orchestration
framework you’ve chosen, and you can start using your new environment.
Each of these orchestration platforms has a different set of
capabilities. For this article, I won’t try to provide a list pros and
cons for each, or a long table comparing features. They are all changing
very quickly, so anything I write would be out of date within a month or
two. Instead, I’ll share some of my personal experiences with all
three, and the scenarios in which I use each of the three frameworks.
Rancher makes it so easy to deploy each of these that I highly recommend
you try them out for yourself and determine which fits your project
best.

Three Frameworks

First, it is important to note that while deploying a new host with
Cattle is almost immediate, doing it with Swarm and Kubernetes can
take 5-10 minutes as servers are added and each orchestration framework
is implemented. From a user perspective, it isn’t any more complex to
deploy the different platforms, as Rancher automates all the deployment
and configuration of the orchestration platforms. The Kubernetes
framework typically takes the longest to launch, as it is built as a set
of microservices such as etcd (a distributed key-value store for the
cluster), the kubernetes master, kubernetes scheduler, and a handful of
other Kubernetes-native services.

Cattle

Cattle was the first orchestration framework available when Rancher
started its beta last June. Because of this, it feels quite mature and
stable, and the user experience is very good. At its core, Cattle
should feel very familiar to anyone familiar with Docker. It is based on
Docker commands and leverages docker-compose to define application
blueprints. Application deployments are organized into “stacks,” which
can be launched directly from an application catalog, automatically
provisioned from a docker-compose.yml file and extended with a
rancher-compose.yml file, or created directly within the UI. Each stack
is a made up of “services,” which are primarily a docker image, along
with scaling information, health checks, service discovery links, and a
host of other configurables. You can also include load balancing
services and externals services into a cattle stack. Because it has been
around for so long, Cattle has developed a very large application
catalog, the vast majority of which has been developed by users and
contributed to
the rancher/community-catalog
github repo. You can now choose from more than 50 different apps, all
of which are defined using a docker-compose file and a rancher-compose
file, and deploy them with a single click. This is the kind of
capability that we like most here
at FricolaB. You can even build a
private catalog from your own git repo, and expose it within your
environment from the settings tab within Rancher. In the example
illustrated in the screenshot, we have created a stack for Gogs, an
application that provides similar functionality to Github, based on the
Go language. In this stack, we have added a load balancer service to
make the external http port that provides access to the graphical Gogs
interface available in a custom subdomain of our server. Thus, our final
deployment will consist simply of three containers; a container with the
database, another with the application, and a third container with a
load balancer.
The Cattle community app catalog

Swarm

Docker Swarm is the native Docker clustering system, and important for
anyone who will be working heavily in the Docker ecosystem. I think it
is important for any container management platform to support Swarm, as
it will probably be the most familiar platform for many users. Because
it uses the native Docker API, orchestrating a cluster with Docker
Swarm allows us to keep compatibility with other standard tools. For
example, EduCaaS, a project that FricolaB
is developing with MTA, provides
users with a simple graphical interface based on Docker Swarm to manage
their applications but platform administrators still have perfect
control of all applications being deployed on the platform from within
Rancher GUI.
Adding hosts and services for Swarm within Rancher Swarm
initial deployment, as already mentioned, is a bit more complex than
Cattle. It uses two extra containers in addition to the Rancher agent:
one acts as Swarm master node and the other one a first client node. We
can check it out inside the System section, which now appears inside of
the new menu item, Swarm, which replaces the Application menu once we
have chosen Swarm as our orchestrator. System submenu is equivalent to
the one we had before with Cattle called “Stacks”. In fact, there we can
still control the stacks that had been created before using Cattle. Now
in this new menu we have three elements. One of them provides us access
to our server via terminal, allowing us to download the configuration
file, connect to the remote Docker socket, and manage our server from
the PC using Docker or Docker Compose. The other two tabs, Projects and
Services, show the containers we are deploying inside Swarm. From
Projects, we can add stacks from the internal catalog or attach a custom
docker-compose.yml file. The Services tab will show individual services
already deployed, indicating the number of containers available for each
service. Every time we deploy a project on our cluster Swarm, a
container will be included within each cluster node, so if we have a
cluster consisting of 4 nodes each service will have 4 containers
associated. This is similar to the way Docker Swarm deployments work
without Rancher.

Kubernetes

Managing Kubernetes services within Rancher For users
familiar with Docker, Kubernetes can have the biggest learning curve of
all these scheduling options. Many of the concepts are quite different
in Kubernetes from Swarm or Cattle, which both will feel very familiar
to anyone who knows Docker. For example, in Kubernetes, the initial
deployment is not a container, but instead a “pod,” which can include
multiple containers. These pods are then assigned to services and
scaling is managed by replication controllers. All of this is pretty
easy to understand once you’ve spun up a Kubernetes environment in
Rancher. The initial deployment of Kubernetes takes a few minutes,
since [as previously described], it is built using a number of
microservices, and with kubelets and proxy services on each hosts.
However, Rancher makes using Kubernetes quite easy by automating the
deployment and scaling of the cluster, and creating an initial namespace
as soon as you add your first host. One thing to note, it probably makes
sense to deploy Kubernetes on multiple VMs. I tried to deploy it once
on a single 4GB RAM server, and spinning everything up took more than 15
minutes, and sometimes failed due to lack of memory. Once you have the
cluster running, you can access it through the Rancher UI, and directly
log into kubectl. You can also manage manage all deployed services, pods
and replication controllers from the UI, and deploy applications from
the Kubernetes catalog.

Closing Note

Although it is not the purpose of this post to make a value judgment
about the three orchestrators, it would be unfair not to mention that
the first two are my favorites. I use Cattle in almost all the
environments I manage with Rancher, but I opt for Swarm when it comes to
servers in which I have delegated certain management functions to users,
since Docker ecosystem provides numerous tools that are worth using in
parallel. Obviously, this is just my point of view: the right solution
is always what meets your needs! *David Lareo is a Rancher user and the
founder of FricolaB. He designs products and
services that respect the fundamental values of the hacker ethic, such
as social awareness, accessibility. *