This section describes the developer-specific DC/OS components, explaining what is necessary to package and provide your own service on DC/OS.
The Mesosphere Datacenter Operating System (DC/OS) provides the optimal user experience possible for orchestrating and managing a datacenter. If you are an Apache Mesos developer, you are already familiar with developing a framework. DC/OS extends Apache Mesos by including a web interface for health checks and monitoring, a command-line, a service packaging description, and a repository that catalogs those packages.
The DC/OS Universe contains all of the services that are installable on DC/OS. For more information on DC/OS Universe, see the GitHub Universe repository.
All packaged services are required to meet a certain standard as defined by Mesosphere. For details on submitting a DC/OS service, see Contributing a package.
Admin Router and web interface integration
By default, a DC/OS service is deployed on a private agent node. To allow configuration control or monitoring of a service by a user, the Admin Router proxies calls on the master node to the service in a private node on the cluster. The HTTP service endpoint requires relative paths for artifacts and resources. The service endpoint can provide a web interface, a RESTful endpoint, or both. When creating a DC/OS CLI subcommand, it is common to have a RESTful endpoint to communicate with the scheduler service.
The integration to the Admin Router is automatic when a framework scheduler registers a
webui_url during the registration process with the Mesos master. There are a couple of limitations:
- The URL must NOT end with a forward slash (/). For example, this is good
internal.dcos.host.name:10000, and this is bad
- DC/OS supports 1 URL and port.
webui_url is provided, the service is listed on the DC/OS web interface as a service with a link. That link is the Admin Router proxy URL name that is based on a naming convention of:
/service/<service_name>. For example,
<dcos_host>/service/unicorn is the proxy to the
webui_url. If you provide a web interface, it will be integrated with the DC/OS web interface and users can click the link for quick access to your service.
Service health check information is provided from the DC/OS service tab when:
- There are service health checks defined in the
marathon.json file. For example:
You can provide public access to your service through the Admin Router or by deploying your own proxy or router to the public agent node. It is recommend to use the Admin Router for scheduler configuration and control, allowing integration with the DC/OS web interface. You can also provide a CLI subcommand for command-line control of a RESTful service endpoint for the scheduler.
DC/OS service structure
Each DC/OS service in the Universe repo is comprised of JSON configuration files. These files are used create the packages that are installed on DC/OS.
|Specifies the supported configuration properties, represented as a JSON-schema.
|Specifies a mustache template that creates a Marathon app definition capable of running your service.
|Specifies the high level metadata about the package.
|Specifies all of the required externally hosted resources (e.g. Docker images, HTTP objects and images).
For more information, see the Creating a Universe Package.
Disclaimer: This document provides the DC/OS Service requirements, but is not the complete DC/OS service certification. For the complete DC/OS Service Specification, send an email ...
This document is intended for a developer creating new DC/OS CLI commands. See also the DC/OS Service Specification. The DC/OS CLI You can install the DC/OS Command Line Interface ...
This page covers general advice and information about creating a DC/OS package that can be published to the Mesosphere Universe. Consult the [Publish a Package] page of the Univ...
You can leverage several integration points when creating a DC/OS Service. The sections below explain how to integrate with each respective component. Admin Router When a DC/OS Ser...