8. Persistent storage

By default, data in containers is not persistent as was the case e.g. in 7. Attaching a database. This means that the data written in a container is lost as soon as it does not exist anymore. We want to prevent this from happening. One possible solution to this problem is to use persistent storage.

Request storage

Attaching persistent storage to a Pod happens in two steps. The first step includes the creation of a so-called PersistentVolumeClaim (PVC) in our namespace. This claim defines amongst other things what size we would like to get.

The PersistentVolumeClaim only represents a request but not the storage itself. It is automatically going to be bound to a PersistentVolume by OpenShift, one that has at least the requested size. If only volumes exist that have a bigger size than was requested, one of these volumes is going to be used. The claim will automatically be updated with the new size. If there are only smaller volumes available, the claim cannot be fulfilled as long as no volume with the exact same or larger size is created.

Attaching a volume to a Pod

In a second step, the PVC from before is going to be attached to the Pod. In 5. Scaling we used oc set to add a readiness probe to the Deployment. We are now going to do the same and insert the PersistentVolume.

Task 8.1: Add a PersistentVolume

The oc set volume command makes it possible to create a PVC and attach it to a Deployment in one fell swoop:

oc set volume dc/mariadb --add --name=mariadb-data --claim-name=mariadb-data --type persistentVolumeClaim --mount-path=/var/lib/mysql --claim-size=1G --overwrite --namespace <namespace>

With the instruction above we create a PVC named mariadb-data of 1Gi in size, attach it to the DeploymentConfig mariadb and mount it at /var/lib/mysql. This is where the MariaDB process writes its data by default so after we make this change, the database will not even notice that it is writing in a PersistentVolume.

We need to redeploy the application pod, our application automatically creates the database schema at startup time. Wait for the database pod to be started fully before restarting the application pod.

If you want to force a redeployment of a Pod, you can use this:

oc rollout restart deployment example-web-app --namespace <namespace>

Using the command oc get persistentvolumeclaim or oc get pvc, we can display the freshly created PersistentVolumeClaim:

oc get pvc --namespace <namespace>

Which gives you an output similar to this:

NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mariadb-data     Bound    pvc-2cb78deb-d157-11e8-a406-42010a840034   1Gi        RWO            standard       11s

The two columns STATUS and VOLUME show us that our claim has been bound to the PersistentVolume pvc-2cb78deb-d157-11e8-a406-42010a840034.

Error case

If the container is not able to start it is the right moment to debug it! Check the logs from the container and search for the error.

oc logs mariadb-f845ccdb7-hf2x5 --namespace <namespace>

Task 8.2: Persistence check

Restore data

Repeat the task to import a database dump .

Test

Scale your MariaDB Pod to 0 replicas and back to 1. Observe that the new Pod didn’t loose any data.