Welcome to part 5 of the DC/OS 101 Tutorial
Earlier 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.
- Take a short look at app2. App2 is a Go based HTTP server that exposes a very simple interface to Redis.
- Deploy app2. Take a short look at the app definition. 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.
dcos marathon app add https://raw.githubusercontent.com/joerg84/dcos-101/master/app2/app2.json
- You have multiple options to verify that
app2is sucessfully running:
By looking at all DC/OS tasks:
By looking at all Marathon apps:
dcos marathon app list
Curl the http server from within the cluster (in this case from the leading master):
dcos node ssh --master-proxy --leader
This should return you the raw HTML response from
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.
You have deployed a second app that uses the native Mesos containerizer.
You have now deployed apps in two different ways:
- Using Docker (app1).
- Using the native Universal Container Runtime (app2).
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 Docker runtime, 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 namespaces. 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.
In the next part of this tutorial you will expose your app to the public.