拓冰网站定制 
Buzz Push Gateway 部署指南为 Buzz 构建 APNs 推送的最后一跳NIP-PL 能力网关【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz导读buzz-push-gateway是 Buzz 社区中负责将推送送达苹果 APNs 的独立公共网关它作为push.buzz.xyz的最后一跳客户端iOS 设备通过 Apple App Attest 完成设备注册enrollment与委托delegation中继relay只持有网关签发的不透明能力凭证endpoint grant网关在验证能力、防重放、配额与授权之后才将加密存储的 APNs token 解密并投递。阅读本文后你将掌握网关的完整环境变量配置与校验规则、密钥轮换与数据库授权模型、指标与告警体系、relay 端BUZZ_PUSH_ENABLED接入方式以及 Helm 生产发布与图表chart发布的全流程。一、定位与构建独立的 APNs 最后一跳buzz-push-gateway的定位是独立的公共 APNs 最后一跳standalone public APNs last hop。它使用 Dockerfile.push-gateway 构建运行在 Debian bookworm slim 基础镜像上最终以非 root 用户buzzuid/gid 1000运行仅暴露8080公共与8081健康检查/指标两个端口。关键约束是绝不要把它放进 relay 镜像也不要向 relay 提供 APNs 凭证。从 crates/buzz-push-gateway/src/lib.rs 可以看到网关源码由apnsAPNs 传输、app_attestApp Attest 验证、authority授权抽象、postgresPostgreSQL 授权存储、grant/token两套 AEAD 密钥环、metrics指标等模块组成是一个完全独立于buzz-relay的 crate。二、网络与健康检查网关运行两个监听器二者职责严格分离监听器环境变量默认值用途公共监听器BUZZ_PUSH_BIND_ADDR0.0.0.0:8080承载全部业务 API将https://push.buzz.xyz路由到此端口私有健康监听器BUZZ_PUSH_HEALTH_ADDR0.0.0.0:8081提供/_liveness、/_readiness探针与GET /metrics严禁暴露到公网在 crates/buzz-push-gateway/src/http.rs 中公共路由与健康路由由router_with_metrics分别构建公共路由/v1/installations注册、/v1/installations/challenges、/v1/delegations、/v1/delegations/revoke、/v1/installations/endpoint、/v1/installations/revoke、/v1/deliveries/apns整体叠加ConcurrencyLimitLayer::new(256)并发限制与 20 秒超时健康路由/_liveness存活与/_readiness就绪当传入metrics_handle时额外挂载GET /metrics。就绪语义_readiness在两个条件下返回 503not_ready——进程正在排空accepting标志为 false对应ReadinessFailure::NotAccepting或 PostgreSQL 授权存储不可用ReadinessFailure::Authority。ready()会逐表检查六张push_gateway_*表的存在性以及当前角色对每张表的SELECT/INSERT/UPDATE/DELETE权限同时要求角色只拥有数据库CONNECT而没有数据库/模式CREATE权限最小权限校验详见 crates/buzz-push-gateway/src/postgres.rs 的ready()实现。优雅关闭从 crates/buzz-push-gateway/src/main.rs 看进程收到 SIGTERM/SIGINT 后先将accepting置为 false停止接受新请求、就绪探针转失败再通过 watch channel 触发公共与健康两个 axum server 的 graceful shutdown公共 server 等待最多 30 秒排空进行中的 APNs 调用随后关闭健康 server。网络策略Helm chart 的 NetworkPolicy 不为8081端口提供 pod 入口默认无任何 pod 入口规则Kubernetes node/kubelet 来源的探针流量天然豁免于 NetworkPolicy。只有当你使用的 CNI 要求 pod 来源的健康抓取时才需要为监控源增加一条窄范围入口规则。三、必填配置与环境变量校验Config::from_env()在 crates/buzz-push-gateway/src/config.rs 中实现缺失或非法配置会直接导致启动失败fail-fast。完整变量如下变量用途与取值约束DATABASE_URLPostgreSQL 授权/准入存储。运行时凭证只需要六张网关表的 DML 权限不需要 DDLBUZZ_PUSH_PUBLIC_DELIVERY_URL外部签名的精确 URL通常为https://push.buzz.xyz/v1/deliveries/apnsBUZZ_PUSH_MAX_GRANT_LIFETIME_SECONDS委托能力delegation capability最大生命周期范围1..31536000秒BUZZ_PUSH_MAX_INSTALLATION_LIFETIME_SECONDS加密 token 安装生命周期默认 90 天7776000秒最大一年客户端必须在到期前续期BUZZ_PUSH_APP_ATTEST_ROOT_CERT_PATH只读挂载的 Apple App Attest 根证书 PEM 路径BUZZ_PUSH_DOGFOOD_APP_ATTEST_APP_ID服务端持有的 Apple App Attest 应用标识TEAMID.bundle-idBUZZ_PUSH_DOGFOOD_APNS_TOPIC服务端持有的 APNs topic永不允许由客户端提供BUZZ_PUSH_DOGFOOD_APNS_ENVIRONMENTproduction或sandbox按部署环境选择BUZZ_PUSH_DOGFOOD_APNS_CERT_PATH只读挂载的 APNs 证书/私钥 PEM 路径BUZZ_PUSH_GRANT_KEYS能力 AEAD 密钥环格式id:base64-32-bytes[,predecessor...]当前密钥排最前BUZZ_PUSH_TOKEN_KEYS独立的 token 托管 AEAD 密钥环格式同上禁止与 grant 密钥复用源码中的校验细节值得注意parse_keyring对每个条目要求id与 base64 解码后恰好 32 字节空 keyring、缺:分隔符、非法 base64 均报ConfigError跨密钥环复用检查from_map会遍历 grant 与 token 两个 keyring只要出现任一相同 id 或相同密钥字节就拒绝启动BUZZ_PUSH_TOKEN_KEYSinvalid相关单测cross_keyring_id_or_material_reuse_fails_startup直接覆盖该路径BUZZ_PUSH_PUBLIC_DELIVERY_URL必须精确匹配https协议、主机push.buzz.xyz、路径/v1/deliveries/apns且不允许端口、query、fragment、用户名、密码配置单测malformed_security_configuration_fails_startup验证了http://或错误主机均被拒绝BUZZ_PUSH_DOGFOOD_APNS_ENVIRONMENT仅接受production默认与sandbox其他值如staging启动即报错BUZZ_PUSH_BIND_ADDR/BUZZ_PUSH_HEALTH_ADDR缺省时保持0.0.0.0:8080/0.0.0.0:8081有对应单测listener_defaults_remain_public_when_addresses_are_absent。可选端点配额策略变量BUZZ_PUSH_ENDPOINT_QUOTA_WINDOW_SECONDS默认10最大86400BUZZ_PUSH_ENDPOINT_QUOTA_MAX_DELIVERIES默认10最大10000。这两项是 Buzz 自身的策略假设并非 Apple 公布的限额应结合负载调优同时保留硬性上限。四、应用档案Profile模型当前仅一个编译内 dogfood 档案这个 MVP 网关只内置一个应用档案buzz-ios-dogfood对应xyz.block.buzz.dogfood.mobile。chart 中的profiles.dogfood.appAttestAppId会被渲染为BUZZ_PUSH_DOGFOOD_APP_ATTEST_APP_ID见 deploy/charts/buzz-push-gateway/templates/deployment.yaml该变量缺失或为空时网关拒绝启动。精确的TEAMID.bundle-id属于环境自有的非机密部署配置生产 values 文件刻意留空要求生产渲染器从 GitOps 环境注入避免把 Block 团队标识硬编码进本仓库见 deploy/charts/buzz-push-gateway/values-production.yaml注册enroll时服务端会做两层校验http.rs中r.app_profile ! AppProfile::BuzzIosDogfood直接返回invalid_request同时AppAttestVerifier会密码学验证配置的应用 IDaudience 为https://push.buzz.xyz/v1/installations支持第二个应用身份需要显式的代码、schema、chart、凭证与部署变更当前网关不按多档案选择。数据库层面 0002_application_profiles.sql 与 0004_dogfood_only_profile.sql 逐步收紧到仅接受buzz-ios-dogfood。五、密钥与轮换规则App Attest 根证书只读挂载启动时任何字节不一致都会导致启动失败。唯一接受的产物是 Apple 官方Apple App Attestation Root CAPEM其指纹如下证书 SHA-2561C: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-256c778d09ac341f7fd9f8f3b19e2b815af6aed4ad4490e1e92c05cb355212a5013注意Apple 根证书轮换必须当作一次经过评审的代码/配置发布处理而不是不加固定unpinned地替换挂载。APNs 证书身份与两套 AEAD 密钥环一律从密钥管理器挂载绝不允许把值放进镜像、manifest、日志或指标 label。AEAD 轮换纪律当前密钥永远排第一位只保留仅解密的前任密钥直到所有用它们加密的能力/token 已过期或被重新加密。grant 与 token 的 key id 与密钥字节必须互不相同。轮换是运维发布流程加入新当前密钥保留前任→ 部署 → 等待保留窗口 → 移除旧密钥。数据库备份即密文网关把 APNs token 以密文形式存储在 PostgreSQL 中因此数据库备份包含密文加授权元数据必须与服务密钥享受同等访问控制与保留策略。六、PostgreSQL 与多副本6.1 独立的会话超时策略网关的专用连接池不消费relay 侧的BUZZ_DB_LOCK_TIMEOUT_MS、BUZZ_DB_IDLE_TXN_TIMEOUT_MS、BUZZ_DB_STATEMENT_TIMEOUT_MS。它的会话超时策略与buzz-db写者策略相互独立需要单独设计与发布。6.2 单库、事务化权威与迁移历史所有副本必须共享同一个 PostgreSQL 数据库投递授权delivery authority、重放准入replay admission、端点配额预留都在该库中事务化执行因此副本数量不会放大滥用上限。网关在 crates/buzz-push-gateway/migrations 下拥有独立的作用域迁移历史0001–0004只创建六张push_gateway_*授权表外加 SQLx 的迁移历史表绝不运行 relay 迁移。六张表定义在 0001_push_gateway_authority.sqlpush_gateway_challenges注册挑战哈希存储 过期时间push_gateway_installations注册设备App Attest 密钥、断言计数器、加密 token 密文、token 指纹、endpoint epoch、过期时间、撤销时间push_gateway_delegations委托安装 → relay 公钥含 generation、not_before/expires_at、唯一约束(installation_id, relay_pubkey)push_gateway_endpoint_quotas端点配额token 指纹为 PK窗口开始时间 已准入计数push_gateway_delivery_auth_replays/push_gateway_delivery_request_replays投递防重放栅栏复合主键。6.3 迁移 Job 与最小权限Helm chart 通过 pre-install/pre-upgrade 迁移 Job 使用migration.existingSecret含 DDL 能力的DATABASE_URL执行迁移URL 必须指向专用网关数据库绝不能是 relay 数据库——SQLx 把_sqlx_migrations历史记录放在public模式中共享数据库会与其它应用的迁移历史冲突migration.runtimeDatabaseRole指定已存在的 LOGIN 角色chart 默认buzz_push_gateway_runtime供运行时DATABASE_URL使用迁移完成后Job 会撤销该角色的数据库CREATE权限以及PUBLIC与该角色在public模式上的CREATE权限随后仅授予数据库CONNECT、模式USAGE以及对六张网关表的SELECT, INSERT, UPDATE, DELETE见 crates/buzz-push-gateway/src/postgres.rs 的apply_migrations_and_grants与 deploy/charts/buzz-push-gateway/templates/migration-job.yaml迁移角色必须拥有数据库/模式对象的所有权或有权执行这些授权它永不提供给运行时副本就绪探针会拒绝空/部分 schema、缺失 DML 权限、或运行时角色仍保留数据库/模式CREATEHelm 在更新副本前会等待迁移钩子完成滚动发布因此不会与无条件的启动迁移竞争终止 pod 前必须把该副本从负载均衡 Service 端点中移除就绪失败会被自动摘除。6.4 保留回收器Reaper服务在启动时以及每 5 分钟执行清理过期挑战与重放行、空闲配额行、过期/撤销的委托、以及达到保留条件的安装含其加密 token 密文。保留回收不依赖进程重启因此必须监控 reaper 失败与表增长。测试 crates/buzz-push-gateway/src/postgres.rs 中的reaper_deletes_active_child_of_retention_eligible_revoked_installation专门验证了先删子委托、再删父安装的外键安全顺序。七、指标与告警7.1 指标出口与基数纪律网关在私有健康监听器BUZZ_PUSH_HEALTH_ADDR默认0.0.0.0:8081上以 Prometheus 文本格式暴露GET /metrics与探针同端口绝不在公共 8080 上暴露。所有序列均已净化且基数有界label 值只取自闭集五类 APNs 结果、固定准入结果、已返回给调用方的静态错误码、就绪失败原因。任何 endpoint、设备 token、relay 公钥、request id 或请求级标识符都不会用作 label这在 crates/buzz-push-gateway/src/metrics.rs 有明确注释与单测验证。指标类型Labels含义push_gateway_apns_send_attempts_totalcounter无进入具体 APNs HTTP 发送缝seam的次数与终态结果对比可发现从未到达传输层的工作push_gateway_apns_deliveries_totalcounteroutcomeaccepted|invalid_endpoint|retry|configuration_fault|permanent_request_faultAPNs 发送终态结果push_gateway_apns_delivery_secondshistogram—APNs 发送往返延迟秒bucket 见APNS_LATENCY_BUCKETS_Spush_gateway_admissions_totalcounterresultadmitted|rejected|unavailableauthorize_delivery重放/配额栅栏的准入结果push_gateway_delivery_errors_totalcounterclass静态仅统计选定的投递处理器退出类见下push_gateway_reaper_failures_totalcounter—保留回收器清扫失败次数push_gateway_readiness_failures_totalcountercausenot_accepting|authority按原因统计就绪探针失败push_gateway_delivery_errors_total刻意保持狭窄只统计/v1/deliveries/apns处理器在准入门槛之后的选定退出类——invalid_grant在发放 permit 前、准入缝被拒、rate_limited、temporarily_unavailable准入缝处权威存储不可用、profile_mismatch、profile_disabled、token_custodyendpoint-token 解密失败、finish_failed分离的 disposition/join 失败以 503 返回。enrollment、delegation、rotation、revocation 处理器上的请求/认证/attestation/grant 校验不计入该指标——它是投递热路径信号不是全 API 的错误率。7.2 抓取是 opt-in 的默认 chart 渲染不变8081无 pod 入口。两种接入方式prometheus-operator设置podMonitor.enabledtrue同时开启networkPolicy.monitoring.enabledtrue并用namespaceSelector/podSelector指名你的抓取器Datadog Autodiscovery保持podMonitor.enabledfalse通过podAnnotations提供 OpenMetrics 检查并开启同一条窄范围 NetworkPolicy 入口。文档给出的可复制配置如下podAnnotations: ad.datadoghq.com/gateway.checks: | { openmetrics: { init_config: {}, instances: [{ openmetrics_endpoint: http://%%host%%:8081/metrics, service: buzz-push-gateway, namespace: block.buzz_push_gateway, metrics: [push_gateway_.*], histogram_buckets_as_distributions: true, send_distribution_buckets: true, send_monotonic_counter: true, collect_counters_with_distributions: true }] } } networkPolicy: monitoring: enabled: true namespaceSelector: # 替换为 Datadog Agent 所在命名空间的 label kubernetes.io/metadata.name: datadog podSelector: # 替换为 Datadog Agent 的 pod label app.kubernetes.io/name: datadog-agent两种模式都只为8081添加一条限定到指定来源的入口规则绝不放开为全量node/kubelet 来源的探针流量仍然豁免。没有 PodMonitor CRD 的集群不要启用podMonitor。7.3 告警规则opt-inPrometheusRule通过prometheusRule.enabledtrue启用。告警阈值与运维动作告警触发条件级别动作PushGatewayConfigurationFault10 分钟窗口内出现任何configuration_fault结果criticalAPNs 证书/topic/环境不健康检查BUZZ_PUSH_DOGFOOD_APNS_*没有 endpoint 被失效PushGatewayAdmissionUnavailable5 分钟窗口内出现任何准入unavailablecriticalPostgreSQL 授权存储不可达检查数据库连通性与 pod 的postgresEgressCidrsNetworkPolicyPushGatewayReadinessAuthorityFailing5 分钟窗口内就绪authority持续失败warning副本正因 DB 检查失败被从 Service 摘除在容量跌破 PodDisruptionBudget 前修复 DB 健康PushGatewayReaperFailing30 分钟窗口内 reaper 失败 ≥2 次每 5 分钟运行一次warning过期预留未被清扫bounded-until-expiry 窗口在增长检查 DB 写入可用性PushGatewayHighApnsRetryRate10 分钟窗口内可重试比例 prometheusRule.apnsRetryRatioThreshold默认0.25且尝试数超过apnsRetryMinSamples默认20持续 15 分钟warningAPNs 在限流或降级429/500/503投递被延迟而非丢失阈值默认值在 deploy/charts/buzz-push-gateway/values.yaml 的prometheusRule段。八、Relay 侧接入BUZZ_PUSH_ENABLEDRelay 推送是显式部署 opt-in由BUZZ_PUSH_ENABLEDtrue开启严格布尔解析器拒绝未知值默认关闭。在 crates/buzz-relay/src/config.rs 中未配置BUZZ_PUSH_GATEWAY_DELIVERY_URL时默认使用精确规范 URLhttps://push.buzz.xyz/v1/deliveries/apns运营者也可作为高级覆盖提供其他精确 HTTPS/v1/deliveries/apnsURL开启状态下显式传空 URL 是启动错误BUZZ_PUSH_GATEWAY_DELIVERY_URL must not be empty when BUZZ_PUSH_ENABLEDtrue。只有开启的 relay 才会广告其 host-scoped NIP-PL 描述符、接受租约lease、启动 matcher 与投递 worker。Relay 保留租约匹配、授权、持久化 jobs/重试、generation 检查它们只拿到不透明能力opaque capabilities绝不接触 APNs token 或 provider 凭证。开启的 relay 在其既有 Prometheus 端点上额外导出以下有界基数序列同样不以社区、账户、relay key、安装、事件或请求标识作 label指标类型Labels含义buzz_push_enabledgauge—仅当部署 opt-in 激活时为1buzz_push_match_jobs_totalcounterresultmatched|unmatched|error|context_errormatcher 评估的已接受消息事件buzz_push_match_queue_secondshistogram—relay 收到事件到 matcher 评估的延迟buzz_push_wakes_totalcounterresultenqueued|duplicate|inactive_lease持久化 wake 入队结果buzz_push_wake_enqueue_errors_totalcounter—集合式 outbox 事务失败次数buzz_push_wake_queue_secondshistogram—首次尝试 outbox 入队到 worker 的延迟buzz_push_gateway_requests_totalcounter—到达网关传输缝的 relay 请求数buzz_push_gateway_request_secondshistogram—relay 观测到的网关请求延迟buzz_push_deliveries_totalcounteroutcome静态闭集已接受/重试/抑制/耗尽/无效/失败的 relay 投递结果Relay 集成状态按来源事件匹配 读授权检查、持久化入队、发送时再校验、NIP-98 投递等运行时全部只在BUZZ_PUSH_ENABLEDtrue时运行。端到端使用仍依赖客户端 App Attest 注册/委托流程把网关签发的**不透明能力而非裸 APNs token**放入加密 relay 租约。九、内部 dogfood 评估与回滚启用前提规范网关的唯一 dogfood 档案必须配置好服务端持有的 App Attest 应用 ID、APNs topic、生产证书身份与生产 APNs 环境且只有选定的内部 relay 部署设置BUZZ_PUSH_ENABLEDtrue。每个 iOS 构件都包含原生推送桥与 Notification Service Extension但客户端在其当前已认证 relay 广告出完全有效的 NIP-11nip-pl描述符之前保持不活跃。此 MVP 没有 App Store 网关档案。物理设备验证必须使用 App Attest 身份与 APNs topic 均匹配 dogfood 档案的应用。当前网关不能仅靠改部署 values 来注册xyz.block.buzz.mobile或其他 bundle id——新增身份需要上文所述的多档案显式工作。发布验证路径feature 合入main后从精确的当前origin/main提交发布下一个不可变mobile-vX.Y.Z-rc.N候选 → 用常规发布流水线构建该 tag → 等待签名的xyz.block.buzz.dogfood.mobile构件出现在发布平台 → 在物理设备安装。针对规范网关与一个开启推送的内部 relay 验证APNs 投递、拉取并验签的通知内容、精确消息点击路由然后再扩大内部评估范围。iOS 签名细节首个候选之前私有 dogfood 构建器的签名与导出配置必须为xyz.block.buzz.dogfood.mobile与xyz.block.buzz.dogfood.mobile.NotificationService分别映射 distribution profile——仅 app-only profile 无法给扩展extension提供配置。要启用富媒体通知展示需先在父 dogfood App ID 上启用 Apple 的 Communication Notifications 能力并重新生成 app provisioning profile扩展 profile 不需要该能力未来的 App Store 发布同样适用该父 App ID 前置条件。评估度量对每个评估批次从上述直方图测量 relay 接收→匹配、wake 队列、relay→gateway、gateway→APNs 的延迟跟踪已接受或重放终态的 relay 结果 / 新入队 wakes比例、网关 APNs 的 accepted/retry/invalid/configuration 结果、重试耗尽与 NSE 解析回退。APNs 接受不等于设备展示需记录小样本手动物理设备数据event-created、banner-visible、notification-tap 时间戳验证可见标题/正文来自拉取并验签的 relay 内容、点击打开精确触发消息在隐私保护的客户端遥测设计完成前回退到 channel 与占位/失败场景都要在手动样本中显式计数。回滚不删除凭证、不修改既有租约把已启用 relay 的BUZZ_PUSH_ENABLEDfalse即可停止广告、租约接受、匹配、worker 与新网关流量。若网关本身不健康务必先关 relay 投递、再禁用网关部署。既有租约与网关授权随后自然过期。十、Helm 生产输入与不可变镜像chart 默认main镜像 tag由 push-gateway lane 发布。生产发布时打开对应 workflow run 的Publish public push gateway imagejob 摘要复制其sha256:...摘要在注入前用gh验证发布的 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只有命令成功后才把精确摘要作为image.digest注入环境的 GitOps valueschart 随即渲染ghcr.io/block/buzz-push-gatewaysha256:...并忽略可变 tag。values-production.yaml是有意的无效生产输入契约部署 CI 必须注入已验签镜像摘要、已配给的 dogfood Apple 应用标识与真实 PostgreSQL 网络。已有 ingress 或 service mesh 路由的环境保持httpRoute.enabledfalse若由本 chart 独占 Gateway API 路由则启用它并注入环境自有的parentRefschema 校验拒绝启用但无 parent的渲染。渲染守卫render guard同时验证缺失必填输入被拒绝与完全注入的渲染可通过见 deploy/charts/buzz-push-gateway/tests/render.sh 与 deploy/charts/buzz-push-gateway/values.schema.json。网络策略要点APNs HTTPS 与 PostgreSQL 出站放在独立的 CIDR 列表中。APNs 目前要求宽泛的 TCP/443 可达性networkPolicy.postgresEgressCidrs必须收窄到生产数据库网络DNS 的 namespace/pod selector 必须匹配集群 DNS 部署。示例私有 CIDR如10.0.0.0/8不构成对生产拓扑的断言。Secret 轮换与滚动重启Kubernetes 不会因 Secret 字节变化而重启 pod。AEAD 或 APNs 证书轮换要求在密钥管理器更新后显式滚动重启例如kubectl rollout restart deployment/release-buzz-push-gateway并在移除前任密钥前完成就绪验证。Service-account token 自动挂载已禁用。十一、网关 chart 发布流程网关 chart 拥有与主buzzchart无冲突的独立发布 lane。发布 chart 版本X.Y.Z更新 deploy/charts/buzz-push-gateway/Chart.yaml 的version并保持appVersion等于网关二进制的 workspace package 版本验证 chart然后开启分支名恰好为push-chart-release/X.Y.Z的同仓库 PRdeploy/charts/buzz-push-gateway/tests/render.sh git switch -c push-chart-release/X.Y.Z git add deploy/charts/buzz-push-gateway/Chart.yaml git commit -m release: push gateway chart X.Y.Z git push -u origin push-chart-release/X.Y.ZPR 合并后自动化工作流创建push-chart-vX.Y.Ztag 并以该不可变 tag 与裸版本分发发布任务发布者先校验检出 commit 是 tag 目标、chart 版本等于X.Y.Z再推送oci://ghcr.io/block/buzz/charts/buzz-push-gateway。手动推送push-chart-vX.Y.Ztag 是文档化的救援路径执行同样的检查。发布成功后先检查再拉取helm show chart oci://ghcr.io/block/buzz/charts/buzz-push-gateway --version X.Y.Z helm pull oci://ghcr.io/block/buzz/charts/buzz-push-gateway --version X.Y.Z结语buzz-push-gateway把谁可以推送、推到哪台设备、能推多频繁集中到一个可独立发布、可回滚、指标与密钥纪律严格的最后跳网关中客户端经 App Attest 证明设备身份relay 只搬运不透明能力网关在 PostgreSQL 事务栅栏上完成重放/配额/授权校验后才接触 APNs 明文 token。本文所涉全部实现细节均可在 crates/buzz-push-gateway、crates/buzz-relay/src/config.rs 与 deploy/charts/buzz-push-gateway 中进一步核对相关集成测试与夹具位于 crates/buzz-push-gateway/tests 及 deploy/charts/buzz-push-gateway/tests。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Buzz Push Gateway 部署指南：为 Buzz 构建 APNs 推送的最后一跳（NIP-PL 能力网关）
Buzz Push Gateway 部署指南为 Buzz 构建 APNs 推送的最后一跳NIP-PL 能力网关【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz导读buzz-push-gateway是 Buzz 社区中负责将推送送达苹果 APNs 的独立公共网关它作为push.buzz.xyz的最后一跳客户端iOS 设备通过 Apple App Attest 完成设备注册enrollment与委托delegation中继relay只持有网关签发的不透明能力凭证endpoint grant网关在验证能力、防重放、配额与授权之后才将加密存储的 APNs token 解密并投递。阅读本文后你将掌握网关的完整环境变量配置与校验规则、密钥轮换与数据库授权模型、指标与告警体系、relay 端BUZZ_PUSH_ENABLED接入方式以及 Helm 生产发布与图表chart发布的全流程。一、定位与构建独立的 APNs 最后一跳buzz-push-gateway的定位是独立的公共 APNs 最后一跳standalone public APNs last hop。它使用 Dockerfile.push-gateway 构建运行在 Debian bookworm slim 基础镜像上最终以非 root 用户buzzuid/gid 1000运行仅暴露8080公共与8081健康检查/指标两个端口。关键约束是绝不要把它放进 relay 镜像也不要向 relay 提供 APNs 凭证。从 crates/buzz-push-gateway/src/lib.rs 可以看到网关源码由apnsAPNs 传输、app_attestApp Attest 验证、authority授权抽象、postgresPostgreSQL 授权存储、grant/token两套 AEAD 密钥环、metrics指标等模块组成是一个完全独立于buzz-relay的 crate。二、网络与健康检查网关运行两个监听器二者职责严格分离监听器环境变量默认值用途公共监听器BUZZ_PUSH_BIND_ADDR0.0.0.0:8080承载全部业务 API将https://push.buzz.xyz路由到此端口私有健康监听器BUZZ_PUSH_HEALTH_ADDR0.0.0.0:8081提供/_liveness、/_readiness探针与GET /metrics严禁暴露到公网在 crates/buzz-push-gateway/src/http.rs 中公共路由与健康路由由router_with_metrics分别构建公共路由/v1/installations注册、/v1/installations/challenges、/v1/delegations、/v1/delegations/revoke、/v1/installations/endpoint、/v1/installations/revoke、/v1/deliveries/apns整体叠加ConcurrencyLimitLayer::new(256)并发限制与 20 秒超时健康路由/_liveness存活与/_readiness就绪当传入metrics_handle时额外挂载GET /metrics。就绪语义_readiness在两个条件下返回 503not_ready——进程正在排空accepting标志为 false对应ReadinessFailure::NotAccepting或 PostgreSQL 授权存储不可用ReadinessFailure::Authority。ready()会逐表检查六张push_gateway_*表的存在性以及当前角色对每张表的SELECT/INSERT/UPDATE/DELETE权限同时要求角色只拥有数据库CONNECT而没有数据库/模式CREATE权限最小权限校验详见 crates/buzz-push-gateway/src/postgres.rs 的ready()实现。优雅关闭从 crates/buzz-push-gateway/src/main.rs 看进程收到 SIGTERM/SIGINT 后先将accepting置为 false停止接受新请求、就绪探针转失败再通过 watch channel 触发公共与健康两个 axum server 的 graceful shutdown公共 server 等待最多 30 秒排空进行中的 APNs 调用随后关闭健康 server。网络策略Helm chart 的 NetworkPolicy 不为8081端口提供 pod 入口默认无任何 pod 入口规则Kubernetes node/kubelet 来源的探针流量天然豁免于 NetworkPolicy。只有当你使用的 CNI 要求 pod 来源的健康抓取时才需要为监控源增加一条窄范围入口规则。三、必填配置与环境变量校验Config::from_env()在 crates/buzz-push-gateway/src/config.rs 中实现缺失或非法配置会直接导致启动失败fail-fast。完整变量如下变量用途与取值约束DATABASE_URLPostgreSQL 授权/准入存储。运行时凭证只需要六张网关表的 DML 权限不需要 DDLBUZZ_PUSH_PUBLIC_DELIVERY_URL外部签名的精确 URL通常为https://push.buzz.xyz/v1/deliveries/apnsBUZZ_PUSH_MAX_GRANT_LIFETIME_SECONDS委托能力delegation capability最大生命周期范围1..31536000秒BUZZ_PUSH_MAX_INSTALLATION_LIFETIME_SECONDS加密 token 安装生命周期默认 90 天7776000秒最大一年客户端必须在到期前续期BUZZ_PUSH_APP_ATTEST_ROOT_CERT_PATH只读挂载的 Apple App Attest 根证书 PEM 路径BUZZ_PUSH_DOGFOOD_APP_ATTEST_APP_ID服务端持有的 Apple App Attest 应用标识TEAMID.bundle-idBUZZ_PUSH_DOGFOOD_APNS_TOPIC服务端持有的 APNs topic永不允许由客户端提供BUZZ_PUSH_DOGFOOD_APNS_ENVIRONMENTproduction或sandbox按部署环境选择BUZZ_PUSH_DOGFOOD_APNS_CERT_PATH只读挂载的 APNs 证书/私钥 PEM 路径BUZZ_PUSH_GRANT_KEYS能力 AEAD 密钥环格式id:base64-32-bytes[,predecessor...]当前密钥排最前BUZZ_PUSH_TOKEN_KEYS独立的 token 托管 AEAD 密钥环格式同上禁止与 grant 密钥复用源码中的校验细节值得注意parse_keyring对每个条目要求id与 base64 解码后恰好 32 字节空 keyring、缺:分隔符、非法 base64 均报ConfigError跨密钥环复用检查from_map会遍历 grant 与 token 两个 keyring只要出现任一相同 id 或相同密钥字节就拒绝启动BUZZ_PUSH_TOKEN_KEYSinvalid相关单测cross_keyring_id_or_material_reuse_fails_startup直接覆盖该路径BUZZ_PUSH_PUBLIC_DELIVERY_URL必须精确匹配https协议、主机push.buzz.xyz、路径/v1/deliveries/apns且不允许端口、query、fragment、用户名、密码配置单测malformed_security_configuration_fails_startup验证了http://或错误主机均被拒绝BUZZ_PUSH_DOGFOOD_APNS_ENVIRONMENT仅接受production默认与sandbox其他值如staging启动即报错BUZZ_PUSH_BIND_ADDR/BUZZ_PUSH_HEALTH_ADDR缺省时保持0.0.0.0:8080/0.0.0.0:8081有对应单测listener_defaults_remain_public_when_addresses_are_absent。可选端点配额策略变量BUZZ_PUSH_ENDPOINT_QUOTA_WINDOW_SECONDS默认10最大86400BUZZ_PUSH_ENDPOINT_QUOTA_MAX_DELIVERIES默认10最大10000。这两项是 Buzz 自身的策略假设并非 Apple 公布的限额应结合负载调优同时保留硬性上限。四、应用档案Profile模型当前仅一个编译内 dogfood 档案这个 MVP 网关只内置一个应用档案buzz-ios-dogfood对应xyz.block.buzz.dogfood.mobile。chart 中的profiles.dogfood.appAttestAppId会被渲染为BUZZ_PUSH_DOGFOOD_APP_ATTEST_APP_ID见 deploy/charts/buzz-push-gateway/templates/deployment.yaml该变量缺失或为空时网关拒绝启动。精确的TEAMID.bundle-id属于环境自有的非机密部署配置生产 values 文件刻意留空要求生产渲染器从 GitOps 环境注入避免把 Block 团队标识硬编码进本仓库见 deploy/charts/buzz-push-gateway/values-production.yaml注册enroll时服务端会做两层校验http.rs中r.app_profile ! AppProfile::BuzzIosDogfood直接返回invalid_request同时AppAttestVerifier会密码学验证配置的应用 IDaudience 为https://push.buzz.xyz/v1/installations支持第二个应用身份需要显式的代码、schema、chart、凭证与部署变更当前网关不按多档案选择。数据库层面 0002_application_profiles.sql 与 0004_dogfood_only_profile.sql 逐步收紧到仅接受buzz-ios-dogfood。五、密钥与轮换规则App Attest 根证书只读挂载启动时任何字节不一致都会导致启动失败。唯一接受的产物是 Apple 官方Apple App Attestation Root CAPEM其指纹如下证书 SHA-2561C: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-256c778d09ac341f7fd9f8f3b19e2b815af6aed4ad4490e1e92c05cb355212a5013注意Apple 根证书轮换必须当作一次经过评审的代码/配置发布处理而不是不加固定unpinned地替换挂载。APNs 证书身份与两套 AEAD 密钥环一律从密钥管理器挂载绝不允许把值放进镜像、manifest、日志或指标 label。AEAD 轮换纪律当前密钥永远排第一位只保留仅解密的前任密钥直到所有用它们加密的能力/token 已过期或被重新加密。grant 与 token 的 key id 与密钥字节必须互不相同。轮换是运维发布流程加入新当前密钥保留前任→ 部署 → 等待保留窗口 → 移除旧密钥。数据库备份即密文网关把 APNs token 以密文形式存储在 PostgreSQL 中因此数据库备份包含密文加授权元数据必须与服务密钥享受同等访问控制与保留策略。六、PostgreSQL 与多副本6.1 独立的会话超时策略网关的专用连接池不消费relay 侧的BUZZ_DB_LOCK_TIMEOUT_MS、BUZZ_DB_IDLE_TXN_TIMEOUT_MS、BUZZ_DB_STATEMENT_TIMEOUT_MS。它的会话超时策略与buzz-db写者策略相互独立需要单独设计与发布。6.2 单库、事务化权威与迁移历史所有副本必须共享同一个 PostgreSQL 数据库投递授权delivery authority、重放准入replay admission、端点配额预留都在该库中事务化执行因此副本数量不会放大滥用上限。网关在 crates/buzz-push-gateway/migrations 下拥有独立的作用域迁移历史0001–0004只创建六张push_gateway_*授权表外加 SQLx 的迁移历史表绝不运行 relay 迁移。六张表定义在 0001_push_gateway_authority.sqlpush_gateway_challenges注册挑战哈希存储 过期时间push_gateway_installations注册设备App Attest 密钥、断言计数器、加密 token 密文、token 指纹、endpoint epoch、过期时间、撤销时间push_gateway_delegations委托安装 → relay 公钥含 generation、not_before/expires_at、唯一约束(installation_id, relay_pubkey)push_gateway_endpoint_quotas端点配额token 指纹为 PK窗口开始时间 已准入计数push_gateway_delivery_auth_replays/push_gateway_delivery_request_replays投递防重放栅栏复合主键。6.3 迁移 Job 与最小权限Helm chart 通过 pre-install/pre-upgrade 迁移 Job 使用migration.existingSecret含 DDL 能力的DATABASE_URL执行迁移URL 必须指向专用网关数据库绝不能是 relay 数据库——SQLx 把_sqlx_migrations历史记录放在public模式中共享数据库会与其它应用的迁移历史冲突migration.runtimeDatabaseRole指定已存在的 LOGIN 角色chart 默认buzz_push_gateway_runtime供运行时DATABASE_URL使用迁移完成后Job 会撤销该角色的数据库CREATE权限以及PUBLIC与该角色在public模式上的CREATE权限随后仅授予数据库CONNECT、模式USAGE以及对六张网关表的SELECT, INSERT, UPDATE, DELETE见 crates/buzz-push-gateway/src/postgres.rs 的apply_migrations_and_grants与 deploy/charts/buzz-push-gateway/templates/migration-job.yaml迁移角色必须拥有数据库/模式对象的所有权或有权执行这些授权它永不提供给运行时副本就绪探针会拒绝空/部分 schema、缺失 DML 权限、或运行时角色仍保留数据库/模式CREATEHelm 在更新副本前会等待迁移钩子完成滚动发布因此不会与无条件的启动迁移竞争终止 pod 前必须把该副本从负载均衡 Service 端点中移除就绪失败会被自动摘除。6.4 保留回收器Reaper服务在启动时以及每 5 分钟执行清理过期挑战与重放行、空闲配额行、过期/撤销的委托、以及达到保留条件的安装含其加密 token 密文。保留回收不依赖进程重启因此必须监控 reaper 失败与表增长。测试 crates/buzz-push-gateway/src/postgres.rs 中的reaper_deletes_active_child_of_retention_eligible_revoked_installation专门验证了先删子委托、再删父安装的外键安全顺序。七、指标与告警7.1 指标出口与基数纪律网关在私有健康监听器BUZZ_PUSH_HEALTH_ADDR默认0.0.0.0:8081上以 Prometheus 文本格式暴露GET /metrics与探针同端口绝不在公共 8080 上暴露。所有序列均已净化且基数有界label 值只取自闭集五类 APNs 结果、固定准入结果、已返回给调用方的静态错误码、就绪失败原因。任何 endpoint、设备 token、relay 公钥、request id 或请求级标识符都不会用作 label这在 crates/buzz-push-gateway/src/metrics.rs 有明确注释与单测验证。指标类型Labels含义push_gateway_apns_send_attempts_totalcounter无进入具体 APNs HTTP 发送缝seam的次数与终态结果对比可发现从未到达传输层的工作push_gateway_apns_deliveries_totalcounteroutcomeaccepted|invalid_endpoint|retry|configuration_fault|permanent_request_faultAPNs 发送终态结果push_gateway_apns_delivery_secondshistogram—APNs 发送往返延迟秒bucket 见APNS_LATENCY_BUCKETS_Spush_gateway_admissions_totalcounterresultadmitted|rejected|unavailableauthorize_delivery重放/配额栅栏的准入结果push_gateway_delivery_errors_totalcounterclass静态仅统计选定的投递处理器退出类见下push_gateway_reaper_failures_totalcounter—保留回收器清扫失败次数push_gateway_readiness_failures_totalcountercausenot_accepting|authority按原因统计就绪探针失败push_gateway_delivery_errors_total刻意保持狭窄只统计/v1/deliveries/apns处理器在准入门槛之后的选定退出类——invalid_grant在发放 permit 前、准入缝被拒、rate_limited、temporarily_unavailable准入缝处权威存储不可用、profile_mismatch、profile_disabled、token_custodyendpoint-token 解密失败、finish_failed分离的 disposition/join 失败以 503 返回。enrollment、delegation、rotation、revocation 处理器上的请求/认证/attestation/grant 校验不计入该指标——它是投递热路径信号不是全 API 的错误率。7.2 抓取是 opt-in 的默认 chart 渲染不变8081无 pod 入口。两种接入方式prometheus-operator设置podMonitor.enabledtrue同时开启networkPolicy.monitoring.enabledtrue并用namespaceSelector/podSelector指名你的抓取器Datadog Autodiscovery保持podMonitor.enabledfalse通过podAnnotations提供 OpenMetrics 检查并开启同一条窄范围 NetworkPolicy 入口。文档给出的可复制配置如下podAnnotations: ad.datadoghq.com/gateway.checks: | { openmetrics: { init_config: {}, instances: [{ openmetrics_endpoint: http://%%host%%:8081/metrics, service: buzz-push-gateway, namespace: block.buzz_push_gateway, metrics: [push_gateway_.*], histogram_buckets_as_distributions: true, send_distribution_buckets: true, send_monotonic_counter: true, collect_counters_with_distributions: true }] } } networkPolicy: monitoring: enabled: true namespaceSelector: # 替换为 Datadog Agent 所在命名空间的 label kubernetes.io/metadata.name: datadog podSelector: # 替换为 Datadog Agent 的 pod label app.kubernetes.io/name: datadog-agent两种模式都只为8081添加一条限定到指定来源的入口规则绝不放开为全量node/kubelet 来源的探针流量仍然豁免。没有 PodMonitor CRD 的集群不要启用podMonitor。7.3 告警规则opt-inPrometheusRule通过prometheusRule.enabledtrue启用。告警阈值与运维动作告警触发条件级别动作PushGatewayConfigurationFault10 分钟窗口内出现任何configuration_fault结果criticalAPNs 证书/topic/环境不健康检查BUZZ_PUSH_DOGFOOD_APNS_*没有 endpoint 被失效PushGatewayAdmissionUnavailable5 分钟窗口内出现任何准入unavailablecriticalPostgreSQL 授权存储不可达检查数据库连通性与 pod 的postgresEgressCidrsNetworkPolicyPushGatewayReadinessAuthorityFailing5 分钟窗口内就绪authority持续失败warning副本正因 DB 检查失败被从 Service 摘除在容量跌破 PodDisruptionBudget 前修复 DB 健康PushGatewayReaperFailing30 分钟窗口内 reaper 失败 ≥2 次每 5 分钟运行一次warning过期预留未被清扫bounded-until-expiry 窗口在增长检查 DB 写入可用性PushGatewayHighApnsRetryRate10 分钟窗口内可重试比例 prometheusRule.apnsRetryRatioThreshold默认0.25且尝试数超过apnsRetryMinSamples默认20持续 15 分钟warningAPNs 在限流或降级429/500/503投递被延迟而非丢失阈值默认值在 deploy/charts/buzz-push-gateway/values.yaml 的prometheusRule段。八、Relay 侧接入BUZZ_PUSH_ENABLEDRelay 推送是显式部署 opt-in由BUZZ_PUSH_ENABLEDtrue开启严格布尔解析器拒绝未知值默认关闭。在 crates/buzz-relay/src/config.rs 中未配置BUZZ_PUSH_GATEWAY_DELIVERY_URL时默认使用精确规范 URLhttps://push.buzz.xyz/v1/deliveries/apns运营者也可作为高级覆盖提供其他精确 HTTPS/v1/deliveries/apnsURL开启状态下显式传空 URL 是启动错误BUZZ_PUSH_GATEWAY_DELIVERY_URL must not be empty when BUZZ_PUSH_ENABLEDtrue。只有开启的 relay 才会广告其 host-scoped NIP-PL 描述符、接受租约lease、启动 matcher 与投递 worker。Relay 保留租约匹配、授权、持久化 jobs/重试、generation 检查它们只拿到不透明能力opaque capabilities绝不接触 APNs token 或 provider 凭证。开启的 relay 在其既有 Prometheus 端点上额外导出以下有界基数序列同样不以社区、账户、relay key、安装、事件或请求标识作 label指标类型Labels含义buzz_push_enabledgauge—仅当部署 opt-in 激活时为1buzz_push_match_jobs_totalcounterresultmatched|unmatched|error|context_errormatcher 评估的已接受消息事件buzz_push_match_queue_secondshistogram—relay 收到事件到 matcher 评估的延迟buzz_push_wakes_totalcounterresultenqueued|duplicate|inactive_lease持久化 wake 入队结果buzz_push_wake_enqueue_errors_totalcounter—集合式 outbox 事务失败次数buzz_push_wake_queue_secondshistogram—首次尝试 outbox 入队到 worker 的延迟buzz_push_gateway_requests_totalcounter—到达网关传输缝的 relay 请求数buzz_push_gateway_request_secondshistogram—relay 观测到的网关请求延迟buzz_push_deliveries_totalcounteroutcome静态闭集已接受/重试/抑制/耗尽/无效/失败的 relay 投递结果Relay 集成状态按来源事件匹配 读授权检查、持久化入队、发送时再校验、NIP-98 投递等运行时全部只在BUZZ_PUSH_ENABLEDtrue时运行。端到端使用仍依赖客户端 App Attest 注册/委托流程把网关签发的**不透明能力而非裸 APNs token**放入加密 relay 租约。九、内部 dogfood 评估与回滚启用前提规范网关的唯一 dogfood 档案必须配置好服务端持有的 App Attest 应用 ID、APNs topic、生产证书身份与生产 APNs 环境且只有选定的内部 relay 部署设置BUZZ_PUSH_ENABLEDtrue。每个 iOS 构件都包含原生推送桥与 Notification Service Extension但客户端在其当前已认证 relay 广告出完全有效的 NIP-11nip-pl描述符之前保持不活跃。此 MVP 没有 App Store 网关档案。物理设备验证必须使用 App Attest 身份与 APNs topic 均匹配 dogfood 档案的应用。当前网关不能仅靠改部署 values 来注册xyz.block.buzz.mobile或其他 bundle id——新增身份需要上文所述的多档案显式工作。发布验证路径feature 合入main后从精确的当前origin/main提交发布下一个不可变mobile-vX.Y.Z-rc.N候选 → 用常规发布流水线构建该 tag → 等待签名的xyz.block.buzz.dogfood.mobile构件出现在发布平台 → 在物理设备安装。针对规范网关与一个开启推送的内部 relay 验证APNs 投递、拉取并验签的通知内容、精确消息点击路由然后再扩大内部评估范围。iOS 签名细节首个候选之前私有 dogfood 构建器的签名与导出配置必须为xyz.block.buzz.dogfood.mobile与xyz.block.buzz.dogfood.mobile.NotificationService分别映射 distribution profile——仅 app-only profile 无法给扩展extension提供配置。要启用富媒体通知展示需先在父 dogfood App ID 上启用 Apple 的 Communication Notifications 能力并重新生成 app provisioning profile扩展 profile 不需要该能力未来的 App Store 发布同样适用该父 App ID 前置条件。评估度量对每个评估批次从上述直方图测量 relay 接收→匹配、wake 队列、relay→gateway、gateway→APNs 的延迟跟踪已接受或重放终态的 relay 结果 / 新入队 wakes比例、网关 APNs 的 accepted/retry/invalid/configuration 结果、重试耗尽与 NSE 解析回退。APNs 接受不等于设备展示需记录小样本手动物理设备数据event-created、banner-visible、notification-tap 时间戳验证可见标题/正文来自拉取并验签的 relay 内容、点击打开精确触发消息在隐私保护的客户端遥测设计完成前回退到 channel 与占位/失败场景都要在手动样本中显式计数。回滚不删除凭证、不修改既有租约把已启用 relay 的BUZZ_PUSH_ENABLEDfalse即可停止广告、租约接受、匹配、worker 与新网关流量。若网关本身不健康务必先关 relay 投递、再禁用网关部署。既有租约与网关授权随后自然过期。十、Helm 生产输入与不可变镜像chart 默认main镜像 tag由 push-gateway lane 发布。生产发布时打开对应 workflow run 的Publish public push gateway imagejob 摘要复制其sha256:...摘要在注入前用gh验证发布的 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只有命令成功后才把精确摘要作为image.digest注入环境的 GitOps valueschart 随即渲染ghcr.io/block/buzz-push-gatewaysha256:...并忽略可变 tag。values-production.yaml是有意的无效生产输入契约部署 CI 必须注入已验签镜像摘要、已配给的 dogfood Apple 应用标识与真实 PostgreSQL 网络。已有 ingress 或 service mesh 路由的环境保持httpRoute.enabledfalse若由本 chart 独占 Gateway API 路由则启用它并注入环境自有的parentRefschema 校验拒绝启用但无 parent的渲染。渲染守卫render guard同时验证缺失必填输入被拒绝与完全注入的渲染可通过见 deploy/charts/buzz-push-gateway/tests/render.sh 与 deploy/charts/buzz-push-gateway/values.schema.json。网络策略要点APNs HTTPS 与 PostgreSQL 出站放在独立的 CIDR 列表中。APNs 目前要求宽泛的 TCP/443 可达性networkPolicy.postgresEgressCidrs必须收窄到生产数据库网络DNS 的 namespace/pod selector 必须匹配集群 DNS 部署。示例私有 CIDR如10.0.0.0/8不构成对生产拓扑的断言。Secret 轮换与滚动重启Kubernetes 不会因 Secret 字节变化而重启 pod。AEAD 或 APNs 证书轮换要求在密钥管理器更新后显式滚动重启例如kubectl rollout restart deployment/release-buzz-push-gateway并在移除前任密钥前完成就绪验证。Service-account token 自动挂载已禁用。十一、网关 chart 发布流程网关 chart 拥有与主buzzchart无冲突的独立发布 lane。发布 chart 版本X.Y.Z更新 deploy/charts/buzz-push-gateway/Chart.yaml 的version并保持appVersion等于网关二进制的 workspace package 版本验证 chart然后开启分支名恰好为push-chart-release/X.Y.Z的同仓库 PRdeploy/charts/buzz-push-gateway/tests/render.sh git switch -c push-chart-release/X.Y.Z git add deploy/charts/buzz-push-gateway/Chart.yaml git commit -m release: push gateway chart X.Y.Z git push -u origin push-chart-release/X.Y.ZPR 合并后自动化工作流创建push-chart-vX.Y.Ztag 并以该不可变 tag 与裸版本分发发布任务发布者先校验检出 commit 是 tag 目标、chart 版本等于X.Y.Z再推送oci://ghcr.io/block/buzz/charts/buzz-push-gateway。手动推送push-chart-vX.Y.Ztag 是文档化的救援路径执行同样的检查。发布成功后先检查再拉取helm show chart oci://ghcr.io/block/buzz/charts/buzz-push-gateway --version X.Y.Z helm pull oci://ghcr.io/block/buzz/charts/buzz-push-gateway --version X.Y.Z结语buzz-push-gateway把谁可以推送、推到哪台设备、能推多频繁集中到一个可独立发布、可回滚、指标与密钥纪律严格的最后跳网关中客户端经 App Attest 证明设备身份relay 只搬运不透明能力网关在 PostgreSQL 事务栅栏上完成重放/配额/授权校验后才接触 APNs 明文 token。本文所涉全部实现细节均可在 crates/buzz-push-gateway、crates/buzz-relay/src/config.rs 与 deploy/charts/buzz-push-gateway 中进一步核对相关集成测试与夹具位于 crates/buzz-push-gateway/tests 及 deploy/charts/buzz-push-gateway/tests。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考