Terraform言語の静的解析 / static analysis of Terraform language

Lint Night #4 の発表資料です
https://lintnight.connpass.com/event/385142/

Transcript

1. Terraform言語の静的検査 @wata727
2. Terraform AWSやGoogle Cloudのリソースを*.tfファイルで宣言的に管理できる resource "aws_instance" "example" { ami = var.ami instance_type = "t3.micro" }
3. Terraform 不正な値を使った場合には...？ resource "aws_instance" "example" { ami = var.ami instance_type = "t1.2xlarge" # invalid type! }
4. Terraform aws_instance.example: Creating... │ Error: creating EC2 Instance: operation error EC2: RunInstances, ... │ │ with aws_instance.example, │ on main.tf line 17, in resource "aws_instance" "example": │ 17: resource "aws_instance" "example" { │
5. TFLint ― A Pluggable Terraform Linter • https://github.com/terraform-linters/tflint • *.tfファイルをパースして静的に問題を検出 • プラグインによって検査ルールを拡張可能
6. TFLint ― A Pluggable Terraform Linter $ tflint 1 issue(s) found: Error: "t1.2xlarge" is an invalid value as instance_type (aws_instance_invalid_type) on main.tf line 19: 19: instance_type = "t1.2xlarge" # invalid type!
7. 基本的なアプローチ • *.tfファイルのパーサーは公式パッケージとして提供されている ◦ https://github.com/hashicorp/hcl • hclparse.ParseHCLFileでhcl.Fileオブジェクトが手に入るため、file.Bodyからファ イルの中身を正確に取り出すことができる • この辺りの考え方は一般的なLinterと同じ
8. Terraform言語とHCL
9. Terraform言語とHCL • HCL ≠ Terraform言語 • Terraform言語はHCLの上に追加の意味論を持つ言語 • 例えば... ◦ resource blockがEC2インスタンスなどのリソースと対応付けられることは Terraform言語の仕様 ◦ resourceのようにブロックに名前とラベルを設定できるのはHCLの仕様 ◦ var.amiがvariable blockに定義された変数に解決されるのはTerraform言語 の仕様 ◦ var.amiのようにオブジェクトの属性を評価できるのはHCLの仕様
10. Terraform言語とHCL .tflint.hclはHCLだがTerraform言語ではない rule "aws_instance_invalid_type" { enabled = false }
11. HCL Syntax-Agnostic Information Model • HCLには構文に依存しない情報モデルが定義されており、複数の具象構文が実装 できるように抽象型と意味論が定義されている ◦ https://github.com/hashicorp/hcl/blob/v2.24.0/spec.md • よく知られるHCLと呼ばれる構文は正確にはHCL native syntaxと呼ばれる具象構 文のひとつ • TerraformがJSONでも書けるのはHCL JSON syntaxがHCLの具象構文のひとつ であるため
12. HCL JSON構文 { "resource": { "aws_instance": { "example": { "instance_type": "t2.micro", } } } }
13. HCL JSON構文 JSON構文にはブロック定義とオブジェクト属性の曖昧性がある # block foo { bar = "baz" } # object attribute foo = { bar = "baz" } # block or object attribute? { "foo": { "bar": "baz" } }
14. Schema-driven Processing • HCL JSONの曖昧性のために、HCLの構造にアクセスする主要な手段としてス キーマ駆動のアプローチがある • アプリケーションはスキーマをfile.Bodyに対して適用して、期待する構造を取り出 す
15. Schema-driven Processing ブロックスキーマの例 &hcl.BodySchema{ Blocks: []hcl.BlockSchema{ { Type: "resource", LabelNames: []string{"type", "name"}, }, }, }
16. 式の評価 Terraform言語ではvariable blockで変数を定義、利用できる resource "aws_instance" "example" { ami = var.ami instance_type = var.type # => t1.2xlarge }
17. go-cty • https://github.com/zclconf/go-cty • Go言語の上に実装された独自の型システム • 未知の値やマーク付き値、リファインメントなど特徴的な表現ができる • Terraform言語の型システムはgo-ctyで実装されている
18. 未知の値をどう扱うか？ applyするまでわからない値をどう評価するか？ resource "aws_subnet" "my_subnet" { vpc_id = aws_vpc.my_vpc.id # => ? }
19. Unknown Value • go-ctyではStringやNumberといったプリミティブ型の表現に加えて、値が未知であ ることを表現する仕組みがある ◦ cty.StringVal(“one”) ◦ cty.NumberIntVal(3) ◦ cty.UnknownVal(cty.String) • 未知の値は演算を通して伝染する ◦ 例えば、3 + unknown = unknownになる
20. TerraformにおけるUnknown Value • applyするまでわからない値はunknownとして解決される • terraform plan時に出てくる(known after apply)の正体はunknown value Terraform will perform the following actions: # aws_instance.example will be created + resource "aws_instance" "example" { + ami = "ami-0e467ee8344baec9e" + arn = (known after apply)
21. Value Refinements • go-ctyでは未知の値に追加の制約を与えることができる ◦ cty.UnknownVal(cty.Number).NumberUpperBound(2) • 自明なケースで未知の値に解決されてしまうのを防ぐ ◦ 例えば <unknown expr> ? 1 : 2 のような式は明らかに2より大きくならないが、 unknownが伝染して制約が失われてしまう • v1.18の時点ではNotNullやStringPrefix, CollectionLengthUpperBoundなどの Refinementsがサポートされている
22. TFLintでの応用
23. 式の評価 • 多くのLinterでは、副作用や停止性の問題を避けるために式を完全に評価しないこ とが多い • Terraform言語では... ◦ 宣言的であり、式の評価順に依存しない ◦ 無限ループや再帰が書けない ◦ 慣習的に複数回dry-runで評価される • これらの性質からTFLintにおける式の評価はほぼ安全
24. 式の評価 • go-ctyのunknown valueの仕組みに乗っかり、簡単に解決できない値を未知の値 として扱っている ◦ デフォルト値の無い必須変数 ◦ データソースの属性 ◦ モジュールの出力 ◦ プロバイダ定義関数の返り値 • Terraform言語の型システムの上で実現できているため、保守性が高い
25. Terraform言語セマンティクスの実装 • HCLはTerraform言語のセマンティクスをカバーしない • そのため、TFLintでは内部で独自実装している ◦ 評価コンテキストの初期化 ◦ for_each, count, dynamic blocksの展開 ◦ ビルトイン関数 ◦ 式中のアドレスのパース
26. Terraform言語セマンティクスの実装 • TFLintにおける初期実装は相当雑だった ◦ 式のパースを正規表現でやっていた(！) • 当然うまくいかなかったのでTerraformの内部実装をライブラリとして再利用して互 換性を向上させた • Terraformの方針転換によって、パッケージがライブラリとして利用できなくなったた め、forkしてLinter向けにインターフェイスを整えた
27. Schema-driven Processing • Terraform同様にスキーマベースで*.tfファイルを処理する • TFLint本体では厳密なスキーマを要求せず、各ルールが必要な最低限のスキーマ を定義して本体に問い合わせる • Terraformのバージョンアップによる新しいブロックやメタ属性の追加に対して堅牢 になり、より多くのバージョンのTerraformをサポートできる
28. おまけ
29. TerraformでDeep Mergeをどう書くか？ • 再帰が書けない = オブジェクトのDeep Mergeを素直に実装できない • Deep Mergeを行うTerraform moduleが存在する(？) ◦ https://github.com/Invicton-Labs/terraform-null-deepmerge
30. TerraformでDeep Mergeをどう書くか？ 3743行のローカル変数を組み合わせて深さ100までのDeep Mergeを実現
31. TerraformでDeep Mergeをどう書くか？ • 大量のローカル変数を都度評価するため、TFLintがハングするバグ ◦ https://github.com/terraform-linters/tflint/issues/2287 • 一度解決したローカル変数をキャッシュして解決 ◦ https://github.com/terraform-linters/tflint/pull/2301
32. 参考文献 • https://developer.hashicorp.com/terraform/language/syntax • https://github.com/hashicorp/hcl/blob/v2.24.0/spec.md • https://github.com/hashicorp/hcl/blob/v2.24.0/hclsyntax/spec.md • https://github.com/hashicorp/hcl/blob/v2.24.0/json/spec.md • https://log.martinatkins.me/2021/06/14/terraform-plan-unknown-values/ • https://github.com/zclconf/go-cty/blob/v1.18.0/docs/concepts.md • https://github.com/zclconf/go-cty/blob/v1.18.0/docs/marks.md • https://github.com/zclconf/go-cty/blob/v1.18.0/docs/refinements.md • https://github.com/hashicorp/hcl/pull/590 • https://github.com/hashicorp/terraform/pull/33234