BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース HashiCorp Terraform AWSプロバイダーでAmazon S3バケットリソースに対する大きな変更

HashiCorp Terraform AWSプロバイダーでAmazon S3バケットリソースに対する大きな変更

ブックマーク

原文(投稿日:2022/02/13)へのリンク

HashiCorpは、Terraform AWSプロバイダーバージョン4.0のリリースを発表した。Amazon S3バケットリソースに非常に大きな変更が加えられている。このリリースでは、デフォルトリソースのライフサイクルの完全な制御ができ、プロバイダー構成が変更され、複数のデータソースの処理が改善されている。

このリリースでは、オーバーロードされたトップレベルリソースを削減するために、aws_s3_bucketリソースが大幅にリファクタリングされた。aws_s3_bucketリソースの引数と属性は非推奨になり、読み取り専用のcomputed引数に移行された。新たにaws_s3_bucket_*リソースが更新された。以前は、S3バケットでのサーバ側の暗号化の設定は次のように処理されていた。

resource "aws_s3_bucket" "example" {
  # ... other configuration ...
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        kms_master_key_id = aws_kms_key.mykey.arn
        sse_algorithm     = "aws:kms"
      }
    }
  }
}

バージョン4.0にアップグレードした後、上記のコードを実行しようとすると、server_side_encryption_configurationが読み取り専用であるというエラーが返される。以下に示すように、新しいaws_s3_bucket_server_side_encryption_configurationリソースを使用するように設定を更新する必要がある。

resource "aws_s3_bucket" "example" {
  # ... other configuration ...
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.mykey.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

新しいリソースに更新した後、データの損失を防ぐために、変更された各リソースでterraform importを実行することが推奨されている。

GitHubリポジトリに対してオープンとなっているこの問題が示すように、この更新はコミュニティによって手放しで歓迎されているわけではない。これは「aws_s3_bucketはTerraform AWSプロバイダーの次のメジャーリリース(5.0)まで維持される」ことを示すリリース投稿内の言葉に一部起因している。HashiCorpのコミュニティマネージャーであるJustin Rezolk氏によって明らかにされたように、バージョン4.0は、元の非推奨の属性をバージョン5.0まで読み取り専用に移行し、そのときに削除される可能性がある。彼は続けて次のように述べている。

これは、リリースに関するブログ投稿(私たちが取り組んでいること)には反映されていません。また、これはソフトウェアの世界で「非推奨」が意味することを必ずしも反映しているわけではないと認識しています。ここでの考え方は、これによって構成が壊れるのではなく、computed属性のドリフト検出がないということです。

一部のユーザは、新しいリソースに更新してterraform importを実行するという推奨されるアプローチでは、大量のS3バケットを使用する組織において規模を拡大できないと述べている。ユーザjoe-a-tは、「問題は、文字通り何百ものディレクトリでは、数千回という規模でこれらの指示に従う必要がある」と説明している

コミュニティからのフィードバックに基づいて、Terraform AWSプロバイダーチームは、顧客バケットの移行を支援できる移行ツールを検討している。Rezolk氏はアップグレードが適切に実行されるまで、暫定的にプロバイダーバージョンを4.0.0より前のバージョンに固定することを強く勧めている。

このリリースでは、リージョンごとのデフォルトVPCやアベイラビリティーゾーンごとのデフォルトサブネットなど、AWS内のデフォルトリソースの処理も改善されている。AWSは最近APIを更新しており、それによりこれらのデフォルトリソースで完全なCRUDライフサイクルができるようになった。これにより、デフォルトのリソースの作成と破棄をサポートするようにTerraformプロバイダーを更新できるようになった。

通常のTerraformリソースとは異なり、デフォルトのサブネットやVPCが、指定されたエリア内に存在する場合、Terraformはそれを作成をせずに管理を行う。さらに、terraform destroyではデフォルトのアイテムは削除されないが、代わりにTerraform状態からそれらが削除される。そうでなく、デフォルトのVPCまたはサブネットを削除する場合には、force_destroytrueに設定する必要がある。

このリリースでは、プロバイダーの設計原則との整合性を向上させるために、複数のデータソースが更新されている。4.0では、結果の配列を返すことが期待されるすべてのAWSプロバイダーの複数のデータソースは、結果がゼロの場合に空のリストを返すようになった。

他にも多くのプロバイダー構成に対する更新がある。FIPSエンドポイントの自動解決のサポートなどである。以前は、必要なすべてのFIPSエンドポイントを一覧化する必要があった。それはまだサポートされている一方で、利用可能なFIPSエンドポイントを基に自動解決するように設定することができる。

provider "aws" { 
  use_fips_endpoint = true 
}

リリースの詳細については、アップグレードガイド変更ログで確認できる。S3バケット管理を含むすべてのHashiCorp Learnコンテンツも更新され、新しいリソースが追加される予定である。

作者について

この記事に星をつける

おすすめ度
スタイル

BT