Welcome back. In this lesson, we'll look at persistence. If you're going to use stateful apps, then you need to think about persistent storage. DC/OS offers two options: persistent volumes and external volumes. Both options allow you to persist state, such that if a task fails, data will remain. External volumes are considered experimental in DC/OS 1.10. However, it's based on a project called REX-Ray, that allows you to use external storage providers, such as AWS EBS, GCE Disks, OpenStack Cinder, and others. Now, this is a great way to have data centrally located and persisted.

We're going to focus on local volumes for this lesson. Local volumes create a device on the agent that's running the application and shares it with a container. That means if a task fails, it needs to be restarted on the same agent. Also, these volumes aren't backed up by DC/OS. Actually, DC/OS doesn't manage them at all. That's on you, so if you want them deleted or backed up, you're going to have to take care of that.

So, for this demo, I want to show that if a task fails, it's going to restart on the same node, and it will have access to the same data as the original container. So, here's what I'm going to do. I'm going to add a gate to a file in a persistent volume, only if the file doesn't already exist.

So, if the file exists, it's not gonna edit the date. Then, I'll print the date in the file to standard out, so that you can see that the date doesn't change. And to simulate a failure, what I'll do is wait 30 seconds and then shut down the container.

Now, because I don't wanna do any of this manually, what I do is I have this one-liner here, and it's just gonna kind of wrap that functionality that I just mentioned. It's going to check to see if the /data/date file exists. If not, it will create it by sending the date into it. Then, it's going to cat the results to standard out. It'll sleep for 30 seconds, and then we'll shut down.

Other than knowing what that command is doing, it's not very interesting. What is interesting is the volumes property. This allows you to map a volume on the agent to a volume in the container. So, let's create this app. Okay, and let's head over to the UI. And great! It's already running. Let's look at the log, because standard out shows that it's going to have a date, and the date here is Saturday, September 23rd, at 20:23 UTC.

So now, in 30 seconds or so, this container's going to shut down, and even without a health check, that's considered a failure. So, I'm going to speed this up, just a bit, so you don't have to wait the full 30 seconds. And now, in just a second, the container's going to be killed and restarted. And there it was. Now it was quick, but the container is now back up and running. Let's look at the logs. And notice that standard out didn't change.

Now, because there wasn't a visual change in the log, it may seem like nothing actually happened. However, the container stopped, and since Marathon is supposed to keep containers in a running state, it started another one. Because there are persistent volumes, a failed task starts on the same agent. And so, it's started up another container, and then just rebounted that volume. And so, now you're seeing that the date is the same, because it was only set the first time.

On the Files Tab, you can see that there's a list of files created by the container. Here's our data folder, and the date file inside of that. And volumes are important for any sort of stateful application. They require some planning for backup, replication, and other management tasks. However, should you have some stateful workloads, you should start looking at volumes. Alright, in the next lesson, we're going to look at Service Discovery. So if you're ready to get started, I'll see you in the next lesson.