Container orchestration is a popular topic at the moment because containers can help to solve problems faced by development and operations teams. However, running containers in production at scale is a non-trivial task. Even with the introduction of orchestration tools, container management isn’t without challenges. Container orchestration is a newer concept for most companies, which means the learning curve is going to be steep. And while the learning curve may be steep, the effort should pay off in the form of standardized deployments, application isolation, and more.
This course is designed to make the learning curve a bit less steep. You'll learn how to use Marathon, a popular orchestration tool, to manage containers with DC/OS.
- You should be able to deploy Mesos and Docker containers
- You should understand how to use constraints
- You should understand how to use health checks
- You should be familiar with App groups and Pods
- You should be able to perform a rolling upgrade
- You should understand service discovery and load balancing
- DevOps Engineers
- Site Reliability Engineers
To get the most from this course, you should already be familiar with DC/OS and containers and be comfortable with using the command line and with editing JSON.
|Lecture||What you'll learn|
|Intro||What to expect from this course|
|Overview||A review of container orchestration|
|Mesos Containers||How to deploy Mesos containers|
|Docker Containers||How to deploy Docker containers|
|Constraints||How to constrain containers to certain agents|
|Health Checks||How to ensure services are healthy|
|App Groups||How to form app groups|
|Pods||How to share networking and storage|
|Rolling Upgrades||How to preform a rolling upgrade|
|Persistence||How to use persistent storage|
|Service Discovery||How to use service discovery|
|Load Balancing||How to distribute traffic|
|Scenario||Tie everything together|
|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. Deployments can be a nightmare. I'd imagine most engineers have been involved in at least one deployment that went so far from expected that hours later the system was still down. These days, both the tooling and strategies for upgrades are better than they every have been, there are different options for deploying changes to one or more apps, there are methods such as Canary, Bluegreen, Rolling, and others that, combined with a CI pipeline have made deployments more science than art.
While there are third party frameworks such as Vamp and Marathon LB that allow you to perform different types of deployments out of the box, DCOS offers rolling upgrades. Let's check out how to perform a rolling upgrade. I have a JSON file here for an app that uses Python three five and this is a docker container.
It doesn't do all that much. It sleeps for five seconds and then it starts up a very simple web server using Python's HTTP module. Scrolling down, you can see that there will be 20 instances of this container, and that's so that you can actually see the upgrade process in action. There's a new property down here which is the interesting part called "Upgrade Strategy," and there are two properties of that that you can set.
The first is the minimum health capacity, which is a floating point between zero and one. It determines the percentage of instances that should remain healthy at any given point while upgrading. I've set this to . 85 of the 20 total instances, and that means that 85% of the instances need to be healthy.
As you can imagine, this means that you're going to want to health check. Now you don't need one, however, if you don't have a health check, you're really just gambling that everything is going to work. The next property is called Maximum Over Capacity, which is also a floating point between zero and one, that represents the percentage of instances that can be created over the total number of instances.
In this example, there are 20 instances. So, this tells Marathon than there can be up to 23 total instances in order to accommodate the upgrade. Let's create this and then we'll head over into the UI. Okay, switch to the UI, and this is going to take a little bit of time to get all these started, so I'll just fast forward this a little bit, okay.
Drilling into these services shows all 20 are healthy, so what we wanna do is upgrade the container to use Python three six rather than three five. I'll use the UI for this, though you could just as easily use the command line. So I wanna change the image to three dot six, and let's deploy this. Okay, notice right off three instances were killed, and then three started right up in their place.
Now once they have become healthy, three more are going to be killed off, and then this is just going to repeat until they've all been replaced. So that you don't need to wait for this to happen, this might take a few minutes, what I'll do is speed this up so you can see a time lapsed version. Okay, so that's it.
All of the instances have been replaced and are now healthy. By using the Upgrade Strategy property, you can use the default rolling deployment mechanism with relative ease. If you're using health checks, then rolling upgrades are a great built-in mechanism. However, you may be wondering about other methods for deployments and upgrades.
There are different ways to handle deployments, and there's one popular framework called Vamp, which does more than just deployments, but also handles different deployment types, and that's worth checking out. Like anything, rolling upgrades is going to have its pros and cons, which I will leave you to weigh, and in the next lesson, we're going to take a look at persistent volumes.
So, if you're ready to keep learning, then I will 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.