あーあ、今日も、疲れた。気がついたら20時なんだもん、ひっでぇな。 そして本来やるべきことの、半分もできていない。雑用の波が押し寄せる。言いたいことは多々あるが、ぶちまけ大会するわけにはいかない。このモヤモヤを一体どうしたらいいのか。 ま、でも今日も上手い寿司が食えたからな。寿司だ。寿司が今のオレのプライドを支えてるんだ。

今日のTerraform loopネタはLambda関数作成。ログ監視の一貫なので、CloudWatchLogsのロググループとサブスクリプションフィルタ作成も一緒にやる。 この例でのディレクトリ構成は以下の通り。lambda/upload配下のzipファイルはTerraformにより生成されたもので、初回は空である。 work_dir ├── config.tf #初期化ファイル ├── lambda │ ├── code │ │ ├── func001 │ │ │ └── lambda-func001.py │ │ ├── func002 │ │ │ └── lambda-func002.py │ │ └── func003 │ │ └── lambda-func003.py │ └── upload │ ├── lambda-func001.zip │ ├── lambda-func002.zip │ └── lambda-func003.zip ├── lambda.auto.tfvars ├── lambda_cwl.tf ├── terraform.tfvars #regionのみ定義 └── variables.tf 最初に、すべて定数で記述したパターン。 lambda_logs.tf（定数バージョン） ################################################# # Lambda archive data ################################################# data "archive_file" "data-lambda-func001" { type = "zip" source_dir = "lambda/code/func001" output_path = "lambda/upload/lambda-func001....

過去記事Terraform loop処理の応用編(2)で、AWS Code兄弟のリソースをTerraformのloop処理で作成した。それとは別に、CodePipelineのトリガーをEventBridgeルールにしたかったので追加処理を書いた。パイプラインの数だけ対応するルールを作成するため、これもloop処理で書く。Code兄弟の分も含めて全て同じtfファイルにまとめてもよいが、ここでは分割している。 以下tfコード本体に、ルールとターゲットを作成する処理を書く。 event_rule.tf ######################################## # EventBridge rule ######################################## resource "aws_cloudwatch_event_rule" "pln-rule" { for_each = var.events_param_list name = lookup(each.value, "name") description = "Start the pipeline when detect CodeCommit repository state change." event_pattern = <<-EOT { "source": ["aws.codecommit"], "detail-type": ["CodeCommit Repository State Change"], "resources": ["arn:aws:codecommit:ap-northeast-1:012345678910:${lookup(each.value, "repo_name")}"], "detail": { "event": ["referenceCreated", "referenceUpdated"], "referenceType": ["branch"], "referenceName" : ["master"] } } EOT } ######################################## # EventBridge target ######################################## resource "aws_cloudwatch_event_target" "pln-rule" { for_each = var....

“SNS"は"Social Networking Service"の略だ。この言葉の上では、プラットフォーム自体がサービスなのだ。しかし、そこに参加した途端に、自分自身が他者にサービスせざるを得なくなる。俗に言う、フォロバとかいいね返しとか、そういうことだ。 そういうのは嫌いだ、しかしそこに参加している限り、鍵垢でもない限り、その渦から完全に逃れることはできない、この、人付き合いが嫌いな俺様であってもだ、しかし嫌いなものは嫌いなんだ、反応に対していちいち反応してたら自分のやりたいことができないし、余計にエネルギーを使うことになる。つまり、反応した相手の投稿をチェックするという作業自体が余剰作業なのだ、他人にサービスするためにやってるんじゃないからね。 これは、SNSの面倒で嫌いな部分だが、いいこともある、「反応に対する反応」により、センスがいいナイスなアカウントを発見することも多々あるからだ。tumblrの場合、ナイスなポストがあればreblogするし、この人は光る何かを持っている、とピピっときたらフォローせざるを得ない。相手が素晴らしいセンスの持ち主だと、サービスを通り越して夢中になってしまうこともある。 でも最近疲れてきたな、夢中になりすぎて疲れたのか、疲れたから夢中になれなくなったのか知らんが、あまり楽しくない。結局「お付き合い」の比重が多くなると、本来の目的からずれてしまうんだ、リアルワールドでやることのプライオリティが上がっているせいもあるな。 しかしよく考えると、SNSとの付き合いなんてそれくらいか、それより低程度がいいのである、本来は。リアルワールドで重要なことが多いほど、SNSにかまけていられる時間やエネルギーは減る。つまり、「あんまり楽しくない」程度に捉えている方が自然なのである。 そういう意味では、俺もやっと自然に戻れたんだろうか。

前回投稿Terraform loop処理の応用編 の続き。CodeDeployを作成するTerraformコードに、CodeCommit, CodePipelineを追加して通して作ってみる。 cicd.tf #################################### # CodeCommit #################################### resource "aws_codecommit_repository" "codecommit_repos" { for_each = var.codecommit_param_list repository_name = lookup(each.value, "repository_name") description = lookup(each.value, "description") } #################################### # CodeDeploy Application #################################### resource "aws_codedeploy_app" "codedeploy" { for_each = var.deploy_param_list name = lookup(each.value, "name") compute_platform = "Server" } #################################### # CodeDeploy Deployment Group #################################### resource "aws_codedeploy_deployment_group" "codedeploy_grp" { for_each = var.deploy_param_list app_name = lookup(each.value, "name") deployment_group_name = lookup(each.value, "deployment_group_name") depends_on = [aws_codedeploy_app.codedeploy] service_role_arn = var....

過去記事Terraform loop処理の超シンプルな例 の続き。loopで作成したTerraformリソースの参照方法を検証したらやはりハマったので記録書いておく。 前回はCodeCommitリポジトリを作成したが、今回はそれ抜きでCodeDeployのリソースを作成した。CodeDeployは (1)アプリケーションと、(2)デプロイメントグループの2つのリソースを作成する。(2)は(1)に依存している。 作業ディレクトリ構成 work_dir ├── cicd.auto.tfvars ├── cicd.tf ├── config.tf #初期化用config ├── terraform.tfvars #regionのみ定義 └── variables.tf cicd.tf （リソース作成用コード） #################################### # CodeDeploy Application #################################### resource "aws_codedeploy_app" "codedeploy" { for_each = var.deploy_param_list name = lookup(each.value, "name") compute_platform = "Server" } #################################### # CodeDeploy Deployment Group #################################### resource "aws_codedeploy_deployment_group" "codedeploy_grp" { for_each = var.deploy_param_list app_name = lookup(each.value, "name") deployment_group_name = lookup(each.value, "deployment_group_name") service_role_arn = var.deploy_role deployment_config_name = "CodeDeployDefault.AllAtOnce" ec2_tag_set { ec2_tag_filter { key = "Name" type = "KEY_AND_VALUE" value = lookup(each....

過去記事からの派生案件で、Terraformで使うtfvarsファイルについて、繰り返しデータを多数投入する想定のため、これを自動生成したいと考えた。 Terraform loop処理の超シンプルな例 Python - Jinja2テンプレートで連続データを処理したい 実際に使用するファイル群は過去記事に記載しているがこんな想定で。（もちろん実際は他にもいろいろ必要）自動生成したいのは、以下の*印をつけたcodecommit.auto.tfvarsである。（この時点では手動で値を記述したもの） work_dir/ ├── codecommit.auto.tfvars * ├── codecommit.tf ├── config.tf ├── terraform.tfvars ├── variables.tf └── vpc.tf これとは別に、tfvars自動生成作業用ディレクトリの作業前はこの状態。以下3つのファイルを用意する。codecommit.tmplはテンプレートとなる。このファイル名はスクリプトから呼び出すので名称に注意。対象のAWSリソースによって変えるが、tfファイルの名称に合わせておけばよい。 script_dir/ ├── codecommit.tmpl ├── create_vars.py └── data.csv codecommit.tmpl param{{ num }} = { repository_name = "{{ repo_name }}" description = "{{ des }}" } data.csv （今回の例ではヘッダーありの前提） num,repo_name,des 1,"my-repo001","my-repo001の説明" 2,"my-repo002","my-repo002の説明" 3,"my-repo003","my-repo003の説明" create_vars.py import sys import pandas as pd from jinja2 import Environment, FileSystemLoader def main(): # テンプレート読み込み env = Environment(loader=FileSystemLoader('....