🥇Terraform の落とし穴 | プロホスター

ループ、if ステートメント、デプロイメント手法に関連する落とし穴や、Terraform 全般に影響を与えるより一般的な問題など、いくつかの落とし穴に焦点を当ててみましょう。

count パラメータと for_each パラメータには制限があります。
ダウンタイムゼロの導入を制限する。
たとえ良い計画であっても失敗する可能性はあります。
リファクタリングには落とし穴がある可能性があります。
遅延された一貫性は、遅延と一致します。

count および for_each パラメータには制限があります

この章の例では、ループと条件ロジックで count パラメーターと for_each 式を広範囲に使用しています。パフォーマンスは良好ですが、注意しなければならない重要な制限が XNUMX つあります。

Count と for_each はリソース出力変数を参照できません。
count と for_each はモジュール構成では使用できません。

count と for_each はリソース出力変数を参照できません

複数の EC2 サーバーをデプロイする必要があるが、何らかの理由で ASG を使用したくないと想像してください。コードは次のようになります。

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

一つずつ見ていきましょう。

count パラメータは静的な値に設定されているため、このコードは問題なく動作します。apply コマンドを実行すると、2 つの EC2 サーバーが作成されます。しかし、現在の AWS リージョン内の各アベイラビリティーゾーン (AZ) に XNUMX つのサーバーをデプロイしたい場合はどうすればよいでしょうか? コードで aws_availability_zones データソースからゾーンのリストをロードし、各ゾーンをループし、count パラメーターと配列インデックスアクセスを使用してその中に ECXNUMX サーバーを作成できます。

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

count パラメーターは問題なくデータソースを参照できるため、このコードも正常に機能します。しかし、作成する必要があるサーバーの数がリソースの出力に依存する場合はどうなるでしょうか? これを示す最も簡単な方法は、random_integer リソースを使用することです。これは、名前が示すように、ランダムな整数を返します。

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

このコードは 1 から 3 までの乱数を生成します。このリソースの出力を aws_instance リソースの count パラメーターで使用しようとするとどうなるかを見てみましょう。

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

このコードで terraform plan を実行すると、次のエラーが発生します。

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

Terraform では、リソースが作成または変更される前の計画段階で count と for_each を計算する必要があります。これは、count と for_each はリテラル、変数、データソース、さらにはリソースリスト (スケジュール時に長さを決定できる限り) を参照できるが、計算されたリソース出力変数は参照できないことを意味します。

count と for_each はモジュール構成では使用できません

いつか、モジュール構成に count パラメーターを追加したくなるかもしれません。

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

このコードは、モジュール内で count を使用して、webserver-cluster リソースのコピーを 0 つ作成しようとします。または、count パラメーターを XNUMX に設定して、ブール条件に基づいてモジュールの接続をオプションにすることもできます。これは合理的なコードのように見えるかもしれませんが、terraform plan を実行すると次のエラーが発生します。

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

残念ながら、Terraform 0.12.6 の時点では、モジュールリソースでの count または for_each の使用はサポートされていません。 Terraform 0.12 リリースノート (http://bit.ly/3257bv4) によると、HashiCorp は将来この機能を追加する予定であるため、この本を読んだ時期によっては、すでに利用可能になっている可能性があります。確実に調べるには、ここでTerraformの変更ログを読んでください.

ゼロダウンタイム展開の制限事項

create_before_destroy ブロックを ASG と組み合わせて使用することは、ダウンタイムをゼロにデプロイするための優れたソリューションです。ただし、自動スケーリングルールはサポートされていないという XNUMX つの注意点があります。より正確に言えば、これにより、デプロイごとに ASG サイズが min_size にリセットされます。これは、自動スケーリングルールを使用して実行中のサーバーの数を増やしている場合に問題になる可能性があります。

たとえば、webserver-cluster モジュールには aws_autoscaling_schedule リソースのペアが含まれており、午前 9 時にクラスター内のサーバーの数が 11 台から 9 台に増加します。たとえば午前 XNUMX 時にデプロイすると、新しい ASG は XNUMX 台ではなく XNUMX 台のサーバーで起動し、翌日の午前 XNUMX 時までそのままの状態になります。

この制限はいくつかの方法で回避できます。

aws_autoscaling_schedule の繰り返しパラメータを 0 9 * * * (「午前 9 時に実行」) から 0-59 9-17 * * * (「午前 9 時から午後 5 時まで毎分実行」) のような値に変更します。 ASG にすでに XNUMX 台のサーバーがある場合、この自動スケーリングルールを再度実行しても何も変更されません。これが望ましいことです。ただし、ASG が最近デプロイされたばかりの場合、このルールにより、最大 XNUMX 分以内にサーバーの数が XNUMX に達することが保証されます。これは完全にエレガントなアプローチではなく、XNUMX 台のサーバーから XNUMX 台のサーバーへの大幅な変更やその逆もユーザーに問題を引き起こす可能性があります。
AWS API を使用して ASG 内のアクティブなサーバーの数を決定するカスタムスクリプトを作成し、外部データソースを使用してそれを呼び出し (249 ページの「外部データソース」を参照)、ASG のdesired_capacity パラメータを、によって返される値に設定します。スクリプト。こうすることで、新しい ASG インスタンスは常に既存の Terraform コードと同じ容量で実行されるため、保守がより困難になります。

もちろん、Terraform にはダウンタイムなしのデプロイメントのサポートが組み込まれていることが理想的ですが、2019 年 XNUMX 月の時点で、HashiCorp チームにはこの機能を追加する計画はありませんでした (詳細 - ここ).

正しい計画が実行されない可能性がある

plan コマンドは完全に正しいデプロイメントプランを生成しても、apply コマンドがエラーを返す場合があります。たとえば、第 2 章で作成した IAM ユーザーに使用したのと同じ名前で aws_iam_user リソースを追加してみます。

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

ここで plan コマンドを実行すると、Terraform は一見妥当なデプロイメントプランを出力します。

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

Plan: 1 to add, 0 to change, 0 to destroy.

apply コマンドを実行すると、次のエラーが表示されます。

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

もちろん、問題は、その名前の IAM ユーザーがすでに存在していることです。そして、これは IAM ユーザーだけでなく、ほぼすべてのリソースで発生する可能性があります。誰かがこのリソースを手動またはコマンドラインを使用して作成した可能性がありますが、いずれにせよ、ID が一致すると競合が発生します。このエラーにはさまざまなバリエーションがあり、Terraform を初めて使用する人を驚かせることがよくあります。

重要な点は、terraform plan コマンドは、Terraform 状態ファイルで指定されているリソースのみを考慮するということです。リソースが他の方法 (たとえば、AWS コンソール内で手動でクリックするなど) で作成された場合、リソースは状態ファイルに保存されないため、Terraform は plan コマンドを実行するときにそれらを考慮しません。その結果、一見正しいように見える計画が失敗に終わることもあります。

このことから学べることが XNUMX つあります。

すでに Terraform の使用を開始している場合は、他のものを使用しないでください。インフラストラクチャの一部が Terraform を使用して管理されている場合、手動で変更することはできなくなります。そうしないと、Terraform で奇妙なエラーが発生する危険があるだけでなく、コードがインフラストラクチャを正確に表現できなくなるため、IaC の利点の多くが無効になります。
すでにインフラストラクチャがある場合は、import コマンドを使用します。既存のインフラストラクチャで Terraform の使用を開始する場合は、terraform import コマンドを使用して状態ファイルに追加できます。このようにして、Terraform はどのインフラストラクチャを管理する必要があるかを認識します。 import コマンドは 2 つの引数を取ります。 190 つ目は、構成ファイル内のリソースアドレスです。ここでの構文はリソースリンクの場合と同じです: _。 (aws_iam_user.existing_user など)。 22 番目の引数は、インポートするリソースの ID です。リソース ID aws_iam_user がユーザー名 (yevgeniy.brikman など)、リソース ID aws_instance が EC5 サーバー ID (i-XNUMXeXNUMXeXNUMX など) であるとします。リソースのインポート方法は通常、ページの下部にあるドキュメントに示されています。
以下は、第 2 章で Terraform 構成に追加した aws_iam_user リソースと IAM ユーザーを同期するインポートコマンドです (もちろん、yevgeniy.brikman は自分の名前に置き換えてください)。
```
$ terraform import aws_iam_user.existing_user yevgeniy.brikman
```
Terraform は AWS API を呼び出して IAM ユーザーを検索し、そのユーザーと Terraform 設定内の aws_iam_user.existing_user リソースとの間に状態ファイルの関連付けを作成します。今後、plan コマンドを実行すると、Terraform は IAM ユーザーがすでに存在することを認識し、再度作成しようとしなくなります。

Terraform にインポートしたいリソースがすでにたくさんある場合、コードを手動で記述して一度に 4 つずつインポートするのは面倒な場合があることに注意してください。したがって、AWS アカウントからコードと状態を自動的にインポートできる Terraforming (http://terraforming.dtanXNUMX.net/) のようなツールを検討する価値があります。

リファクタリングには落とし穴がある可能性がある

リファクタリング これは、外部の動作を変更せずに、コードの内部構造を変更するプログラミングの一般的な手法です。これは、コードをより明確、整然とし、保守しやすくするためです。リファクタリングは定期的に使用する必要のある不可欠なテクニックです。しかし、Terraform やその他の IaC ツールに関しては、コード部分の「外部動作」が何を意味するかについて細心の注意を払う必要があり、そうしないと、予期しない問題が発生します。

たとえば、一般的なタイプのリファクタリングは、変数または関数の名前をよりわかりやすい名前に置き換えることです。多くの IDE にはリファクタリングのサポートが組み込まれており、プロジェクト全体で変数や関数の名前を自動的に変更できます。汎用プログラミング言語では、これは考えもしないような些細な手順ですが、Terraform ではこれに細心の注意を払う必要があり、そうしないと機能停止が発生する可能性があります。

たとえば、webserver-cluster モジュールには入力変数 cluster_name があります。
```
variable "cluster_name" {
   description = "The name to use for all the cluster resources"
   type          = string
}
```
このモジュールを使用して foo というマイクロサービスをデプロイし始めたと想像してください。後で、サービスの名前を bar に変更したいとします。この変更は些細なことのように思えるかもしれませんが、実際にはサービスの中断を引き起こす可能性があります。

実際には、webserver-cluster モジュールは、XNUMX つのセキュリティグループと ALB の name パラメーターを含む、いくつかのリソースでクラスター名変数を使用します。
```
resource "aws_lb" "example" {
   name                    = var.cluster_name
   load_balancer_type = "application"
   subnets = data.aws_subnet_ids.default.ids
   security_groups      = [aws_security_group.alb.id]
}
```
リソースの name パラメーターを変更すると、Terraform はそのリソースの古いバージョンを削除し、代わりに新しいバージョンを作成します。ただし、そのリソースが ALB である場合、そのリソースを削除してから新しいバージョンをダウンロードするまでの間に、トラフィックを Web サーバーにリダイレクトするメカニズムがありません。同様に、セキュリティグループが削除されると、サーバーは新しいグループが作成されるまでネットワークトラフィックを拒否し始めます。

興味があるかもしれない別のタイプのリファクタリングは、Terraform ID の変更です。例として、webserver-cluster モジュールの aws_security_group リソースを見てみましょう。
```
resource "aws_security_group" "instance" {
  # (...)
}
```
このリソースの識別子をインスタンスと呼びます。リファクタリング中に、よりわかりやすい (あなたの意見では) 名前「cluster_instance」に変更することにしたと想像してください。
```
resource "aws_security_group" "cluster_instance" {
   # (...)
}
```
結局何が起こるのでしょうか？そうです、混乱です。

Terraform は、各リソース ID をクラウドプロバイダー ID に関連付けます。たとえば、iam_user は AWS IAM ユーザー ID に関連付けられ、aws_instance は AWS EC2 サーバー ID に関連付けられます。リソース ID を変更すると (aws_security_group の場合のように、インスタンスからクラスターインスタンスに)、Terraform に変更すると、古いリソースを削除して新しいリソースを追加したかのように表示されます。これらの変更を適用すると、Terraform は古いセキュリティグループを削除して新しいセキュリティグループを作成し、サーバーはネットワークトラフィックを拒否し始めます。

この議論から得られる重要な教訓を XNUMX つ挙げます。
- 常に plan コマンドを使用してください。これらすべての障害を明らかにすることができます。出力を注意深く確認し、Terraform が削除すべきでないリソースの削除を計画している状況に注意してください。
- 削除する前に作成してください。リソースを置き換える場合は、元のリソースを削除する前に、代替リソースを作成する必要があるかどうかを慎重に検討してください。答えが「はい」の場合は、create_before_destroy が役に立ちます。同じ結果は、XNUMX つの手順を実行することによって手動で実現できます。まず、新しいリソースを構成に追加して apply コマンドを実行し、次に古いリソースを構成から削除して、apply コマンドを再度使用します。
- 識別子を変更するには、状態を変更する必要があります。リソースを削除して新しいバージョンを作成せずに、リソースに関連付けられた ID を変更する (たとえば、aws_security_group の名前をインスタンスからクラスターインスタンスに変更する) 場合は、それに応じて Terraform 状態ファイルを更新する必要があります。これは決して手動で行わないでください。代わりに terraform state コマンドを使用してください。識別子の名前を変更する場合は、次の構文を持つ terraform state mv コマンドを実行する必要があります。
```
terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>
```
  ORIGINAL_REFERENCE は現在の形式でリソースを参照する式で、NEW_REFERENCE は移動先の場所です。たとえば、aws_security_group グループの名前をinstanceからcluster_instanceに変更する場合は、次のコマンドを実行する必要があります。
```
$ terraform state mv 
   aws_security_group.instance 
   aws_security_group.cluster_instance
```
  これにより、以前に aws_security_group.instance に関連付けられていた状態が、今後は aws_security_group.cluster_instance に関連付けられる必要があることが Terraform に伝えられます。名前を変更してこのコマンドを実行した後、terraform plan に何も変更が表示されない場合は、すべてが正しく行われたことになります。
- 一部の設定は変更できません。多くのリソースのパラメータは変更できません。それらを変更しようとすると、Terraform は古いリソースを削除し、代わりに新しいリソースを作成します。通常、各リソースページには、特定の設定を変更したときに何が起こるかが示されているため、必ずドキュメントを確認してください。常に plan コマンドを使用し、create_before_destroy 戦略の使用を検討してください。
遅延された一貫性は一貫性があります...遅延あり

AWS などの一部のクラウドプロバイダーの API は非同期であり、一貫性が遅延しています。非同期とは、要求されたアクションが完了するのを待たずに、インターフェイスがすぐに応答を返すことができることを意味します。遅延一貫性とは、変更がシステム全体に反映されるまでに時間がかかる可能性があることを意味します。この処理が行われている間、応答は一貫性がなく、どのデータソースレプリカが API 呼び出しに応答しているかに依存する可能性があります。

たとえば、AWS に対して EC2 サーバーの作成を要求する API 呼び出しを行うと想像してください。 API は、サーバー自体が作成されるのを待たずに、ほぼ即座に「成功」応答 (201 Created) を返します。すぐに接続しようとすると、その時点では AWS がまだリソースを初期化中であるか、サーバーがまだ起動していないため、ほぼ確実に失敗します。さらに、このサーバーに関する情報を取得するために別の呼び出しを行うと、エラー (404 Not Found) が発生する可能性があります。問題は、この EC2 サーバーに関する情報がどこでも利用できるようになるまでに、AWS 全体に伝播される可能性があり、数秒待つ必要があるということです。

遅延整合性を備えた非同期 API を使用する場合は、アクションが完了してシステム全体に伝播されるまで、定期的にリクエストを再試行する必要があります。残念ながら、AWS SDK にはこれに適したツールが提供されておらず、Terraform プロジェクトは 6813 (https://github.com/bashicorp/terraform/issues/6813) のような多くのバグに悩まされていました。
```
$ terraform apply
aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
The subnet ID 'subnet-xxxxxxx' does not exist
```
つまり、リソース (サブネットなど) を作成し、それに関する情報 (新しく作成されたサブネットの ID など) を取得しようとしましたが、Terraform はそれを見つけることができません。これらのバグ (6813 を含む) のほとんどは修正されていますが、特に Terraform が新しいリソースタイプのサポートを追加した場合には、依然として時折発生します。これは面倒ですが、ほとんどの場合、害はありません。 terraform apply を再度実行すると、この時点で情報がすでにシステム全体に広がっているため、すべてが機能するはずです。

この抜粋はエフゲニー・ブリクマンの本からのものです「Terraform: コードレベルのインフラストラクチャ」.

出所： habr.com

Terraform の落とし穴

count および for_each パラメータには制限があります

count と for_each はリソース出力変数を参照できません

count と for_each はモジュール構成では使用できません

ゼロダウンタイム展開の制限事項

正しい計画が実行されない可能性がある

リファクタリングには落とし穴がある可能性がある

遅延された一貫性は一貫性があります...遅延あり

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル