Skip to main content

· 2 min read
Shunsuke Suzuki

Pull Request を再度 review してほしい場合には、 mention つきでコメントするのではなく、 Re-request review をしましょう。 GitHub には再度 review 依頼するための機能があります。

image

mention つきのコメントでは、一度通知を見逃したり、後で対応しようと思って時間が経ってしまった場合に、 忘れられやすいという問題があります。

Re-request review を使うと mention 同様に通知がリアルタイムで通知が行くのに加え、 review 待ちの pull request を検索で絞り込めたり、自分の review 待ちの pull request を一覧できたりします。

自分の review 待ちの pull request 一覧: https://github.com/pulls/review-requested

検索で絞り込み

  • Awaiting review from you
  • Awaiting review from you or your team

image

また、 Slack の integration で定期的に通知を飛ばしてリマインドすることで、忘れるのを防ぐことができます。

· 5 min read
Shunsuke Suzuki

仕事

  • GitHub Discussions の検証
  • renovate-issue-action の導入
  • tfcmt で patch option の有効化
  • etc

GitHub Discussions に仕事のナレッジを蓄積できないか検証したりしました。 Slack と比べてナレッジを蓄積しやすいのではないかと期待する一方、 Slack のようにその場で質問をしてすぐ解決するのには向かないかなという気もしました。 ちゃんとしたドキュメント書くよりはとりあえず Discussions に Q&A 形式でナレッジを残しておくのは低コストでやれるかなと思う反面、手間もかかりそうです。 活用の仕方を模索すること、無理なく運用できるルールを定めること、組織・チームでツールの活用方法・使い分けの認識を合わせる必要がありそうです。

Blog

OSS 開発

新規開発

first release datenamebadgeslangtypeshort description
2022-04-23renovate-issue-actionGitHub last commitgocli for GitHub ActionsCreate, update, and close GitHub Issues with GitHub Actions according to Renovate Pull Requests
2022-04-21zap-errorGitHub last commitgolibraryEmbed zap.Field into error

zap-error

zap-error は Go の error に zap.Field を埋め込み、構造化されたコンテキストを error に持たせてロギングできるようにするライブラリです。 Go では fmt.Errorf を使ってエラーにコンテキストを付与させるのが一般的ですが、 fmt.Errorf では構造化されたコンテキストを付与させることができません。 また、 uber-go/zap を始めとしたライブラリを使った構造化ロギングも一般的に行われることです。 であれば error に構造化されたコンテキストを付与しロギングに活用したいと思うのは個人的には自然なことだと思っています。 zap-error はそのための薄いライブラリです。 error に zap.Fields を付与する関数と、 error を zap.Fields に変換する関数の 2 つの API しか提供していません。 zap の logger をラップするようなことはしていないので zap はそのまま使えます。

ちなみに logrus 用の logrus-error というのも元々作っています。

renovate-issue-action

Renovate ですんなり automerge 出来なかった Pull Request を Issue としてハンドリングするための GitHub Action です(正確には Action ではなくて CLI ですが)。 これはいずれちゃんとブログを書きたいですね。

Update

OSS Contribution

merged daterepositorylangPR's short description
2022-04-29shuaibiyy/awesome-terraformdocumenttools: add tfaction
2022-04-29shuaibiyy/awesome-terraformdocumentfix: update links to some tools
2022-04-22kreuzwerker/terraform-provider-dockergochore: remove the workflow to close stale issues and pull requests
2022-04-21mitchellh/mapstructuregofix: panic when Decode's input is array and output is a slice
2022-04-12rhysd/actionlintgofix: add permissions "pages" and "discussions" and remove invalid permission "metadata"
2022-04-06terraform-linters/tflint-ruleset-awsgostyle: format rules/api/rule.go.tmpl and run go generate ./...

tfaction が awesome-terraform に追加されました。

· 2 min read
Shunsuke Suzuki

3 月は blog を結構読みました。

https://zenn.dev/shunsuke_suzuki/scraps/602d6f6b803168

後は職場のインフラ周りのコードとかを読み返して復習しました。

最近は OSS 開発やブログの執筆などの output が中心で、 input をする時間があまり取れていなかったのでブログなどを読むという形で input をしました。

仕事

Blog

datetitle
2022-03-30Terraform Modules を Monorepo で versioning して管理
2022-03-29Automate handling a number of Pull Requests by Renovate in Terraform Monorepo
2022-03-05tfaction v0.5.0 の update

OSS 開発

  • aqua v1.2.0 ~ v1.3.0
  • aqua-registry v1.6.0 ~ v1.11.0
  • tfaction v0.5.0 ~ v0.5.7
  • tfcmt v3.1.0

その他

AWS CodeDeploy を用いた AWS Lambda の Progressive Delivery に関して検討しました。

https://zenn.dev/shunsuke_suzuki/scraps/64bf029c5eeb7b

PipeCD も考えましたが、 CodeDeploy で出来るんならそれでいい気がするので、まずは CodeDeploy で検討しています。

· 2 min read
Shunsuke Suzuki

まとめ

aqua, aqua-registry, aqua-installer の v1 をリリースしました。 v1 に伴う変更は特にありません。 aqua v1.1.0 では aqua g -i によって aqua.yaml に package を追加できるようにし、使い勝手を良くしました。 tfaction は結構色々機能追加やバグ修正が入ってます。 仕事ではブログにも書いたように Renovate の大量 PR を自動で処理できるように改善を行いました。

仕事

  • Terraform
    • tfaction バグ修正
    • GITHUB_TOKEN rate limit 引っかかったので GitHub App の token に置き換え
    • CI こけた renovate PR の自動 close 検討
    • tfsec や AWS Provider v4 の update 対応をどうするか検討したり、対応したりしてた
  • AWS Account 分割

Blog

OSS 開発

· 5 min read
Shunsuke Suzuki

Job

  • AWS Control Tower
    • 登録できてなかった Account を登録できた
  • AWS SSO
    • ユーザーへの案内・催促を行い、 IAM User から SSO に移行してもらった
    • ローカルの開発で Access Key に依存していた部分に関して修正し、 Access Key なしでローカルで開発できるようにした(人によってはまだ Access Key に依存したツールを使っている
      • S3 Browser が SSO でなぜか動かないらしい(自分が Windows 持ってないので確認できてないけど
      • Cyberduck が SSO サポートしていない
    • 一部のユーザーの Access Key の deactivate
    • 不要な IAM User のクリーニング
    • 来月中には一部の例外を除き、移行を完了させたい
    • SSO 出来ない人を SSO できるように対応した (同期対象の Group や、 Permission Set を追加したり)
    • SSO に関する User 向け、 SRE 向けドキュメントを英語で書いた
  • aqua を更新し、 Access Token なしでも動くようにした(API call を減らし、 rate limit の問題を解決した
  • Self Hosted Renovate in GitHub Actions
  • AWS WAF
    • COUNT, BLOCK log を Lambda で抽出しようとしているが、なぜか COUNT log が抽出できていない
    • あまり時間取れてない
  • Route53 のドメインのアカウントの移管
  • Lambda の CI/CD
  • git-secrets から secretlint への移行
  • circleci-config-merge を CI で実行して自動修正するようにした

課題

  • Renovate の Automerge が base branch が更新されたことで disable になり、結局手でマージしないといけなくなっている
    • 自動化の検討

Blog, Slide

OSS

aqua の公式サイトを立ち上げました。

https://aquaproj.github.io/

Docusaurus v2 で生成して、 GitHub Pages でホスティングしています。

aqua 用の GitHub Organization を作り、関連リポジトリを transfer しました。

https://github.com/aquaproj

OSS Contribution

tfmigratortfcmtawesome-terraform に追加してもらいました。

その他

このブログのリポジトリを別の GitHub Organization に transfer しました

https://github.com/techblog-szksh-cloud/techblog-szksh-cloud.github.io

理由は techblog.szksh.cloud が suzuki-shunsuke.github.io の CNAME になっていて、 OSS のドキュメントなどを GitHub Pages で公開したいときに都合が悪かったからです。

ついでに CI を Drone から GitHub Actions に移行しました。

suzuki-shunsuke/issue の活用

https://github.com/suzuki-shunsuke/issue/issues に記録を残すようにしました。

https://github.com/suzuki-shunsuke/issue/issues?q=is%3Aissue+updated%3A2021-11-01..2021-11-30

前から使ってましたが、あまり活用できてなかったので、意識的に活用していこうと思っています。 せっかくツールとかを検証しても、ちゃんと記録が残ってないと忘れてしまいもったいないというのと、 issue に残すと自然と検証とかが進むような気がしています。

Docusaurus

Docusaurus はいい感じなので suzuki-shunsuke/profile やこのブログを Docusaurus に移行するのもありかもしれないなと思いました (思っただけでまだ何もしてません

ただ、 OSS のドキュメントに Docusaurus を使う場合、個人的には package.json を同じリポジトリに置きたくないので、 同じリポジトリでプロダクトとドキュメントを管理しにくいかなという気はしています。

· 9 min read
Shunsuke Suzuki

以前 aqua v0.7.3 がリリースされた際に aqua で組織・チームのツール群を管理 という記事を書きました。 あれからもうすぐ 2 ヶ月になり、最新バージョンは v0.7.16 になりました。 そこで v0.7.4 ~ v0.7.16 の間の更新と、関連 repository の更新を幾つか(全部ではない)紹介します。

基本的に Release Note に書いてある内容です。

  • GitHub の Access Token が基本的に不要になりました
  • Homebrew で install できるようになりました
  • aqua.yaml がより簡潔に書けるようになりました
  • aqua.yaml の packages を他のローカルのファイルから import できるようになりました
  • aqua.yaml をディレクトリの階層的にネストできるようになりました
  • aqua which コマンドをサポートしました
  • github_archive, github_content type をサポートしました
  • (advanced) バージョンによってパッケージの type が変更された場合にも対応できるようになりました
  • Standard Registry の package の数が 139 => 220 になりました。
  • aqua のための CircleCI Orb をリリースしました

GitHub の Access Token が基本的に不要になりました

private repository から package をインストール場合は当然必要ですが、そうでなければ不要になりました。 これにより、 aqua を導入するハードルが下がりましたし、 GitHub API の Rate Limit に引っかかることが基本的になくなりました。

余談ですが、 private repository のツールを簡単に install できるのも aqua の便利な点だなと思っています。

Homebrew で install できるようになりました

$ brew install suzuki-shunsuke/aqua/aqua

Homebrew で install できるようにすることで、より手軽に導入してもらえるようになりました。

ちなみに aqua を aqua で管理出来ないのかというと、現状できません(無限ループになってしまう)。

aqua.yaml がより簡潔に書けるようになりました

AS IS

- name: direnv/direnv
registry: standard
version: v2.28.0 # renovate: depName=direnv/direnv

TO BE

- name: direnv/direnv@v2.28.0
  • registry: standard が省略可能
  • version を name に @ のあとに書ける
    • これにより、 Renovate の Regex Manager 用にコメント # renovate: depName=direnv/direnv を書く必要がなくなりました

これにより 1 行で書けるようになりました。 ただ簡潔にかけて楽というだけでなく、 Renovate 用のコメントでパッケージ名を間違えて指定するリスクがなくなりました。

e.g. パッケージ名を間違えている例

- name: direnv/direnv
registry: standard
version: v2.28.0 # renovate: depName=cli/cli

aqua-renovate-config を使えばコメントを書かなくても version を上げることが出来ます。

aqua.yaml の packages を他のローカルのファイルから import できるようになりました

e.g.

ディレクトリ構成

aqua.yaml
aqua/
reviewdog.yaml
golangci-lint.yaml
...

aqua.yaml

packages:
- import: aqua/*.yaml

aqua/reviewdog.yaml

packages:
- name: reviewdog/reviewdog@v0.13.0

このようにファイルを分割することで、特定のパッケージが update された場合のみ CI で特定の job を実行するといったことがやりやすくなります。 例えば GitHub Actions の on.<push|pull_request>.paths の場合、

name: test
on:
pull_request:
paths:
- '**.go'
- aqua/golangci-lint.yaml

aqua.yaml をディレクトリの階層的にネストできるようになりました

aqua はカレントディレクトリからルートディレクトリに遡って ^\.?aqua\.ya?ml$ を探索します。 このとき、それまではファイルを一つ見つけた時点で探索をやめていましたが、全ての階層を探索するようになりました。 同じパッケージが定義されていた場合、先に見つかった設定ファイルの version が優先されます。 これにより、 Monorepo でも aqua が使いやすくなりました。 Monorepo 直下に aqua.yaml を置きつつ、サブディレクトリに aqua.yaml を置いても、サブディレクトリ配下で Monorepo 直下の aqua.yaml も参照できるようになりました。

aqua which コマンドをサポートしました

$ which gh
/Users/shunsuke-suzuki/.aqua/bin/gh

$ aqua which gh
/Users/shunsuke-suzuki/.aqua/pkgs/github_release/github.com/cli/cli/v2.2.0/gh_2.2.0_macOS_amd64.tar.gz/gh_2.2.0_macOS_amd64/bin/gh

aqua は ~/.aqua/bin 配下にシンボリックリンクを作成し、コマンド実行時に動的にバージョンを決定し、インストールされたコマンドを実行します。 よって whichcommand -v では実際に実行されるコマンドのパスが分かりませんが、 aqua which コマンドを使うとパスが分かります。 ちなみに aqua で管理されてないコマンドでもパスを取得できます。

$ aqua which git
/usr/local/bin/git

少々変わった使い方ですが、 aqua でインストールされた実行ファイルを別のパスにコピーしたい場合に便利です。

$ cp "$(aqua which gh)" src/gh

github_archive, github_content type をサポートしました

Standard Registry にある package をインストールしているだけの方は、そもそも package の type というものを気にする必要もないので あまり関係ない話かもしれませんが、 http, github_release package に加えて、 github_archive, github_content package もサポートされました。 github_archive は GitHub Repository の Archive をパッケージとして扱うもので、 tfenv を aqua でインストールする際なんかに使われています。 github_content は GitHub Content API を使って GitHub Repository の単一ファイルをパッケージとして扱うものです。

(advanced) バージョンによってパッケージの type が変更された場合にも対応できるようになりました

これまた advanced な内容で多くの方にはあまり関係ない裏側の仕組みの話ですが、パッケージによってはバージョンによって type が変わることがあります(かなりまれですが)。 あとは repository の owner が変わったりなんかもありますが、そういった場合にも対応できるようになりました。 ちなみに GitHub Release の asset のファイル名のフォーマットや、 asset のディレクトリ構成が変わることは時々ありますが、それらには元々対応できています。

e.g. https://github.com/suzuki-shunsuke/aqua-registry/blob/v0.10.7/registry.yaml#L486-L492

https://github.com/suzuki-shunsuke/aqua/blob/v0.7.16/docs/registry_config.md#version_constraint-version_overrides

Standard Registry package の数が 139 => 220 になりました。

Standard Registry は v0.8.6 から v0.10.7 になりましたが、その結果 package の数は 139 から 220 になりました。

aqua のための CircleCI Orb をリリースしました

CircleCI で Orb を使って aqua を install したり aqua を使ってパッケージをインストールできるようになりました。 aqua とパッケージを cache してくれます。

· One min read
Shunsuke Suzuki

Job

  • AWS SSO の導入
    • Google アカウントで AWS へサインインできるように設定
    • AWS SSO の Terraform 管理
    • ssosync を Lambda で定期実行
    • 開発者向けの移行ガイドの作成し、実際に案内
    • terraform, kubectl などのツールで AWS にアクセスできるかの検証
  • AWS WAF の COUNT, BLOCK の log を Firehose, Lambda で抽出
  • akoiaqua にリプレース

Blog

OSS

https://github.com/pulls?q=is%3Aclosed+is%3Apublic+is%3Apr+author%3Asuzuki-shunsuke+archived%3Afalse+created%3A2021-10-01..2021-10-31+

OSS Contribution

· One min read
Shunsuke Suzuki

仕事

今月は有休消化やシルバーウィークもあり、稼働が少なく、あまり仕事が進まなかったです。

  • AWS SSO や Organizations を導入するためのロードマップの策定
  • AWS SSO の検証

登壇

新たに作った OSS

Blog

· 4 min read
Shunsuke Suzuki

aqua v0.7.3 をリリースし、 複数の global configuration をサポートしました。

個人で使う分にはあまり嬉しい機能でもないかもしれませんが、 会社・組織・チームといった集団(以下組織で統一)で設定を共有するには便利な機能だと思います。

これまで aqua では 2 つの設定ファイルをサポートしていました。

  • -c で指定した場合はそのファイル、そうでなければカレントディレクトリから探索して最初に見つかったファイル
    • リポジトリ直下にそのリポジトリ用の aqua.yaml をおく
  • global configuration (デフォルトは ~/.aqua/global/[.]aqua.y[a]ml)
    • 個人の dotfiles とかで aqua.yaml を管理しておく

こうすることで特定のリポジトリ用の設定と個人の設定を管理することができます。

しかし、第三の設定を参照することはできませんでした。 例えばある組織で使うツールセットを aqua で管理しようと思ってもこれまでは難しかったです。

そこで AQUA_GLOBAL_CONFIG という環境変数に : 区切りで設定ファイルへのパスを設定することで先頭から順に設定ファイルを参照するようにしました。

設定ファイルの優先順位は高い方から順に次のようになります。

  1. -c で指定した場合はそのファイル、そうでなければカレントディレクトリから探索して最初に見つかったファイル
  2. AQUA_GLOBAL_CONFIG
  3. global configuration (デフォルトは ~/.aqua/global/[.]aqua.y[a]ml)

イメージとしては

  1. プロジェクト(リポジトリ)の設定
  2. 組織の設定
  3. 個人の設定

という感じです。

例えば GitHub Organizations に aqua-config というリポジトリを作成し、以下のようなファイルを用意したとしましょう。

  • all.yaml: 全 Developer 用の設定
  • sre.yaml: SRE Team 用の設定

そのリポジトリをローカル /home/foo/aqua-config に checkout したとしましょう。 あなたが SRE の場合、 AQUA_GLOBAL_CONFIG を次のように設定しましょう。

export AQUA_GLOBAL_CONFIG=/home/foo/aqua-config/sre.yaml:/home/foo/aqua-config/all.yaml

こうすることで特定のリポジトリ用の設定と個人の設定(dotfiles)に加えて、 自分が所属する組織用の設定も参照することができます。

組織としては組織に必要なツール群を aqua で宣言的に管理できるため、 セットアップのコストも下がり、バージョンも組織で統一することができます。

aqua install に追加された -a option

v0.7.3 では aqua install-a option が追加されました。 aqua install はデフォルトでは global configuration は参照しません。 global configuration を参照するのは aqua exec 及び aqua でインストールされたツールを実行したとき(内部的に aqua exec が実行されている)だけです。

-a option をつけると global configuration も含めて全ての設定ファイルを参照し install を実行します。

aqua.yaml を Git で管理している場合は定期的に リポジトリを pull して aqua i -a -l を実行するのが良いでしょう。 簡単なスクリプトを書いたり、 cron で定期実行するようにするとよいかもしれません。

· 4 min read
Shunsuke Suzuki

aqua v0.5.1 で追加された generate というサブコマンドを紹介します。

aqua では Registry を活用することで設定を記述する手間を省くことができますが、 Registry を活用するには、インストールしたいツールが Registry で定義されているか、されているとしたら name はなにか調べる必要があります。 Registry で定義されているのに見逃してしまうこともあるでしょう。

また、 aqua でツールをインストールするには version を指定する必要がありますが、多くの場合はとりあえず最新バージョンはなにかを調べることになるでしょう。

これらの手間を減らすために generate というインタラクティブなコマンドを追加しました。 これは aqua.yaml で指定されている Registry で定義されている packages の一覧から package を fuzzy search によって選択し、 更に github_release package の場合は release version の一覧を fuzzy search によって選択することで package の YAML 定義を出力するコマンドです。

使ってみるのが早いでしょう。 aqua.yaml に Standard Registry を追加した上で aqua g を実行してみます。

registries:
- type: standard
ref: v0.2.1 # renovate: depName=suzuki-shunsuke/aqua-registry

すると fuzzy search が起動し、 package が選択できます。 自分が使いたいツール名で検索してみて、あればそれを選択します。

  direnv (standard)
consul (standard)
conftest (standard)
> golangci-lint (standard)
47/47
>

golangci-lint を選んでみましょう。 すると golangci-lint のバージョンの一覧が選択できます。

  v1.40.0
v1.40.1
v1.41.0
v1.41.1
> v1.42.0
30/30
>

version を選ぶと YAML が出力されます。

$ aqua g
- name: golangci-lint
registry: standard
version: v1.42.0

この YAML を aqua.yamlpackages に追記すれば OK です。

helm のように GitHub Release からではなく公式サイトからインストールするようなツールはバージョンのリストを取得するのが難しいのでバージョンの選択はできません。

$ aqua g
- name: helm
registry: standard
version: ""

それでも helm が helm という name で standard registry に登録されていることはわかるので、十分便利です。

ちなみに fuzzy search には ktr0731/go-fuzzyfinder を使わせていただきました。非常に簡単に fuzzy search が実装できてとても便利でした。