If you are a software engineer like myself, two areas that I am not well versed in are networking and storage. Yes, my application has to communicate and yes my application needs to be deployed and requires some storage. Though that is usually the extent of my knowledge. Thanks to using elastic compute from cloud vendors in the last several years, the answer I usually give is “yes, attach 100gb of standard block storage per instance”. That storage would be pretty durable; as durable as what you expect a VM to be.
Though fast forward to the world of containerization. Containers are ephemeral e.g meant to die to the type of workload you place in containers needs to take the ephemerality into consideration. A running container does have storage and also if running in Kubernetes, the Kubernetes node itself has storage also. There is an entire industry based on Kubernetes Storage e.g CSI. In Shipa there is volume management functionality that helps streamline how storage is provisioned on your Kubernetes nodes. Even with a very slim or even distroless base image, your container will use some sort of storage. For the developer though, the focus shifts to the application, and Shipa helps make this simpler.
Applications Need Storage
Let’s say that you are deploying WordPress. If leveraging WordPress from public Docker Hub, Let’s say you also want to leverage MySQL. Typically MySQL will write to “/var/lib/mysql”. Though this would require volumes to be explicitly wired into the deployment manifests and is up to the deployment to provision. Having developers manage this can get complicated since there is not a central spot. Even more so what if the container dies or restarts? The storage should be defined somewhere else.
Kubernetes does have another way of managing storage. If there is storage that is needed to be managed at the cluster level e.g the Kubernetes node level, Kubernetes has something called PV or a Persistent Volume. Now storage is a cluster-level resource and can be placed on nodes. There are benefits to this approach like the storage presenting itself to the containers instead of complexity needing to be managed at deployment times. Also as the name suggests, Persistent Volumes are more persistent than container volumes. Shipa can help create these rapidly with Shipa Volumes.
Shipa Volumes
Shipa Volumes allow you to create Persistent Volumes easily and will bind these to your Shipa Applications pretty seamlessly. Let’s say you want to have “var/shiparocks” available to your applications so yourself or developers don’t have to manage that themselves. The easiest way would be to create a Shipa Volume.
Why Create a Shipa Volume
In my Shipa Cloud instance I have a few apps deployed. Clearly, “var/shiparocks” doesn’t exist. To validate this, you can SSH into the running container. Even this is a breeze with Shipa with Shipa App Shell.
shipa app list shipa app shell -a portal ls -l /var/shiparocks exit
Don’t worry we can expose this to the running containers with Shipa Volumes.
Create Your First Shipa Volume
Assuming that you have something deployed through Shipa or Shipa Cloud, you can head to Shipa -> Volume Plans then + Create Volume Plan.
You will need to provide a Storage Class; here is a list of providers and their Kubernetes Storage Classes. Of if you have access to your cluster, can run a kubectl command.
kubectl get storageclass
In my case here I am using Oracle Kubernetes so the default Storage Class is “oci”.
Click Create.
You can validate that there are no Persistent Volume Claims [PCVs].
kubectl get pvc -A
Back to the Shipa UI, click into the Plan created e.g “oraclestorage” and create a new Volume.
Can give a name and size and associate with a Shipa Team and Framework. The Access Mode does take a little research since storage can be unique through cloud vendors. E.g here is Oracle Cloud’s Documentation suggesting the Access Mode is “Read Write Once”.
Next click Create. Now you are ready to Bind the Volume by clicking on the Bind icon.
Select an application to bind to and give a directory e.g Mount Point to create.
Mount Point: /var/shiparocks/
Click Bind and you have just created a PVC
kubectl get pvc -A
SSH back into the container and see that like PVC magic, the directory is accessible to the container!
shipa app shell -a portal ls -l /var/shiparocks
Just one more way that Shipa abstracts away infrastructure complexity that can be a burden for developers. For myself, before Shipa I would have had trouble creating and binding a PVC.
Cheers,
-Ravi
