fix(chart): remove unused volume mounts and DB secret from nginx container

[danielqb]

Problem

The nginx container in glpi-deployment.yaml mounted the files, marketplace,
and etc PersistentVolumeClaims (ReadWriteOnce) even though nginx's actual
config (default.conf) never reads from those paths - it only serves static
assets from /var/www/html/public (baked into the image) and proxies
everything else to php-fpm via fastcgi_pass. It also pulled glpi-secret
(DB credentials) via envFrom despite never connecting to the database.

Since both nginx and php-fpm mounted the same RWO PVCs, a cluster without
explicit pod affinity forcing them onto the same node could schedule them
on different nodes, causing FailedMount/ContainerCreating for whichever
pod lands second.

Fix

Removed the files/marketplace/etc volumeMounts and volumes, and the
glpi-secret envFrom, from the nginx container. Only php-fpm (which is
the only container that actually touches GLPI_VAR_DIR/marketplace/etc
and the database) keeps these. nginx now only mounts nginx-conf.

This also reduces blast radius: nginx no longer has DB credentials in
its environment (least privilege).

Testing

• helm lint: 0 failures
• helm template: nginx Deployment renders with only nginx-conf volume,
  no envFrom block

[eduardofraga]

This project requires RWX persistent volume claim because php-fpm and nginx access same volume.

[danielqb]

Thanks for the pushback - I re-verified this carefully before updating, since I want to make sure I'm not missing something.

Checked the actual shipped nginx config (docker/nginx/conf.d/default.conf, which matches helm/templates/glpi-configmap.yaml's nginx-conf exactly): root /var/www/html/public; is fixed, with only two location blocks - static try_files against that root, and fastcgi_pass to php-fpm for everything else. /var/lib/glpi, /var/www/html/marketplace, and /etc/glpi are never referenced anywhere in nginx's own config - they're separate, non-overlapping paths from root.

The nginx image itself is built with COPY --from=BUILD /var/www/html /var/www/html (docker/nginx/Dockerfile) - GLPI's web root is baked into the nginx image layer at build time, independent of any PVC.

Verified live on a kind cluster with these mounts removed:

• Login page: HTTP 200, real GLPI title
• /css_compiled/css_glpi.min.css (compiled/minified CSS - a good stress test since it could plausibly be runtime-generated): HTTP 200, and response headers (Last-Modified, ETag, Accept-Ranges) confirm nginx serves it as a static file directly from its own image layer, not proxied through PHP - completely unaffected by the removed PVC mounts either way

Happy to do any additional verification you'd like (e.g. testing a specific marketplace plugin scenario) if there's a case I'm not accounting for - genuinely want to get this right rather than just push back. Rebased onto the new helm/ structure and re-tested with helm lint --strict + helm template.

[eduardofraga]

Try replace hardcoded to extraEnv, extraVolumes and extraVolumeMounts in values

[danielqb]

Updated per your suggestion. Kept the original fix (nginx no longer mounts files/marketplace/etc or pulls glpi-secret/glpi-config by default, since its shipped config never uses them), and added the escape hatch you asked for:

• glpi.phpfpm.extraEnv / extraVolumeMounts / extraVolumes
• glpi.nginx.extraEnv / extraVolumeMounts / extraVolumes

Matching the exact naming convention already used by helmforge/mariadb/helmforge/valkey's own extraEnv/extraVolumes/extraVolumeMounts. So by default nginx stays lean (matching what its actual config needs), but anyone with a custom nginx-conf that needs direct filesystem access to one of those paths (e.g. serving marketplace assets directly instead of through PHP) can add it back via values, without a fork.

Rebased onto current main (post #174/#175/#176/#177/#191/#193). Re-tested with helm lint --strict, helm template (default + with all six extra* values populated), and a live kind install (HTTP 200, real login page).