跳转到内容
多云网络

部署演示环境

前置条件

Section titled “前置条件”
  • Terraform，版本不低于 terraform/versions.tf 中的下限 —— >= 1.8，以支持 provider 定义的函数以及用于守护 VIP 的 check 块。
  • xcsh provider。 没有任何地方锁定版本：.terraform.lock.hcl 已被 gitignore， 且约束仅是一个开放式下限，因此每次 init 都会解析出最新发布的版本。这对预发布项目是 有意为之的 —— 演示环境应当在 provider 回归时直接失败，而不是停留在掩盖问题的陈旧版本上。
  • 一个 F5 XC API 凭据，对应 var.expected_xc_tenant 中的租户，导出为 XCSH_API_TOKEN（或 P12/PEM 对）。只导出凭据，绝不要导出 URL —— 见下文。
  • Azure 凭据，具备创建资源组、VNet、Route Server 和 VM 的权限。
  • 一个已存在的 F5 XC 命名空间，用于应用层。部署只会读取它，绝不创建或销毁它， 因此承载着无关演示的命名空间绝不会出现在该 stack 的销毁清单中。

提供两个没有默认值的取值

Section titled “提供两个没有默认值的取值”

其他每个变量都有一个可用的默认值，且每个对象名称都派生自 var.component。 有两个变量被有意留空：

Terminal window
cd terraform
cp terraform.tfvars.example terraform.tfvars
变量为何没有默认值
origin_ip任何默认值都指向某台特定机器。一个过时的值会把新部署的流量发送到别人的主机上，而不是直接失败。
lb_domain负载均衡器基于 Host 匹配，因此这是每个请求都必须发送的值。它归运行该部署的人所有。

两者都有格式校验，因此拼写错误会让 plan 失败，而不是让演示失败。

terraform.tfvars 已被 gitignore，并且必须保持这样：它携带了订阅 ID 和 各工程师专属的取值。

租户来自配置，而不是你的 shell 正在导出的内容

Section titled “租户来自配置，而不是你的 shell 正在导出的内容”

var.expected_xc_tenant 指定租户，并且是唯一指定它的地方。 providers.tf 由它派生出 xcsh provider 的 api_url，这会有意覆盖环境中任何 XCSH_API_URL；而 terraform/main.tf 中的一个 postcondition 会在环境指向不同租户时 让 plan 失败。

在不运行任何改变状态的操作的前提下读取两侧的值：

Terminal window
terraform output -raw xc_tenant       # what the deployment targets
terraform output -raw xc_env_tenant   # what your shell claims — diagnostic only
f5-sales-demo
f5-sales-demo

执行 apply

Section titled “执行 apply”

  1. 初始化。 backend 配置未提交到仓库；请提供你自己的。

    Terminal window
    terraform init -backend-config=backend.hcl

  2. 首次 apply。 这会构建 Azure、CE 站点和注册令牌，并启动 CE。

    Terminal window
    terraform apply

  3. 在 CE 完成注册后再次 apply。 这不是可选步骤，原因在下文说明， 而不是留给你自己去发现。

    Terminal window
    terraform apply

然后在向任何人展示之前，先前往验证其健康状态。

注册审批已自动化，而 apply 仍然是两阶段的

Section titled “注册审批已自动化，而 apply 仍然是两阶段的”

注册审批不再需要有人在控制台操作：xcsh_registration_approval 资源会执行它， 而站点模块会解析出应当审批哪个注册。

但这仍然不能让该部署变成一次无人干预的 apply，其原因值得在你观察首次运行并断定它失败 之前先行理解：

  • CE 的注册对象命名为 r-<uuid>。它绝不会以站点命名，因此在 plan 阶段无法预测该名称。
  • 注册对象只有在 VM 启动且 vpm 完成注册之后才存在。
  • 因此首次 apply 根本不会规划任何审批。在 CE 完成注册后重新 apply， 审批便会被创建。

terraform/main.tf 在文件开头记录了这一顺序，那是权威版本 —— 部署顺序与实现它的代码 放在一起。

运维人员 SSH 是构建期的决定

Section titled “运维人员 SSH 是构建期的决定”

该部署会向设备的 admin 账户写入一个运维密钥，该账户的登录 shell 是 Site CLI。 它由 cloud-init 的 write_files 写入，而后者只在首次启动时运行一次。

拆除部署

Section titled “拆除部署”
Terminal window
terraform destroy

应用命名空间会保留：它只被读取，从不被管理，因此 destroy 不会连带删除承载着无关演示的 命名空间。资源组中的其他一切都会被移除。