ARTIFACTORY: How to apply your pre-made PVC's for each Artifactory pod in a Helm deployment

If you would like to manage and provision your own PVCs for your Artifactory pods, rather than letting the chart create it with its default configuration, then we will need to create them, with some pre-configured settings, prior to deploying the chart.

When can this be useful?

• If your PVC or PV or both got deleted accidentally, this can be a great way to restore the Artifactory’s Pod’s access to the external storage. By creating a new PV pointing to an external storage (EBS in AWS for an example), and then creating the PVC with the naming convention, upon the Pod’s deletion, it will pick up the new PVC connected to the PV, which is connected to the volume, like nothing ever happened.
• If you want to migrate Helm Charts, from artifactory-ha to artifactory, or artifactory to jfrog-platform charts, but keep the same data, this is the only method that wouldn’t require you to migrate the actual external volume, as you can do like the above, and create a new PV connected to the same external volume, you had in the previous Chart installation

PVC naming convention:

It’s important to understand how Artifactory’s chart behaves when creating your own PVC’s for your Artifactory pod. If you deploy the chart with the release name “artifactory”, it will deploy your PVC’s with the following names (The number at the end corresponds with the replica count of your pods):

artifactory-volume-artifactory-0 
artifactory-volume-artifactory-1 

If you deploy the chart with any other release name that isn’t “artifactory”, let’s say “mustard”, then it will deploy your PVC’s with the following names:

artifactory-volume-mustard-artifactory-0
artifactory-volume-mustard-artifactory-1

If you deploy artifactory-ha chart, the release name won’t matter, and it will always deploy with the same naming convention:

volume-mustard-artifactory-ha-primary-0

Step by step implementation:

Now that we know how the naming convention works, we will start by creating our own custom PVC. For the sake of simplicity, I will be using the regular Artifactory chart with 2 replicas and will be using a standard GCE Persistent Disk Storage class, for my PV provisioning. It’s up to you to decide how to create your own PV’s.

Create the PVC’s:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 annotations:
   volume.beta.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
   volume.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
 finalizers:
 - kubernetes.io/pvc-protection
 name: artifactory-volume-artifactory-0
spec:
 accessModes:
 - ReadWriteOnce
 resources:
   requests:
     storage: 50Gi
 storageClassName: standard
 volumeMode: Filesystem
- - -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 annotations:
   volume.beta.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
   volume.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
 finalizers:
 - kubernetes.io/pvc-protection
 name: artifactory-volume-artifactory-1
spec:
 accessModes:
 - ReadWriteOnce
 resources:
   requests:
     storage: 50Gi
 storageClassName: standard
 volumeMode: Filesystem

Apply the PVC’s to your cluster:

kubectl apply -f art0-pvc.yaml -n your-namespace
kubectl apply -f art1-pvc.yaml -n your-namespace

Deploy the chart:

helm upgrade --install artifactory jfrog/artifactory -n your-namespace 

After this, you should have Artifactory deployed with the PVC’s you configured.