企业官网建设流程全解析

• 云原生
• 容器编排

本篇指南以 bitnami/concourse/CHANGELOG.md 为主线，系统梳理 Bitnami 发布的 Concourse Helm Chart（当前版本 5.1.47，Concourse 7.13.2）从 2021 年 0.1.0 到 2025 年 5.1.47 的完整演进脉络，重点拆解其中的安全默认值提升、网络策略、外部数据库 SSL 连接、镜像验证、PostgreSQL 大版本升级等关键技术变更，并结合本仓库 模板源码 与 values.yaml 给出可落地的配置方法与升级方案。读完本文，你将掌握该 Chart 的架构组成、关键参数含义、版本升级断点以及将外部数据库安全接入 Concourse 的完整实践。

一、Chart 概况与整体架构

Concourse 是一个用 Go 编写的自动化系统，最常用于 CI/CD，其设计目标是扩展到任意复杂度的自动化流水线。本仓库中的 Bitnami Concourse Chart 基于 Chart.yaml 定义：

• Chart 版本：5.1.47
• 应用版本：7.13.2（镜像docker.io/bitnami/concourse:7.13.2-debian-12-r12）
• 依赖：postgresql（条件依赖，postgresql.enabled为 true 时引入，版本 16.X.X，对应 PostgreSQL 17.x）与common（Bitnami 通用模板库，2.x.x）
• 许可证：Apache-2.0

从 templates 目录结构 可以看出该 Chart 由三大部分组成：

Web 与 Worker 的密钥材料（host_key、session_signing_key、worker_key 等）通过 Secret 以defaultMode: 0400只读挂载到/bitnami/concourse/concourse-keys，Worker 通过CONCOURSE_TSA_HOST指向 Web 的 Gateway Service 完成注册与握手，这些细节在 web/deployment.yaml 与 worker/statefulset.yaml 中有完整体现。

二、快速安装与参数化部署

前置条件（来自 README.md）：Kubernetes 1.23+、Helm 3.8.0+、底层基础设施支持 PV provisioner、扩缩容场景需要 ReadWriteMany 卷。

2.1 一键安装

helm install my-release oci://registry-1.docker.io/bitnamicharts/concourse

2.2 通过 --set 指定参数

helm install my-release \ --set secrets.localUsers=admin:password \ oci://registry-1.docker.io/bitnamicharts/concourse

该命令将 Concourse 本地账户用户名与密码设置为admin:password。secrets.localUsers支持username:password或username:bcrypted_password两种格式，未设置时自动生成。启用本地认证（basic auth）由secrets.localAuth.enabled（默认true）控制，对应CONCOURSE_ADD_LOCAL_USER环境变量从 Secret 中读取（见 web/deployment.yaml）。

2.3 使用 YAML 文件覆盖

helm install my-release -f values.yaml oci://registry-1.docker.io/bitnamicharts/concourse

完整参数清单（Global、Common、Web、Worker、流量暴露、Init 容器、数据库、外部数据库等分组，共 200+ 项）可查阅 values.yaml 与 README.md 的参数表。

三、CHANGELOG 核心演进主线（2021–2025）

CHANGELOG 忠实记录了 Chart 从诞生到当前版本的每一次变更。按大版本归纳，演进主线如下：

下面逐主题展开讲解这些变更的实质内容与底层实现。

四、安全加固演进：从 3.x 到 5.x 的纵深防御

安全是 2023–2024 年间该 Chart 最主要的演进方向，几乎每个 minor 版本都在收紧容器与集群层面的安全默认值。

4.1 Pod / 容器安全上下文（3.1.0 → 4.0.0）

• 3.1.0（2024-01）：为containerSecurityContext新增seccompProfile支持（#21907），默认类型为RuntimeDefault。
• 3.2.0（2024-01）：改进podSecurityContext与containerSecurityContext的默认值（#22106）。
• 4.0.0（2024-04）：大幅收紧安全默认值（#24541），具体为：
  • Web 节点runAsGroup从0改为1001；
  • readOnlyRootFilesystem设为true（web 节点，配合/tmp挂载为 emptyDir）；
  • resourcesPreset从none改为测试套件可运行的最小档位；
  • global.compatibility.openshift.adaptSecurityContext从disabled改为auto。

上述默认值在 README.md 的 Web 参数表中可直接核对：web.containerSecurityContext.runAsNonRoot: true、privileged: false、allowPrivilegeEscalation: false、capabilities.drop: ["ALL"]、seccompProfile.type: RuntimeDefault。

在模板实现层面，安全上下文统一通过common.compatibility.renderSecurityContext渲染（见 web/deployment.yaml），该 helper 会根据global.compatibility.openshift.adaptSecurityContext的值决定是否剥离runAsUser、runAsGroup、fsGroup，交由 OpenShift 平台注入默认 ID。

注意：Worker 节点因运行容器运行时（默认containerd）需要特权，其runAsUser/runAsGroup默认为0、privileged: true，与 Web 节点形成鲜明对比，这是由 Concourse Worker 的底层运行机制决定的，请勿照搬 Web 的安全上下文。

4.2 OpenShift 兼容性（3.3.1 / 3.7.0 / 5.0.7）

• 3.3.1（2024-01）：将seLinuxOptions置为 null 以兼容 OpenShift（#22575）。
• 3.7.0（2024-03）：新增对 OpenShift restricted-v2 SCC 的自动适配（#24070）。
• 5.0.7（2024-11）：统一seLinuxOptions的默认值（#30348）。

global.compatibility.openshift.adaptSecurityContext支持三种取值：auto（检测到运行集群为 OpenShift 时自动适配）、force（始终适配）、disabled（不执行适配）。

4.3 ServiceAccount Token 挂载收敛（3.3.0）

3.3.0 将 service-account token 的自动挂载从 ServiceAccount 声明迁移到 Pod 声明（#22391），通过web.automountServiceAccountToken/worker.automountServiceAccountToken控制。该 Chart 默认automountServiceAccountToken: true（Pod 级别），同时serviceAccount.automountServiceAccountToken默认为false，在 web/deployment.yaml 中有明确体现。

4.4 NetworkPolicy（3.4.0）

3.4.0 起默认创建 NetworkPolicy（#23334）。以 web/networkpolicy.yaml 为例，默认策略同时声明Ingress与Egress两类策略：

• Ingress：放行 http（8080）、tsa（2222）、pprof（2221）端口；若web.networkPolicy.allowExternal为 false，则仅允许来自本 Chart Web/Worker Pod、带-client: "true"标签的 Pod 以及ingressNSMatchLabels/ingressNSPodMatchLabels匹配的命名空间访问。
• Egress：默认allowExternalEgress: true时允许全部出站；否则只放行 DNS（53）、Web 与 Worker 之间的互访端口、PostgreSQL 端口（内置数据库时仅限同 Release 的 postgresql Pod）。

Worker 侧对应 worker/networkpolicy.yaml，默认同样开启。

4.5 PDB 与健康探针（4.1.0 → 4.2.4）

• 4.1.0（2024-05）：PDB（PodDisruptionBudget）评审（#25869）。
• 4.2.4（2024-06）：将 PDB 与模板中对齐（#26688）。
• 4.2.1（2024-05）：为 web 与 worker 使用不同的 liveness/readiness 探针（#26340）——Web 的 readiness 通过 HTTP GET{baseUrl}/api/v1/info检查，liveness 使用 TCP 探测 http 端口；Worker 的探针统一指向 health 端口 8888（httpGet: //tcpSocket: healthz）。

当前默认值：Web/Worker 的 liveness、readiness 均启用（initialDelay 10s、period 15s、timeout 3s），startup 探针默认关闭，并支持customLivenessProbe/customReadinessProbe/customStartupProbe完全覆盖默认探针。

4.6 镜像验证与非标准镜像检测（4.2.0 / 5.1.0）

• 4.2.0（2024-05）：当原始镜像被替换时给出警告（#26189）。
• 5.1.0（2024-12）：引入镜像验证能力，同时检测非标准镜像（#30872）。如需关闭验证，可设置global.security.allowInsecureImages: true（默认false，见 values.yaml）。

该机制配合 Bitnami Secure Images（BSI）体系：基于安全加固的 Photon Linux 构建，提供近乎零 CVE 的镜像、VEX 漏洞声明、SBOM 与 in-toto 供应链来源证明。

五、数据库：内置 PostgreSQL 与外部数据库 SSL 模式

5.1 内置 PostgreSQL

默认postgresql.enabled: true，Chart 会附带部署 Bitnami PostgreSQL 子图表，默认创建用户bn_concourse、数据库bitnami_concourse（见 README.md 数据库参数表）。Web 的 db-migrate 与 concourse 容器通过CONCOURSE_POSTGRES_*系列环境变量连接数据库。

5.2 外部数据库

使用托管数据库或共享数据库时，关闭内置 PostgreSQL 并配置externalDatabase.*：

postgresql.enabled=false externalDatabase.host=myexternalhost externalDatabase.user=myuser externalDatabase.password=mypassword externalDatabase.database=mydatabase externalDatabase.port=5432

未指定externalDatabase.existingSecret时，templates/config/secret-external-db.yaml 会自动生成名为<release>-externaldb的 Secret 保存数据库密码。

5.3 SSL Mode：5.1.47 的新能力

5.1.47（2025-09-11，PR #36249）为外部数据库新增了 SSL Mode 支持，新增参数externalDatabase.sslmode，取值与含义如下：

底层实现位于 templates/_helpers.tpl 的concourse.database.sslmode定义：

{{- define "concourse.database.sslmode" -}} {{- ternary "disable" .Values.externalDatabase.sslmode .Values.postgresql.enabled | quote -}} {{- end -}}

即：启用内置 PostgreSQL 时固定为disable（集群内网络）；使用外部数据库时透传用户配置的externalDatabase.sslmode。该值通过CONCOURSE_POSTGRES_SSLMODE环境变量注入 Web 主容器与 db-migrate init 容器（见 web/deployment.yaml），同时concourse.database.host、concourse.database.port两个 helper 也以同样的 ternary 模式解析主机与端口（内置时固定 5432）。

生产实践建议：使用云厂商托管 PostgreSQL（如 RDS、Cloud SQL）时，优先设置externalDatabase.sslmode=verify-full，并配合externalDatabase.existingSecret复用已有的凭据 Secret，避免密码以明文写入 values 文件。

六、功能特性增强：认证、密钥与扩展配置

6.1 Conjur 集成（1.1.0）

1.1.0（2022-05，PR #10167）引入 Conjur 作为凭证管理器。配置项集中在web.conjur.*与secrets.conjur*：

• web.conjur.enabled：启用 Conjur 集成；
• web.conjur.applianceUrl：Conjur 实例地址（必填）；
• web.conjur.pipelineSecretTemplate/teamSecretTemplate/secretTemplate：流水线级、团队级、通用级密钥路径模板，默认分别为concourse/{{.Team}}/{{.Pipeline}}/{{.Secret}}、concourse/{{.Team}}/{{.Secret}}、concourse/{{.Secret}}；
• secrets.conjurAccount/conjurAuthnLogin/conjurAuthnApiKey/conjurAuthnTokenFile/conjurCACert：认证与证书配置。

_helpers.tpl 中的concourse.web.conjur.validateValues会在渲染阶段强制校验：启用 Conjur 时applianceUrl、conjurAccount、conjurAuthnLogin必须设置，且conjurAuthnApiKey与conjurAuthnTokenFile二选一、不可同时设置。

6.2 镜像 digest 支持（1.4.0）

1.4.0（2022-08，PR #11870）允许通过image.digest以sha256:...形式锁定镜像，设置后优先于 tag。这与 Bitnami 建议的不可变 tag（immutable tags）实践相辅相成，可确保生产环境镜像不被同一 tag 的新版本悄悄替换。

6.3 Ingress 与流量暴露

• 1.2.0（2022-05）：新增ingress.extraRules特性（#10253）。
• 1.3.0（2022-05）：补充缺失的 service 参数（#10404）。

当前 Ingress 配置支持ingress.enabled、ingress.hostname（默认concourse.local）、ingress.tls、ingress.selfSigned（Helm 自签证书）、ingress.extraHosts、ingress.extraPaths、ingress.extraTls、ingress.secrets、ingress.extraRules等全套参数。Web 服务默认类型为LoadBalancer（HTTP 80 / HTTPS 443），Worker Gateway 服务默认ClusterIP（TSA 2222）。

6.4 Worker 弹性伸缩（HPA）

Worker 支持基于worker.autoscaling.enabled开启 HPA，可配置maxReplicas、minReplicas、builtInMetrics与customMetrics，对应 templates/worker/horizontalpodautoscaler.yaml。Worker 默认replicaCount: 2、mode: deployment，也可切换为statefulset以使用稳定的 Pod 身份与持久卷。

6.5 资源预设与自定义资源

3.5.1（2024-02，PR #23437）引入resourcesPreset支持，取值none/nano/micro/small/medium/large/xlarge/2xlarge，自动生成resources段。但官方明确建议生产环境直接使用resources手动配置 CPU 与内存请求/限制，因为预设值无法完全适配具体业务负载（该说明也出现在 README.md）。

6.6 认证会话与会话签名

web.auth.duration控制 token 有效期（默认24h），web.auth.cookieSecure控制 cookie 的 Secure 标志（默认false，开启 HTTPS 时应设为true），web.auth.passwordConnector指定fly login -u ... -p ...使用的密码连接器，web.auth.mainTeam.localUser以逗号分隔列表指定 main 团队本地用户（默认user）。

七、升级指南：跨大版本的关键注意点

CHANGELOG 与 README.md 的 Upgrading 章节 共同给出了各 major 版本的升级要点：

7.1 1.0.0：命名标准化

端口参数全面归组：web.containerPort、web.tsa.containerPort、web.tsa.debugContainerPort、web.tls.containerPort并入web.containerPorts；worker.*与service.web.*、service.workerGateway.*同理。升级前需检查自定义 values 是否引用了旧参数名。

7.2 2.0.0 / 3.0.0：PostgreSQL 子图表大版本

2.0.0 升级至 PostgreSQL 12.x，3.0.0 升级至 13.x，均为破坏性变更，需按子图表官方升级说明迁移数据。

7.3 4.0.0：安全默认值变更（易破坏自定义脚本）

• web节点runAsGroup由0变为1001；
• readOnlyRootFilesystem设为true；
• resourcesPreset由none提升至最小可用档；
• OpenShift 适配策略默认改为auto。

若部署中依赖旧的运行用户或可写根文件系统（如自定义 init 脚本），升级后可能异常，需要显式回退这些默认值。

7.4 5.0.0：PostgreSQL 17.x

5.0.0（2024-10-03，PR #29730）将 PostgreSQL 子图表提升至 16.0.0（即 PostgreSQL 17.x），为破坏性大版本变更，需遵循 PostgreSQL 官方升级流程（pg_dump/restore 或 pg_upgrade）后再升级 Chart。

7.5 5.1.0：镜像验证默认开启

升级至 5.1.0 后默认启用镜像验证；如私有环境无法完成验证，可设置global.security.allowInsecureImages: true关闭。

7.6 凭据更新与备份恢复

• 凭据更新：Chart 升级时复用先前渲染的 Secret 或web.existingSecret指定的 Secret。可通过helm upgrade传入新的secrets.localUsers（username:password）或指定新的web.existingSecret完成轮换。注意：部署后无法用 Helm 直接修改应用访问凭据，需要删除 PV 重新部署或借助应用自带管理工具。
• 备份恢复：使用 Velero 备份源部署的持久卷并挂载到新部署，具体流程见 README.md 的 "Backup and restore" 章节。

八、源码级验证：关键环境变量与模板对应关系

为便于读者继续深入，这里列出 CHANGELOG 中主要变更对应的模板实现位置：

结语

Bitnami Concourse Helm Chart 的版本演进（0.1.0 → 5.1.47）清晰展现了两个并行主线：对外部生态的开放（外部数据库、Conjur 凭证管理、Ingress 多域名、镜像 digest）与对内安全基线的持续收紧（非 root 运行、只读根文件系统、seccomp、SELinux、NetworkPolicy、镜像验证）。对于生产部署，建议以 5.1.47 为基线，显式配置resources、externalDatabase.sslmode=verify-full（使用外部数据库时）、web.auth.cookieSecure=true（启用 HTTPS 时），并按 7.3–7.5 节的断点规划升级路径。

• 云原生
• 容器编排