}}

Deploying non-native Marathons

Enterprise DC/OS Preview Updated: April 18, 2017

About deploying non-native Marathons

Each service that Marathon launches uses the same Mesos role that Marathon registered with for quotas and reservations.

In addition, any users of a given Marathon can run tasks under any Linux user that Marathon can run tasks under.

To achieve finer-grained control over reservations, quotas and Linux user accounts, you must deploy non-native instances of Marathon. The non-native instances of Marathon will be launched by the native instance of Marathon.

While the native Marathon instance runs on the master nodes, the non-native Marathon instances will run on the private agent nodes. You may need additional private agent nodes to accommodate the increased resource demands.

Namespacing considerations

You can copy and paste the code snippets in this section as is and succeed in deploying a single non-native Marathon instance. However, if you need to deploy more than one non-native Marathon instance or desire more descriptive names, you will need to modify the code snippets before issuing them.

We recommend a simple strategy for modifying the code snippets. Just replace each instance of serv-group with the name of the service group that the non-native Marathon will be deployed into.

In the procedures, we will use the following names:

  • momee-serv-group as the name of the service group

  • momee-serv-group-service as the name of the non-native Marathon service

  • momee-serv-group-principal as the name of the non-native Marathon service account

  • momee-serv-group/momee-serv-group-service/momee-serv-group-secret where momee-serv-group-secret is the name of the non-native Marathon service account secret and the secret is available in the serv-group/momee-serv-group/ path

  • momee-serv-group-role as the Mesos role of the non-native Marathon

  • momee-serv-group-private-key.pem as the name of the file containing the private key of the non-native Marathon service account

  • momee-serv-group-public-key.pem as the name of the file containing the public key of the non-native Marathon service account

Let’s imagine you have a service group called test, another called dev, and a third called prod. After replacing serv-group with the name of the actual service group as we recommend, you will end up with the following names.

  • momee-test as the name of the service group

  • momee-test-service as the name of the non-native Marathon service

  • momee-test-principal as the name of the non-native Marathon service account

  • momee-test/momee-test-service/momee-test-secret where momee-test-secret is the name of the non-native Marathon service account secret and the secret is available in the momee-test/momee-test-service/ path

  • momee-test-role as the Mesos role of the non-native Marathon

  • momee-test-private-key.pem as the name of the file containing the private key of the non-native Marathon service account

  • momee-test-public-key.pem as the name of the file containing the public key of the non-native Marathon service account

By following this scheme, you will end up with unique yet descriptive names for each of your non-native Marathon instances. These names will match with the various roles, service accounts, secrets, and files associated with the non-native Marathon instance. In addition, following this scheme will protect the service account secret from other non-native Marathon instances and from the services that the non-native Marathon launches.

Linux user account considerations

The procedures that follow will result in a non-native Marathon instance that runs under the nobody Linux user. Feel free to replace the nobody Linux user in the config.json and in the code snippets with another user of your choice. However, you must ensure that the Linux user account exists on each of your agent nodes before attempting to deploy.

Deploying a non-native Marathon instance

Requirement: You must have a private Docker registry that each private DC/OS agent can access over the network. Popular options include DockerHub, Amazon EC2 Container Registry, and Quay. We also provide a Docker registry DC/OS package, but it is experimental at this time and not explicitly covered in the following procedures.

To deploy a non-native Marathon instance, complete the following steps.

  1. Contact your sales or support representative to obtain the Marathon tarball.
    Important: Ensure that you receive mesosphere/marathon-dcos-ee:1.4.0-RC4_1.9.4 or later.

  2. Load and push the Marathon image up to your private Docker registry.

  3. Create a service account for the non-native Marathon instance.

  4. Provision each private agent with the credentials for the private Docker registry.

  5. Deploy the non-native Marathon.

  6. Deploy a test service.

  7. Granting users permissions to the non-native Marathon.

Load and push the Marathon image

Prerequisites: The Marathon tarball file obtained from your sales or support representative. Docker Engine installed. Private Docker registry. From a terminal prompt, navigate to t...

Create a Marathon service account

About creating a service account for the non-native Marathon instance Whether you can or must provision your non-native Marathon instances with a service account varies by security...

Deploy the non-native instance of Marathon

Prerequisites: Marathon image pushed up to your private Docker registry. Service account for the Marathon instance. Private agents provisioned with the credentials for the private ...

Deploy a test service

Prerequisites: Non-native Marathon deployed. DC/OS CLI installed. You must also be logged in as a user with the necessary permissions via dcos auth login. You can go ahead and use ...

Guaranteeing resources by role (advanced)

About guaranteeing resources to the non-native Marathon role After deploying the non-native Marathon with a unique Mesos role, you may wish to use quotas, static reservations, or d...