fix(hosting): deploy ClickHouse from the official image instead of Bitnami#4249
fix(hosting): deploy ClickHouse from the official image instead of Bitnami#4249matt-aitken wants to merge 2 commits into
Conversation
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📜 Recent review details⏰ Context from checks skipped due to timeout. (3)
WalkthroughClickHouse configuration is updated across self-hosting documentation, Docker Compose, and Helm. Docker now uses the official image, updated credentials and paths, file limits, and a compatible data-path configuration. Helm replaces the Bitnami dependency with custom ClickHouse resources, pinned image settings, explicit ports, probes, persistence, security settings, generated URLs, and updated tests. Documentation records the ClickHouse 25.8+ requirement and external service port key. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🧭 Helm Chart Prerelease PublishedVersion: Install: helm upgrade --install trigger \
oci://ghcr.io/triggerdotdev/charts/trigger \
--version "4.5.4-pr4249.7302aa9"
|
…tnami The Bitnami free image catalog is EOL and its frozen bitnamilegacy archive tops out at ClickHouse 25.7.5, below the 25.8 floor the platform requires since v4.5.0. The Docker Compose stack and the Helm chart now run the official clickhouse/clickhouse-server image at 26.2, the same version the platform is developed and tested against. The Helm chart deploys ClickHouse with a chart-owned StatefulSet instead of the Bitnami subchart. Existing deployments keep their data with no manual steps: a config override keeps the on-disk layout compatible with volumes created by the Bitnami-based setup, Compose reuses the same named volume, and the Helm chart automatically adopts the data PVC left behind by the old subchart.
e2e7e33 to
4608012
Compare
…e inline credentials The chart-deployed ClickHouse now reads CLICKHOUSE_PASSWORD from a chart-owned Secret instead of a plaintext env value in the pod spec, and the CLICKHOUSE_URL helpers percent-encode inline usernames and passwords so special characters no longer produce an unparseable URL.
| Inline credentials (auth.* and external.* values) are percent-encoded via | ||
| urlquery, so special characters are safe there — except spaces, which | ||
| urlquery encodes as `+` and userinfo decoding keeps literal. |
There was a problem hiding this comment.
🔍 urlquery encodes spaces as + which may not decode correctly in URL userinfo
The comment at hosting/k8s/helm/templates/_helpers.tpl:438-440 correctly notes that Go's urlquery template function encodes spaces as + rather than %20. In the userinfo component of a URL, + is a literal character (not a space), so passwords containing spaces would be mangled. The default password (password) doesn't contain spaces, but users with space-containing passwords would hit this edge case. The comment documents it but there's no runtime guard. Worth considering a validation or a note in the values.yaml comments near auth.password.
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
Self-hosted deployments now run ClickHouse from the official
clickhouse/clickhouse-serverimage instead ofbitnamilegacy/clickhouse. Bitnami's free image catalog is EOL and the frozen legacy archive tops out at ClickHouse 25.7.5, below the 25.8 minimum the platform requires since v4.5.0, which broke every ClickHouse insert on chart-bundled deployments. Both stacks now default to 26.2, the same version the platform is developed and tested against.Existing deployments keep their ClickHouse data with no manual migration.
Fixes #4197.
Details
Docker Compose: the
clickhouseservice uses the official image with its native env vars, plus the recommendednofileulimits. It reuses the same named volume as before: adata-paths.xmlconfig override points ClickHouse at thedata/subdirectory of the volume, which is exactly the layout the Bitnami image used, so old volumes work in place (including SQL-created users) and fresh installs get the identical layout.Helm chart: the Bitnami ClickHouse subchart is replaced by a chart-owned single-node StatefulSet and Service running the official image (non-root, HTTP
/pingprobes, config overrides mounted intoconfig.d, and the samedata-paths.xmllayout compatibility). On upgrade, the chart automatically adopts the data PVC left behind by the old subchart (data-<release>-clickhouse-shard0-0) vialookup, andfsGrouprelabeling handles the uid change on first mount. Existingclickhouse.*values keep working:auth,persistence(includingglobal.storageClass),resources,secure,external.*, andconfigdFiles. Bitnami-only keys (shards,replicaCount,keeper,resourcesPreset) are gone. The docs now state the 25.8 minimum for bring-your-own ClickHouse.One caveat:
lookupreturns nothing when manifests are rendered without cluster access (GitOps tools that usehelm template). For that case there's a newclickhouse.persistence.existingClaimvalue, documented in the values file and the Kubernetes self-hosting docs.Verification
main(Bitnami 25.5), wrote 5,000 rows, then brought the same project up with this branch's compose file. The official 26.2 server came up healthy on the same volume with all rows intact, SQL-created users working, and writes succeeding.helm lint,helm template(default values,existingClaimset, external ClickHouse, and the production example) and kubeconform all pass, mirroring the release CI steps.input_format_json_infer_array_of_dynamic_from_array_of_different_types(the setting that fails on 25.7.5) succeed on the upgraded volume.