Deploy Software Beyond Limits
Apollo：把软件部署到"你连不进去"的任何环境
这是 Palantir 产品体系的"地基"——Foundry 与 AIP 之所以能在客户云、本地机房、气隙网络、乃至海上的舰船和边缘设备上持续运行，靠的就是它。本页用 9 个小节、边玩边学，让你从"部署好难"到"原来如此"。
一句话结论
Apollo 是 Palantir 产品体系的部署底座，官方定义是「在异构环境中部署、监控、修复并保护你的软件」。它把「部署」从一次性动作变成持续的运行状态——你只声明想要什么状态，升级、回滚、合规与漏洞扫描由它接管。
- 控制流反转：不是从外面把版本 push 进去，而是让每个环境里的 Agent 主动拉取声明式指令，按策略自行收敛到目标状态。这是它能被安全团队接受的前提。
- 三个核心思想：声明式状态（描述「应该跑什么」，用持续对账循环把现实拉向描述）、约束（Plan 只在所有相关约束满足时才下发）、渐进（沿 Release Channel 逐级晋级，靠健康信号把关）。
- Hub & Spoke：Hub（中枢）内含编排引擎，掌握产品目录、向各 Spoke 下发 Plan、负责 Release 晋级；每个 Spoke 环境跑一个控制平面与 Agent，回报实际状态并轮询、执行 Plan。
- Plans 与约束闸门：任何变更（安装、改配置、升级、卸载、改密钥）都是一份 Plan，只有在所有相关约束满足时才下发执行。
- Run Anywhere：在多云、本地、私有 SaaS、气隙、边缘等形态各异的环境上，用同一套控制中心把软件当作「一支舰队」来管理。
- 与 Foundry / AIP 的关系：Foundry 与 AIP 是「产品」，Apollo 是它们「如何抵达你、并始终保持最新」的方式。它不是 PaaS，也不是 Kubernetes 的替代品——它在更高抽象层编排编排者，接管 CI/CD 里的「CD」部分，并与 Terraform 等 IaC 工具协同。
0序章 · 为什么"部署"成了最难的事
先从一个被大多数"上云教程"忽略的真相说起。
普通 CI/CD 教程默认：你拥有目标环境。工程师写个流水线，把新版本 push 到自己的 Kubernetes 集群；出问题时开个终端进去修。这套逻辑在自家机房里没问题。
但 Palantir 的产品（Foundry / Gotham / AIP）运行在客户控制的环境里：客户的云、本地数据中心、气隙网络（无入站连接）、机密隔离区、舰船、边缘设备。供应商根本连不进去。给几百个这样的环境"手工发版"，不可能规模化——传统做法是给每个客户冻结一个版本，于是客户三年后还停留在老版本。
Apollo 干的事，就是把控制流反过来：不是从外面推，而是让每个环境里的 Agent 主动拉取声明式指令，按策略自行收敛到目标状态。这正是它能被安全团队接受的前提。下面几章，我们一步步拆开它。
提示：Apollo 是 Foundry 与 AIP 之下那层"持续交付"基座。
1一句话看懂 Apollo
官方定义 + 一个能立刻做对的小测。
“Apollo deploys, monitors, remediates, and secures your software across heterogeneous environments.”
—— Apollo 在异构环境中部署、监控、修复并保护你的软件。它把"部署"从一次性动作，变成持续的运行状态。
换个说法：Apollo 是企业的部署操作系统。它在多云、本地、私有 SaaS、气隙、边缘等任何环境里，用同一套工具把软件持续地交付并保持健康——你只管声明"想要什么状态"，剩下的升级、回滚、合规、漏洞扫描它都接管。
小测：下列哪句话最贴近 Apollo 的"拉取 / 声明式对账"模型？
记住：Apollo 不"执行一串步骤"，而是"不断把现实对账到声明"。
2三个核心思想：声明 · 约束 · 渐进
理解这三个词，就理解了 Apollo 为什么"稳"。点开看看每一条在解决什么。
📐
声明式状态
Declarative State
你描述"应该跑什么"：哪个产品、哪个版本/频道、什么配置、什么依赖。Apollo 用持续对账循环（reconciliation loop）把现实状态不断拉向这个描述——而不是执行一串假设起点正确的部署步骤。
🚧
约束
Constraints
每个环境自带规则：维护窗口、服务间依赖顺序、审批闸门、可升级的先后次序。Apollo 把这些都当作对账的约束——"能升级的地方就升级，不能的地方就等"，人不用盯一张复杂的矩阵。
🌊
渐进式交付
Progressive Delivery
版本按层级推进：内部 → 金丝雀(canary) → 大范围生产，每晋级一步都有健康信号把门。金丝雀里暴露的回归会在波及全局前被拦下，回滚是一次状态变更而非人工抢救。
这三点串起来就是：声明目标 → 受约束地对账 → 用渐进发布兜底风险。它们也解释了为什么 Apollo 不只是一个"高级 CD 工具"。
🕹️ 推 vs 拉：控制流反转
点下面两个按钮，直观感受 Apollo 为什么能部署到"连不进去"的环境。
小记忆法：说"想要什么"（声明）· 守"什么时候能动"（约束）· 分段"放出去看效果"（渐进）。
3Hub & Spoke：Apollo 的"神经系统"
Apollo 用 Hub（中枢）和 Spoke（辐条）管理整个软件舰队。我们用一个步进器，走一遍"一次升级是怎么闭环的"。
- Hub（中枢环境）：内含编排引擎（Orchestration Engine），掌握产品目录、向各 Spoke 下发 Plan、负责 Release 晋级。
- Spoke（辐条环境）：每个跑一个 Spoke 控制平面，内含 Agent——负责把观察到的状态（Reported State）回报给 Hub，并轮询、执行 Hub 下发的 Plan。
关键点：Hub 从不主动连进 Spoke；是 Spoke 的 Agent 自己来"要"Plan。这让气隙/机密网络也能被纳管——安全团队不必开任何入站隧道。
一句话：Hub 决定"发什么"，Spoke 的 Agent "拉去执行并回报"，闭环持续对账。
4Plans 与"约束闸门"
Apollo 里，任何变更都是一份 Plan（安装、改配置、升级、卸载、改密钥）。但它只在所有相关约束满足时才下发执行。亲手试试这个"闸门模拟器"。
① 维护窗口已开启
② 依赖服务已就绪
③ 审批闸门已通过
④ 当前 SLO 健康
Plan: 升级 Foundry → v2.3（订阅 Release Channel: stable）
切换左侧开关，再点"尝试下发"。
这正是 Apollo 相对"后台偷偷跑的控制循环"的区别：Plan 范式带来透明——谁、何时、改了什么，全程可追溯，天然就是审计证据。
任何一条约束不满足，Plan 就被"拦在门外"，等到条件满足才执行。
5Release Channels：让发布"分段试错"
版本不是一股脑推全量，而是沿 Release Channel 逐级晋级，靠健康信号把关。点"晋级"，再试试在金丝雀里"制造故障"。
内部
Internal
Internal
小范围
金丝雀
Canary
Canary
放量观察
生产
Production
Production
全量
当前版本位于：内部(Internal)。每晋级前需通过 SLO/soak 健康门槛。
如果金丝雀健康检查失败，编排引擎会自动召回（recall）该版本，让所有环境回退——把"一次事故"挡在波及全量之前。整个过程被记录，本身就是合规证据。
对比传统：回滚是"改一次状态"，不是人工救火。
6Run Anywhere：把你的软件舰队统一纳管
Apollo 在同一控制中心下，把形态各异的环境当作"一支舰队"来管。点下面每张环境卡，看它如何被纳入同一套发布流程。
已统一纳管：0 / 8 个环境
☁️
AWS
公有云
☁️
Azure
公有云
☁️
GCP
公有云
🏢
私有云
客户托管
🖥️
本地机房
On-Prem
🔀
混合云
Hybrid
🔒
气隙网络
Air-gapped
📡
边缘设备
Edge
特别看气隙网络：没有入站连接，传统推送根本到不了。Apollo 的拉取模型让环境内的 Agent 主动获取经签名校验的制品——安全团队不必开隧道。这正是"Beyond Limits"的含义。
它运行在应用层、基础设施之上，是可定制的"拿来即用"平台，接在 CI 之后。
7Apollo 如何托起 Foundry 与 AIP
把视野拉到整个 Palantir 体系，看清 Apollo 的位置——它是底座。
🤖 AIP · 生成式 AI 平台
安全的 LLM 连接、Agent 开发、Evals 治理
🗄️ Foundry · 数据运营平台
数据管理、逻辑编写、Ontology 开发、分析、工作流
🚀 Apollo · 持续交付（底座）
把上面两者部署、监控、修复、保护到任何异构环境，并持续保持版本收敛
换个角度：Foundry 和 AIP 是"产品"，Apollo 是它们"如何抵达你、并始终保持最新"的方式。一个在自家云或本地的 Foundry 客户，正被 Apollo 默默服务——可见的症状是"平台一直在演进，却从不需要专门立项去升级"。Apollo 也可独立卖给有同类"分布困境"的软件厂商。
它不是 PaaS、也不是 Kubernetes 的替代品：它在更高抽象层，编排编排者——把 K8s 当作执行引擎，接管 CI/CD 里的"CD"部分，换成持续对账模型；也和 Terraform 等 IaC 协同。
与前三课对照：AIP=AI 智能体平台，Foundry=数据运营平台，Ontology=语义与执行内核，而 Apollo=把它们送到任何角落的部署引擎。
8总复习：综合自测 + 术语速查
5 道题检验你是否真的懂了。提交后看得分。
📚 点击术语，看解释
Product产品
Release发行版
Release Channel发布频道
Environment环境
Hub中枢
Spoke辐条
Plan计划
Constraint约束
Agent代理
Entity实体
Orchestration Engine编排引擎
Day 2 Ops运营期运维
Maintenance Window维护窗口
SBOM软件物料清单
恭喜走到这里 🎉 你可以回看任意章节巩固。
关于 Palantir Apollo 的常见问题
以下问答可直接引用；答案整理自 Palantir 官方页面与平台文档。
- Palantir Apollo 是什么？
- Apollo 是 Palantir 产品体系的部署底座，官方定义是「在异构环境中部署、监控、修复并保护你的软件」。它把「部署」从一次性动作变成持续的运行状态：你只声明想要什么状态，剩下的升级、回滚、合规、漏洞扫描由它接管。
- Apollo 的「控制流反转」是什么意思？
- 普通 CI/CD 默认你拥有目标环境，于是从外部把新版本 push 进去。Apollo 把控制流反过来：不是从外面推，而是让每个环境里的 Agent 主动拉取声明式指令，按策略自行收敛到目标状态。这正是它能被安全团队接受、并能部署到「连不进去」的环境的前提。
- Apollo 的三个核心思想是什么？
- ① 声明式状态：你描述「应该跑什么」（哪个产品、哪个版本或频道、什么配置与依赖），Apollo 用持续对账循环（reconciliation loop）把现实状态不断拉向这个描述；② 约束：任何变更都是一份 Plan，只有在所有相关约束满足时才下发执行；③ 渐进：版本沿 Release Channel 逐级晋级，靠健康信号把关，而不是一股脑推全量。
- Hub & Spoke 架构如何工作？
- Hub（中枢环境）内含编排引擎（Orchestration Engine），掌握产品目录、向各 Spoke 下发 Plan、负责 Release 晋级；每个 Spoke（辐条环境）跑一个 Spoke 控制平面，内含 Agent，负责把观察到的实际状态回报给 Hub，并轮询、执行 Hub 下发的 Plan。两者配合形成一次升级的完整闭环。
- Apollo 的 Plan 和约束（Constraint）是什么？
- 在 Apollo 里，任何变更——安装、改配置、升级、卸载、改密钥——都是一份 Plan（计划）。但 Plan 只在所有相关约束满足时才会被下发执行，这个「约束闸门」是 Apollo 能安全地在生产环境持续变更的关键机制。
- Apollo 和 Kubernetes、Terraform、CI/CD 是什么关系？
- Apollo 不是 PaaS，也不是 Kubernetes 的替代品。它在更高的抽象层「编排编排者」——把 Kubernetes 当作执行引擎，接管 CI/CD 里的「CD」（持续交付）部分并换成持续对账模型，同时与 Terraform 等基础设施即代码（IaC）工具协同工作。
基于 palantir.com/platforms/apollo 及其官方文档整理 · 本页为教学用途，互动内容为非官方的通俗化解读 · 单文件、零依赖、可离线打开