57 posts tagged with "oss"

転職することになったのでその経緯とかを書こうかなと思います。

現職ではなにをやっていたのか​

現職では Recruit でスタディサプリ及び Quipper Product (Quipper School, Quipper Video) の SRE をやっていました。

2019-10-01 から Quipper Japan Branch の SRE team に Join し、 Quipper Japan Branch が 2021-10-01 に Recruit に統合されてからは Recruit の SRE をやっていました。 統合されてからも携わっているプロダクトや業務内容は特に変わってないので、 2 年 9 ヶ月ほど在籍していたことになります。

https://github.com/suzuki-shunsuke/resume に職務経歴書を置いているのでそちらも参照してください。 ちなみにこのリポジトリは今回の転職の際に作ったのですが、このリポジトリが更新されているのに気づいて自分の転職をいち早く察した方もいたようでした。

SRE として様々なことを経験しましたが、特に自分は Terraform の CI/CD Pipeline の改善に注力してきました。 そしてその過程で様々な OSS を開発してきました。 詳細はブログや職務経歴書に書いてあるので割愛します。

コロナの流行に伴い途中から今に至るまでフルリモートになり、フルリモートだった期間のほうが長いです。 フルリモートになってからはオフィスにはワクチンの職域接種を除き 1 回しか行ってないですし、 同じチームでも自分の後に入社した方とは直接会ったことはないです。 ですが、 Slack や Google Meet などでコミュニケーションを取っていたので自分としては特に不便はありませんでした。

スタサプ SRE のすすめ​

IT の力で教育に変革を起こし、学びたい人がより自由に学べる世界を目指すスタディサプリ及び Quipper Product に関われて嬉しく思っています。 転職する自分が言うのもなんですが、スタサプの SRE チームは本当に恵まれた環境です。転職を考えている人は是非候補に入れてみてください。

スタサプ SRE の良いところ:

• 同僚(SRE 以外も含む)が優秀
  • ブログも是非読んでください: https://blog.studysapuri.jp/
• 現状に満足することなく、日々改善に取り組んでいる
  • 技術的な部分だでなく、 MTG などのあり方なども日々見直している
  • 振り返りをし、課題と改善案を考え実行するというサイクルを日々回している
• 自己完結なプロダクトチームのためのプラットフォームの開発を行っている
  • SRE がプロダクトチームに依頼を受けてインフラを構築するのではない
• 裁量が大きく、自分で課題を見つけて改善することが出来る
  • なぜそれが必要なのか Issue を書くなど、説明責任は伴うが、ちゃんと説明できれば No とはあまり言われない
  • 自走出来ない人には向きません
• 情報が比較的オープン
  • Slack の Private channel や DM でのコミュニケーションがほぼない
  • GitHub リポジトリもスタサプ関連のものならほぼ全部見れる
  • GitHub を検索すればだいたい情報が見つかる
• ドキュメントを書く文化もある
• Postomortem や Design Doc, Production Readiness Check, SLI/SLO といった SRE の基本的なプラクティスが既に定着している
• サービスが安定している
  • サービスの性質上・ SNS でバズって急にスパイクするようなことがほぼない
  • 基本的には k8s の Cluster Autoscaler や Horizontal Pod Autoscaler で対応できる(長期的なサービス拡大のために他にもやっていることはあります)
  • 障害は少なく、深夜や休日に稼働しないといけないことも少ないので、 QOL を損なわない

https://brand.studysapuri.jp/career/position/sre にもいいことが書いてあるので、読んでみてください。

あと、 Security に特化したポジションもあるので、そちらも興味があれば是非。

転職への流れ​

転職のきっかけは、 @deeeet さんから Twitter DM で声をかけていただいたことでした。 deeeet さんとは過去に 2 回ほど面識があり、最初は「突撃 Terraform」、2 回目は Open Policy Agent Rego Knowledge Sharing Meetup というオンライン LT 会でした。 ただ、面識があるとはいえ deeeet さんが自分のことを認識しているとは思っていなかったので驚きました。 ここ何年か OSS の開発や blog の執筆などを精力的に行ってきたのが功を奏したのかもしれません。

DM で声をかけていただいてから直ぐにカジュアル面談をして頂き、その後直ぐ採用ページから応募しました。 職務経歴書の言語の指定は特にありませんでしたが、採用ページに日本語の JD がないことから、英語で書きました。 markdown で書いて md-to-pdf で PDF に変換しました。 markdown で職務経歴書を書いたのははじめてですが、自分にとっては Word などと比べてずっと書きやすかったです。

自分は今回のも含めて過去に 3 回転職をしていますが、 エージェントを介さずに直接応募したのははじめてでした。 過去 2 回の転職活動は色々な会社の募集要項に目を通して複数社の面接を受けて日程を調整して面接を受けに行ってと、なかなか精神的にも肉体的にも大変でした。 一方、今回は 1 社しか受けなかったこと、またこのご時世なので面接も全てリモートだったこともありだいぶ負担は少なかったです。

どこに転職するのか​

2022-07-01 から、 Mercari の Platform Group に Join します。まだ1ヶ月以上先ですが、今から楽しみです。

Mercari には優秀なエンジニアが集まってますし、 Platform Group の Blog Series を読んで技術的にチャレンジングなことをやっていて面白そうだと感じました。 自分が現職で取り組んでいた Terraform CI/CD Pipeline などの改善にも通じる部分があり、自分の経験・強みを活かしつつ新しいことに挑戦できるのではないかと思いました。 Blog Series や OSS の公開など、社外にも技術をオープンにしているのも良い文化だと感じました。

現職でプラットフォームエンジニアリングのようなことをやっていく中で、 抽象化された UI/UX を提供すること・生産性を損なわずにプラットフォームのセキュリティを担保することがとても重要かつ難しい課題だと感じていて、 Developer Experience at Mercari や Securing Terraform monorepo CI に書かれていることに共感しました。

余談ですが、とある方から転職するなら Hashicorp に転職して欲しいと言われました。 自分のこれまでの OSS の開発の経験を活かし、より多くの人・組織に使ってもらえる OSS の開発に携わってほしい(そのほうがより大きなバリューが出せる)という意図だと思いますが、 具体的な社名が出てくるとは思っていなかったのでびっくりしました。 どこに所属するにせよ、より多くの人・組織に使ってもらえるような OSS の開発をしていきたいですね。

おまけ: OSS 活動の振り返り​

転職の話とは関係ないですが、ついでにここ数年の OSS 活動などについても振り返りたいと思います。

2022-05-19 時点の状況

GitHub Followers: 139

やはり Star 数上位 3 つは思い入れがありますし、 github-comment や ci-info も便利なのでもっと評価されてほしいと思います。 色々なものを作ってきましたが、ここではこれらに絞って紹介します。

aqua​

一番思い入れがあるのは aqua です。 汎用的な CLI のバージョン管理ツールは色々ありそうで意外とあまりありません(多分)。 有名なのは asdf くらいですが、これは自分が求めているものではありませんでした (Nix とかもあるけど、良く知りません) 。

バージョンを固定することで、バージョンの違いによるトラブルを起こらないようにすることができます。 aqua は使うのがとても簡単で、 (symbolic link さえ作られていれば) コマンド実行時に自動で指定したバージョンがインストールされバージョンが切り替わります。 aqua g による検索は使い勝手がよいです。 GitHub Actions で簡単に導入ができるよう Action が提供されています。

aqua は Renovate の Preset Config を提供しており、 Renovate を使って簡単に update の自動化ができます。 aqua は Renovate を最も上手く活用した OSS の一つだと思っています。

aqua には Registry という Ecosystem があります。 aqua 本体への contribution にはそれなりのハードルがあるかと思いますが、 aqua-registry という公式の Registry には簡単に Contribution することができます。 2022-05-19 時点でありがたいことに自分以外に 13 人の方に Contribution 頂いています。 本体とは独立した拡張機構を持った OSS を作ることができたことにも満足しています。

aqua-registry に登録されているツールの数は、 2022-05-19 現在 asdf-plugins を超えました。 だから aqua のほうが優れているという話ではありませんが、 asdf と同等以上に多くのツールをサポートしているとは言えると思います。

$ asdf plugin list all | wc -l   
     470

$ aqua list | wc -l
     499

aqua はツールのインストールと継続的 update を非常に容易にします。 ツールをダウンロードして展開してインストールするような定型的なシェルスクリプトを書く必要はありませんし、いつまでも古いバージョンが使われることもありません。

また、 Go で GitHub Actions の Action を作りたいと行った場合に、態々 Action としてパッケージングせずに aqua で install して run step で実行するということもやりやすくなります。 例えば自分は renovate-issue-action という GitHub Actions で実行することを前提とした CLI ツールを作っていますが、 これも態々 Action としてパッケージングせずに aqua で install して run step で実行するようにしています。

e.g.

- uses: aquaproj/aqua-installer@v1.0.0
  with:
    aqua_version: v1.6.0
- run: renovate-issue-action

tfaction​

tfaction は GitHub Actions で Terraform の CI/CD Pipeline を構築するための Action の Collection です。 便利な単体の Action は色々あると思いますが、 workflow 全体をカバーするものはあまり他にないのではないかと思っています。 こういう CI/CD Pipeline はあまりオープンにされない面もあると思うので、それを OSS にできたことは有意義なことだと思っています。

tfcmt​

tfcmt は CI で実行した terraform plan, apply の結果を Pull Request に分かりやすく通知する CLI ツールです。 tfnotify のフォークですが、 GitHub への通知に特化する代わりに様々な機能改善を入れています。 GitHub を使っているのであれば tfcmt を個人的にはオススメします。 OSS は気に入らなければフォークすればいいとはよく言ったものですが(?)、実際にフォークして個人でここまで開発するとは、我ながらよくやったなと思います。

github-comment​

github-comment は Pull Request, Issue にコメントをしたりコメントを非表示にしたりする CLI ツールです。 使い方次第ですが、 CI をよりユーザーフレンドリーにし、 Developer と DevOps Engineer の双方の生産性を高めることもできるツールです。

github-comment で PR にコメントをして CI の結果を分かりやすくする

ci-info​

ci-info は地味なツールですが、 CI に関連した情報を取得してファイルに書き出したり環境変数として出力する CLI ツールです。 CI を実装していると、 push event に関連する Pull Request とか、 Pull Request の label の list とか、 Pull Request で変更されたファイルの一覧とか、 Pull Request の Author とか欲しくなったりするのですが、そういった情報を取得するコードを毎回書くのは地味に面倒です。ページネーションとかも考えるとなおさらです。 また、 CircleCI や GitHub Actions など複数の CI Platform に対応していて、それらの違いを吸収する意味合いもあります。

さいごに​

以上、現職でやってきたこと、転職の経緯、ここ数年やってきた OSS 開発について書きました。

仕事​

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

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

Blog​

• tfcmt がコメントの更新をサポート
• tfcmt supports updating comments

OSS 開発​

新規開発​

first release date	name	badges	lang	type	short description
2022-04-23	renovate-issue-action		go	cli for GitHub Actions	Create, update, and close GitHub Issues with GitHub Actions according to Renovate Pull Requests
2022-04-21	zap-error		go	library	Embed 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​

• aquaproj/aqua-registry
  • 遂に登録されているツールの数で asdf-plugins を超えました: https://twitter.com/szkdash/status/1518895119205683201
  • v1.11.0 => v2.10.0
• aquaproj/aqua
  • v1.3.0-0 => v1.5.0-0
  • v1.3.0: overrides のサポート
  • v1.4.0: Registry のテスト向けに、 GOOS と GOARCH を環境変数で変更できるようにしました
    • aqua-registry の CI でも使われていて、本来 CI でテストが難しい ARM64 向けのテストに活用されています
    • JSON Schema を追加しました
• suzuki-shunsuke/tfcmt
  • v3.1.0 => v3.2.1
  • plan のコメントの更新をサポートしました
• suzuki-shunsuke/tfaction
  • v0.5.7 => v0.5.11

OSS Contribution​

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

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

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

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

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

仕事​

• Blog 執筆
• Terraform
  • Module を Monorepo に集約: Terraform Modules を Monorepo で versioning して管理
• AWS Account 分割

Blog​

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 で検討しています。

まとめ​

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​

• Migrate Terraform CI from AWS CodeBuild to GitHub Actions
• Renovate の大量の Pull Request を処理する技術
• Terraform の CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました

OSS 開発​

• aqua v1.0.0 ~ v1.1.0
• aqua-registry v1.0.0 ~ v1.5.0
• aqua-installer v1.0.0
• tfaction v0.4.0 ~ v0.4.12
• New
  • https://github.com/suzuki-shunsuke/reenable-automerge-action
  • https://github.com/suzuki-shunsuke/renovate-autoclose-action

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
  • https://github.com/renovatebot/github-action
  • 無事 Self Hosted で動かせるようになった
  • 結果的に Self Hosted じゃなくても良かったのではという気はしている
• AWS WAF
  • COUNT, BLOCK log を Lambda で抽出しようとしているが、なぜか COUNT log が抽出できていない
  • あまり時間取れてない
• Route53 のドメインのアカウントの移管
• Lambda の CI/CD
  • 実現したいことを言語化: https://github.com/suzuki-shunsuke/issue/issues/70
  • 検討(あまり進んでない
• git-secrets から secretlint への移行
• circleci-config-merge を CI で実行して自動修正するようにした

課題​

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

Blog, Slide​

• https://techblog.szksh.cloud/archives/2021/11/
  • aqua の最近の update (v0.7.4 ~ v0.7.16)
• OPA Policy Testing by Table Driven Test
• https://suzuki-shunsuke.github.io/slides/aqua/introduction-5min/

OSS​

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

https://aquaproj.github.io/

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

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

https://github.com/aquaproj

OSS Contribution​

tfmigrator と tfcmt を awesome-terraform に追加してもらいました。

• https://github.com/shuaibiyy/awesome-terraform/pull/139
• https://github.com/shuaibiyy/awesome-terraform/pull/138

その他​

このブログのリポジトリを別の 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 を同じリポジトリに置きたくないので、 同じリポジトリでプロダクトとドキュメントを管理しにくいかなという気はしています。

以前 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 配下にシンボリックリンクを作成し、コマンド実行時に動的にバージョンを決定し、インストールされたコマンドを実行します。 よって which や command -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 してくれます。

Job​

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

Blog​

• 2021-10-13: HashiTalks Japan 2021 で弊プロダクトの Terraform Platform について登壇しました

OSS​

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

• Profile などの更新: https://github.com/suzuki-shunsuke/suzuki-shunsuke
• GitHub Actions の開発
• 自作ツールを Homebrew でインストールできるようにした
• aqua: v0.7.3 => v0.7.10
  • aqua-registry: v0.8.8 => v0.10.3

OSS Contribution​

• hashicorp/terraform-provider-aws: fix make testacc

仕事​

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

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

登壇​

• 2021-09-30 HashiTalks Japan 2021 (youtube)
  • Terraform Platform in Quipper (youtube)
  • Talk (30 min)

新たに作った OSS​

• aqua-renovate-config
  • Renovate Configuration to update packages and registries of aqua

Blog​

• English
  • Tips about Renovate
  • 2021-09-08 aqua - Declarative CLI Version Manager
• https://techblog.szksh.cloud/archives/2021/09/
  • 2021-09-25 aqua で組織・チームのツール群を管理
  • 2021-09-05 aqua の設定ファイルをインタラクティブに生成する generate コマンド
  • 2021-09-04 aqua v0.1.0 から v0.5.0 での変更点

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 で定期実行するようにするとよいかもしれません。

• aqua - CLI ツールのバージョン管理
• aqua v0.1.0 から v0.5.0 での変更点

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.yaml の packages に追記すれば OK です。

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

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

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

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