For the first release of the CSI Driver for PowerMax we wanted to show how the PV dynamic provisioning and snapshot capabilities.
To present a realistic scenario, we used Gitlab CI/CD, its Kubernetes runner, and the CSI Driver off course.
The concept is:
- the master branch corresponds to the latest image and is the production environment
- anytime we push a new branch to GitLab we:
- build the image
- take a snapshot of PV from production
- create an environment to access the new app
- new commits on the branch will keep using their own environment with an independent PV
- on branch merge:
- the dedicated environment and related PV are deleted
- the production is redeployed with the latest image
we can see that, if the branch is the latest, we deploy a dedicated volume (i.e. only the first time). For every other branches we start from a snapshot taken at the time of the first branch creation.
Under the scene, we will have two independent volumes in PowerMax. For more deep-dive on PowerMax SnapVX (i.e. PowerMax local replicas) you can check that white paper.
To avoid, the storage box to be bloated by the project, we also defined a resource Quota on the namespace.
The current version of the CSI driver (v1.2) the snapshot API is v1alpha1 and not compatible with Kubernetes v1.17 and beyond.
A snapshot is only accessible from the same namespace and cannot restore a volume on a different namespace.
One of the tricks is is to put the Gitlab variable
CI_COMMIT_SHORT_SHA in the helm template ; that way, we make sure it is re-proceed and therefore redeployed with the latest build by Helm.
Finally, to save some time in building the images, I used local gems.
For a live demo, check the videos here: