我正在使用 Terraform 將代碼部署到我的 Azure 基礎架構中。
我有一個帶有一些網路規則的 Azure 防火墻,其中有一堆自由文本 IP 地址作為源/目標。下面是一個例子;[請注意,為了本示例,實際 IP 地址已更改];
網路規則集合
network_rule_collection {
name = "test_rules"
priority = 400
action = "Allow"
rule {
name = "test-rule-1"
protocols = ["Any"]
source_addresses = ["123.0.2.10/32"]
destination_ports = ["1234"]
destination_addresses = ["124.82.189.200/32","125,82.189.200/32","126..82.189.200/32"]
}
}
}
[注意IP地址有錯誤是為了證明]
但是,當我運行 Terraform Validate 時,它??沒有顯示錯誤(即使上面輸入了無效的 IP 地址)
所以我需要一種方法來驗證自由文本 IP 地址,作為 Terraform 驗證/計劃的一部分。目前,Terraform 接受這一點并將無效 IP 部署到基礎設施中。
uj5u.com熱心網友回復:
根據檔案,Validate 將驗證語法,而不是值。
Validate 運行檢查以驗證配置在語法上是否有效
一種選擇是定義變數并使用正則運算式添加自定義驗證規則。參考
variable "ip_address" {
type = string
description = "Example to validate IP address."
validation {
condition = can(regex("^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$",var.ip_address))
error_message = "Invalid IP address provided."
}
}
uj5u.com熱心網友回復:
您可以將 IP 地址定義為變數并使用驗證規則:
https://www.terraform.io/language/values/variables#custom-validation-rules
除了如上所述的型別約束之外,模塊作者還可以使用嵌套在相應變數塊中的驗證塊為特定變數指定任意自定義驗證規則:
然后使用正則運算式來驗證給定的 IP 地址看看這個媒體博客以獲得靈感https://ishusinghkanwar.medium.com/variable-validation-in-terraform-a9c887d987ff
uj5u.com熱心網友回復:
由于您要填充的引數被定義為采用 CIDR 塊地址,原則上提供者可以驗證這些,但在這種特殊情況下它似乎沒有自己的驗證規則,因此它依賴于遠程 API 的驗證因此只會在應用步驟中生效。
可能值得在提供商的 GitHub 存盤庫中打開一個問題來討論在此處添加內置驗證的可能性,但為了這個答案,我假設這是不可能的,并討論如何在自己的配置中定義驗證規則.
將這些值直接硬編碼在資源配置中,沒有辦法進行自定義驗證,因為resource塊的內容(除了一些特殊的引數,如countand for_each)完全由相應的提供者負責。
但是,如果您打算撰寫一個共享 Terraform 模塊,將這些 IP 地址作為輸入變數,然后從資源配置中參考它們,您可以撰寫自定義驗證規則來描述額外的約束,這些約束必須為真才能獲得特定值該變數被認為是有效的。
塊中的condition引數validation需要一個布林值,即true如果條件成立并且false條件不滿足。但是,由于 Terraform 也有許多內置函式,如果不滿足它們自己的驗證規則,這些函式被定義為失敗并出現錯誤,因此 Terraform 還有一個特殊can函式,可以在將失敗轉換為的特殊背景關系中評估運算式結果false,任何成功都轉化為true結果,從而滿足condition論證的期望。
然后,一個典型的策略是識別一個現有的 Terraform 函式,該函式具有您要應用的相同驗證規則,并在內部呼叫該值can以使用其成功或失敗作為驗證條件。
特別是對于 CIDR 塊地址,Terraform 具有少量函式,它們將這些作為輸入并生成派生的 CIDR 塊地址或 IP 地址。例如,cidrnetmask采用 IPv4 CIDR 塊地址并以網路掩碼表示法回傳相同的地址。如果給定的字串不是有效的 IPv4 CIDR 塊,它將失敗,因此它似乎是描述您要在此處檢查的規則的好候選:
variable "source_address" {
type = string
validation {
condition = can(cidrnetmask(var.source_address))
error_message = "Must be a valid IPv4 CIDR block address."
}
}
您在此處的示例有接受多個地址的額外要求,因此需要稍微復雜的驗證規則來測驗條件是否適用于給定集合的所有成員,這就是該alltrue函式的用途:
variable "source_addresses" {
type = set(string)
validation {
condition = alltrue([
for a in var.source_addresses : can(cidrnetmask(a))
])
error_message = "All elements must be valid IPv4 CIDR block addresses."
}
}
The [ for ... ] expression here is producing a list of boolean results from trying can(cidrnetmask(a)) for each element a of the set. alltrue then interprets that result and returns a single true only if every element of the list is true.
In order for these rules to apply, you'll need to pass the potentially-invalid IP addresses through these input variables, instead of providing them directly inside the resource block as in your example. That only really makes sense if you are intending to write a reusable module where callers will be providing different IP addresses for each instance. If you intend to have just a fixed set of IP addresses anyway, it'd be simpler to just make sure they are valid when you initially specify them and trust that they'll therefore stay valid in future unless changed.
轉載請註明出處,本文鏈接:https://www.uj5u.com/qianduan/426225.html
標籤:天蓝色 变量 天蓝色的devops 地形
上一篇:如何在api(asp.netapi)中驗證通過spa(react應用程式)從azureadb2c獲得的訪問令牌?
