The course is part of this learning path
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 email@example.com.
Welcome back! This lesson is going to focus on using the command line interface to install MySQL and Wordpress.
First thing to do is install the CLI. DC/OS makes this easy by providing a mechanism from inside of the UI to get and configure the CLI.
On the top of the side navigation clicking on the dcos drop down shows a few links. Notice the option for “Install CLI” under the support heading.
Clicking this opens a dialog that has a copy and paste ready command that will download the CLI, install it, and configure it.
To install the CLI just copy this and paste it into a terminal. Let’s check that out. I’ll copy this, and switch over to my terminal, and paste it here.
After the CLI has been downloaded and moved to the bin directory, it’s going to set the DC/OS URL so that the CLI knows where the DC/OS cluster is located.
Next, it needs to authenticate against the DC/OS cluster. The installer should open up a URL to authenticate in your browser. If not, follow the link it provides.
Since I’m using Github for auth I’ll select the Github option, and since I’m already authenticated in the UI, it’s going to take me to a page containing the auth token.
I’ll click copy to clipboard, and then head back to the terminal...and I’ll paste this here.
Notice here that the login was successful. This is great, because now I can start interacting with DC/OS via the command line.
I’m going to clear the terminal, and run dcos without any arguments to show you the available commands.
Going through these quickly:
“auth” will kick off the authentication flow that you just saw.
“config” allows you to change configuration settings, such as the URL to the DC/OS cluster.
“experimental” is where you’ll find functionality that isn’t in production yet.
“help” displays some help info.
“job” allows you to deploy and manage jobs.
“marathon” allows you to interact with marathon applications.
“node” is used to get info about the nodes in the cluster.
“package” allows you to install DC/OS packages.
“service” is used to manage services.
“task” is used to manage tasks.
For this course I’ll be focusing on installing packages from the DC/OS Catalog, so you’ll mainly see the package command. However, you’ll get to see the other commands used later in the learning path.
Let’s take the CLI for a quick spin before installing Wordpress.
While I don’t have any running user services, there are some system services that you can see by running the “dcos service” command.
Notice marathon and metronome are both running and active. Recall that Marathon is used for long running services, hence the name marathon. And Metronome is an Mesos framework for running short lived services, which DC/OS uses it for running jobs.
For each command, you can use the minus minus help flag. As an example, if I ran “dcos task” you can see that nothing seemed to happen. If you’re not familiar with the task command, you might not know if something happened successfully or not. So if I run it again with the help flag, it prints usage details for the “task” command.
Scrolling up you can see all of the subcommands for the task command, there’s an “exec” command to launch a task, a “log” command, an “ls”, etcetera. I don’t have any tasks, however, if I did, you’d see them listed with the ls command.
Okay, hopefully by now you’re feeling pretty comfortable with the CLI. So now I want to use it to show you how to perform the same MySQL and Wordpress install that I showed with the UI.
If you wanted to install a package without changing the configuration, then it’s really simple.
All you need to do is run the command "dcos package install” followed by the name of the package from the Catalog. For example, running “dcos package install mysql” would install MySQL from the Catalog with all of the defaults.
In this lesson, just like the previous lesson, I want to edit the configuration of the services just a bit. So for that, I’ll need to let the CLI know about the changes I want to make.
When I used the advanced installation in the UI there were input fields to edit things such as CPU, memory, the service name, and everything else. What you didn’t see is that behind the scenes all the UI was doing was building a JSON object that was posted to the API.
In order to do an advanced install with the CLI, you need to create that JSON object and pass it to the CLI.
If you already know the required structure for the JSON, and the settings that you need, then all you need to do is fire up your favorite text editor and start typing.
However, it’s not likely you’ll know the settings for every package you want to install.
Luckily you can get the info you need from either the CLI or the UI.
From the CLI you can run the “dcos package describe” command with the config flag, followed by the name of the package. This will return some JSON describing the properties that you can set, as well as their current defaults.
By describing the JSON for the MySQL service, you can see that there are a lot of properties we can edit. Scrolling back up, you can see the same fields we changed in the UI, things such as username, password, etc.
There’s also a way to use the UI to get the JSON along with the values you set. Actually, in the previous lesson, on the summary dialog that appears before confirming the install, there’s a download as JSON button.
This button downloads the JSON that is generated from filling out the advanced options.
I already have a JSON file for mysql and wordpress. If I cat the MySQL file you can see the settings.
The MySQL starts with the name of the service, followed by options for the CPU and memory.
Then there’s a database section which has all the properties for the database name, the username and the passwords. If you recall from the previous lesson, I set these to wordpress to make the install easier.
Then in the storage section, persistence is disabled, so the host volume is going to be the temp directory.
At the bottom is the networking section where the port is set, as well as enabling host mode.
The wordpress JSON file is a bit simpler. There are details about the name of the service, CPU and memory. Then there’s the database section, the networking and the storage.
So, these two files are just a JSON version of the values used in the UI in the previous lesson.
Now it’s time to create the services. First, if I run the dcos package list command, you’ll notice that there’s nothing installed. So I’m starting with a blank slate.
First I’ll install MySQL by running the command ‘dcos package install mysql --options=”mysql.json”’
This tells DC/OS to install the mysql package from the catalog and use the options set in the mysql.json file. If we didn’t set a value for a specific property in that file, then it uses the defaults.
Okay, it’s asking if I want to continue with the install, so I’ll type yes...and there it is.
Now, to see the state of the task I can issue the command “dcos task” and it will return info about the newly created task. Notice it shows the name of the task, the host, the state of R, for running, and some IDs. So the MySQL service is up-and-running.
Okay, now it’s time to get the Wordpress service running. For that, I’ll head back into the terminal.
I’m just going to press up on the keyboard and edit the previous command. The end result should be “dcos package install wordpress --options=”wordpress.json”
And it’s going to prompt for confirmation, so I’ll type yes...great! With this installed, I should be able to launch the wordpress page from the UI...and...there it is!
If I head back into the terminal and I run the “dcos task” command...you can see that there are two tasks running, there’s the mysql and wordpress.
Okay, before wrapping up, it’s time to clean up these services from the CLI, so to do that I’m going to run the command “dcos marathon app remove wordpress”
And if I list the tasks again, notice wordpress is no longer showing.
I’ll do the same thing for MySQL by running “dcos marathon app remove dbserver”
The reason this is called dbserver is that I named this service dbserver. So when you’re installing a package you use the name of the package. When you remove it, you use the name of the service that you provided.
And back in the UI, the services page has already updated to reflect that there are no services.
Alright, that’s going to wrap up this lesson. The next lesson will wrap up this course and talk a bit about what’s next for this learning path.
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.