複数の AWS Lambda のエラーを CloudWatch Alarms で検知できるように Terraform で定義する

1.この記事を書こうと思った背景 複数の AWS Lambda に CloudWatch Alarms で監視しよう!ということがあったので、 Terraform で以下のように dimensions で監視したい Lambda を列挙するだけだろ!と思いきや、ダメだった。 apply すると、最後に書いた FunctionName のみがCloudWatch Alarms に適用されてしまった。(以下の場合、my_lambda_function2 ) resource "aws_cloudwatch_metric_alarm" "this" { metric_name = "Errors" namespace = "AWS/Lambda" dimensions = { "FunctionName" = "my_lambda_function1", "FunctionName" = "my_lambda_function2" } #略 } ※ FunctionName に * をつけても「*_lambda_function」などとベタ書きとして認識されてしまってダメ。正規表現っぽく指定することは出来なかった。 dimensions = { "FunctionName" = "*_lambda_function", } さて、じゃあどうしようか?と調べたことを書き留めておく。 なお、上記の dimensions は以下を参考に指定した。 Choose a dimension. By Function Name (FunctionName) – View aggregate metrics for all versions and aliases of a function. ...

May 30, 2022 · 5 min · gkzz

[Changes to S3 Bucket Drift Detection] Terraform AWS Provider 4.9の aws_s3_bucket リソースにおけるアップデート内容

1.この記事を書こうと思った背景 これまで、Terraform AWS Provider のバージョンを3.7系から4.x系に引き上げようとすると以下のissueで取り上げられているような、 aws_s3_bucket resourceでエラーとなっていた。 S3 bucket issue: Can’t configure a value for “versioning” #23125 このエラーは、Terraformの以下のガイドに記載されているとおり、aws_s3_bucket resourceの大規模な仕様変更が入ったことに起因する。 Version 4.0.0 of the AWS Provider introduces significant changes to the aws_s3_bucket resource. See S3 Bucket Refactor for more details. 出所:Terraform AWS Provider Version 4 Upgrade Guide ところが、AWS Provider 4.9に引き上げるとエラー判定とされなくなっていた、、!? v4.0のリリース内容もびっくりだが、これもびっくりなので筆を執ることにした。 AWS Provivder 4.9.0の CHANGELOG 2.AWS Provider 4.9に引き上げるとエラー判定ではなくWARNING判定となる これまでの4.x系では aws_s3_bucket resource で3.7系までの書きっぷりをすると、エラーとしてきた 一方、4.9系ではWARNINGは出れどresourceは作ってくれた。それと明示的に修正が必要な箇所を指摘してくれる!! ※ WARNINGが出ていて大丈夫なんですか? という点については分かっていない。Terraform が指摘してくれた箇所の修正をしたほうがいいことは間違いないだろう。(今後のアップグレードによっては、またエラー扱いとなるというこもありうる) 修正方法はこれまでの4.x系への引き上げ時におこなわれている方法と同じであり、自分の場合の修正箇所を書いておく。 3.AWS Provider 4.9へバージョンを引き上げるまでのエラー対応(自分の場合) 冒頭で取り上げたエラーや4.9で確認された WARNING を回避するためには、左記の issue の コメント に記載されているとおり、aws_s3_bucket resource にすべて詰め込むのではなく、設定したい内容に応じて別に resource を定義する必要がある。 ...

April 9, 2022 · 6 min · gkzz

asdf で kubectl のバージョンを切り替えながら asdf とそのプラグインの設定方法を理解する

1.この記事で達成したいこと asdfとそのプラグインを設定する方法が頭の中でごちゃごちゃしていた。たとえば、、。 asdf plugin-addとasdf installはどっちからコマンド実行するの? 既にプラグインはをインストールしているか?確認するのはどうやるの? そこで実際に以下のasdfのプラグインを使いながら、その設定方法を理解したい kubectl asdf-community/asdf-kubectl: Kubectl plugin for the asdf version manager 2.はじめに そもそもasdfとはなにか?という説明は公式ドキュメントに譲りたいが、ひとことでいえば バージョン管理ツール である バージョン管理の類似ツールを挙げるとすれば、pythonのvirtualenvはそのひとつであろう。相違点はバージョン管理の対象がひとつだけか複数か。(virtualenvの場合はpythonのみのひとつだけ。) asdfでバージョンを管理するためには、asdf自体のインストールすることに加えて、バージョン管理したいツールに対応したプラグインもインストールする必要 がある 3.環境情報 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ asdf --version v0.10.0-0f99d0a 4.asdf自体のインストール asdfのドキュメントに従って進めればよいが、そのインストール方法はいくつかある 今回採用した方法はasdfのリポジトリのブランチを指定してクローンするという方法 指定したリリースブランチは、release-v0.10.0 $ git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch release-v0.10.0 $ tail ~/.bashrc 略 . $HOME/.asdf/asdf.sh . $HOME/.asdf/completions/asdf.bash これでasdfのインストールは終わった。いよいよプラグインのインストールに移るが、ややこしく感じたので大まかな流れをおさえておきたい。 5.バージョン管理したいプラグインのインストールと設定の大まかな流れ 必要になったプラグインあるいはそのバージョンが既にあるか確認 $ asdf plugin list | grep <プラグイン> プラグインがなければ追加 $ asdf plugin-add <プラグイン> <リポジトリ> 任意のバージョンをインストール $ asdf install <プラグイン> <バージョン> asdf global/localで導入 $ asdf local <プラグイン> <バージョン> 導入したプラグインとそのバージョンが書かれていることを確認 $ asdf current $ cat .tool-versions (不要なバージョンはuninstall) $ asdf uninstall <プラグイン> <バージョン> 参考:https://asdf-vm.com/guide/getting-started.html#install-the-plugin ...

January 13, 2022 · 2 min · gkzz

sensitve=true な値を terraform output で確認する方法

1.この記事で達成したいこと sensitve=trueな値をterraform outputで確認したい 1-1.お悩みポイント そもそもsensitve=trueとしている理由は、terraform applyやterraform outputする際にはCLI(ターミナル)上では出力させたくないから なので、terraform applyやterraform outputする際には表示されないのが正しい! とはいえ、確認したいときはある。さて、どうするか、、??? $ terraform output aws_iam_smtp_password_v4 = <sensitive> sensitive=trueの技術的仕様はterraform.tfstateに記載されている値のうち、出力させないそれらを指定するというもの なので以下のように確認することはできるが、チョット煩わしい。シュッとやりたい。 $ cat terraform.tfstate | jq -r .outputs { "aws_iam_smtp_password_v4": { "value": "xxxxxxxxxxxxxxxxxxxxxx", "type": "string", "sensitive": true } } このような都合のいい、「ワガママ」な事情をよしなに汲み取ってterraform outputで確認するというのが本記事の目的 2.前提 Terraformのインストール方法を始めとする初期設定は終えているものとして話を進める 今回出力したくないセキュアな値は ses_smtp_password_v4 とする サンプルコードは以下のとおり $ cat main.tf resource "aws_iam_user" "dummy" { name = "dummy" path = "/dummy/" } resource "aws_iam_access_key" "dummy" { user = aws_iam_user.dummy.name } output "aws_iam_smtp_password_v4" { value = aws_iam_access_key.dummy.ses_smtp_password_v4 sensitive = true } 3.環境情報 Terraform実行環境 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ terraform version Terraform v1.1.0 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v3.70.0 4.sensitive=trueとしてterraform applyするとマスクされることを確認 $ terraform apply Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # aws_iam_access_key.dummy will be created + resource "aws_iam_access_key" "dummy" { + create_date = (known after apply) + encrypted_secret = (known after apply) + encrypted_ses_smtp_password_v4 = (known after apply) + id = (known after apply) + key_fingerprint = (known after apply) + secret = (sensitive value) + ses_smtp_password_v4 = (sensitive value) + status = "Active" + user = "dummy" } # aws_iam_user.dummy will be created + resource "aws_iam_user" "dummy" { + arn = (known after apply) + force_destroy = false + id = (known after apply) + name = "dummy" + path = "/dummy/" + tags_all = (known after apply) + unique_id = (known after apply) } Plan: 2 to add, 0 to change, 0 to destroy. Changes to Outputs: + aws_iam_smtp_password_v4 = (sensitive value) Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes 略 Apply complete! Resources: 2 added, 0 changed, 0 destroyed. Outputs: aws_iam_smtp_password_v4 = <sensitive> # <-- マスクされている!(これでいいんだけど実際ちゃんと入っているか確認したい!!) 4-1.terraform outputコマンドを実行すると・・・(再掲) sensitve=trueと指定しているのでマスクされている $ terraform output aws_iam_smtp_password_v4 = <sensitive> 5.sensitve=trueな値をシュッと確認する(cat terraform.tfstateしない) terraform outputコマンドに -json オプションを付与すればok $ terraform output -json { "aws_iam_smtp_password_v4": { "sensitive": true, "type": "string", "value": "xxxxxxxxxxxxxxxxxxxxxx" } } もちろんjqで加工することもできる $ terraform output -json | \ > jq -r '.aws_iam_smtp_password_v4 | { aws_iam_smtp_password_v4: .value }' { "aws_iam_smtp_password_v4": "xxxxxxxxxxxxxxxxxxxxxx" } もっとシンプルにterraform output -jsonの結果を絞る方法として、terraform output -json ${KEY} もある ${KEY}はoutputで指定しているもの $ terraform output -json aws_iam_smtp_password_v4 "xxxxxxxxxxxxxxxxxxxxxx $ grep output main.tf output "aws_iam_smtp_password_v4" { 6.参考 sensitive=trueな値を出力させる方法について Note: When using the -json or -raw command-line flag, any sensitive values in Terraform state will be displayed in plain text. ...

January 7, 2022 · 2 min · gkzz

【InvalidParameterValue: The same permission must not appear multiple times】aws_security_group リソースを terraform apply したときのエラーの原因と解決策

1.この記事で達成したいこと aws_security_groupリソースを使って複数のインバウンドルールを追加しようとして引いたエラーを解決する $ terraform apply 略 │ Error: error updating Security Group (sg-000000000000): error authorizing Security Group (ingress) rules: InvalidParameterValue: The same permission must not appear multiple times │ status code: 400, request id: 000000000000000000 │ │ with aws_security_group.dummy-sg, │ on main.tf line 23, in resource "aws_security_group" "dummy-sg": │ 23: resource "aws_security_group" "dummy-sg" { エラーメッセージが指す23行目付近で書いていること $ view main.tf 略 23 resource "aws_security_group" "dummy-sg" { 24 name = "dummy-sg" 25 description = "dummy security group" 26 vpc_id = aws_vpc.dummy-vpc.id 27 28 ingress { 29 description = "Allow 80 from anywhere for redirection" 30 from_port = 80 31 to_port = 80 32 protocol = "all" 33 cidr_blocks = ["0.0.0.0/0"] 34 } 35 36 ingress { 37 description = "Allow 8080 from anywhere for redirection" 38 from_port = 8080 39 to_port = 8080 40 protocol = "all" 41 cidr_blocks = ["0.0.0.0/0"] 42 } 2.前提 Terraformのインストール方法を始めとする初期設定は終えているものとして話を進める 3.環境情報 Terraform実行環境 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ terraform version Terraform v1.1.0 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v3.70.0 ※ terraform applyで使う要件については、後述するaws_security_groupリソースくらい。なので、ここでは割愛。 ...

January 4, 2022 · 3 min · gkzz