Do you remember the days of deploying an N-tier application to on-premises servers? The planning that went into determining the right amount of hardware to use so that you weren’t under or significantly over-provisioned. Deployments were often problematic because what ran well on the developer’s computer didn’t always work outside of their environment. Deployments also were assumed to cause downtime, and scheduled during non-peak hours.
In the event of a hardware failure, your app might have been unavailable depending on how much hardware you had access to, and how the application was designed. Failovers may or may not have been automatic, and frankly, it was all a lot of work.
Well, if you thought that was difficult, imagine trying to do all of this at the scale of Google, Facebook, Twitter, Netflix, or similar companies.
All of the companies I just mentioned found that hyperscale computing required a new way to look at things. And regardless of the actual tools that they used, they all had the same solution, which was to treat their entire data center as a single entity.
And that’s what DC/OS does: it’s a central OS for your data center, and it’s the topic of this course.
- You should understand how DC/OS is used
- You should have a high-level understanding of DC/OS
- You should be familiar with the UI
- You should be familiar with the CLI
- You should be able to install services from the catalog
- DevOps Engineers
- Site Reliability Engineers
- Familiarity with containers
- Comfort with the command line
|Lecture||What you'll learn|
|Intro||What to expect from this course|
|A Brief History||The history of DC/OS|
|Overview||An overview of DC/OS|
|Components||About the components of DC/OS|
|Exploring the UI||How to navigate the UI|
|Installing WordPress (UI)||How to install WordPress from the Catalog|
|Installing WordPress (CLI)||How to install WordPress from the Catalog|
|Summary||How to keep learning|
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Welcome back! In this lesson we’ll explore the DC/OS user interface in order to get you familiar with it before you use it for yourself in the labs.
Here I am in the UI. When I setup the cluster I chose to use social login providers, so I’m logged in with my Github account.
The default landing page is this dashboard here, and it’s kind of like a computer’s activity monitor. It shows the CPU, memory, and disk allocation for the cluster. It also shows any running services, though, I don’t have yet. It shows any tasks and it also shows the health of the components running in the cluster. These are the components that were a part of that DC/OS architectural diagram I showed in a previous lesson.
At the bottom here you can see the nodes that make up this cluster. For this demo, I have 2 private nodes and 1 public node.
On the left hand side of the page is the navigation. Let’s click on the services link. This page shows some create buttons at the moment, since I don’t have any services. Once you have services created, they’ll be listed here. As I’m showing this, it’s probably a good time to cover what exactly a service is, in the context of DC/OS.
Here’s the abridged definition from the DC/OS docs:
“A DC/OS service is a set of one or more service instances that can be started and stopped as a group and restarted automatically if they exit before being stopped.”
A service in DC/OS could be a app or pod run with Marathon, or it could also be something run on an agent via systemd. And there are two types of services, there are system services, and user services.
System services extend the functionality of DC/OS and are owned by the DC/OS user.
User services are services that you might create, such as using Marathon to start up a container running nginx.
While I don’t have any services yet on my cluster, here’s a look at a screen with a few services.
Notice the cassandra service has 4 instances, as does kafka, while the marathon load balancer and zeppelin have just one each. So a service here, is kind of how you might think of it from an application development standpoint. Each service is a discrete unit of functionality that can scale up or down as needed.
Don’t worry if the concept doesn’t make sense now, as you move through the DC/OS content, it will start to become clear.
Next let’s check out the jobs page. This is basically cron for DC/OS, allowing you to create scheduled tasks.
Next is one of my favorite features, the DC/OS package manager referred to as the Mesosphere Catalog. The Catalog allows you to install packages from a package repository. There’s a default community repository that has all kinds of different services that you can install.
Scrolling through the list you can spot things such as cassandra, etcd, mongoDB, MySQL, SQL Server, Vamp, Wordpress, and all of these others. You can even run your own private instance of the catalog which would allow you push button installs of your apps. Which is very cool!
Moving on to the nodes page, you can see all of the nodes in the cluster. By clicking on the hostname for one of the nodes you get a detail view of that node. It shows any tasks running on the node. The health tab shows the state of the different components that run on that node. And then details shows some version and state info as well as details about the nodes resources.
The next page to check out is the networking page, which shows you the details of your virtual networks. There’s not much to see here at the moment.
On the system overview page, you’ll get details about the cluster, such as the DC/OS version, and public IP.
You’ll get details about Marathon, such as the version and the leader’s IP, as well as config details and some zookeeper info.
The components page is going to show you the state of all of the DC/OS components. This is going to help you to identify any problems.
Under the settings list there’s an option for Package Repositories, and this is where you can add new repos.
And finally there’s the Organization page, for managing users.
So, as you can see the UI is pretty straight forward. It’s a modern web UI that’s pretty easy to navigate.
Okay, let’s wrap up this lesson here. In the next lesson we’re going to get hands on by installing MySQL and Wordpress from the DC/OS Catalog.
So if you’re ready to start using DC/OS, then let’s get started in the next lesson!
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.