About DC/OS

The Datacenter Operating System (DC/OS) is a distributed operating system based on the Apache Mesos distributed systems kernel. It integrates several battle-tested open-source components to enable the management of multiple machines as if they were a single computer. The combination of scalability, availability, efficiency, flexibility, and usability makes DC/OS the best way to build, deploy, and manage modern applications.

• Scalability:
  DC/OS dynamically distributes tasks and programmatically manages resource allocations, enabling your services to be both highly elastic and highly scalable.
• Availability:
  DC/OS monitors the health of your applications and services, load balancing, restarting, or even rescheduling them when necessary to make them highly available.
• Efficiency:
  DC/OS supports many custom schedulers, sharing resources between diverse collocated workloads including microservices, batch jobs, analytics pipelines, message queues, and big data storage.
• Flexibility:
  DC/OS can be installed on-premise or in the public cloud, on bare metal or on virtual machines, to run containers or legacy binaries, freeing you from making infrastructure decisions based purely on platform lock-in.
• Usability:
  DC/OS simplifies the installation, management, and monitoring of the cluster and its distributed services with a scriptable command-line interface (CLI), intuitive web interface, and easy-to-use installer.

Architecture Components

Master Node
Each master node runs Apache Mesos, Marathon and ZooKeeper (to provide leader election). Running three ZooKeeper nodes will allow one to fail and for the service to still be available. It is recommended to run at least three master nodes for a highly-available configuration.
Slave Node
Each Slave node runs your application. Slave nodes located in private subnet so not accessible from the outside.
Public Slave Node
Same as Slave Node but accessible via outside. All connections are going through load-balancer.

Nat Instance
Amazon NAT instance is a nat-proxy for private subnets to access the WEB. Slave Nodes and Master Nodes connect to Internet using this instance.
Master ELB
Load-balancer for connection to master nodes and admin panel
Slave ELB
Load-balancer for accessing your public applications
Internal ELB
Load-balancer for internal communication. Multiple master services and slaves communicates via this load-balancer.

Installation

You can create a DC/OS cluster for Amazon Web Services (AWS) by using the DC/OS template on AWS CloudFormation.

The DC/OS cloud templates are optimized to run Mesosphere DC/OS. Depending on the DC/OS services that you install, you might have to modify the DC/OS templates to suit your needs.
AWS CloudFormation template

Templates available
1 or 3 Mesos master nodes in the admin zone
5 Mesos agent nodes in the private zone
1 Mesos agent node in the public zone
Amazon EC2 m3.xlarge instance

This values could be changed via Cloud-formation template designer.

Installing DC/OS CLI

The easiest way to install the DC/OS CLI is by clicking the signpost icon in the lower left corner of the DC/OS web interface. Or, you can manually install the CLI by following these instructions.

Install virtualenv:

$ sudo pip install virtualenv

Tip: On some older Python versions, you might receive an “Insecure Platform” warning, but you can safely ignore this. For more information, see https://virtualenv.pypa.io/en/latest/installation.html.

From the command line, create a new directory named dcos and change your working directory to it.

$ mkdir dcos && cd dcos

Download the DC/OS CLI install script to your new directory:

$ curl -O https://downloads.dcos.io/dcos-cli/install.sh

Run the DC/OS CLI install script, where is the DC/OS installation directory and is the hostname of your master node prefixed with http://:

$ bash install.sh <install_dir> http://<hosturl>

For example, if the hostname of your AWS master node is dcos-ab-1234.us-west-2.elb.amazonaws.com:

$ bash install.sh . http://dcos-ab-1234.us-west-2.elb.amazonaws.com

Follow the on-screen DC/OS CLI instructions. You can ignore any Python “Insecure Platform” warnings.
You can now use the CLI.

Installing Marathon-LB

Follow this steps to install marathon-lb based on HA-proxy

1. Install marathon-lb

$ dcos package install marathon-lb

To check that marathon-lb is working, find the IP for your public node and navigate to

http://<public slave ip>:9090/haproxy?stats

you will see a statistics report page like this:

2. Install internal LB (optional)
Set up your internal load balancer. To do this, we must first specify some configuration options for the marathon-lb package. Create a file called options.json with the following contents:

{
  "marathon-lb":{
    "name":"marathon-lb-internal",
    "haproxy-group":"internal",
    "bind-http-https":false,
    "role":""
  }
}

In this options file, we’re changing the name of the app instance and the name of the HAProxy group. The options file also disables the HTTP and HTTPS forwarding on ports 80 and 443 because it is not needed.

Next, run the install command with the new options:

$ dcos package install --options=options.json marathon-lb

Now there are 2 load balancers: an internal load balancer and an external one, which was installed along with marathon-lb

Creating DC/OS application

Packages — predefined DC/OS applications that stored at mesos-universe repo here: Universe Repo

To install DC/OS package use:

dcos package install <package name>

If you want to create your own application, you need to define a json-file, and install it with:

dcos marathon app add <name-of-your-app>.json

This json template is quite simple, you may use Marathon REST API to check the available commands:
https://mesosphere.github.io/marathon/docs/rest-api.html

Here’s is the sample grafana-template json, for creating application inside marathon:

{
  "id": "/grafana",
  "instances": 1,
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "quay.io/7insyde/grafana",
      "network": "BRIDGE",
      "portMappings": [{
        "containerPort": 3000,
        "hostPort": 3000,
        "protocol": "tcp",
        "servicePort": 10030
      }],
      "privileged": false
    },
    "volumes": []
  },
  "env": {
    "INFLUXDB_PORT_8086_TCP_ADDR": "influxdb.marathon.mesos",
    "INFLUXDB_PORT_8086_TCP_PORT": "8086"
  },
  "healthChecks": [{
    "gracePeriodSeconds": 300,
    "ignoreHttp1xx": false,
    "intervalSeconds": 60,
    "maxConsecutiveFailures": 3,
    "path": "/",
    "portIndex": 0,
    "protocol": "HTTP",
    "timeoutSeconds": 20
  }],
  "labels": {
    "HAPROXY_GROUP": "external"
  },
  "cpus": 1,
  "disk": 0,
  "mem": 512,
  "ports": [
    10030
  ]
}

IMPORTANT:

"labels": {
    "HAPROXY_GROUP"

is used to define your Load-balancer. “external” will launch the application connected to external load-balancer, and “internal” will connect it to internal load-balancer

There are 3 type of ports in DC/OS:

• Container Port
  Container port defines the port inside the container. Same as Docker.
• Host Port
  Host port define the port, which would be open on the slave instance. This port is used to communicate between the instances
• Service Port
  This is Load-balancer port to access the application from the outside.

In our example grafana uses

"portMappings": [{
        "containerPort": 3000,
        "hostPort": 3000,
        "protocol": "tcp",
        "servicePort": 10030

Where 3000 is port inside container, as well as port that being map to slave instance, but we are using ports 10030 (for ha-proxy elb) to access this application from the outside.

In our example grafana uses

"portMappings": [{
        "containerPort": 3000,
        "hostPort": 3000,
        "protocol": "tcp",
        "servicePort": 10030

Where 3000 is port inside container, as well as port that being map to slave instance, but we are using ports 10030 (for HAproxy ELB) to access this application from the outside.