写nginx.conf、docker-compose.yml、配环境变量——这些重复劳动占据了DevOps工程师大量时间。SwiftDeploy的做法是：你只需要写一份manifest.yaml，剩下的全部自动生成。
这份清单文件是唯一的真相来源。所有生成的配置文件都派生自它。修改清单，重新生成，整套基础设施配置保持一致更新。
核心技术是模板替换。作者创建了两套带占位符的模板：
templates/nginx.conf.tmpl → 包含{{NGINX_PORT}}、{{SERVICE_PORT}}
templates/docker-compose.yml.tmpl → 包含{{SERVICE_IMAGE}}、{{SERVICE_MODE}}
运行swiftdeploy init时，CLI读取清单，用sed将占位符替换为实际值：
sed -e "s|{{NGINX_PORT}}|8080|g" templates/nginx.conf.tmpl > nginx.conf
这意味着：没有硬编码；改清单、跑init，就能拿到全新配置；审查者可以删掉生成文件，重新init，验证一切可复现。
API用Go写成，单二进制文件编译后仅11.9MB。无运行时依赖，启动快，远低于300MB镜像限制。
部署或晋升前，SwiftDeploy会向OPA询问："这允许吗？"
OPA（Open Policy Agent，开放策略代理）是独立容器，基于Rego语言编写的规则做是/否决策。核心原则是：CLI本身不做决定，只询问OPA并呈现结果。
为何把决策隔离到OPA？
如果把阈值硬编码在CLI里：
if [ $DISK_GB -lt 10 ]; then exit 1; fi
改阈值就得改CLI代码、测试、重新部署。用OPA则只需编辑策略文件、重启OPA，CLI完全不用动。
基础设施策略示例：
package infrastructure
default allow := false
allow if {
input.disk_free_gb >= data.thresholds.min_disk_free_gb
input.cpu_load <= data.thresholds.max_cpu_load
阈值单独放在JSON文件里，不硬编码在Rego中。改thresholds.json、重启OPA，新限制立即生效。
金丝雀安全策略
晋升稳定版前，CLI抓取/metrics数据发给OPA：
package canary
allow if {
input.error_rate <= data.thresholds.max_error_rate
input.p99_latency_ms <= data.thresholds.max_p99_latency_ms
若错误率超1%或P99延迟超500ms，晋升被阻断，并返回明确提示。
API还暴露/chaos端点（仅金丝雀模式），用于模拟降级行为：
# 注入80%错误率
curl -X POST http://localhost:8080/chaos \
-d '{"mode": "error", "rate": 0.8'
热门跟贴