In addition to a number of bug fixes, Marathon 0.2 adds constraints, which allow you to control the placement of your app tasks in a cluster.
Constraints give operators control over where apps should run, to optimize for fault tolerance or locality. Constraints can be set via the REST API or the Marathon gem when you’re starting an app. Make sure you have the gem version 0.2.0 or later for constraint support. Constraints are made up of three parts: a field name, an operator, and an optional value. The field can be any Mesos slave attribute, or the slave hostname.
UNIQUE tells Marathon to enforce uniqueness of the attribute across all of an app’s tasks. For example the following constraint ensures that there is only one app task running on each host:
marathon start -i sleep -C 'sleep 60' -n 3 --constraint hostname:UNIQUE http POST localhost:8080/v1/apps/start id=sleep cmd='sleep 60' instances=3 constraints:='[["hostname","UNIQUE"]]'
CLUSTER allows you to run all of your app’s tasks on slaves that share a certain attribute. This is useful for example if you have apps with special hardware needs, or if you want to run them on the same rack for low latency.
marathon start -i sleep -C 'sleep 60' -n 3 --constraint rack_id:CLUSTER:rack-1 http POST localhost:8080/v1/apps/start id=sleep cmd='sleep 60' instances=3 constraints:='[["rack_id","CLUSTER","rack-1"]]'
GROUP_BY can be used to distribute your tasks evenly across racks or datacenters for high availability.
marathon start -i sleep -C 'sleep 60' -n 3 --constraint rack_id:GROUP_BY http POST localhost:8080/v1/apps/start id=sleep cmd='sleep 60' instances=3 constraints:='[["rack_id","GROUP_BY"]]'
Optionally, you can add a value to limit the number of tasks per group.
If you’re running multiple instances of Marathon in HA mode, previously the followers did an HTTP redirect to the master when they received API requests. This is problematic for some clients, especially for non-GET requests. Redirection was replaced with proxying so followers now transparently forward requests to the leader.
You can now configure a maximum number of tasks an app is allowed to launch per second. This prevents misconfigured applications from creating a flood of failing tasks. Just add the
taskRateLimit key to the JSON request when starting an app, and set it to the maximum number of new tasks per second, e.g.
A Dockerfile was added to allow Marathon to be started in a Docker container.