くりにっき

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

itamae-plugin-recipe-datadogのメンテナになった＆itamae-plugins orgのオーナーになった

itamae

簡単な経緯

PRを送ったらitamae-plugin-recipe-datadogのメンテナになった

詳しい経緯

経緯は id:takanamito さんのエントリに詳しく書いてます。

takanamito.hateblo.jp

itamae-plugin-recipe-datadogとは

Itamaeでdatadog-agentをインストールするためのプラグインです。

今年のISUCONに向けてずっと素振りをやってるんですが、今年はDatadogを使いたくてitamae-plugin-recipe-datadogを使ってました。

そこで、Itamaeを実行する度に余計にDatadogのインストールスクリプトが実行されて遅くなってたので下記のパッチを投げました。

github.com

そしたらある日突然下記のようなメンションをもらってメンテナになりました。

itamae-plugins orgのオーナーになった経緯

自分がメンテするのは別にいいんですが、Datadogは有名なツールなので個人プロダクトよりは複数人で管理できる https://github.com/itamae-plugins に置くのがいいと考えました。

github.com

orgのオーナーである id:k0kubun さんに相談したところorgのオーナー権限をもらいました。

v0.2.2について

いくつか機能追加したいとは思ってるんですが、CIやテストをセットアップしたり過去バージョンのCHANGELOGを全部書いてたら結構差分が多くなったのでとりあえず最低限の分だけいれてます。

https://github.com/itamae-plugins/itamae-plugin-recipe-datadog/blob/master/CHANGELOG.md#v022

まとめ

takanamitoさんのエントリに

自分は勉強会やイベントでsue445さんの発表を見ており、いくつもgemをリリースされている方なので信頼できると判断してお声がけしました。 （あとになって気付きましたが、itamae本体のメンテナでもありますね）

と書いてあったので日頃の活動ってのは大事だなと実感しました。。。*1

あと、k0kubunさんとは同じItamaeコミッタ仲間だしリアルでも何回かやり取りしたことあるのも良かったと思います。（僕もGitHub orgのオーナー権限をいくつか持ってるので分かるんだけど、普通見ず知らずの人にオーナー権限は渡せない）

2022/4/2 1:10追記

パッチ袋にあった機能を取り込んでv0.3.0をリリースしました。

https://github.com/itamae-plugins/itamae-plugin-recipe-datadog/blob/master/CHANGELOG.md#v030

2022/4/6 14:20追記

Speeeさんの方からもブログがきてました

tech.speee.jp

*1:最近表立った活動をあまりできてないのは内緒

plant_erd v0.4.0をリリースした

golang

github.com

GitHubがmermaidに対応予定 *1 ということでplant_erdもmermaidに対応しました。

https://github.com/sue445/plant_erd/blob/master/CHANGELOG.md#v040

plant_erdって名前でPlantUML以外のフォーマットに対応するのがかなり悩ましかったんですが、GitHubが対応する以上今後これがデファクトになる予感がしたので対応しました。（mermaid用にリポジトリ分けるという案もあったけど いい名前が思いつかなかった メンテナンスコストが上がるのでやめた）

ただしPlantUMLで埋め込めていた情報（index情報とか）がmermaidだと埋め込めなかったので、完全な代替にはならなさそうです。（詳しくはREADMEの図を参照）

*1:https://github.com/github/roadmap/issues/372

gitのログをとにかく全部出したい

git

git log ではなくgitの内部のログの話です。

最近gitコマンドの通信周りを追っていてログをとにかく全部出して挙動確認してるのでメモ。

  • --verbose ：git以外のコマンドにもよくあるオプションなので定番
  • GIT_TRACE, GIT_TRACE_SETUP：git内部のデバッグログ
  • GIT_CURL_VERBOSE：gitがリモートリポジトリに通信する時の詳細なログを表示

ということで、gitのログをとにかく全部出したい時は

GIT_TRACE=true GIT_TRACE_SETUP=true GIT_CURL_VERBOSE=true git fetch --verbose

や

export GIT_TRACE=true
export GIT_TRACE_SETUP=true
export GIT_CURL_VERBOSE=true
git fetch --verbose

のようにする。

参考URL

git-scm.com

faraday v2対応を行った＆faraday-mashifyをリリースした

gem

公式ドキュメント

https://github.com/lostisland/faraday/blob/main/UPGRADING.md

具体的な対応内容

faraday v0系とv1系は共存できたんですが、v2系はプラグイン周りに大きな変更があった関係でそれまでのバージョンと共存できなかったので拙作のAPIクライアントgemに関してもfaraday v2系未満のサポートを切ってメジャーバージョンアップを行いました。

faraday v2系でRuby 2.6系未満のサポートが切られてるので必然的に自分のgemでもRuby 2.6未満のサポートを切っています。

faraday_boolean v1.0.0

pixela v3.0.0, prismdb-ruby v1.0.0, chatwork-ruby v1.0.0

いずれのgemもmashify（普通のHashを ActiveSupport::HashWithIndifferentAccess のようなメソッドアクセスできるいい感じのHashにするやつ）を使ってたのですが、mashifyが組み込まれてる faraday_middleware がfaraday v2系だと非推奨になって対応をどうするちょっと困りました。（gemspecに ~> 1.0 が書かれてるのでv2系と共存もできない *1 ）

v2系だとfaraday_middlewareに組み込まれてたプラグインは各gemに分割される方針になってるようなのでfaraday-mashifyというgemがあるかと思いきやなかったのでIssueで聞いてみました。

github.com

そうしたらfaradayのメンテナから

We welcome people who would like to create and maintain them though, it doesn't have to be us!

という返事をもらったので自分でfaraday-mashifyを作り、自分のgemに組み込んで今回の対応を行いました。

github.com

その他地味にハマったところ

faraday v2対応時にテストコードが軒並みコケて調べたところ、レスポンスヘッダのContent-Typeが正しく設定されていないと response :json が動かなくて *2 地味にハマりました...

普通にWeb APIを叩いたらContent-Typeにjsonが入らないというのはまず無いはずなんですが、自分のテストコードだと webmock で外部通信部分をスタブにしていてスタブ側でContent-Typeを設定してなくてテストコードが軒並みコケていたというオチでした、、、

実際の対応内容 https://github.com/sue445/pixela/pull/91/commits/2adf922689b023fd458f6293f04c7e4b5b5b01fa

*1:https://github.com/lostisland/faraday_middleware/blob/v1.2.0/faraday_middleware.gemspec#L19

*2:https://github.com/lostisland/faraday/blob/v2.0.1/lib/faraday/response/json.rb#L38-L43 でContent-Typeのチェックをしてる

個人gemを軒並みRuby 3.1対応した

毎年やる作業ということもあり、個人gem全部のGitHub Actionsの設定を修正してPRを投げるツール自体は作ってるのでそんなに大変ではなかったです。

ツールについては詳しくは https://speakerdeck.com/sue445/ruby-on-ci-number-ginzarails?slide=79 を読んでください。

例年だとPRを一斉に作ってビルドが通ったらヨシッ！って感じでマージするだけの定形作業なんですが、今年はいくつかハマったのでピックアップ

Psych 4.0の非互換で動かなくなった

詳細は下記を参照

techlife.cookpad.com

Psych.load のデフォルトが safe_load になった関係でYAMLファイルを読み込んでるところで

Psych::DisallowedClass:
  Tried to load unspecified class: Date

のようなエラーが出るようになったので対応しました。

https://github.com/sue445/rubicure/runs/4672373245?check_suite_focus=true

で、permitted_classes を使おうとしたところ permitted_classes はPsych 3.1.0以降にしか存在せず、かつPsych 3.1.0以降を含んでるのがRuby 2.6.0以降だったので*1、いくつかのgemでRuby 2.6.0未満もサポートをきってメジャーバージョンアップしました。

リリースして気づいたけどgemspec側でPsych 3.1.0以降を指定してたら古いRubyのバージョンのサポートを切らなくてよかったかもしれない。（Ruby 2.5は既にEOLなのでサポートきっても支障はないんだけど）

Ruby 3.1.0 + Rails(activerecord) 7.0が現時点では動かない

詳しくは https://gist.github.com/yahonda/2776d8d7b6ea7045359f38c10449937b を参照。

そのうち7.0.1が出るだろうと思ってactiverecordを使ってるgemは gem "activerecord", "~> 7.0.1" をつけてDraft PRで寝かせておくことにしました

github.com

github.com

github.com

PRを作るとCircleCIからBANされた

gemが軒並みRuby 3.1対応したのでアプリもやるかーと思ってPRを作った瞬間CircleCIからBANされて厳しい顔になってます。

このPRの後にもいくつかPRを作ったけど同様にBANされたので諦めてサポートの対応待ち。

2022/1/1 16:00追記

CircleCIのサポートチケット作った数時間後に対応されてた。（自動検知システムでブロックされてたらしい）

1プロジェクトだけどうしてもビルドできなかったのでまだ完全解決ではないんだけど正月に対応してもらえるとは思わなかったので神対応すぎる。

2021/1/6 18:00追記

書くの忘れてたけど残り1つも1/3にBAN解除されていました。

*1: https://github.com/sue445/sengiri_yaml/pull/26

Keyless Terraformに特化したTerraformテンプレートリポジトリを作った（AWS, GCP対応）

Terraform CI GitHubActions AWS GCP

tl;dr;

github.com

github.com

前置き

9月くらいにGitHub ActionsでOpenID Connector（以下OIDC）を用いた認証を利用することができるようになりました。

dev.classmethod.jp

cloud.google.com

CI上でAWSやGCPのAPIを利用する場合は通常IAM UserのAWS_ACCESS_KEY_IDやAWS_SECRET_ACCESS_KEY（AWSの場合）やサービスアカウントのキーファイル（GCPの場合）をリポジトリのSecretsに設定することになりますが、OIDCによりこれらの機微情報の生成自体が不要になりました。（keyless）

モチベーション

OIDCは便利だしググればいくらでも情報は出てくるのですが、Terraformのリポジトリを作る度に調べたり諸々設定するのが大変なので楽をするためにテンプレートリポジトリを作りました。

テンプレートリポジトリについて

github.com

github.com

Terraformリポジトリの作り方やCIのワークフローは様々な流派がありますが、自分がよくやる

  • PullRequestで terraform plan, terraform fmt, tflint を実行しつつ、plan結果をPullRequestにコメントする
  • mainブランチでは terraform apply を実行
  • Slack通知

のような一番シンプルなパターンをテンプレートリポジトリにしています。

頑張った点：Terraformを実行するための初期設定をCloud FormationやDeployment Managerで行うようにした

Terraformを実行するためには terraform.tfstate を置くためのバケットを作成したりAWSの場合は排他ロックのためのDynamoDBのテーブルが必要で、GitHubのOIDCのためにもいくつか設定が必要です。

このような初期設定を（ほぼ）一発で終わらせるためにCloud FormationやDeployment Managerの設定ファイルを作成しました。

各リポジトリのREADMEにも書いてますがテンプレートから新規リポジトリを作った後にいくつかの手順を踏むだけでGitHub ActionsでTerraformが実行できるようになります。

ただしGCPのDeployment Managerだと現時点でWorkload Identity Poolを作成できないため、Deployment ManagerでTerraform用のGCSバケットやサービスアカウントを作った後でローカルからの terraform apply でWorkload Identity Poolを作るようにしています。

Terraformの実行に必要なリソースをTerraformで作るのは個人的には気持ち悪さがあるのですが、gcloudコマンドを2～3回叩かせるのもセットアップの手間が増えて嫌なのでTerraformで作ってます。（Deployment ManagerがWorkload Identity Poolに対応したらやめたい...）

AWSに関してはCloud Formationのコンソールから設定ファイルをアップロードするだけでTerraformの実行に必要なリソースを全て作れます。

個人gemにrubygems_mfa_requiredをつけた

gem

rubocop 1.23.0で Gemspec/RequireMFA が増えていたので rubygems_mfa_required の存在に偶然気づきました。

guides.rubygems.org

gemリリース時のMFA *1 は元から設定していたんですが、gemspecに

spec.metadata = { "rubygems_mfa_required" => "true" }

# or

spec.metadata["rubygems_mfa_required"] = "true"

みたいのを書いておくことで *2 gemのリリースや削除でMFAが必須になってさらにセキュアになるので、この機会に手持ちのgemに軒並み rubygems_mfa_required をつけました。

github.com

多分3日がかりで40〜50個のgemに適用してリリースしたと思います

*1: https://rubygems.org/settings/edit で設定できるアカウントに対するMFA

*2:最近のbundlerだとbundle gemした時に最初からspec.metadataがついてるので既存設定を上書きしない後者がいいと思います