Marathon auf Triton

Der Beitrag ist im Oktober 2015 erschienen


Nein, jetzt kommt keine Geschichte aus der Antike mit Erfolgsmeldungen per Kurier oder göttliche Meeresmischwesen. Vielmehr geht es um Orchestrierung von Containern - mandantenfähig und stabil. Nach dem Hackathon, den Joyent auf dem MesosCon 2015 in Dublin gesponsort hat war abzusehen, dass die schon geschilderten Anstrengungen zu Ergebnissen führen würden. Um Triton als IaaS für Mesos/Marathon nutzen zu können, waren offenbar ein paar Änderungen am Mesos erforderlich:

  1. Remove network ports as a consumable resource. Because every container gets one or more unique network interfaces, there's never a port conflict to worry about. This simplified networking is one of the many advantages of Joyent's container-native infrastructure.
  2. Remove the assumption of cgroups in the Docker containerizer. Joyent Triton uses secure SmartOS Zones to isolate containers on bare metal. We've been using this technology to power our cloud for almost ten years and it's what allows us to offer Mesos with consumption-model pricing in a multi-tenant environment.
  3. Don't mount the Mesos sandbox as a host volume in the Docker container. Because Docker containers run in a multi-tenant environment, there's no access to the underlying host filesystem. This is an important factor in multi-tenant security.
  4. Lower-case the Docker container name to comply with expectations in the Docker remote API.
  5. Automatically clean up stopped containers to eliminate the need for garbage collection or any charges for containers that are provisioned, but not doing work.

Durch diese Änderungen wird jetzt folgendes Setup realisiert, wenn man die von Casey Bisson erstellten Docker-Images verwendet:

(leider ist das Diagramm verschwunden)

Es wird mindestens ein Mesos-Master, ein Mesos-Slave, ein Zookeeper, eine Consul- und eine Marathon-Instanz gestartet. Da dies mit docker-compose geschieht, können diese leicht mit docker-compose scale "vermehrt" werden. Der Mesos-Slave kommuniziert dann per Docker-API mit dem Docker-Daemon von Triton.

Die Marathon-Tasks werden wie gehabt per curl-Aufruf angelegt:

curl -X POST http://10.64.227.39:8080/v2/apps -d @marathon-tasks/nginx.json -H 'Content-type: application/json'

Die zugehörige Beschreibung des Tasks sieht so aus:

{
    "id": "/nginx",
    "cmd": null,
    "cpus": 0.0625,
    "mem": 128,
    "disk": 64,
    "container": {
        "type": "DOCKER",
        "volumes": [],
        "docker": {
            "image": "nginx",
            "network": "BRIDGE",
            "portMappings": [
                {
                    "containerPort": 80,
                    "hostPort": 80,
                    "servicePort": 0,
                    "protocol": "tcp"
                }
            ],
            "privileged": false,
            "parameters": [],
            "forcePullImage": false
        }
    },
    "instances": 1,
    "maxLaunchDelaySeconds": 60,
    "upgradeStrategy": {
        "minimumHealthCapacity": 0.9,
        "maximumOverCapacity": 0.2
    },
    "uris": []
}

Wenn der Task dann angelegt ist, kann dieser per Marathon skaliert werden. Marathon wird auch die konfigurierte Anzahl der Instanzen konstant halten - falls welche ausfallen, wird die entsprechende Anzahl wieder aufgefüllt. Neben einem Task für nginx hat Casey Bisson auch einen für den schon bekannten Couchbase Cluster angelegt. So können also auch Marathon und Mesos mandantenfähig als Orchestrierungsinstrument für Docker-Container eingesetzt werden.