Files
helm-charts/rss-bridge/templates/NOTES.txt
T
jklein 3fa67d55ef rss-bridge: new chart
Takes over the four loose manifests in cluster-config/rss-bridge/ as a
proper chart, on the current template-chart standard: strict values
schema, null-safe helpers, computed limits, replicas/scaleDown,
checksum/config, NOTES.txt.

Two things deviate from the repo standard on purpose:

- The Ingress models host AND TLS secret name per entry instead of the
  single conventional tls-<release>-<chart>-ingress. The installation
  this replaces has grown three separate certificates, one per host.
  Renaming them would make cert-manager issue three new ones and leave
  each host unreachable until it did - a self-inflicted outage on a
  deployment that has been up for over a year. Entries sharing a secret
  name are grouped into one tls entry, and omitting the name falls back
  to the convention, so consolidating later is a values change.

- Requests and limits are decoupled. The old manifest requested 2Gi of
  ephemeral storage, identical to its limit, reserving two gigabytes for
  a workload measured at 2.2 MB after fetching all five whitelisted
  bridges. The request drops to 64Mi; the limit stays at 2Gi.

Hardening was verified rather than assumed. The image ships no USER and
runs as root by default, but runs fully hardened once its writable paths
are provided: uid/gid 33, readOnlyRootFilesystem, all capabilities
dropped, seccompProfile RuntimeDefault. The writable paths were found by
running the image with a writable rootfs, exercising every bridge and
reading its diff layer - /app/cache, /run, /run/php, /var/lib/nginx.
/tmp did not show up that way, because PHP's opcache creates its lock
file there and unlinks it immediately; it only surfaced when the
hardened container died at startup. Stopping at the first writable path
would have shipped a chart that cannot start.

Probes use the app's own /?action=health, which renders fixed JSON
without touching the cache or any remote site, so neither a scraped site
going down nor an unwritable cache can restart the pod.

Fixes #128
2026-08-23 23:33:23 +02:00

43 lines
1.8 KiB
Plaintext

RSS-Bridge {{ .Chart.AppVersion }} was installed as release "{{ .Release.Name }}".
{{ if .Values.ingress.enabled -}}
Reachable at:
{{ range $entry := .Values.ingress.hosts }} https://{{ $entry.host }}
{{ end }}
Each host serves the same instance. Certificates are issued by the
cert-manager cluster issuer "{{ .Values.ingress.clusterIssuer }}" into these secrets:
{{ range $secret := (fromYaml (include "rss-bridge.tlsGroups" (dict "hosts" .Values.ingress.hosts "root" $))).order }} {{ $secret }}
{{ end }}
{{- else -}}
The Ingress is disabled (ingress.enabled=false). Reach the instance with:
kubectl --namespace {{ .Release.Namespace }} port-forward svc/{{ .Release.Name }}-{{ .Chart.Name }}-service 8080:80
and open http://localhost:8080
{{- end }}
Enabled bridges ({{ len .Values.whitelist }} entr{{ if eq (len .Values.whitelist) 1 }}y{{ else }}ies{{ end }} in whitelist.txt):
{{ range $entry := .Values.whitelist }} {{ $entry }}
{{ end }}
{{- if has "*" .Values.whitelist }}
"*" enables every bridge the image ships. Narrow it down by listing bridge
names in the "whitelist" value.
{{- end }}
Useful to know:
* Health endpoint: /?action=health - a fixed JSON document that touches
neither the cache nor any remote site. All three probes use it.
* Changing the "whitelist" value rolls the pod: the deployment carries a
checksum over the ConfigMap, because a subPath mount would otherwise never
reach the running container.
* The feed cache lives in an emptyDir at /app/cache and is therefore
deliberately lost on every restart. RSS-Bridge refills it on demand; it
holds only fetched feeds, no configuration and no user data.
* The container runs read-only and non-root as uid 33 (www-data).
{{- if .Values.scaleDown }}
WARNING: scaleDown is true, so this release is running with 0 replicas.
Set scaleDown=false to bring it back up.
{{- end }}