Caputchin
自动化

使用 Terraform 或 OpenTofu

官方的 Caputchin 提供方让你把账户作为基础设施即代码来管理:在 .tf 文件里声明团队、站点密钥、安全策略、成员和令牌,并像任何其他资源那样应用它们。它就是 自动化 下其余一切所用的同一个管理 API,表达为 Terraform 资源。

它发布一次,并从同一份源 同时在 Terraform 和 OpenTofu 上工作;HCL 完全相同,只有 CLI 二进制(terraformtofu)和 registry 不同。下面所有地方,用你所跑的那一个。

铸造一个访问令牌

提供方从 CAPUTCHIN_MANAGEMENT_TOKEN 环境变量读它的令牌(推荐,好让它待在源码之外)。两种令牌都能用(见 API 认证):一个 个人访问令牌 用于全账户的基础设施,或一个限定到你配置所管理的那些团队上的 团队访问令牌

export CAPUTCHIN_MANAGEMENT_TOKEN=cpt_pat_...

有一个先有鸡还是先有蛋的情况:提供方也能 铸造 令牌(caputchin_account_tokencaputchin_troop_pat 资源),但它首先就需要一个令牌来做身份验证。在仪表盘里手动铸造第一个,然后让 Terraform 管理其余的。

配置提供方

terraform {
  required_providers {
    caputchin = {
      source  = "caputchin/caputchin"
      version = "~> 0.1"
    }
  }
}

# Token from CAPUTCHIN_MANAGEMENT_TOKEN; endpoint defaults to https://caputchin.com/api.
provider "caputchin" {}

同一个 source = "caputchin/caputchin" 从 Terraform Registry 和 OpenTofu Registry 都能解析,所以在任一工具下这一段都一样。

一个完整示例:一个带设了关卡的站点密钥的团队

这会创建一个团队、一个在它里面的站点密钥,并给那个密钥打开游戏关卡:

resource "caputchin_troop" "shop" {
  name = "shop-team"
}

resource "caputchin_site_key" "shop_frontend" {
  name     = "shop-frontend"
  troop_id = caputchin_troop.shop.id
}

resource "caputchin_site_security_settings" "shop_frontend" {
  site_id      = caputchin_site_key.shop_frontend.id
  require_game = true
}

# The public key is an attribute; the secret is sensitive, in state only.
output "shop_site_key" {
  value = caputchin_site_key.shop_frontend.key
}

然后,用任一工具:

terraform init && terraform apply
# or
tofu init && tofu apply

这个站点密钥的 secret 是一个敏感的计算属性;从 state 里读它(terraform output)来配置你的 后端验证。在 Apex 上,每次 apply 都归到你的令牌名下、记在 审计日志 里,于是一次通过 Terraform 的更改和一次仪表盘编辑一样可追溯。

你能管理什么

资源覆盖和仪表盘同样的面:团队及其成员和令牌、站点密钥、安全设置、托管验证、游戏与白标自定义,以及账户令牌。数据源让你把现有的团队、站点、账户信息和统计读进一份配置里。

完整参考

每个资源和数据源,带它所有的参数和属性以及导入语法,都在提供方的 registry 页上。它是从提供方源生成的,所以它精确地跟踪已发布的版本:

  • Terraform Registry:registry.terraform.io/providers/caputchin/caputchin
  • OpenTofu Registry:search.opentofu.org/provider/caputchin/caputchin

每个资源所执行的底层操作,见 交互式 API 参考

另见

本页内容