Welcome to part 5 of the DC/OS 101 Tutorial
- A running DC/OS cluster with the DC/OS CLI installed.
- app1 deployed and running in your cluster.
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.
- Understand the application
- 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.
- Deploy app2:
dcos marathon app add https://raw.githubusercontent.com/joerg84/dcos-101/master/app2/app2.json
- You have multiple options to check app 2 is 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 app2’s webserver.
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.