Um innerhalb eines Docker Setups, bzw. in diesem Fall eines Kubernetes Setup, bestimmte Ordner zu persistieren, müssen diese im host System gemountet werden. Für pgadmin wollen wir gerne die Datenbank persistieren, welche sich standardmäßig unter /var/lib/pgadmin befindet und Metadaten beinhaltet.
Angenommen wir haben bereits ein PVC mit dem Namen pgadmin-data, würde die Kubernetes yaml Konfiguration wie folgt aussehen:
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: pgadmin-deploy
spec:
replicas: 1
template:
metadata:
labels:
app: pgadmin
spec:
containers:
- image: dpage/pgadmin4:5.3
name: pgadmin
ports:
- containerPort: 80
name: http
protocol: TCP
volumeMounts:
- name: pgadmin-data
mountPath: /var/lib/pgadmin
volumes:
- name: pgadmin-data
persistentVolumeClaim:
claimName: pgadmin-data
Allerdings werden wir beim Einbinden des PVCs höchstwahrscheinlich diesem Fehler begegnen: Permission denied: ‘/var/lib/pgadmin/sessions’
Wenn ein PVC in Kubernetes gemountet wird, ist er standardmäßig dem Nutzer root zugeordnet. Das image, was genutzt wurde (pgadmin/dpage) läuft aber unter dem pgadmin Nutzer mit der UID:GID von 5050:5050. Dieser hat somit keinen Zugriff auf den entsprechenden PVC Ordner, der nur root Nutzern vorenthalten ist. Eine mögliche Lösung, um dieses Problem zu umgehen, einen initContainer zu initialisieren, welcher den PVC als root Nutzer mountet und die Berechtigungen anpasst.
initContainers:
- name: pgadmin-init
image: alpine
args: [ "sh", "-c", "chown 5050:5050 /var/lib/pgadmin " ]
volumeMounts:
- name: pgadmin-data
mountPath: /var/lib/pgadmin
Im Folgendem github issue wird auch vorgeschlagen, eine custom storageclass für das PVC zu erstellen, welche dann spezifische mounoptions besitzt. Allerdings besitzt die oracle cloud in diesem Fall dieses feature nicht.
Es scheint weiterhin auch einen Lösungsansatz zu geben, welcher die fsgroup im SecurityContext anpasst. (siehe stackoverflow)
