如何部署 buzz-push-gateway 作为 APNs 最后一跳并配置必需环境变量、健康监听器与 PostgreSQL 权限？

如何部署 buzz-push-gateway 作为 APNs 最后一跳并配置必需环境变量、健康监听器与 PostgreSQL 权限【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzzbuzz 项目中的buzz-push-gateway是一个独立的公开 APNs 最后一跳服务为push.buzz.xyz提供基于 capability 的门控投递能力。部署它的核心工作是用 Dockerfile.push-gateway 产出的镜像运行一个 Helm 部署注入必需的环境变量配置 8080/8081 两个监听器与探针并让 PostgreSQL 权限模型满足“迁移 Job 有 DDL、运行副本只有 DML”的分离。完整的部署说明见 docs/push-gateway-deployment.md本文围绕它给出一条可执行路径。适用前提一个 Kubernetes 集群、可用的 Helm、一个专用的 PostgreSQL 数据库不能与 relay 共库以及 Apple 侧的 App Attest 根证书和 APNs 证书身份。这个 MVP 只编译了一个应用 profilebuzz-ios-dogfood不存在 App Store gateway profile。构建与获取镜像镜像由 Dockerfile.push-gateway 构建基于rust:1.95-bookworm用 cargo-chef 编译buzz-push-gateway最终运行阶段是debian:bookworm-slim以 UID/GID 1000 的buzz用户运行EXPOSE 8080 8081入口为/usr/local/bin/buzz-push-gateway。Chart 默认使用main镜像 tag由 push-gateway 发布流水线在每次 main 推送时发布。生产部署时不要直接使用可变 tag而是固定摘要。文档给出的流程打开对应 workflow 运行的Publish public push gateway image任务摘要复制其中的sha256:...摘要。在注入前先校验摘要的 subject 与 provenancegh attestation verify \ oci://ghcr.io/block/buzz-push-gatewaysha256:64-lowercase-hex \ --repo block/buzz \ --signer-workflow block/buzz/.github/workflows/docker.yml \ --source-digest 40-lowercase-hex-source-commit上面两个占位符分别替换为上一步复制的 64 位十六进制摘要以及构建该镜像的 40 位源提交哈希。只有该命令成功后才把同一摘要作为image.digest注入环境的 GitOps valueschart 随后渲染ghcr.io/block/buzz-push-gatewaysha256:...并忽略 tag。准备专用 PostgreSQL 数据库与权限文档明确约束了三层权限模型部署前必须按此准备数据库运行副本的DATABASE_URL只需要对六张push_gateway_*authority 表的DML权限不需要 DDL。迁移使用独立的、具备 DDL 权限的DATABASE_URL且该 URL 必须指向一个专用 gateway 数据库而不是 relay 数据库——因为 SQLx 的_sqlx_migrations历史表落在public共库会与其他应用的迁移历史冲突。迁移 Job 由 chart 以 pre-install/pre-upgrade hook 形式运行见 migration-job.yaml参数固定为--migrate-only从migration.existingSecret默认buzz-push-gateway-migrations取DATABASE_URL。迁移完成后Job 会从运行时角色默认buzz_push_gateway_runtime撤销数据库CREATE并从PUBLIC和该角色撤销 schemaCREATE只授予数据库CONNECT、schemaUSAGE以及六张 gateway 表的SELECT, INSERT, UPDATE, DELETE。迁移角色必须拥有这些库/schema 对象的所有权或具备发放这些 GRANT 的权限并且绝不能提供给运行副本。迁移范围由 crates/buzz-push-gateway/migrations 下的 scoped 迁移文件限定只创建六张push_gateway_*表加 SQLx 迁移历史表从不运行 relay 迁移。所有副本必须共享同一个 PostgreSQL 数据库投递授权、重放准入和端点配额预留都是事务性的副本数不会成倍放大滥用上限。配置必需环境变量Deployment 模板deployment.yaml会渲染下列环境变量。其中DATABASE_URL、BUZZ_PUSH_GRANT_KEYS、BUZZ_PUSH_TOKEN_KEYS三个通过secretKeyRef从existingSecret默认 Secretbuzz-push-gateway注入其余来自 chart values变量用途与约束BUZZ_PUSH_BIND_ADDR公共监听默认0.0.0.0:8080https://push.buzz.xyz应路由到此端口BUZZ_PUSH_HEALTH_ADDR私有健康监听默认0.0.0.0:8081不可公开暴露BUZZ_PUSH_PUBLIC_DELIVERY_URL对外签名的精确 URL常规值为https://push.buzz.xyz/v1/deliveries/apnsBUZZ_PUSH_MAX_GRANT_LIFETIME_SECONDS最大委托能力有效期范围1..31536000BUZZ_PUSH_APP_ATTEST_ROOT_CERT_PATH只读挂载的 Apple App Attest 根证书 PEMBUZZ_PUSH_DOGFOOD_APP_ATTEST_APP_ID服务端持有的精确 App Attest 应用标识TEAMID.bundle-id缺失或为空时网关拒绝启动BUZZ_PUSH_DOGFOOD_APNS_TOPIC服务端持有的 APNs topic客户端请求永远不能提供或覆盖BUZZ_PUSH_DOGFOOD_APNS_ENVIRONMENTproduction或sandbox由部署配置选择BUZZ_PUSH_DOGFOOD_APNS_CERT_PATH只读的 APNs 证书/私钥 PEMBUZZ_PUSH_GRANT_KEYScapability AEAD 密钥环格式id:base64-32-bytes[,predecessor...]当前密钥在前BUZZ_PUSH_TOKEN_KEYS独立的 token 托管 AEAD 密钥环同格式绝不能复用 grant 密钥两者的 key id 和字节必须不同可选的端点配额策略变量BUZZ_PUSH_ENDPOINT_QUOTA_WINDOW_SECONDS默认10最大86400和BUZZ_PUSH_ENDPOINT_QUOTA_MAX_DELIVERIES默认10最大10000。文档注明这些是 Buzz 策略假设而非 Apple 公布的限制应在保留硬上限的前提下压测调优。两个 AEAD 密钥环、APNs 证书身份都来自 secret manager 挂载任何值都不应出现在镜像、manifest、日志或 metrics 标签里。旧密钥保留为 decrypt-only predecessor直到其下所有 capability/token 过期或重加密后再移除。App Attest 根证书要求启动时逐字节校验唯一接受的是 Apple 官方Apple App Attestation Root CA证书 SHA-256 指纹1C:B9:82:3B:A2:8B:A6:AD:2D:33:A0:06:94:1D:E2:AE:4F:51:3E:F1:D4:E8:31:B9:F7:E0:FA:7B:62:42:C9:32PEM 文件 SHA-256c778d09ac341f7fd9f8f3b19e2b815af6aed4ad4490e1e92c05cb355212a5013Apple 根轮换应作为经过评审的代码/配置发布处理而不是直接替换挂载。配置健康监听器与探针公共监听 8080唯一允许 pod ingress 的端口NetworkPolicy 中 ingress 只放行 8080 TCP见 networkpolicy.yaml。私有健康监听 8081探测/_liveness和/_readiness不要把该端口暴露到公网。Kubernetes node/kubelet 来源的探针流量豁免 NetworkPolicy只有目标 CNI 要求 pod-origin 抓取时才添加 narrowly selected 的监控来源。Readiness 在 PostgreSQL authority 不可用时失败优雅关闭会先停止接受新请求再排空 in-flight 的 APNs 调用。Pod 必须先从负载均衡 Service 端点摘除 readiness再终止。Chart 的 Deployment 中固定了三类探针均以/_liveness或/_readiness打到health端口liveness 每 10s、readiness 每 5s、startup 每 2s 最多 60 次失败。Prometheus metrics 同样只在私有健康监听BUZZ_PUSH_HEALTH_ADDR默认 8081的GET /metrics上提供绝不在公共 8080 上。抓取默认关闭opt-inprometheus-operator 需要podMonitor.enabledtrue且networkPolicy.monitoring.enabledtrue并指定 scraper 的 namespace/pod selectorDatadog 则通过podAnnotations注入 OpenMetrics check。两种模式都只添加一条指向配置来源的 8081 ingress 规则不允许 blanket 放行networkPolicy.monitoring开了但 selector 为空时chart 直接渲染失败。注入 Chart 值并渲染部署values-production.yaml 被刻意留成“无法直接部署”的生产输入契约image.tag、image.digest、profiles.dogfood.appAttestAppId、networkPolicy.postgresEgressCidrs都是空值部署 CI 必须注入已校验的镜像摘要、provisioned 的 dogfood Apple 应用标识和真实 PostgreSQL 网络。仓库自带的渲染测试 render.sh 展示了生产注入的完整参数形态其中sha256:aaaa...与REALTEAM...是该测试脚本里的占位值实际部署必须替换为你环境自己的值helm template push deploy/charts/buzz-push-gateway \ -f deploy/charts/buzz-push-gateway/values-production.yaml \ --set image.digestsha256:已校验的64位十六进制摘要 \ --set profiles.dogfood.appAttestAppIdTEAMID.xyz.block.buzz.dogfood.mobile \ --set networkPolicy.postgresEgressCidrs[0]生产数据库网段入口路由二选一环境中已有 ingress 或 service mesh 路由时保持httpRoute.enabledfalse由 chart 自己持有 Gateway API 路由时置httpRoute.enabledtrue并注入环境持有的parentRef——schema 会拒绝“enabled 但无 parent”的渲染。网络策略上APNs 出向与 PostgreSQL 出向使用两个独立 CIDR 列表APNs 目前要求宽的 TCP/443 可达apnsEgressCidrs默认0.0.0.0/0而networkPolicy.postgresEgressCidrs默认示例10.0.0.0/8仅是示例私有网段必须收窄到生产数据库网络DNS 的 namespace/pod selector 要与集群 DNS 部署匹配。验证部署是否就绪按顺序做这些检查渲染期运行helm lint deploy/charts/buzz-push-gateway仓库的render.sh本身也是一份可执行的渲染契约它验证了默认渲染、生产注入渲染、Gateway API 分支和监控分支并断言若干负向用例必须失败——例如未注入的values-production.yaml直接渲染、httpRoute.enabledtrue但无parentRefs、monitoring 开启但 selector 为空都应当渲染失败。镜像gh attestation verify成功是注入image.digest的前置条件见前文命令。数据库权限readiness 会拒绝空/部分 schema、缺失 DML或运行时角色仍持有数据库/schemaCREATE的情况。因此副本通过 readiness 即同时验证了“迁移完成 权限收窄到位”。Pod 状态滚动部署时 Helm 会等待 pre-install/pre-upgrade 迁移 hook 完成后再更新副本因此不会出现无条件启动迁移的竞态检查 Deployment 副本达到replicaCount默认 2且拓扑打散约束maxSkew: 1且 readiness 通过。路由确认https://push.buzz.xyz到达 8080且 8081 不可从集群外触达。文档示例默认 chart 渲染下NetworkPolicy ingress 只含 80808081上没有任何 pod ingressrender.sh中的 ruby 断言即用于核对这些渲染结果。密钥轮换、运行维护与回滚Kubernetes 在引用的 Secret 字节变化时不会重启 Pod。AEAD 或 APNs 证书轮换后必须显式滚动重启例如kubectl rollout restart deployment/release-buzz-push-gateway并在移除 predecessor 密钥前确认 readiness 通过。网关在启动时及每 5 分钟清理过期的 challenge/replay 行、空闲配额行、过期/撤销的委托和达到保留期的 installation含其加密 token 密文。监控 reaper 失败与表增长即可保留机制不依赖进程重启。数据库备份包含 APNs token 密文与 authority 元数据必须与服务密钥享受同样的访问控制与保留策略。回滚不需要删除凭据或改动现有 lease先在启用了 relay 上设置BUZZ_PUSH_ENABLEDfalse停止广告、lease 接受、匹配与新的 gateway 流量网关本身不健康时在 relay 投递关闭之后再禁用 gateway deployment。现有 lease 与 gateway authority 会自然过期。限制该 MVP 只有一个编译内 profilebuzz-ios-dogfood无法通过改部署值来注册xyz.block.buzz.mobile等其他 bundle identifier支持其他应用身份需要显式的代码、schema、chart、凭据与部署变更。网关的专用连接池不消费 relay 侧的BUZZ_DB_LOCK_TIMEOUT_MS、BUZZ_DB_IDLE_TXN_TIMEOUT_MS、BUZZ_DB_STATEMENT_TIMEOUT_MS其 session 超时策略需要独立设计与发布。不要把buzz-push-gateway跑在 relay 镜像里也不要给 relay 配置 APNs 凭据——relay 只持有不透明 capability永远拿不到 APNs token。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考