Marathon, Apache Mesos’s framework for managing containers, can make your life much easier. (That may be surprising when you consider that the first guy to run a marathon died at the end of it, at least according to the ancient Greek story, but I digress.) Like other orchestration solutions such as Kubernetes and Docker Swarm, Marathon allows you to scale your container infrastructure by automating most of the management and monitoring tasks.
Mesos Marathon has evolved into a sophisticated and feature-rich tool. You could literally write a book about it. (I’m betting someone is in the midst of that.) That means I can’t fit everything there is to know about Marathon into a single blog post. But I can go over the essentials, so I’ll explain when you should use Marathon, and introduce the basics of the tool.
Is Marathon Right for You?
The container orchestration field is now very large, with Swarm and Kubernetes representing only two of the most popular choices. (There are several others to boot, as this non-exhaustive list shows.) So you’re probably wondering why you would choose Marathon in the first place, given that you have so many other options.
I’d be crazy if I said Marathon was the right tool for every cluster. It’s not. But it does have some features that set it apart and make it an ideal choice for certain container-orchestration situations.
Marathon’s key distinguishing features include:
- Ultra-high availability. Marathon lets you run multiple schedulers at the same time so that if one goes down, the system keeps ticking. Swarm and Kubernetes are also designed to be highly available, but Marathon takes this to an extreme.
- Lots of ways to interact with and manage the service. It has a built-in Web interface. (Swarm and Kubernetes have Web UIs, too, but they’re not necessarily part of the core package.) It has multiple CLI clients (although these are add-ons, which you have to install separately). And it offers a rich API. In other words, it gives you lots of options for managing or scripting the tool in many different, complex ways.
- Application “health checks.” This feature gives you detailed information about the status of applications that Marathon is managing. If you like performance monitoring a lot, you’ll like Marathon.
- Easy to run locally for development purposes (in contrast to, for example, Kubernetes).
Last but not least, I think it’s fair to say that Marathon is a more mature tool than most other container orchestration solutions. It has been around longer and has more features. Swarm, Kubernetes and the rest of the crowd will probably catch up (and may well end up with more features than Marathon offers). But if you want an orchestration tool that is completely mature today, Marathon is an excellent choice.
Installing Marathon
One of the things I like most about Marathon is how easy it is to install. Whereas some other orchestration tools require you to use scripts to download, build and install, you can easily grab the Marathon source with a straight-forward Git clone, then make an executable JAR using the distribution-specific scripts that ship with the source.
In other words, run these commands to install Marathon on any GNU/Linux distribution:
git clone https://github.com/mesosphere/marathon.git
cd marathon
sbt assembly
./bin/build-distribution
The only potentially tricky part of these instructions (I say “potentially” because it’s not actually hard if you’re familiar with Scala applications) is the sbt tool. If you don’t already have sbt on your system, you can install it by following these instructions. Everything else is pretty straightforward.
Running Marathon
There are two different ways to use Marathon: locally for testing purposes, or in production. I’ll outline each method below.
Running Marathon Locally
As noted, a really cool thing about Marathon is that it’s easy to run locally, in case you want to play around with the UI or do other forms of testing. This feature sets it apart from a tool like Kubernetes, which you can’t run locally without resorting to some tricks (like setting up a single-node cluster through Docker running over localhost, or a resource-heavy testing environment like Vagrant).
To run Marathon locally, just launch it from the CLI in local mode with a command like:
./bin/start --master local --zk zk://localhost:2181/marathon
That’s all it takes to get the Web UI up and running at http://localhost:8080. (I told you the Web interface on Marathon was extremely easy.)
Running Marathon in a Production Cluster
Running Marathon in a production environment entails creating a Mesos cluster with Docker. Fortunately, it’s pretty simple if you use pre-built containers from Docker Hub. These are the basic steps:
First, create a ZooKeeper container. You need this to take advantage of Marathon’s high-availability mode. Here’s the command:
docker run -d -p 2181:2181 -p 2888:2888 -p 3888:3888 garland/zookeeper
Second, start a Mesos master container, so you can build your cluster:
docker run --net="host" \
-p 5050:5050 \
-e "MESOS_HOSTNAME=localhost" \
-e "MESOS_IP=localhost" \
-e "MESOS_ZK=zk://localhost:2181/mesos" \
-e "MESOS_PORT=5050" \
-e "MESOS_LOG_DIR=/var/log/mesos" \
-e "MESOS_QUORUM=1" \
-e "MESOS_REGISTRY=in_memory" \
-e "MESOS_WORK_DIR=/var/lib/mesos" \
-d \
garland/mesosphere-docker-mesos-master
If your Docker server is on a different machine than the one you’re working from, replace “localhost” in the command above with the IP of the Docker server.
Third, start Marathon:
docker run \
-d \
-p 8080:8080 \
garland/mesosphere-docker-marathon --master zk://${HOST_IP}:2181/mesos --zk zk://${HOST_IP}:2181/marathon
Again, replace “localhost” with the Docker server IP address as needed.
Fourth, add a Mesos slave to your cluster:
docker run -d \
--name mesos_slave_1 \
--entrypoint="mesos-slave" \
-e "MESOS_MASTER=zk://${HOST_IP}:2181/mesos" \
-e "MESOS_LOG_DIR=/var/log/mesos" \
-e "MESOS_LOGGING_LEVEL=INFO" \
garland/mesosphere-docker-mesos-master:latest
And once again, replace “localhost” as appropriate.
That’s all. Now, you can access the Mesos and Marathon Web UIs at http://localhost:5050 and http://localhost:8080, respectively. (If the Docker host is on a different machine, use its IP instead of localhost.)
You can also use any of the various CLI clients for controlling Marathon. See this page (under section “Marathon Clients”) for a list.
Additional Resources
If you’re interested in learning more about topics like orchestration, composition and clustering in Docker, see Michael Floyd’s blog post explaining how containerization enables DevOps teams. If you’d like to learn more about docker logging, check out the Sumo Logic App for Docker.
Read more blogs from the Sumo Logic DevOps community at devops.sumologic.com.
