marathon

Deploy and manage containers (including Docker) on top of Apache Mesos at scale.

4,066

845

4,066

View on GitHub

Top Related Projects

kubernetes

109,710

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.

mesos

5,233

Apache Mesos

classicswarm

5,756

Swarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit

origin

8,481

Conformance test suite for OpenShift

Quick Overview

Marathon is a production-grade 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 fault tolerance, scalability, and resource isolation.

Pros

Highly scalable and fault-tolerant, capable of managing thousands of applications
Supports Docker containers and custom executors
Offers advanced features like service discovery, load balancing, and health checks
Integrates well with other DC/OS and Mesos components

Cons

Steeper learning curve compared to some other container orchestration platforms
Less active development and community support compared to Kubernetes
Requires Apache Mesos as a dependency, which adds complexity to the setup
Limited adoption outside of DC/OS environments

Getting Started

To get started with Marathon, you'll need to have DC/OS or Apache Mesos installed. Here's a basic example of how to deploy a simple application using Marathon's REST API:

# Deploy a simple Docker container
curl -X POST http://marathon.mesos:8080/v2/apps -d '{
  "id": "hello-world",
  "cmd": "echo Hello Marathon",
  "cpus": 0.1,
  "mem": 32,
  "instances": 1
}' -H "Content-type: application/json"

# Check the status of the application
curl http://marathon.mesos:8080/v2/apps/hello-world

# Scale the application to 3 instances
curl -X PUT http://marathon.mesos:8080/v2/apps/hello-world -d '{
  "instances": 3
}' -H "Content-type: application/json"

For more advanced usage and configuration options, refer to the Marathon documentation and API reference.

Competitor Comparisons

kubernetes

109,710

Production-Grade Container Scheduling and Management

Pros of Kubernetes

More extensive ecosystem and community support
Better scalability for large, complex deployments
Native support for stateful applications

Cons of Kubernetes

Steeper learning curve and more complex setup
Higher resource overhead for smaller deployments
Less integrated UI for management tasks

Code Comparison

Marathon configuration example:

{
  "id": "/my-app",
  "cmd": "python3 -m http.server 8080",
  "cpus": 0.5,
  "mem": 32,
  "instances": 2
}

Kubernetes deployment example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  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 separation of concerns through its various resource types (Deployments, Services, ConfigMaps, etc.). Marathon's configuration is generally simpler for basic use cases, while Kubernetes provides more flexibility for complex scenarios.

nomad

14,854

Pros of Nomad

Simpler architecture and easier to set up and maintain
Supports a wider range of workloads, including non-containerized applications
Better integration with other HashiCorp tools like Consul and Vault

Cons of Nomad

Less mature ecosystem compared to Marathon's Mesos-based infrastructure
Fewer advanced features for container orchestration and scaling
Limited support for stateful applications and persistent storage management

Code Comparison

Marathon (Java):

@Path("/v2/apps")
public class AppsResource {
    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    public Response createApp(@Context HttpServletRequest request, App app) {
        // App creation 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 must be specified"))
    }
    // Additional validation logic
    return mErr.ErrorOrNil()
}

Both Marathon and Nomad are cluster management and scheduling platforms, but they have different approaches and target use cases. Marathon is tightly integrated with Apache Mesos and focuses on container orchestration, while Nomad is more versatile and can handle various workload types. The code snippets showcase their different implementation languages and approaches to API design and job validation.

mesos

5,233

Apache Mesos

Pros of Mesos

More flexible and general-purpose resource management framework
Supports a wider range of workloads and applications
Larger community and ecosystem with more integrations

Cons of Mesos

Steeper learning curve and more complex setup
Requires more configuration and management overhead
Less focused on container orchestration compared to Marathon

Code Comparison

Mesos (C++):

class MesosSchedulerDriver : public SchedulerDriver {
public:
  virtual Status start();
  virtual Status stop(bool failover = false);
  virtual Status abort();
  // ...
};

Marathon (Scala):

class MarathonScheduler(
    eventBus: EventStream,
    marathonStore: MarathonStore[InstanceId, Instance],
    taskTracker: TaskTracker,
    // ...
) extends Scheduler {
  // ...
}

The code snippets show the core scheduler classes for both projects. Mesos uses C++ and provides a more low-level interface, while Marathon is written in Scala and offers a higher-level abstraction focused on long-running services and container orchestration.

Marathon is built on top of Mesos and provides a more specialized framework for container orchestration and application deployment. Mesos, on the other hand, offers a more general-purpose resource management solution that can be used with various frameworks, including Marathon.

classicswarm

5,756

Swarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit

Pros of Classic Swarm

Simpler setup and configuration compared to Marathon
Native integration with Docker ecosystem
Lightweight and easier to learn for Docker users

Cons of Classic Swarm

Limited scalability for large clusters
Fewer advanced features and less flexibility than Marathon
Discontinued project with no active development

Code Comparison

Marathon (Java):

@Path("/v2/apps")
public class AppsResource {
    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    public Response createApp(@Context UriInfo uriInfo, App app) {
        // App creation logic
    }
}

Classic Swarm (Go):

func (c *Cluster) CreateContainer(config *cluster.ContainerConfig, name string) (*cluster.Container, error) {
    // Container creation logic
}

Summary

Marathon and Classic Swarm are both container orchestration platforms, but they differ in complexity and features. Marathon, part of the Mesos ecosystem, offers more advanced capabilities and scalability for large clusters. Classic Swarm, while simpler and more tightly integrated with Docker, has been discontinued in favor of Docker Swarm mode. Marathon is better suited for complex, large-scale deployments, while Classic Swarm was ideal for smaller Docker-centric environments before its deprecation.

origin

8,481

Conformance test suite for OpenShift

Pros of Origin

More comprehensive platform-as-a-service (PaaS) solution, offering a complete container application platform
Built on Kubernetes, providing better scalability and orchestration capabilities
Stronger security features, including integrated authentication and authorization

Cons of Origin

Steeper learning curve due to its more complex architecture
Potentially higher resource requirements for smaller deployments
Less flexibility for custom scheduling compared to Marathon's fine-grained control

Code Comparison

Origin (using OpenShift CLI):

oc new-app https://github.com/sclorg/nodejs-ex
oc expose svc/nodejs-ex

Marathon (using Marathon API):

{
  "id": "/nodejs-app",
  "cmd": "npm start",
  "cpus": 0.5,
  "mem": 256,
  "instances": 1
}

Origin focuses on a higher-level abstraction for deploying applications, while Marathon provides more granular control over resource allocation and scheduling. Origin's approach is more opinionated and integrated, whereas Marathon offers more flexibility in terms of container orchestration within a Mesos cluster.

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

README

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
1. 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"
```
2. 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:

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, 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

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