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 firstname.lastname@example.org.
Welcome back! Hearing about the concepts behind something is important, however, it can also be boring if you’re a hands-on learner like me. So, let’s dive into a demo of how to install Wordpress and MySQL from the DC/OS Catalog.
Let’s start by heading to the packages page and searching for MySQL. There are a few options, however we want the one that says MySQL.
Clicking on the tile gives us a details page. You can install the software with all of the defaults, or click on the “configure” option to adjust settings before installing.
I’m going to use the “configure” option.
This opens another dialog where you can make any changes. I’ll change the service name from MySQL dbserver. And I’m going to leave the resources set to the defaults of half of a CPU, and 1,024MB of RAM.
On the database tab, I’m going to set all of the values here to “wordpress” and the reason is that the Wordpress package uses “wordpress” for all of its defaults. So this is just to make the installation easier to demonstrate. In production applications, PLEASE, PLEASE, PLEASE, don’t ever use a one word password.
On the storage tab, this is where you can configure persistent storage for this service. If you don’t configure persistent storage, then the data is going to be ephemeral; meaning that once the service stops any data will be lost. If you’re familiar with containers, this shouldn’t be a new concept for you.
I’m not going to configure persistent storage for this demo. So let’s move on to networking. By default the port is set to 3306. To make this demo easier, I’m going to use host mode, which will ensure that the container running MySQL binds to port 3306 on the agent where this will run. Because it’s binding to port 3306 on the agent, it also means that only one instance of this service can be run per agent.
Okay, clicking review and deploy will bring up a summary to review before clicking deploy.
Now I want to head over to the services page so you can see the service getting deployed. This deployment could take a couple minutes, so I’m going to grab some coffee, and be right back.
Alright, this took right around a minute to deploy, and the status is now set to running.
Heading back to the dashboard, notice that the CPU for the cluster is now at 4% utilization and the memory is at 2% utilization. That’s because when setting up MySQL, I told it to use half of a CPU and 1024MB of RAM...Which you can see on the services page.
So now that the database is installed it’s time to install Wordpress. Back to the packages page, and start typing wordpress… and before I even complete the word, it’s the only option in the list. I’m going to use the advanced install again.
I’m going to bump this memory up from 512 to 1024...perfect.
On the database tab, notice the hostname is mysql.marathon.mesos followed by the port. This hostname uses service discovery to locate the service named mysql. That first part of the hostname is the name of the service that you want to connect to. Recall the we changed the service name from MySQL to dbserver. So let’s edit this to reflect that change.
Service discovery is something covered later on in the learning path so I’m not going to cover it now. Though, I wanted to make sure to call it out here so you know what’s happening.
Regarding the schema name, username and passwords, notice they’re all set to wordpress. That’s why I set all of those to wordpress when installing MySQL.
I’m not going to do anything with networking or storage, so it’s time to click review and deploy. And this all looks good, so, I’ll click deploy.
This install should be pretty quick...actually, there it is, all done. Now it’s time to see if everything was successful. For that hovering the mouse over the Wordpress service will cause a launch icon beside the service’s name. Clicking the icon opens up wordpress in another tab.
And...there it is, this is the Wordpress installer, which means that wordpress is up-and-running.
Before wrapping up this lesson, I want to show you how to destroy a service.
On the services page, hover over the service you want to destroy and click the ellipsis on the right, and then select delete.
It will prompt you to verify that you want to destroy the service. And once you confirm, away the service goes.
I’m going to remove both services since in the next lesson I’ll demo how to use the CLI to do this same thing.
So, if you’re interested in see the CLI in action, I’ll see you 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.