Gitlab CI/CD with CSI PowerMax

The premise

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 application itself is a fork of the VueJS example app TODO, which we modified to use Sinatra as an API provider and SQLite to store the TODOs.

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

Most of the magic on the storage layer happens in the PVC , Snap definitions, and with the Helm variables.

Under the scene, we will have two independent volumes in PowerMax. For more deep-dive on PowerMax SnapVX 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.

Limitations

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.

For a live demo, check the videos here: