Postgres Flexibility

[varet80]

no worries I am in no rush :) - I too didnt test the PR i sent over yesterday either

bumping version to .1 seems to solve the issue, i can report nginx ingress/cert-manager issues me a cert successfully.

there seem to be some issue with default postgresql credentials as my backend container does not seem to be able to connect to the pg database. could it be that you mixed up username/passwords/database names along the way? i am a bit confused as to how you feed the db credentials - ideally i d like to feed them from secrets (sealed secrets)

    # -- Postgresql DB password
    dbUser: "{{ .Values.postgresql.auth.database }}"

feel free to respond when you're done with your work - dont let me distract you from work ;)

Originally posted by @loeken in https://github.com/varet80/publiccharts/issues/4#issuecomment-1136964742

[varet80]

@loeken I split the issue here

I made my module too specific to use the integrated postgresql.

I am suggesting to:

1. Disable these env variables when integrated postgres is not installed
2. Add support for external Secrets (you can give me some example how you use them
3. Add support (if missing) for extra Env Variables Does it soudng good? if so I can submit a branch with these changes

[loeken]

1.) i removed them and i now i am able to spin it up. i used argocd to deploy this helm chart https://github.com/loeken/homelab/blob/30eb1563507f85370123f80414685240730c7369/deploy/argocd/bootstrap-optional-apps/templates/librephotos.yaml this works and i can login pg errors disappeared

2.) https://github.com/bitnami-labs/sealed-secrets you install this controller and the kubeseal binary on your laptop. lets say you have mysecret.yaml

---
apiVersion: v1
kind: Secret
metadata:
  name: librephoto-secrets
  namespace: librephoto
type: Opaque
stringData:
  PG_PASSWORD: "topsecret"
  REDIS_PASSWORD: "evenmoresecure"

you can

cat mysecret.yaml | kubeseal

that will basically send the unencrypted version to the cluster via kubeseal, it ll encrypt your local secret and return you a sealed ( encrypted ) version of it

cat mysecret.yaml | kubeseal | kubectl apply -f -

and you can then apply the encrypted version of your secret ( technically a sealedsecret ) and interact with it as if it was a normal secret ( k8s holds the keys so decrypts the sealed secret when needed and provides a secret in readable form to the cluster )

in other helm charts/value files you may have noticed "existingSecrets" which is often used so you can specify the name of the secret ( and encrypt that ) vs providing secrets in value files.

you could see an example of a PR i sent to another repo https://github.com/devopstales/helm-charts/pull/12/files the helm code checks if existingSecret is set and if a name is provided you can tell the helm chart to use the existing secret instead

3.) i dont have strong feelings about this part, if you do provide externalSecrets functionality to provide a secret where we can feed all passwords to the chart i dont think i would need any other extra env vars changed.

[varet80]

@loeken can you test and give some feedback on pr #10 ?

External Secrets are a list (multiple can be declared)