Components

Understanding DC/OS components

DC/OS is composed of many open source microservice components meticulously tuned and configured to work together. Mesosphere DC/OS Enterprise includes most of the open source DC/OS components but also includes several additional components, modules, and plugins.

Figure 1 - DC/OS components

From the top, DC/OS is an inclusive container platform that handles container orchestration, package management, and security. From the bottom, DC/OS is an operating system built on top of Apache Mesos that handles cluster management and software defined networking, while simplifying logging and metrics collection.

Cluster management

DC/OS provides a way to view and operate a large number of individual machine-level systems as a single cluster-level system. It hides the complexity of Mesos, the distributed systems kernel, with higher level abstractions, interfaces, and tools. Cluster management is the core of that functionality, including the kernel, its dependencies, and its user interfaces.

Apache Mesos

Mesos manages resources and tasks as a distributed systems kernel. Mesos Master exposes scheduler, executor, and operator interfaces to facilitate cluster management. Mesos Agent manages individual executors, tasks, and resources on each DC/OS agent node. Mesos Agent Public is a Mesos Agent configured to run on DC/OS public agent nodes.

System services

dcos-mesos-master.service

dcos-mesos-slave.service

dcos-mesos-slave-public.service

Read the following documentation resources to learn more about Apache Mesos:

System service

DC/OS Installer

The DC/OS Installer (dcos_generate_config.ee.sh) generates install artifacts and installs DC/OS. As part of the install process on each node, the DC/OS Download service downloads the install artifacts from the bootstrap machine and the DC/OS Setup service installs components using the DC/OS Component Package Manager (Pkgpanda).

System services

dcos-download.service

dcos-setup.service

Read the following documentation resources to learn more about DC/OS and installation methods:

DC/OS CLI

System service

Container orchestration

Container orchestration is the continuous, automated scheduling, coordination, and management of containerized processes and the resources they consume. DC/OS includes built-in orchestration of the most commonly used high level container-based abstractions: jobs and services. Many use cases are handled directly by these basic abstractions, but they also enable the deployment of custom schedulers for tasks that require more flexible programmatic lifecycle management automation.

System service

Docker Engine

Docker Engine is not installed by the DC/OS Installer, but rather is a system dependency that runs on each node. The Mesos Agent also includes a separate logical component called Docker Containerizer which delegates the containerization of Mesos task to Docker Engine.

System service

docker.service - Docker Engine is not installed by the DC/OS installer.

Read the following documentation resource to learn more about Docker Engine:

System services

Logging and metrics

No software runs perfectly, especially not the first time. Distributing tasks across a cluster, as well as the normal patterns of analyzing and debugging these services, become tedious. DC/OS includes several components to help ease the pain of debugging distributed systems by aggregating, caching, and streaming logs, metrics, and cluster state metadata.

System service

Networking

In a world where machines are given numbers instead of names, tasks are scheduled automatically, dependencies are declaratively defined, and services run in distributed sets, network administration also needs to be elevated from plugging in cables to configuring software-defined networks. To accomplish this, DC/OS includes a fleet of networking components for routing, proxying, name resolution, virtual IPs, load balancing, and distributed reconfiguration.

System services

Package management

Just as machine operating systems need package management to install, upgrade, configure, and remove individual applications and services, a datacenter operating system needs package management to do the same for distributed services. In DC/OS there are two levels of package management: machine-level for components; and cluster-level for user services.

System Service

IAM and Security Enterprise

Identity and access management in DC/OS Enterprise is governed by an internal database of users, user groups, and permissions. External identity providers can also be attached to take advantage of existing databases. Permissions are enforced both at the edge by Admin Router’s reverse proxy and also at the component level for controlling access to specific actions. Secrets, like SSL certificates, can also be securely generated, managed, stored, and injected into user services.

DC/OS Identity and Access Manager (Bouncer)

DC/OS Identity and Access Manager (IAM) controls access to DC/OS components and services by managing users, user groups, service accounts, permissions, and identity providers. In addition to managing a local user database, DC/OS IAM can delegate to external identity providers using LDAP, SAML, or Open ID Connect. For fine grained access control, other DC/OS components, like Mesos and Marathon, integrate with DC/OS IAM directly. DC/OS IAM is also known as Bouncer.

System service

dcos-bouncer.service

Read the following documentation resources to learn more about DC/OS Identity and Access Manager (Bouncer):

System service

Vault

Vault is a tool for securely managing secrets. A secret is anything that you want to control access to, such as API keys, passwords, certificates, and more. Vault provides a unified interface to any secret, while providing tight access control and recording a detailed audit log.

System service

Sockets and timers

Several components are configured to use on-demand systemd sockets which allows them to be started when a request comes in, rather than running continuously and consuming resources unnecessarily. While these sockets are separate systemd units they are not considered separate components.

Several components are configured to use systemd timers which allows them to be periodically executed or restarted. Periodic execution avoids continuous execution and consuming resources unnecessarily. Periodic restarting allows for picking up new configurations from downstream dependencies, like time-based DNS cache expiration. While these timers are separate systemd units they are not considered separate components.

Systemd services

To see a list of the systemd components running on any particular node, list the contents of the /etc/systemd/system/dcos.target.wants/ directory or execute systemctl | grep dcos- to see their current status.