bitnami

Bitnami 映像搬家後：漏改 exporter 的坑，以及用原映像加上 pgvector > 一句話結論：映像來源搬家時，先盤點 chart 裡每個容器；後來自己 build，也要分清楚「加了功能」和「有人持續維護底層」是兩件事。 當初怎麼做 用 Helm 裝 PostgreSQL、Redis，最方便的就是沿用 chart 預設映像。資料庫、metrics exporter、必要時調整目錄權限的初始化容器，都幫你接好了。 直到上游調整映像目錄，原本 chart 指向的來源不再適用。當時先把映像 repository 換成 bitnamilegacy，讓既有版本繼續跑。 以為已經改完，後來卻還要補一個修正：PostgreSQL 和 Redis 的 metrics exporter 沒有一起改來源。 為什麼只改主映像不夠 Bitnami 官方公告 說明，歷史映像搬到 docker.io/bitnamilegacy，Legacy 不再獲得更新或支援，只適合作為過渡。這是當時的遷移背景，不代表現在應該把新部署都指向 Legacy。 一個 chart 通常不只一個 image.repository。主容器改完，metrics sidecar 或 init container 仍可能沿用原來的預設值。 翻回 Git，補修的內容其實只有兩個設定： # 各自放在 PostgreSQL 與 Redis chart 的 values 裡 # PostgreSQL metrics: image: repository: bitnamilegacy/postgres-exporter # Redis 請放另一份 values，不能把兩個 metrics 合併貼到同一份 # metrics: # image: # repository: bitnamilegacy/redis-exporter 教訓很直接：values 看起來改了，不代表最後產生的每個容器都改了。 手把手：先看渲染結果 這次用本機保存的 PostgreSQL chart 16.4.1 與 Redis chart 20.6.2 重做檢查。以下版本是歷史案例的重現條件，不是新部署的版本建議。 1. 把用到的 image 分開列出 下面是 PostgreSQL 單獨 chart 的 values 節錄，檔名設為 image-migration.yaml： global: security: allowInsecureImages: true image: repository: bitnamilegacy/postgresql tag: 17.2.0-debian-12-r5 metrics: enabled: true image: repository: bitnamilegacy/postgres-exporter tag: 0.16.0-debian-12-r2 volumePermissions: enabled: true image: repository: bitnamilegacy/os-shell tag: 12-debian-12-r34 這裡特意開啟 volumePermissions，是為了讓初始化容器出現在渲染結果，不表示每個部署都需要開它。 allowInsecureImages 也要講清楚：這版 chart 會拒絕不認得的替代映像，這個設定讓它跳過來源識別檢查；它沒有替映像做安全認證，也不是修復漏洞。官方說明 有這個參數的範圍。 2. 渲染後逐一核對 假設你已經有對應的 chart 壓縮檔，在該檔案所在資料夾執行： helm template demo ./postgresql-16.4.1.tgz \ -f image-migration.yaml > rendered.yaml rg '^ *image:' rendered.yaml 這次對照結果如下。tag 沒變，變的是 repository： | 容器 | 只改主映像 | 補齊設定後 | |---|---|---| | PostgreSQL | bitnamilegacy/postgresql | bitnamilegacy/postgresql | | metrics exporter | bitnami/postgres-exporter | bitnamilegacy/postgres-exporter | | 權限初始化 | bitnami/os-shell | bitnamilegacy/os-shell | Redis 同樣要看主容器、exporter 與初始化容器。這次也用相同方式渲染確認，但沒有啟動 Redis 或 exporter 做執行期測試。 先維持原 chart 與映像 tag，只調整來源，比同時升 chart、換資料庫版本更容易確認問題在哪。至於 tag 在遠端是否還能拉取，要另外驗證；本次使用本機已存在的基底映像，沒有重做從 Docker Hub 冷拉的測試。 後來為什麼又自己 build 之後需要 PostgreSQL 的 pgvector 擴充。這跟映像目錄搬家是兩個不同需求，只是都碰到同一個映像。 直接換另一個 PostgreSQL 發行映像，還要一起確認 entrypoint、環境變數、資料目錄和執行使用者是否符合原 chart 的期待。當時選擇在原本同一個 Bitnami PostgreSQL 基底上加擴充，把變動縮小。 Dockerfile 可以拆成兩個階段：前面編譯，後面從乾淨的同一基底開始，只拿編譯產物。 ARG BASE=docker.io/bitnamilegacy/postgresql:17.2.0-debian-12-r5 FROM ${BASE} AS build ARG PGVECTOR_VERSION=v0.8.6 USER root RUN apt-get update \ && apt-get install -y --no-install-recommends build-essential git ca-certificates \ && git clone --depth 1 --branch "${PGVECTOR_VERSION}" https://github.com/pgvector/pgvector.git /tmp/pgvector \ && cd /tmp/pgvector \ && make PG_CONFIG=/opt/bitnami/postgresql/bin/pg_config OPTFLAGS="" \ && make PG_CONFIG=/opt/bitnami/postgresql/bin/pg_config OPTFLAGS="" install FROM ${BASE} COPY --from=build /opt/bitnami/postgresql/lib/vector.so /opt/bitnami/postgresql/lib/vector.so COPY --from=build /opt/bitnami/postgresql/share/extension/ /opt/bitnami/postgresql/share/extension/ USER 1001 存成 Dockerfile 後，可以在該資料夾建置： docker build -t local-postgresql-vector:17.2.0-0.8.6 . PG_CONFIG 要指向這個 PostgreSQL 安裝，避免編到另一套版本。OPTFLAGS="" 則避免預設的 -march=native 把建置機特有的 CPU 指令帶進擴充；這是 pgvector 官方提供的可攜性做法，不等於可以跨 CPU 架構直接使用。 第二個 FROM 很重要：編譯階段安裝的套件不會自動進入最終映像。Docker multi-stage build 文件 說明了這種選擇性複製的方式。 怎麼確認相容 這次重新 build 後，以斷開外部網路的隔離容器和全新的測試 volume 驗證： 1. 用原始 PostgreSQL 映像啟動，建立一筆純測試資料。 2. 停止並移除舊容器，讓自建映像掛上同一個測試 volume。 3. 讀回資料，確認 SHOW data_directory 的結果沒變。 4. 建立擴充並執行向量運算。 SQL 驗證的核心是： CREATE EXTENSION vector; SELECT extversion FROM pg_extension WHERE extname = 'vector'; SELECT round(('[1,0,0]'::vector <=> '[0,1,0]'::vector)::numeric, 3); 原始映像沒有可用的 vector 擴充；自建映像回報版本 0.8.6，兩個正交向量的 cosine distance 是 1.000。原先的測試資料仍讀得到，映像的 entrypoint、啟動命令與使用者也維持一致，最終映像內沒有額外留下 gcc。 這驗證的是同一個 PostgreSQL 基底加上擴充，沒有測跨大版本資料格式遷移，也沒有碰正式資料。不能把這個結果延伸成「任意 PostgreSQL 映像都能直接互換」。 換了之後的代價 自建映像沒有讓舊基底恢復更新。編譯階段即使跑了 apt-get update，最終階段仍從原本的 Legacy 基底開始；它增加的是擴充功能，不是替整個執行環境補齊安全更新。 後續仍要維護基底與擴充版本、確認新映像符合 chart 的啟動慣例，並處理映像保存與版本固定。若要更嚴格重現建置，還要進一步固定基底 digest、原始碼 commit 與建置依賴；只固定 tag 不代表完全可重現。 當時先換來源，再沿用原基底加功能，是為了減少同時變動的地方。長期要換到持續維護的映像，仍然是一項獨立工作，不能因為現在能成功啟動就當作已經完成。 延伸閱讀 - Bitnami 映像目錄調整公告 - Bitnami chart 的替代映像檢查 - pgvector 編譯與可攜性 - Docker multi-stage builds

Bitnami PostgreSQL chart alternatives: CloudNativePG and Kapitan If you installed PostgreSQL, Redis or nginx from a Bitnami chart, the packaged chart you pinned and the images it pulls no longer receive updates, and the legacy images are meant only to buy time for a migration. For PostgreSQL the move with the least friction is an operator its own project maintains, CloudNativePG, together with images from that project. Its custom resources can come from the upstream cluster chart or be rendered in your own repository, for example with the cloudnative-pg generator. Both work. Neither replaces Bitnami one to one, because a chart or a generator only produces manifests; the images still need a source you trust. For the other Bitnami charts, Bitnami chart alternatives lists the replacement chart by chart. What Broadcom changed, and when Bitnami announced the change in bitnami/containers#83267, opened on 16 July 2025 under the title "Upcoming changes to the Bitnami catalog (effective August 28th, 2025)". The issue states that "since August 28th, we have not published new Bitnami container images or Helm charts to Docker Hub in OCI format". The deletion of the public catalog docker.io/bitnami was postponed to 29 September 2025, with three 24-hour brownouts on 28 August, 2 September and 17 September. Images and charts are affected differently: - Versioned image tags moved to docker.io/bitnamilegacy. That catalog "will receive no further updates or support and should only be used for temporary migration purposes". Tags based on debian-8, debian-9, debian-10, centos-7 and ol-7 were not copied. - docker.io/bitnami keeps a limited set of hardened images that "are intended for development and are only available on the 'latest' tag". Versioned, supported images are part of the paid Bitnami Secure Images offering. - Packaged charts "will remain available at docker.io/bitnamicharts as OCI artifacts, but they will no longer receive updates". The FAQ adds that deploying them "will not work out-of-the-box unless you override the bundled images with valid ones". - The chart source at bitnami/charts stays available under Apache 2.0. The documented stopgap is to keep the chart version and point every image repository at bitnamilegacy, for PostgreSQL with --set image.repository=bitnamilegacy/postgresql and the same for os-shell and postgres-exporter, plus global.security.allowInsecureImages=true. That keeps a release running. It does not get you a patched PostgreSQL. On 24 September 2025 the CNCF stated that "these changes do not impact the Helm project itself" and that "Bitnami Helm Charts are a specific vendor-maintained implementation". It advised users to "begin exploring migration or mirroring strategies". Helm itself stays a CNCF graduated project under Apache 2.0. What the PostgreSQL chart looks like today On 17 October 2026, the source of bitnami/postgresql in bitnami/charts is at chart version 17.1.2, last changed on 8 September 2026. Its default image is docker.io/bitnami/postgresql:17.6.0-debian-12-r4, and that tag does not resolve. The same tag does resolve in docker.io/bitnamilegacy. The OCI chart docker.io/bitnamicharts/postgresql:17.1.2 does not exist, while 16.7.0, the version from the announcement's example, still does. The source keeps moving, but nothing published matches it, so consuming it means packaging the chart and choosing images yourself. The options | Option | Who maintains the manifests | Images | Cost of staying | |---|---|---|---| | Bitnami chart with bitnamilegacy | nobody, frozen | frozen, no fixes | grows with every CVE | | Bitnami Secure Images | Broadcom | Broadcom | subscription | | Upstream CloudNativePG charts | CloudNativePG project | ghcr.io/cloudnative-pg/postgresql | chart values to track | | Operator plus rendered manifests | you, from a generator | ghcr.io/cloudnative-pg/postgresql | an inventory and a compile step | The last two share the operator. CloudNativePG 1.30.1 was released on 23 September 2026 as cnpg-1.30.1.yaml and as the chart cloudnative-pg 0.29.1. Moving to it is a platform change, not a chart swap. The Bitnami chart renders StatefulSets and Services directly; a CloudNativePG Cluster is a resource the operator reconciles into instances, services and failover. Existing data moves with a logical import; the operator's import documentation describes it as pg_dump over the network followed by pg_restore. For the Cluster itself the upstream project ships a cluster chart. helm template of cluster 0.9.0 with instances=3 and storage.size=10Gi produced the Cluster, a ConfigMap of monitoring queries and a helm test Job. The image came out as ghcr.io/cloudnative-pg/postgresql:16, because the chart's version.postgresql defaults to "16". If you go this way, pin cluster.imageName. Rendering the Cluster with a generator The other way is to keep the manifests in your repository and render them from an inventory. The example does this with the cloudnative-pg generator 1.0.1, which is built for CloudNativePG 1.30.1 and the Barman Cloud Plugin 0.15.1 (see compatibility). The target maps the Bitnami defaults of one database and one owner onto a three-instance cluster: parameters: kapitan: dependencies: - type: oci source: ghcr.io/kadet-hub/cloudnative-pg:1.0.1@sha256:281417a421b0053070fbdc552f9032a3f8d564c0ca2047ec500842a0d060a8f7 output_path: lib/cloudnative-pg compile: - output_path: manifests/ input_type: kadet output_type: yml input_paths: [lib/cloudnative-pg] namespace: databases generators: cloudnative-pg: clusters: app-db: image_name: ghcr.io/cloudnative-pg/postgresql:18.6-system-trixie@sha256:5efb66993894055f0aa50bd94337c6c4ff2e2129f4d433c527151aebbf283fb0 storage: 10Gi bootstrap: initdb: {database: app, owner: app} The generator fills instances: 3 and turns storage: 10Gi into storage.size. The operator creates the app database, the app role and a Secret app-db-app with the credentials and a connection URI, which replaces the password Secret the Bitnami chart rendered. Kapitan 0.36.3 checks neither digests nor attestations when it fetches, so kapitan compile --fetch gives you no integrity check. It also needs the kapitan[oci] extra for OCI sources; without it the compile stops with "The 'oras' package is required for OCI dependencies". The example therefore verifies first and fetches itself: id=https://github.com/kadet-hub/registry/.github/workflows/release.yml@refs/heads/main gh attestation verify "oci://ghcr.io/kadet-hub/index@$(oras resolve ghcr.io/kadet-hub/index:latest)" \ --owner kadet-hub --cert-identity "$id" gh attestation verify oci://ghcr.io/kadet-hub/cloudnative-pg@sha256:281417a4... \ --owner kadet-hub --cert-identity "$id" oras pull -o .oci ghcr.io/kadet-hub/cloudnative-pg@sha256:281417a4... tar -xf .oci/cloudnative-pg.tar -C lib/cloudnative-pg uvx --python 3.13 --from 'kapitan[omegaconf,reclass-rs]==0.36.3' \ --with omegaconf==2.4.0.dev4 kapitan compile --inventory-backend omegaconf Between the two verify calls, run.sh checks that the attested index lists that digest as version 1.0.1 and not yanked. The omegaconf pin is not optional: without it the resolver installed a newer omegaconf and the compile failed with cannot import name 'ListMergeMode'. The compile produced one file, compiled/app-db/manifests/databases/app-db-cluster.yml. Plain kubeconform -strict reports "could not find schema for Cluster", so the generator's shipped CRD schemas go in as the schema location: kubeconform -strict -summary \ -schema-location 'lib/cloudnative-pg/schemas/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json' \ compiled/ # Summary: 1 resource found in 1 file - Valid: 1, Invalid: 0, Errors: 0, Skipped: 0 The schemas are closed, so a value carried over from Bitnami habits fails. Adding replicaCount: 2 under spec gives "additional properties 'replicaCount' not allowed". A schema check is not the operator's admission webhook; [Validate Kubernetes custom resources against their CRDs](kadet-hub.org) covers what it misses. Trade-offs A generator renders manifests, not images. In this example the images come from the CloudNativePG project, pinned by digest, and patching them is now your job: bump the digest, recompile, review the diff. Renovate can propose the generator updates with the kadet-hub preset, but not the PostgreSQL image inside your inventory. The generator does not install the operator or the Barman Cloud Plugin, and it is built for one CloudNativePG line. When you upgrade the operator, pick a generator version built for it. Kapitan is one more tool to learn. For a single database the upstream cluster chart with a pinned image is less to set up. Rendering pays off when the same pattern repeats across clusters and environments, and when you want the rendered YAML in review instead of in a release. The generator, Helm chart or jinja2 guide compares the inputs. A local compile runs the generator's Python with your environment and credentials. The consumer workflow described in Kapitan generators as supply-chain artifacts runs the same compile in a sandbox without network. Originally published at kadet-hub.org.