php-apache/helm/php-homepage/README.md

# PHP homepage chart

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:

```sh
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:

```yaml
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`:

```sh
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.