Tutorial - Deploying native applications

Part 5 of the DC/OS 101 tutorial

Welcome to part 5 of the DC/OS 101 Tutorial

Prerequisites

  • deployed and running in your cluster.

Objective

in this tutorial you deployed an app that operates internally in your cluster, interfacing with other applications in the cluster as opposed to interacting externally. In this part you will deploy an app which provides a GUI to users. You will also deploy this app natively, without relying on Docker as a dependency and therefore reducing complexity.

Steps

  • Understand the application
    • Take a short look at . App2 is a Go based HTTP server that exposes a very simple interface to Redis.
  • Deploy app2
    • Take a short look at the . In this case, the app is a binary without external dependencies. Because of this, you no longer need to deploy it in a Docker container.
    • Deploy app2:

Accessing the app from within the cluster and viewing the raw HTML response proves our application is running, but in the real world you want to expose the app to the public. In the next part of this tutorial you will do exactly that.

Outcome

You have deployed a second app that uses the native Mesos containerizer.

Deep Dive

  1. Using Docker (app1).

Let’s explore the differences in some more detail.

DC/OS uses containerizers to run tasks in containers. Running tasks in containers offers a number of benefits, including the ability to isolate tasks from one another and control task resources programmatically. DC/OS supports two types of containerizers - the DC/OS Universal Container Runtime, and the Docker containerizer.

For your first app, you used a Docker container image to package app1’s dependencies ( Remember: never rely on dependencies being installed on an agent! ) and then used the Docker containerizer to execute it. Because the Docker containerizer internally uses the , you also used the Docker runtime.

For your second app, you did not have any dependencies and therefore could rely on the default DC/OS Universal Container Runtime. Internally, both runtimes use the same OS features for isolation, namely cgroups and . This actually makes it possible to use the DC/OS Universal Container Runtime for running Docker images - check the DC/OS Universal Container Runtime documentation for details.