This chart runs the unified php-apache image with a web root mounted at /srv/http. It is intended for sites whose source and mutable application data live on CephFS so the same files are available to the runtime pod and the browser-based development container.

Published chart packages set appVersion to the unique php-apache image tag created in the same CI run. image.tag is empty by default and therefore uses that appVersion. Keep site-specific values free of image overrides so a chart upgrade also upgrades the runtime image.

Add and refresh the Gitea chart repository with:

helm repo add brunner https://brunner.ninja/charts
helm repo update brunner

Existing sites

Set the existing RWX claim in the site's values file:

fullnameOverride: example-site

persistence:
  existingClaim: example-site

When existingClaim is set, the chart emits no PersistentVolumeClaim. Helm therefore neither owns nor deletes the claim. Deleting the release removes the workload but leaves all website files intact.

The first installation can adopt a Deployment, Service, and Ingress previously created by kubectl apply:

helm upgrade --install example-site brunner/php-homepage \
  --namespace default \
  --values /path/to/example-site/values.yaml \
  --take-ownership \
  --force-conflicts \
  --wait

Review helm template or a server-side dry-run before adoption. The release name and fullnameOverride must match the existing resource names. The chart's selector remains the legacy app: <resource-name> selector so Kubernetes does not reject the Deployment because its selector is immutable.

New sites

With persistence.existingClaim empty, the chart creates an RWX PVC using rook-cephfs. The PVC has helm.sh/resource-policy: keep by default, so an uninstall does not discard site content. Set persistence.retain: false only when deleting the release should also delete its dynamically created claim.

Ingress, TLS, probes, scheduling, storage size, Apache's ServerAdmin, and the image tag are all configurable through values.yaml. TCP startup, readiness, and liveness probes are enabled by default because individual websites may redirect /, require authentication, or select their own HTTP status behavior.

Apache metrics

The image provides an extended mod_status endpoint on pod-local loopback port 8080. It is deliberately not exposed directly by the Service because extended status can contain current client and request details.

Set metrics.enabled to add an Apache exporter sidecar and expose its sanitized Prometheus metrics on the Service. metrics.serviceMonitor.enabled and metrics.prometheusRule.enabled render the corresponding Prometheus Operator resources when their CRDs exist. The rules cover exporter scrape failures, Apache status failures, and worker saturation. No Prometheus namespace, release label, or Alertmanager is hard-coded; selection and alert routing remain the responsibility of the cluster's Prometheus installation.