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.