marathon
Deploy and manage containers (including Docker) on top of Apache Mesos at scale.
Top Related Projects
Deploy and manage containers (including Docker) on top of Apache Mesos at scale.
Apache Mesos
Production-Grade Container Scheduling and Management
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.
Swarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit
Quick Overview
Marathon is an open-source container orchestration platform for Mesosphere's Datacenter Operating System (DC/OS) and Apache Mesos. It is designed to launch long-running applications, services, and cron jobs on a distributed cluster, providing high availability and fault tolerance.
Pros
- Supports Docker containers and custom executors
- Offers service discovery and load balancing
- Provides rolling updates and health checks
- Integrates well with DC/OS and Mesos ecosystems
Cons
- Less popular compared to Kubernetes for container orchestration
- Limited community support due to being archived
- Steeper learning curve for those not familiar with Mesos
- Requires additional setup and configuration compared to some alternatives
Code Examples
{
"id": "/my-app",
"cmd": "python3 -m http.server 8080",
"cpus": 0.5,
"mem": 32,
"instances": 2,
"container": {
"type": "DOCKER",
"docker": {
"image": "python:3.9-alpine"
}
},
"portMappings": [
{
"containerPort": 8080,
"hostPort": 0,
"protocol": "tcp"
}
]
}
This JSON configuration defines a Marathon application that runs a Python HTTP server in a Docker container.
{
"id": "/web-app",
"instances": 3,
"container": {
"type": "DOCKER",
"docker": {
"image": "nginx:latest"
}
},
"healthChecks": [
{
"protocol": "HTTP",
"path": "/",
"portIndex": 0,
"gracePeriodSeconds": 300,
"intervalSeconds": 60,
"timeoutSeconds": 20,
"maxConsecutiveFailures": 3
}
]
}
This example shows a Marathon configuration for an Nginx web application with health checks.
{
"id": "/cron-job",
"cmd": "echo 'Hello, World!' && sleep 5",
"cpus": 0.1,
"mem": 32,
"instances": 1,
"schedule": "0 * * * *"
}
This configuration demonstrates how to set up a cron job in Marathon that runs every hour.
Getting Started
To deploy an application using Marathon:
- Install DC/OS or set up a Mesos cluster with Marathon.
- Create a JSON file with your application configuration (e.g.,
app.json
). - Use the Marathon API to deploy your application:
curl -X POST http://<marathon-host>:8080/v2/apps -H "Content-type: application/json" -d @app.json
- Monitor your application's status:
curl http://<marathon-host>:8080/v2/apps
For more detailed instructions, refer to the Marathon documentation.
Competitor Comparisons
Deploy and manage containers (including Docker) on top of Apache Mesos at scale.
Pros of Marathon
- Identical repository to d2iq-archive/marathon
- Same features, functionality, and codebase
Cons of Marathon
- No unique advantages over d2iq-archive/marathon
- Redundant repository with no distinguishing characteristics
Code Comparison
Both repositories contain identical code, so a comparison is not applicable. Here's a sample from the shared codebase:
def taskKiller(taskId: Task.Id): Future[Unit] = {
val task = taskTracker.fetchTask(taskId).value.flatMap(_.toOption)
task.map { t =>
killTask(t)
}.getOrElse(Future.successful(()))
}
Summary
The repositories d2iq-archive/marathon and d2iq-archive/marathon are identical. They share the same codebase, features, and functionality. There are no distinguishing factors between the two repositories, making them essentially duplicates of each other. The pros and cons listed above reflect this redundancy, as neither repository offers any unique advantages or disadvantages compared to the other. The code comparison further illustrates this point by showing that both repositories contain the same code snippets. In conclusion, these repositories are indistinguishable from one another in terms of content and functionality.
Apache Mesos
Pros of Mesos
- More comprehensive resource management across entire clusters
- Better scalability for large-scale distributed systems
- Supports a wider range of workloads beyond just containerized applications
Cons of Mesos
- Steeper learning curve and more complex setup
- Less focus on container orchestration compared to Marathon
- Requires additional frameworks for specific workload management
Code Comparison
Marathon (container deployment):
{
"id": "/my-app",
"cmd": "python3 -m http.server 8080",
"cpus": 0.5,
"mem": 32,
"instances": 1
}
Mesos (resource offer):
{
"id": "20140916-201449-1740121354-5050-4759-O1",
"framework_id": "20140916-201449-1740121354-5050-4759-0000",
"slave_id": "20140916-201449-1740121354-5050-4759-S0",
"resources": [
{"name": "cpus", "type": "SCALAR", "scalar": {"value": 2}},
{"name": "mem", "type": "SCALAR", "scalar": {"value": 1024}}
]
}
Marathon focuses on container deployment and management, while Mesos handles lower-level resource allocation across a cluster. Marathon provides a simpler interface for deploying containerized applications, whereas Mesos offers more flexibility and control over resource distribution for various types of workloads.
Production-Grade Container Scheduling and Management
Pros of Kubernetes
- More extensive ecosystem and community support
- Better scalability and flexibility for large-scale deployments
- Native support for stateful applications and persistent storage
Cons of Kubernetes
- Steeper learning curve and more complex setup
- Higher resource overhead for small-scale deployments
- Requires more management and maintenance
Code Comparison
Marathon:
{
"id": "/my-app",
"cmd": "python3 -m http.server 8080",
"cpus": 0.5,
"mem": 32,
"instances": 3
}
Kubernetes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
spec:
containers:
- name: my-app
command: ["python3", "-m", "http.server", "8080"]
resources:
limits:
cpu: "0.5"
memory: "32Mi"
Both Marathon and Kubernetes use declarative configuration files to define applications, but Kubernetes offers more granular control and extensibility. Marathon's JSON format is simpler, while Kubernetes uses YAML with a more hierarchical structure, reflecting its broader feature set and flexibility.
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.
Pros of Nomad
- Broader workload support: Handles both containerized and non-containerized applications
- Simpler architecture: Single binary deployment with fewer moving parts
- Better scalability: Efficiently manages clusters of 10,000+ nodes
Cons of Nomad
- Less mature ecosystem: Fewer integrations and third-party tools compared to Marathon
- Limited built-in service discovery: Relies on external tools like Consul for advanced service discovery
Code Comparison
Marathon (Java):
@Path("v2/apps")
public class AppsResource {
@POST
@Consumes(MediaType.APPLICATION_JSON)
public Response createApp(@Context UriInfo uriInfo, AppDefinition appDefinition) {
// Application deployment logic
}
}
Nomad (Go):
func (j *Job) Validate() error {
var mErr multierror.Error
if j.Name == nil || *j.Name == "" {
mErr.Errors = append(mErr.Errors, errors.New("job name cannot be empty"))
}
// Additional validation logic
return mErr.ErrorOrNil()
}
Both repositories focus on orchestrating and managing distributed applications, but they differ in their implementation languages and specific features. Marathon is written in Java and is more focused on container orchestration, while Nomad is written in Go and offers a broader range of workload support.
Swarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit
Pros of Docker Swarm Classic
- Native integration with Docker ecosystem, making it easier for Docker users to adopt
- Simpler setup and configuration compared to Marathon
- Better suited for smaller-scale deployments and Docker-centric environments
Cons of Docker Swarm Classic
- Limited scalability compared to Marathon, which is designed for large-scale deployments
- Fewer advanced features and less flexibility in terms of container orchestration
- Less active development and community support, as it has been superseded by Docker Swarm mode
Code Comparison
Marathon (service definition):
{
"id": "/my-app",
"cmd": "python3 -m http.server 8080",
"cpus": 0.5,
"mem": 32,
"instances": 3
}
Docker Swarm Classic (service creation):
docker run -d --name my-app -p 8080:8080 --replicas 3 python:3 python -m http.server 8080
Both examples demonstrate creating a simple web server service with 3 instances. Marathon uses a JSON configuration file, while Docker Swarm Classic relies on Docker CLI commands. Marathon's approach offers more detailed configuration options, while Docker Swarm Classic provides a more straightforward, Docker-native experience.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Project Status
Support for DC/OS ends on October 31, 2021. We will continue to provide support for our current DC/OS customers per their contracts, of course. However, we will no longer be investing in new features or capabilities or maintaining the related repositories. If a customer wishes to continue use of the DC/OS Enterprise platform or other non-free DC/OS components, the customer can purchase an End-of-Life License or Perpetual Use License, however support is not included in these licenses and continued use of DC/OS will be at your own discretion and risk. We apologize for any inconvenience this may have caused.
We want to thank all of our loyal customers, particularly those DC/OS users who were fellow pioneers in the growth of the cloud native landscape from the beginning.
Marathon
Marathon is a production-proven Apache Mesos framework for container orchestration. DC/OS is the easiest way to start using Marathon. Issues are tracked in JIRA.
Marathon provides a REST API for starting, stopping, and scaling applications. Marathon is written in Scala and can run in highly-available mode by running multiple copies. The state of running tasks gets stored in the Mesos state abstraction.
Marathon is also used as a meta framework: you can start other Mesos frameworks such as Chronos or Storm with it to ensure they survive machine failures. It can launch anything that can be launched in a standard shell. In fact, you can even start other Marathon instances via Marathon.
Features
- HA - run any number of Marathon schedulers, but only one gets elected as leader; if you access a non-leader, your request gets proxied to the current leader
- Constraints - e.g., only one instance of an application per rack, node, etc.
- Service Discovery & Load Balancing via HAProxy or the events API (see below).
- Health Checks: check your application's health via HTTP or TCP checks.
- Event Subscription lets you supply an HTTP endpoint to receive notifications, for example to integrate with an external load balancer.
- Marathon UI
- JSON/REST API for easy integration and scriptability
- Basic Auth and SSL
- Metrics:
query them at
/metrics
in JSON format, push them to systems like Graphite, StatsD and DataDog, or scrape them using Prometheus.
Documentation
Marathon documentation is available on the Marathon GitHub pages site.
Documentation for installing and configuring the full Mesosphere stack including Mesos and Marathon is available on the Mesosphere website.
Issue Tracking
Marathon uses JIRA to track issues. You can browse existing issues or file a new issue with your GitHub account.
Note for users of GitHub issues: All existing issues have been migrated and closed, and a reference to the related JIRA has been added as a comment. We leave the GitHub issues available for reference. Going forward please use JIRA always.
Contributing
We heartily welcome external contributions to Marathon's documentation. Documentation should be committed to the master
branch and published to our GitHub pages site using the instructions in docs/README.md.
Setting Up And Running Marathon
Dependencies
Marathon has the following compile-time dependencies:
- sbt - A build tool for scala. You can find the instructions for installing sbt for Mac OS X and Linux over here.
- JDK 1.8+
For run-time, Marathon has the following dependencies:
- libmesos - JNI bindings for talking to Apache Mesos master. Look at the Install Mesos section for instructions to get libmesos.
- Apache Zookeeper - You can have a separate Zookeeper installation specifically for Marathon, or you can use the same Zookeeper used by Mesos.
Installation
Getting started with DC/OS
The by far easiest way to get Marathon running is to use DC/OS. Marathon is pre-bundled into DC/OS.
Install Mesos
Marathon requires libmesos, a shared object library, that contains JNI bindings for Marathon to talk to the Mesos master. libmesos comes as part of the Apache Mesos installation. There are three options for installing Apache Mesos.
Installing Mesos from prepackaged releases
Instructions on how to install prepackaged releases of Mesos are available in the Marathon docs.
Building Mesos from source
NOTE: Choose this option only if building Marathon from source, else there might be version incompatibility between pre-packaged releases of Marathon and Mesos built from source.
You can find the instructions for compiling Mesos from source in the Apache Mesos getting started docs. If you want Mesos to install libraries and executables in a non-default location use the --prefix option during configuration as follows:
./configure --prefix=<path to Mesos installation>
The make install
will install libmesos (libmesos.so on Linux and libmesos.dylib on Mac OS X) in the install directory.
Using the Mesos Version Manager
NOTE: Choose this option only if building Marathon from source, else there might be version incompatibility between pre-packaged releases of Marathon and Mesos built from source.
The Mesos Version Manager (mvm) compiles, configures, and manages multiple versions of Apache Mesos. It allows switching between versions quickly, making it easy to test Marathon against different versions of Mesos.
Prerequisites
The Mesos Version Manager assumes that all dependencies of Apache Mesos are readily installed.
Please refer to the Apache Mesos getting started docs for instructions on how to set up the build environment.
MVM compiles Mesos with SSL support by default, which requires openssl and libevent to be installed.
On macOS, the packages can be installed using brew: brew install openssl libevent
On CentOS, the packages can be installed using yum: sudo yum install -y libevent-devel openssl-devel
Usage
The script can be run as follows:
cd marathon
cd tools
./mvm.sh <VERSION> [SHELL]
The following command will launch a bash shell configured for Mesos 1.2.0: ./mvm.sh 1.2.0 bash
You should consider placing the script into a folder in your shell's PATH
if you are using it regularly.
The mvm script accepts three different formats as version name:
- Version tags from the Mesos repository. Use
./mvm.sh --tags
in order to obtain a list of available tags. - Commit hashes from the Mesos repository.
- The
--latest
flag, which automatically chooses the latest development version:./mvm.sh --latest
.
MVM Will automatically download & compile Apache Mesos if necessary.
It will then spawn a new bash shell with the chosen version of Mesos activated.
For more information see ./mvm.sh --help
.
Note: You will have to re-run the script if you wish to use Mesos after closing the shell.
See ./mvm.sh --help
information on how to permanently configure your shell for mvm to avoid this.
Install Marathon
Instructions on how to install prepackaged releases are available in the Marathon docs. Alternatively, you can build Marathon from source.
Building from Source
-
To build Marathon from source, check out this repo and use sbt to build a universal:
git clone https://github.com/mesosphere/marathon.git cd marathon sbt 'run --master localhost:5050 --zk zk://localhost:2181/marathon'
Troubleshooting
-
Failure in retrieval of IP address of the local machine will result in an error and may look like this:
Failed to obtain the IP address for '<local-machine>'; the DNS service may not be able to resolve it: nodename nor servname provided, or not known
Make sure that
LIBPROCESS_IP
environment variable is set.export LIBPROCESS_IP="127.0.0.1"
-
When the
MESOS_NATIVE_JAVA_LIBRARY
environment variable is not set, the following error may occur,java.lang.UnsatisfiedLinkError: no mesos in java.library.path...
Make sure that
MESOS_NATIVE_JAVA_LIBRARY
environment variable is set.export MESOS_NATIVE_JAVA_LIBRARY="/path/to/mesos/lib/libmesos.dylib"
-
-
Run
sbt universal:packageZipTarball
to package Marathon as an txz file containing bin/marathon fully packaged. -
Run
cd tools/packager; make tag-docker
for a local Marathon docker image.
Running in Development Mode
Mesos local mode allows you to run Marathon without launching a full Mesos
cluster. It is meant for experimentation and not recommended for production
use. Note that you still need to run ZooKeeper for storing state. The following
command launches Marathon on Mesos in local mode. Point your web browser to
http://localhost:8080
to see the Marathon UI.
mesos-local
sbt 'run --master localhost:5050 --zk zk://localhost:2181/marathon'
For more information on how to run Marathon in production and configuration options, see the Marathon docs.
Developing Marathon
See developing Marathon in the docs.
Marathon Clients
-
marathonctl A handy CLI tool for controlling Marathon
-
Ruby gem and command line client
Running Chronos with the Ruby Marathon Client:
marathon -M http://foo.bar:8080 start -i chronos -u https://s3.amazonaws.com/mesosphere-binaries-public/chronos/chronos.tgz \ -C "./chronos/bin/demo ./chronos/config/nomail.yml \ ./chronos/target/chronos-1.0-SNAPSHOT.jar" -c 1.0 -m 1024
-
Ruby gem marathon_deploy alternative command line tool to deploy using json or yaml files with ENV macros.
-
Scala client, developed at Guidewire
-
Java client, developed at Mesosphere
-
Java client by Mohit Soni
-
Maven plugin, developed by Johannes Unterstein
-
Maven plugin, developed at HolidayCheck
-
Python client, developed at The Factory
-
Python client, developed at Wizcorp
-
Go client by Rohith Jayawardene
-
Go client by Jean-Baptiste Dalido
-
Node client by Silas Sewell
-
Clojure client by Halit Olali
-
sbt plugin, developed at Tapad
Companies using Marathon
Across all installations Marathon is managing applications on more than 100,000 nodes world-wide. These are some of the companies using it:
- Adform
- Alauda
- Allegro
- AllUnite
- Argus Cyber Security
- Artirix
- Arukas
- Avast
- AVENTER
- bol.com
- Brand24
- Branding Brand
- China Mobile
- China Unicom
- Corvisa
- Criteo
- Daemon
- DataMan
- Deutsche Telekom
- DHL Parcel
- Disqus
- DueDil
- eBay
- Erasys
- The Factory
- Football Radar
- Guidewire
- Groupon
- GSShop
- GrowingIO
- HolidayCheck
- Human API
- Indix
- ING
- Intent HQ
- iQIYI
- LaunchKey
- Mapillary
- Measurence
- Motus
- Notonthehighstreet
- OpenTable
- Opera
- Orbitz
- Otto
- OVH
- PayPal
- Qubit
- RelateIQ
- Refinery29
- Sailthru
- SAKURA Internet Inc
- sloppy.io
- SmartProcure
- Strava
- Sveriges Television
- Salesforce
- T2 Systems
- Tapad
- Teradata
- Toss
- trivago
- tronc / L.A. Times
- VANAD Enovation
- Viadeo
- Wikia
- William Hill
- WooRank
- Yelp
Not in the list? Open a pull request and add yourself!
Help
Have you found an issue? Feel free to report it using our JIRA Issues page.
In order to speed up response times, we ask you to provide as much
information on how to reproduce the problem as possible. If the issue is related
in any way to the web UI, we kindly ask you to use the gui
label.
If you have questions, please post on the Marathon Framework email list.
You can find Marathon support in the #marathon
channel, and Mesos support in the #mesos
channel, on freenode (IRC). Alternatively, check out the same channels on the Mesos Slack (request an invitation here).
The team at Mesosphere is also happy to answer any questions.
If you'd like to take part in design research and test new features in Marathon before they're released, please add your name to our UX Research list.
Authors
Marathon was created by Tobias Knaup and Florian Leibert and continues to be developed by the team at Mesosphere and by many contributors from the community.
Acknowledgements
YourKit, LLC
YourKit supports open source projects with its full-featured Java Profiler. YourKit, LLC is the creator of YourKit Java Profiler and YourKit .NET Profiler, innovative and intelligent tools for profiling Java and .NET applications.
Top Related Projects
Deploy and manage containers (including Docker) on top of Apache Mesos at scale.
Apache Mesos
Production-Grade Container Scheduling and Management
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.
Swarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot