くりにっき

フルスタックキュアエンジニアです

AWSのTerraformでDynamoDB state lockingからS3-native state lockingに移行する

前置き

先日Terraform 1.10がリリースされました。

www.hashicorp.com

github.com

Experimentalではありますが個人的には Introduce S3-native state locking (Terraform実行時のロックでDynamoDBが不要になる)がアツイ機能で、いち早く使いたいと思っていました。

github.com

しかし、軽くググった感じ移行ガイド的なものが見つからなかったので手順をまとめました。(英語版は末尾にあります)

手順

Terraformのbackendを書き換える

backendで dynamodb_table を指定してる箇所を use_lockfile *1 に書き換えます。

 terraform {
   backend "s3" {
-    dynamodb_table = "terraform-lock"
+    use_lockfile = true
   }
 }

Terraformで使ってるIAMユーザやIAMロールがterraform.tfstate.tflockにアクセスできるようにする

S3-native state lockingはBackendで利用しているS3バケットのtflockファイルへの s3:PutObject が必要になります。

例えば下記のようなkeyの場合、末尾に .tflock を付与した terraform.tfstate.tflock にも権限が必要です。*2

terraform {
  backend "s3" {
    key = "terraform.tfstate"
  }
}

そのため、下記のように変更が必要です。(TerraformがAmazonS3FullAccessを持っている場合には不要)

Before

{
  "Action": [
    "s3:GetObject",
    "s3:PutObject",
    "s3:DeleteObject"
  ],
  "Resource": "arn:aws:s3:::YOUR-BACKEND-BUCKET-NAME/terraform.tfstate",
  "Effect": "Allow"
},

After

{
  "Action": [
    "s3:GetObject",
    "s3:PutObject",
    "s3:DeleteObject"
  ],
  "Resource": [
    "arn:aws:s3:::YOUR-BACKEND-BUCKET-NAME/terraform.tfstate",
    "arn:aws:s3:::YOUR-BACKEND-BUCKET-NAME/terraform.tfstate.tflock"
  ],
  "Effect": "Allow"
},

一応

"Resource": "arn:aws:s3:::YOUR-BACKEND-BUCKET-NAME/terraform.tfstate*"

みたいなこともできるとは思いますが、AWSでは 最小特権アクセス許可を適用する のをベストプラクティスに挙げているので .tflock だけに権限を追加するのがいいと思っています。

https://github.com/sue445/terraform-aws-template/blob/main/cloud_formation/setup-terraform.yml のようにTerraform実行に必要なリソースをCloudFormationでセットアップしてるのであればその時に使ったテンプレートファイルを編集して再実行するのが一番楽だと思います。

この時点でTerraform実行時にDynamoDBが不要になっているはずなのでTerraformを実行する

問題なければTerraform実行用のDynamoDBのテーブルと、そのテーブルへの権限を消す

小規模利用のAWSアカウントであればTerraform実行用のDynamoDBがアカウント全体の費用のそれなりの割合を占めているはずなので、この時点で消していいでしょう。

中規模以降のAWSアカウントであればTerraform実行用のDynamoDBの費用の割合なんて微々たるものなので消しても消さなくてもどっちでもいいと思います。

あとがき1

僕がメンテしてる https://github.com/sue445/terraform-aws-template でもS3-native state lockingに移行したのですが*3、terraform-aws-templateの利用者のための移行手順は下記に書いています。

github.com

あとがき2

自分のリポジトリでは https://github.com/hashicorp/terraform/pull/35661 だけを見て移行したので気づかなかったんですが、 https://developer.hashicorp.com/terraform/language/backend/s3 にはS3-native state lockingに利用するtflockオブジェクトに対する権限が含まれていなかったので追記するPRを出してます。(マージ済)

github.com

Go 1.23でgo.modにtoolchainを書かなくてよくなった

tl;dr;

タイトルが全て

~Go 1.20

go.modに

go 1.20

のようにマイナーバージョンまで書いていてもDependabotでエラーが起きませんでした。

Go 1.21~1.22

go 1.21

のようにマイナーバージョンまで書いていた場合、Dependabotでエラーになります。

この問題を回避するには下記のようにtoolchainでパッチバージョンまで書く必要がありました。

go 1.21
toolchain go1.21.0

詳しくは下記を参照。

github.com

Go 1.23~

下記のようにgoでパッチバージョンだけ書く&toolchainが無い状態でも Dependabotがエラーにならなくなりました!(Go 1.20までと同じ挙動)

go 1.23

詳しくは下記を参照。

github.com

Go 1.23といえばrange-over func*1 が目玉機能だと思いますがtoolchainが不要になったのも地味に嬉しいやつです

create-merge-requestを作った

これ何?

GitLab CI上で行った変更をMerge Requestとして投げるためのツールです。(開発期間は1週間くらい)

gitlab.com

GitHub Actionsだと peter-evans/create-pull-request が便利でよく使っているのですが、同じようなことをGitLab CIでもやりたくて作りました。

サンプル

一番簡単なサンプルはこれ。

stages:
  - build

create_mr_for_changes:
  stage: build
  
  image: debian:stable-slim

  before_script:
    # Download and install latest create-merge-request
    - apt-get update
    - apt-get install -y curl
    - VERSION=$(curl -s --fail https://gitlab.com/sue445/create-merge-request/-/raw/main/VERSION?ref_type=heads)
    - pushd /tmp
    - curl --retry 3 -L -o create-merge-request.tar.gz https://gitlab.com/sue445/create-merge-request/-/releases/${VERSION}/downloads/create-merge-request_Linux_x86_64.tar.gz
    - tar xzvf create-merge-request.tar.gz
    - mv create-merge-request /usr/local/bin
    - popd

  script:
    # TODO: Add your changes
    - date > now.txt

    # Create Merge Request if repo is changed
    - create-merge-request

  rules:
    # Run only scheduled pipeline
    # ref. https://docs.gitlab.com/ee/ci/pipelines/schedules.html
    - if: $CI_PIPELINE_SOURCE == "schedule"

このサンプルでは実行時にnow.txtを更新して、その差分をMerge Requestとして投げています。

頑張りポイント

gitコマンドを使わずにgitリポジトリにアクセスした

create-merge-requestはGoで作りスタンドアローンバイナリとして配布しています。

しかしスタンドアローンバイナリとして配布しているツールが実行環境にインストールされているgitコマンドに依存していると真のスタンドアローンとはいえないため、 https://github.com/go-git/go-git というGo実装のgitを利用して実行環境にgitがインストールされていなくても使えるようにしました。(システムにインストールされているgitコマンドを使うとgitのバージョンが変わった時に振る舞いが変わると面倒なので内部に組み込んだ方が依存を管理しやすいという嬉しさもある)

可能な限りパラメータを省略できるようにした

下記のhelpを見てもらえれば分かりますが、GitLabのリポジトリに新しいcommitをpushしてMerge Requestを投げるだけでも下記のパラメータが登場します。

REQUIRED PARAMETERS:
   --gitlab-api-endpoint value  GitLab API Endpoint (e.g. https://gitlab.com/api/v4) [$GITLAB_API_ENDPOINT, $CI_API_V4_URL]
   --gitlab-access-token value  GitLab access token [$GITLAB_ACCESS_TOKEN]
   --gitlab-project value       GitLab Project Path (e.g. gitlab-org/gitlab) [$GITLAB_PROJECT, $CI_PROJECT_PATH]

OPTIONAL PARAMETERS:
   --author-email value                     author email for commit (default: create-merge-request@example.com)
   --author-name value                      author name for commit (default: create-merge-request)
   --commit-message value, -m value         commit message (default: [create-merge-request] automated change)
   --source-branch value                    Merge Request branch name (default: create-merge-request/patch)
   --source-branch-suffix value             Merge Request branch name suffix (none,random,timestamp,short-commit-hash) (default: none)
   --target-branch value                    Send Merge Request to this branch (e.g. main, master) (default: main) [$CI_DEFAULT_BRANCH]
   --title value, -t value                  Merge Request title (default: Changes by create-merge-request)
   --description value                      Merge Request description (default: Automated changes by [create-merge-request](https://gitlab.com/sue445/create-merge-request))
   --labels value [ --labels value ]        Merge Request labels
   --assignees value [ --assignees value ]  Merge Request assignees (e.g. user1,user2)
   --reviewers value [ --reviewers value ]  Merge Request reviewers (e.g. user1,user2)

しかし初手で大量にパラメータを設定させるのは大変です。

GitLab CIでは $CI_API_V4_URL$CI_PROJECT_PATH などの環境変数が自動で用意されているため、可能な限りそれらから設定を読み込むようにしました。

それによりGitLab CIで実行する時には GITLAB_ACCESS_TOKEN でGitLabのアクセストークンだけ設定されていればとりあえずMerge Requestが作成できるようにしました。

おまけ

GoのバイナリをGitLabのリポジトリのreleasesに添付する時に https://github.com/goreleaser/goreleaser を利用したのですが、GitLab CI用の設定が現在のGitLabではDeprecatedなものだったのでパッチを投げました。

github.com

terraform-version-updaterを作った

これ何?

https://github.com/tfutils/tfenv で使われる .terraform-version を自動でバージョンアップするためのツールです。(制作期間2日)

github.com

最初の構想

最初は https://github.com/minamijoyo/tfupdate にパッチを送ろうと思っていました。

しかしtfupdateはHCL形式のファイルを扱うことに特化しているため、.terraform-versionのようなプレーンテキストを対応させるのは難しそうな気がしたので別物として作ることにしました。 (できないことはないのだが、結構広範囲に改修する必要がありそうだったり、自分の書いたコードがツールの既存コードとは明らかに異質なものになりそうなので尻込みした)

GitHub Actionsで動かす

DependabotだとTerraformのproviderを自動バージョンアップできますが、Terraformの本体のバージョンは自動バージョンアップできません。

そのためGitHub Actionsでterraform-version-updaterを定期実行することにより、Dependabotのような感じで自動バージョンアップができるようになります

実際に使ったworkflowファイルはリポジトリのREADMEに貼っています。

https://github.com/sue445/terraform-version-updater?tab=readme-ov-file#github-actions-example

feed_squeezerを作った

これなに?

RSSフィードを任意のキーワードで絞り込んだ結果をさらに別のフィードとして返すためのproxy的なウェブアプリです。

github.com

モチベーション

僕はSlackで色々なRSSフィードを購読しています。

YouTubeのチャンネルにもRSSフィードが存在しているのでSlackで購読しています。

例えば 東映アニメーション公式YouTubeチャンネル - YouTube にはプリキュアをはじめとして様々な動画が公開されています。その中でプリキュアに関係する動画だけをSlackで購読したいってことがよくあるため作りました。

2〜3年前くらいに作って個人Slack内でほそぼそと運用していたのですが、OSS化する機運が高まったのでOSS化しました。

2024/06/21 19:59 追記

個人slackだとこういうクエリでfeedをsubscribeしています

使った技術

  • Go
  • Bootstrap
  • Vue.js

工夫ポイント

配布形式をどうするか

Webサービスとして公開するのも考えたのですが、色んなところで使われだすとGoogle Cloudの個人アカウントのCloud RunやCloud Functionsの無料枠が一瞬で吹き飛びそうな気がしたのでDockerイメージやバイナリでの配布にしています。

ちなみにこの画面はローカルで動かしているのを撮影したのでlocalhostになってますが、実際はSlackbotからアクセスできる場所に置く必要があるので自分の好きな場所にDockerイメージやバイナリを動かして利用してください。

僕のおすすめはCloud Runで、Terraformのサンプルコードも置いています。 https://github.com/sue445/feed_squeezer/tree/main/_examples/gcp_cloud_run_terraform

GoでGoogleライクな検索クエリで文字列マッチするような関数を作った

  • AAA BBB : AND検索
  • AAA | BBB : OR検索
  • (AAA BBB) | CCC, (AAA | BBB) CCC : 括弧をつけて検索条件の優先順位付け

具体的には https://github.com/alecthomas/participle というパーサーライブラリを用いて実装しました。

github.com

participleは汎用的なパーサーライブラリなので使うのが難しかったのですが、ChatGPTに助けてもらいながら実装できました。

取得したフィードを一瞬だけキャッシュする

Slackでフィードを購読する時は /feed subscribe *1 を使います。

登録されたフィードは10〜15分おきくらいにSlackbotによる購読チェックが実行されます。

この時にSlackbotは同一のURLに対してほぼ同時にHEADとGETを実行します。

YouTubeチャンネルのフィードには短時間ながらRateLimitが設定されているため、瞬間的にたくさん呼び出すと429エラー(Too Many Requests)になります。

この429エラーを回避するためにキャッシュを導入しました。

バイナリにviewを同梱する

feed_squeezerに渡すurlやqueryなどのパラメータはURLエンコーディングする必要があります。

手でURLエンコーディングするのは大変なのでいい感じに変換するためのフォームをトップページに用意しています。

Goの https://pkg.go.dev/embed を用いてHTMLファイルをバイナリに含めています。

ただしjsやcssなどもバイナリに含めるとバイナリサイズが大きくなりそうだったのでHTMLファイルで利用しているBootstrapやVue.jsなどはCDN経由で参照するようにしました。

ちなみにこれがOSS化する前のfeed_squeezerの画面です。Bootstrapを入れるだけで全然違うなw

最近のエコシステムに乗っかる

今までGo製のツールを作る時はバイナリリリースとかCIでのlint実行とかはオレオレ実装を流用してたのですが、この機会に https://github.com/goreleaser/goreleaserhttps://github.com/golangci/golangci-lint にも初挑戦しました。

2024/06/14 13:28 追記:ブコメレス

id:igrep

絞るのに特化したYahoo! Pipesみたいな

なるほど。Yahoo! Pipesは全然知らなかったです

マッドマックス:フュリオサを見た感想

映画『マッドマックス:フュリオサ』 を3回見に行った感想。

せっかくなので全部別々の劇場に見に行った

特に記載がない場合は字幕版です。

新宿バルト9(DolbyCinema)

tjoy.jp

上映初日に行った。 家から徒歩圏内なのでよく行ってる。

DolbyCinemaなんだけど他がすごすぎて映画体験としては物足りなく感じた。

立川シネマシティ(極上爆音上映)

cinemacity.co.jp

極上爆音上映で有名な映画館。

バルトの翌日に行った。(つまり上映開始2日目)

前日に買ったパンフで予習。

最前列中央で全身でスピーカーの音圧を浴びた。

Fury Roadやガルパンの極爆はだいたい最前列から埋まっていったのに、フュリオサは最前列自分しかいないのが意外だった。

グランドシネマサンシャイン 池袋(ULTRA 4DX吹替)

www.cinemasunshine.co.jp

事前にFury RoadのBDで復習した。

4DXむっちゃ揺れる。人間ドックでグイングイン回転するやつを思い出した。

正面だけじゃなく両サイドにもスクリーンがあるのすごい。

www.cinemasunshine.co.jp

いつもの癖で最前列に座ったけど両サイドにもスクリーンあるのを知ってたら真ん中とか後方とかに座ってたな。

吹替版は初めてだったんだけど最後の吹替版のキャストを見て「マジ!?」ってなった。フュリオサがファイさんなの全然気づかなかったよ...

wwws.warnerbros.co.jp

#RubyKaigi 2024に参加した& #kaigieffectLT 大会に登壇した

RubyKaigi 2024

rubykaigi.org

気になった発表

RubyGems on ruby.wasm

1年前にruby.wasm上で3rd party gemを動かすのにむっちゃ苦労した *1 ので、この発表が今回一番聞きたかったやつ。

セッション終わった後に登壇者を捕まえて「発表だとマイルストーンについて言及されてなかったと思うんですが(現時点でnative extensionの対応以外はmasterに入ってるので順当にいけば12月のruby 3.4には入るという認識)、いつ頃リリース予定なんすか?」って聞いたら「細かい調整にあと1ヶ月くらいかかりそう」とのことでした。(たった1ヶ月!?)

The depths of profiling RubyVernier: A next generation profiler for CRuby

どっちもプロファイラの発表。

プロファイラのことよりも、個人プロダクト(native extension)で困ってることのヒントになるかなと思って発表を聞いた。

発表後に資料で取り上げられてたgemのソースもむっちゃ読んだ。

https://github.com/osyoyu/pf2 はRustのnative extensionで面白かったが自分のお悩み解決には至らなかった。

https://github.com/jhawthorn/vernier はCのnative extensionで自分が使ってるCの関連メソッドも利用してたので自分のお悩み解決のヒントになるかなと思ったんだけど、実際にこのgemの実装を試したけどダメだった。

その他

やんちゃハウス2024

面白そうなので知り合いのyancyaさんが主催してるシェアハウスに参加。

yancya.house

参加者同士の交流はそんなになく各々が好き勝手にやってる感じでした。

やんちゃハウスに関しては同じハウスメンバーの kenchanさん のエントリが詳しいです。

diary.shu-cream.net

やんちゃハウス2024は RubyMusicMixin 2024 の会場から徒歩2分という立地。

あまりに近すぎて、RubyMusicMixin中にローカルオーガナイザーの はなちんさんスマホのバッテリが切れて困ってた時にハウスに充電しに行ったり、RubyMusicMixin終了後にかなりお疲れモードだったので朝まで寝かせていたりもしました。

twitter.com

#kaigieffect LT大会

登壇してました。

timeedev.connpass.com

発表資料

esa-pages.io