I am using kubernetes to deploy a postgresql pod.
My k8s manifest for that works nicely. I only paste the relevant code below:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgresql
spec:
...
template:
...
spec:
containers:
- name: postgresql
image: postgres:14
...
volumeMounts:
- name: my-postgres
mountPath: /var/lib/postgresql/data
...
volumeClaimTemplates:
- metadata:
name: my-postgres
spec:
As you can see above, under container spec, I declared the volumeMounts
with a mount path. And a volumeClaimTemplates
to provision the persistent in cloud.
Like said, it works fine.
when I open the Dockerfile of official postgresql here. On line 186, there is VOLUME /var/lib/postgresql/data
.
I would like to verify if I understand the whole thing correctly:
Is it so that the line 186
VOLUME ...
in postgres Dockerfile is only meant to tell its official mount point? I mean if I use the Dockerfile to run a container, it DOESN'T create a volume but I need to specific a volume & mount to that mount point. Am I right here?In my k8s manifest above, under
volumeMounts:
themountPath:
value has to be exactly the same as the line 186VOLUME ...
in postgres Dockerfile, because that is the mount point they told. Am I right here?
CodePudding user response:
Is it so that the line 186 VOLUME ... in postgres Dockerfile is only meant to tell its official mount point? I mean if I use the Dockerfile to run a container, it DOESN'T create a volume but I need to specific a volume & mount to that mount point. Am I right here?
Yes and no. You need to specify a volume and mount it to achieve persistence, that much is correct. What you do NOT need to do is to mount it to that specific directory (though I would advice to do so).
In my k8s manifest above, under volumeMounts: the mountPath: value has to be exactly the same as the line 186 VOLUME ... in postgres Dockerfile, because that is the mount point they told. Am I right here?
No. You could well mount your volume anywhere into the path of /var/lib/postgresql/data
, say /var/lib/postgresql/
. Technically. However, that comes with its own caveats.
However, all in all, you are really reinventing the wheel. You might want to look into helm charts, specifically bitnami's PostgreSQL helm chart.
CodePudding user response:
if I understood you correctly, your question is "why is a volume specified in the dockerfile, if there is no volume created during the deployment of the container?"
postgresql needs a directory to write its data to. if the default configuration for postgresql is set to /var/lib/postgresql/data, the application expects that it can write its data into that directory.
when deploying postgresql in a classic, non containerized manner, it would start to write the data into this directory path which would be available on the operating system of the host it was installed on.
when deploying postgresql as a container, the operating system is virtualized by your container engine and therefore the directory "/var/lib/postgresql/data" is the directory inside of the container. that means if you restart it, all data would be lost, because it is not persisted on the host it was deployed to.
if you want to keep your data, even if the container restarts, you have to mount a volume inside the container during runtime which keeps on living after the container is stopped.
TL;DR:
yes, you are correct. a volume to persist the data has to be created outside of the container and has to be mounted during the deployment onto "/var/lib/postgresql/data" if you don't alter the default configuration.
yes, you are correct here as well, because it is basically the same mechanism. for the container, it doesn't matter how you provide the volume and the mechanism differ in kubernetes, docker and the other container engines. when deploying on kubernetes, volumes and volumeMounts are the correct way of configuring this behaviour.