5

是否有一种有效的方法将验证逻辑应用于 terraform 运行中使用的变量？具体来说，我想检查一些变量的长度和大小写。这些变量是在 tfvars 文件和 variables.tf 文件中声明的变量的组合，并在运行时由 terraform 收集。

谢谢。

4

3 回答 3

2

自定义验证规则

结果

失败案例

provider aws {
     profile="default"
}
terraform {
  experiments = [variable_validation]
}

## Custom Validation Rules
variable "test" {
  type        = string
  description = "Example to test the case and length of the variable"
  default = "TEsT"

  validation {
    condition     = length(var.test) > 4 && upper(var.test) == var.test
    error_message = "Validation condition of the test variable did not meet."
  }
}

执行

$ terraform plan

Warning: Experimental feature "variable_validation" is active

  on main.tf line 5, in terraform:
   5:   experiments = [variable_validation]

Experimental features are subject to breaking changes in future minor or patch
releases, based on feedback.

If you have feedback on the design of this feature, please open a GitHub issue
to discuss it.


Error: Invalid value for variable   # <---------------------------

  on main.tf line 9:
   9: variable "test" {

Validation condition of the test variable did not meet.

This was checked by the validation rule at main.tf:14,3-13.

通行证

terraform {
  experiments = [variable_validation]
}

## Custom Validation Rules
variable "test" {
  type        = string
  description = "Example to test the case and length of the variable"
  default = "TESTED"

  validation {
    condition     = length(var.test) > 4 && upper(var.test) == var.test
    error_message = "Validation condition of the test variable did not meet."
  }
}

执行

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.


------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

其他

或者，使用 null_resource local-exec 在 shell 脚本中实现逻辑，或者使用外部提供程序将变量发送到外部程序进行验证？

于 2020-02-26T23:37:51.673 回答
1

这不是您目前可以直接使用 Terraform 执行的操作，但我发现在必要时将输入变量更改为所需格式更容易。

例如，aws_lb_target_group资源采用当前要求将其大写的protocol参数aws_lb_listener，而不是像资源对协议（甚至protocol在health_check块中）所做的那样自动大写并抑制差异。

为了解决这个问题，我只在创建资源时使用该upper函数：

variable "protocol" {
  default = "http"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_lb_target_group" "test" {
  name     = "tf-example-lb-tg"
  port     = 80
  protocol = "${upper(var.protocol)}"
  vpc_id   = "${aws_vpc.main.id}"
}

至于检查长度，我只是对事物进行子串化以使它们具有正确的长度。我目前为 ALB 执行此操作，因为名称的最大长度为 32，并且我让 Gitlab CI 为某些服务创建审查环境，这些服务根据 Git 分支名称的 slug 获得名称，因此几乎无法控制所使用的长度。

variable "environment" {}
variable "service_name" {}

variable "internal" {
  default = true
}

resource "aws_lb" "load_balancer" {
  name            = "${substr(var.environment, 0, min(length(var.environment), 27 - length(var.service_name)))}-${var.service_name}-${var.internal ? "int" : "ext"}"
  internal        = "${var.internal}"
  security_groups = ["${aws_security_group.load_balancer.id}"]
  subnets         = ["${data.aws_subnet_ids.selected.ids}"]
}

有了以上内容，环境或服务名称长度的任何组合都将导致环境/服务名称对最多修剪为 27 个字符，从而为我要指定的额外字符留出空间。

于 2018-05-03T08:27:50.603 回答
0

受到这次对话的启发，发现了以下已经存在的提供商： https ://github.com/craigmonson/terraform-provider-validate

于 2020-04-16T12:32:11.520 回答