這個11.9MB的小工具，讓DevOps告別手寫配置文件

　　寫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'