Why does microcks use PersistentVolume?

[Yuutakasan]

I don't want to use an external volume when using k8s etc., can you tell me why PersistentVolume is used?
Currently, it seems like the files are not being output, can you tell me what the impact would be if we did not use PersistentVolume?

[lbroudoux]

Hey! We're using PersistentVolumes attached to the pod running databases. Microcks relies on MongoDB to store mock infos, tests infos and so on. Microcks also relies on Keycloak that uses postgresql persistence for realm definitions, users, groups and so on.

Using these services that come with Microcks is not mandatory. You can reuse existing services or managed ones outside of Kubernetes. See https://microcks.io/documentation/installing/deployment-options/ for details.

If deploying our database services but with ephemeral storage, you'd have no guarantee to find your data back in case of pod restart or rescheduling.

[Yuutakasan]

@lbroudoux
Thanks for the reply.
I understand that mongodb and postgresql can be separated since they are operated in different services. Thank you very much!

[Yuutakasan]

@lbroudoux
Let me ask an additional question.

Comparing the docker-compose and k8s manifest files, I noticed that the configuration is not identical.

Question 1: Can you tell me why the design is different?

I believe k8s deployment allows all pods to share config in volumeMounts, not mongodb or keycloak.

Question 2: Is this understanding correct?

I would like to be able to share the data of a pod with other k8s hosts, so that the data can be lost at any time, but if volumeMounts is used, I think it is necessary to be able to volumeMounts another k8s host when moving to another pod.
https://github.com/microcks/microcks/blob/master/install/kubernetes/microcks/templates/deployment.yaml#L136

Question 3: I'm trying to avoid volumeMounts, so that I don't have to do volumeMounts.

[lbroudoux]

Volumes in Kubernetes should typically use network attached storage volumes so that they're not sticky to a particular host in a cluster. That way it allows your DB pod to be moved from one host to another without loosing data.

At the opposite, docker compose just allow attachment of local host attached path to volumes. This is a very different design.

We provide docker compose for convenience purpose of local evaluation of Microcks but we strongly encourage considering Kube for serious deployment.