Store persistent data in Red Hat OpenShift using PVCs

Without data, software has no value. Data needs to be created, stored, updated, and retrieved. One way to store persistent data in OpenShift is by using a Persistent Volume Claim (PVC). In this learning path, created by Don Schenck, you will learn how to create a PVC and access it with your pod.

In this lesson, you will get an introduction to PVs and PVCs, then log in to your Developer Sandbox account and create a filecontents application.

What you need

What you will do

  • Learn what a PV is
  • Learn what a PVC is
  • Learn how to create a filecontents application

PVCs: An introduction

OpenShift storage is built on the concept of the Persistent Volume (PV). A PV is an abstraction of any underlying storage, such as the AWS Elastic Block Storage. A PV is available to all projects in an OpenShift cluster. A PVC is a specific claim to storage. It uses a PV to obtain the actual storage, but the PVC is limited to an OpenShift project (or, in Kubernetes-speak, a namespace).

Even though a PV is available to all projects, once it is assigned to a PVC, it cannot be used by any other project. In effect, this does limit a PV to a project after it’s put into use. Prior to that, however, the PV is widely available.

Info alert: The administrator defines the underlying storage to the cluster by using a StorageClass object.

While a developer does not need to know what underlying storage is used, it may be helpful. Here’s a list of the storage classes available in the Developer Sandbox (Figure 1).

The four storage classes available in Developer Sandbox: gp2, gp2-csi,gp3, and gp3-csi.
Figure 1: A list of the storage classes available in Developer Sandbox.

When you attempt to provision storage, OpenShift will use the PVC specifications to locate the “best fitting” StorageClass.

Info alert: If you ask for more storage for a PVC than is available in any PV, the PVC will never be bound to your pod; it simply sits and waits for the correct PV to come along.

PVCs have four access modes:

  • ReadWriteOnce (RWO)
  • ReadOnlyMany (ROX)
  • ReadWriteMany (RWX)
  • ReadWriteOncePod (RWOP)

As of this writing (January 28, 2024), the RWOP option is a technical preview. Please note that the Developer Sandbox is limited to RWO by design.

There are other important features and characteristics of PVCs,  and they will be covered as this learning path proceeds. Let’s get started.

Access your sandbox at the command line

If you’re unsure how to do this, you can find instructions here: Access your Developer Sandbox for Red Hat OpenShift from the command line.

Create the filecontents application

Run the following two commands to create and expose the application, filecontents:

oc new-app quay.io/rhdevelopers/filecontents:1.0.0 --labels tier=backend,language=java,filecontents=backend,sandbox=pvcs

The application filecontents is a web API that returns whatever content it finds in a specific file. The default file, which was placed inside the running container when the image was built, is /etc/files/mytext.txt.

Creating a route gives the application an external URL:

oc create route edge --service=filecontents --port=8080

View the results using curl command

This step requires two parts: Get the route, and run Curl. Run the following command to get the route and endpoint needed:

oc get route filecontents -o jsonpath='{"https://"}{.spec.host}'/api/filecontents

Open a command-line session, preferably so you can see the session running while you continue with the remainder of this activity. Now start the curl loop, using the URL you retrieved:

If using PowerShell:

while ($true) { curl https://filecontents-rhn-engineering-dsch-dev.apps.sandbox-m3.1530.p1.openshiftapps.com/api/filecontents;echo '';start-sleep -Milliseconds 300; }

If using Bash:

for ((i=1;i<=10000;i++)); do curl https://filecontents-rhn-engineering-dsch-dev.apps.sandbox-m3.1530.p1.openshiftapps.com/api/filecontents; echo -e; sleep .3; done;

Update the environment variables for your deployment

Initially, the application is reading from a file that is part of the container. The next step is to have the application read from a file in a PVC. For starters, change the environment variables that the app uses to locate the file for input. These two variables, FILE_PATH and FILE_NAME, need to be changed to use the PVC we will create.

Run the following command to set the environment variables.

oc set env deploy/filecontents FILE_PATH=/mypvc FILE_NAME=mytext.txt

View the results using a curl command

When you run this command, OpenShift will perform a rolling update and replace the existing pod with a new pod. Given the values included in the command, you can see where the application will look for the input file.

Looking at the curl loop, you will notice that the app fails, because it is looking for a non-existent file in a non-existent file path:

Add storage to your deployment

Run the following command to create the PVC mypvc and mount it for the deployment we created (filecontents):

oc set volumes deploy/filecontents --add --mount-path=/mypvc --name=mypvc --claim-name=mypvc --read-only=false --type=persistentVolumeClaim --claim-size=1Gi

Yet, the app is still failing. This is because the file, “mytext.txt” does not exist in the PVC. Don't worry. You will learn how to solve this challenge in the next lesson.

Previous resource
Overview: Store persistent data in Red Hat OpenShift using PVCs
Next resource
Copy a file to your PVC and create a new deployment