 Hi, I'm Chris Bloom, and I'm an architect in a storage BU. Today, I'm going to talk about traditional stateful applications on OpenShift 4 using OpenShift Container Storage 4. And we will show this on a little demo that leverages typical Rails and Postgres application. Today, we're going to talk about what we consider traditional stateful applications, why you should use OCS for these applications, and then I'm going to show you this quick demo with the Rails and Postgres application. So what do we consider traditional stateful applications? These are applications that typically store state and rely on that state to be present. So these applications generally, when you install them, have an init phase where they initialize their backend storage. And typically, if it's a database, they put in tables and indexes and all that. And then once users use these applications, the data that they rely on, it grows and you have to keep it. Since they're traditional applications, they're not necessarily aware that they're running inside of OpenShift. And they also don't typically leverage OpenShift for Kubernetes APIs, such as secrets or config maps, but they might be using them indirectly without knowing that they're actually using them. So why should I use OCS for my stateful applications? OCS has a very easy way to install itself. It's built upon battle-tested software like Rogue and Seth that have already been used for many, many years by customers in productive environments. And it has been shown that using this software, it's very easy to scale out and not only increase the capacity, which is easy, but it can also increase the performance almost linearly. Then obviously, using OCS, you get Red Hat support. And since that software, Seth and Rogue, the storage software is so popular, we can also look on a very large community that helps us in certain areas. So going forward with the demo, what we're going to see is a deployment of a typical Rails application that relies on a Postgres database backend. So Postgres manages the state of the application. Application itself is not stateful. And Postgres is backed by OCS to retain it. And to show you that this is actually true, we're going to scale down the application in the end to simulate a fault. And then we scale it back up so that it comes back up and we show that our data is actually safe. So let's head over there. For this, we're going to use this example here that I've prepared. And we're just going to deploy this application now, just like we have in the example here. This will take a bit, but I'm going to fast forward the video so you don't have to wait. With the OC status, we can theoretically check on our application and we do see that it's currently still new. But we can also see that we already have a PVC for our Postgres database. And that is already bound. So the backend storage system, which is backed by CefRBD, has already created this volume and it's ready for the pod to use it. So let's check how far the deployment is already. Okay, so our Postgres deployment has finished. The database is ready to be used. The Rails application is currently in the build phase. And as you can see in the guide here, after the build we deploy, have a hook, and then we actually deploy our application. We'll come back in a second. Okay. As we can see now, the Postgres part is running and the Rails application has gone through its build deployment hook setup and it's now also running. So we are good to continue. And to continue, we will figure out how we can reach our application by checking on the routes. And our routes looks like this. So in this example, we see that we have to append slash articles to log in. We are using these credentials here. So username, open shift, password, secret. Let's do that. We click on new article and we use a title like I'm running on your CS. And this is great. So this is our first article. I'm not going to comment on it right now, so we go back to the other video and we see that this is a great article. So this is our first state. As you've seen, we have gone through an init phase, the Rails application that prepared the Postgres database. And now, as a user, we created our very first data and that will also be retained in our Postgres database. So now, let's look a little bit more on our storage backend. And for this, let's first get an overview of our PVC system volume claim that we already saw before. Now its name is Postgres, it's bound. It's using SethRBD. To look at SethRBD a little bit closer, we will go into the SethRook toolbox. And this is how we get in there. Then we can execute commands like SethDF or RadosDF, which will both give us a good overview of how our storage is used. We do see that our storage glass is based on SSD disks. We do have a lot of pools, but we're currently only interested in this pool because it matches what the storage glass is using. So SethRBD is backed by the SethBlock pool. And so let's look at the images that are inside of this pool. We do this by executing RBD with minus P, which is for pool. And we do see that we have two images. And based on the PVC name, I would assume that it's this volume that is basing our Postgres database. So we can look at this a little bit closer using info. And we do see that size is five gigabytes. So this is very, very likely our image. List all the PVCs in all namespaces like this. Then we can see that there are actually two PVCs that are using the OCS storage glass. And that's our Postgres application and also the Nuva database. Nuva database is using 50 gigabytes. So since this is five gigabytes, this is indeed our Seth volume that we're exporting to our application. So now we have our application up here and we do see that the articles are there and everything is good. So let's simulate a little bit of full. We go over here and this is the web UI of OpenShift 4. And we are looking now at the replication controllers inside of our project that we created called myDatabase app. And we do have here the replication controllers for Postgres and Rails. So what I'm going to do is I'm going to watch the pots here and here I'm going to change the count. So I'm going to decrease the amount of Postgres databases that I say we need. This will terminate our Postgres cluster. So what the replication controller did is it started a new Postgres. And as you can see, even though it's a completely new database, we now have our articles up there and we're perfectly fine with this. So this concludes our little demo of Rails application using Postgres that is backed by OCS as you can see. It's fairly simple to do that and even to demo this in a matter of 10 minutes. And if you have questions, please use the Q&A part and I'm happy to answer there.