/v2/apps

get

Get the list of running applications. Several filters can be applied via the following query parameters.

put

Change multiple applications either by upgrading existing ones or creating new ones. If there is an update to an already running application, the application gets upgraded. All instances of this application get replaced by the new version. The order of dependencies will be applied correctly. The upgradeStrategy defines the behaviour of the upgrade. If the id of the application is not known, the application gets started. The order of dependencies will be applied correctly. It is possible to mix upgrades and installs. If you have more complex scenarios with upgrades, use the groups endpoint. Note: This operation will create a deployment. The operation finishes, if the deployment succeeds. You can query the deployments endoint to see the status of the deployment.

post

Create and start a new application. Note: This operation will create a deployment. The operation finishes, if the deployment succeeds. You can query the deployments endoint to see the status of the deployment.

get

Get the application with id app_id. The response includes some status information besides the current configuration of the app. You can specify optional embed arguments, to get more embedded information.

put

Replaces parameters of a running application. If no application with the given id exists, it will be created. If there is an application with this id, all running instances get upgraded to the new definition.

Note: This operation will create a deployment. The operation finishes, if the deployment succeeds. You can query the deployments endoint to see the status of the deployment.

delete

Destroy an application. All data about that application will be deleted. Note: This operation will create a deployment. The operation finishes, if the deployment succeeds. You can query the deployments endoint to see the status of the deployment.

post

Restart all tasks of this application.

get

List all running tasks for application app_id.

delete

Kill tasks that belong to the application app_id

delete

Kill the task with ID task_id that belongs to the application app_id.

get

List the versions of the application with id app_id

get

List the configuration of the application with id app_id at version version.

/v2/deployments

get

List all running deployments. A deployment is a change in the service setup. A deployment is identified by an id, affects a set of applications and is composed of deployment steps. Every step contains a list of actions with following types

  • StartApplication starts an application, which is currently not running.
  • StopApplication stops an already running application.
  • ScaleApplication changes the number of instances of an application and allows to kill specified instances while scaling.
  • RestartApplication upgrades an already deployed application with a new version.
  • ResolveArtifacts Resolve all artifacts of an application
delete

Revert the deployment with deployment_id by creating a new deployment which reverses all changes.

/v2/groups

get

Get the group with all applications and all transitive child groups.

put

Change parameters of a deployed application group. The new group parameters get applied.

  • Changes to application parameters will result in a restart of this application.
  • A new application added to the group will be started.
  • An existing application removed from the group will be stopped.

If there are no changes to the application definition, no restart is triggered. During restart marathon keeps track, that the configured amount of minimal running instances are always available. This method allows 2 special modes for the update operation>

  • Provide only the version field in the group definition. This will rollback the group to that given version
  • Provide only the scaleBy field will scale all transitive applications instance counts by the given factor.

When one of version or scaleBy are set, nothing else than a version change or transitive instance count scaling will be applied. If both version and scaleBy are set, only a version rollback will be performed – the scaleBy value will not be applied. A deployment can run forever. This is the case, when the new application has a problem and does not become healthy. In this case, human interaction is needed with 2 possible choices

  • Rollback to an existing older version
  • Update with a newer version of the group which does not have the problems of the old one.

Since the deployment of the group can take a considerable amount of time, this endpoint returns immediately with a version. The failure or success of the action is signalled via event. There is a group_change_success and group_change_failed with the given version.

post

Create and start a new application group. Application groups can contain other application groups.

delete

Destroy a group. All data about that group and all associated applications will be deleted. The failure or success of the action is signalled via events. There is a group_change_success and group_change_failed with the given version.

get

List all versions the group with the specified path.

/v2/groups/{group_id}

get

Get the group with all applications and all transitive child groups.

put

Change parameters of a deployed application group. The new group parameters get applied.

  • Changes to application parameters will result in a restart of this application.
  • A new application added to the group will be started.
  • An existing application removed from the group will be stopped.

If there are no changes to the application definition, no restart is triggered. During restart marathon keeps track, that the configured amount of minimal running instances are always available. This method allows 2 special modes for the update operation>

  • Provide only the version field in the group definition. This will rollback the group to that given version
  • Provide only the scaleBy field will scale all transitive applications instance counts by the given factor.

When one of version or scaleBy are set, nothing else than a version change or transitive instance count scaling will be applied. If both version and scaleBy are set, only a version rollback will be performed – the scaleBy value will not be applied. A deployment can run forever. This is the case, when the new application has a problem and does not become healthy. In this case, human interaction is needed with 2 possible choices

  • Rollback to an existing older version
  • Update with a newer version of the group which does not have the problems of the old one.

Since the deployment of the group can take a considerable amount of time, this endpoint returns immediately with a version. The failure or success of the action is signalled via event. There is a group_change_success and group_change_failed with the given version.

post

Create and start a new application group. Application groups can contain other application groups.

delete

Destroy a group. All data about that group and all associated applications will be deleted. The failure or success of the action is signalled via events. There is a group_change_success and group_change_failed with the given version.

get

List all versions the group with the specified path.

/v2/tasks

get

List all running tasks.

post

Kill a list of running tasks.

/v2/artifacts

post

Upload an artifact to the artifact store. A multipart form upload request has to be performed. The form parameter name has to be file. The filename used in the artifact store, is the same as given by the form parameter. The response holds the URL of the artifact in the artifact store in the Location Header.

put

Upload an artifact to the artifact store. A multipart form upload request has to be performed. The form parameter name has to be file. The path used to store the file is taken from the url path. The response holds the URL of the artifact in the artifact store in the Location Header.

post

Upload an artifact to the artifact store. A multipart form upload request has to be performed. The form parameter name has to be file. The path used to store the file is taken from the url path. The response holds the URL of the artifact in the artifact store in the Location Header.

delete

Delete an artifact from the artifact store. The path is the relative path in the artifact store.

get

Download an artifact from the artifact store. The path is the relative path in the artifact store.

/v2/events

get

Attach to the marathon event stream. To use this endpoint, the client has to accept the text/event-stream content type. Please note a request to this endpoint will not be closed by the server. If an event happens on the server side, this event will be propagated to the client immediately. See Server Sent Events for a more detailed explanation. Note for ApiConsole: this function will not yield the expected result from inside ApiConsole.

/v2/eventSubscriptions

get

List all event subscriber callback URLs. _NOTE To activate this endpoint, you need to startup a Marathon instance with --event_subscriber http_callback_

post

Subscribe to the event callback mechanism with the specified callback URL.

delete

Unregister a callback URL from the event subscribers list.

/v2/info

get

Get info about the Marathon Instance

/v2/leader

get

Returns the current leader.

delete

Causes the current leader to abdicate, triggering a new election.

/v2/plugins

get

Returns the list of all loaded plugins

get

Get request is handled by the plugin.

put

Put request is handled by the plugin.

post

Post request is handled by the plugin.

delete

Delete request is handled by the plugin.

/v2/queue

get

List all the tasks queued up or waiting to be scheduled. This is mainly used for troubleshooting and occurs when scaling changes are requested and the volume of scaling changes out paces the ability to schedule those tasks. In addition to the application in the queue, you see also the task count that needs to be started. If the task has a rate limit, then a delay to the start gets applied. You can see this delay for every application with the seconds to wait before the next launch will be tried.

delete

If an application fails too often in a specified amount of time (according to the application definition), the task launch will be delayed. This delay can be removed by calling this endpoint. The effect is, that the tasks of this application will be launched immediately.

/ping

get

Ping this Marathon instance.

/metrics

get

Get metrics data from this Marathon instance