Skip to main content

56 posts tagged with "oss"

View All Tags

· 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​

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

· 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 で抽出
  • akoi を aqua にリプレース

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.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 が実装できてとても便利でした。

· 9 min read
Shunsuke Suzuki

先日 aqua v0.1.0 をリリースした記事を書いたばかりですが、 そこから更に開発を続けて v0.5.0 をリリースしたので、変更点を紹介します。

基本的に Release Note に書いてあるとおりです。

  • PATH を project (aqua.yaml) 毎に設定する必要がなくなりました
    • ~/.aqua/bin を PATH に追加すればよくなりました
    • direnv などを使って環境変数を追加する必要がなくなりました
  • install コマンドに --test option を追加し、 file.src の設定が正しいかテストできるようになりました
    • CI で aqua の設定をテストするのに便利
  • GitHub Release だけでなく、任意の URL から tool のダウンロード・インストールができるようになりました
    • Go や helm, Hashicorp の product のような公式サイトからダウンロードするタイプのツールも install できるようになりました
  • Breaking Change: inline_registry の設定の形式を変更しました
  • aqua の設定の再利用性を高める Registry という仕組みを導入しました
  • 簡単な slide を公開しました: https://speakerdeck.com/szksh/introduction-of-aqua

PATH を project (aqua.yaml) 毎に設定する必要がなくなりました​

aqua v0.1.0 では symbolic link を aqua.yaml のあるディレクトリの .aqua/bin 配下に作成しており、ここを PATH に追加する必要がありました。 direnv とかを使うと便利ですが、間接的に(?) aqua が direnv のようなツールに依存している形になり、微妙でした。

aqua v0.5.0 では symbolic link を ~/.aqua/bin 配下に作成するため、 .bashrc などで ~/.aqua/bin を PATH に追加しておけば project ごとに環境変数を追加する必要はなくなりました。 ちなみに作成される symbolic link は aqua-proxy へのリンクであり、ツールのバージョンには依存しないので ~/.aqua/bin を共有しても干渉することはありません。

~/.aqua/bin 配下に symbolic link を作って PATH に追加する場合、一つ大きな課題があります (だからこそ v0.1.0 ではプロジェクトごとに symbolic link を作っていました)。 ~/.aqua/bin 配下に symbolic link を作って PATH に追加すると、基本的にそのファイルが呼ばれることになります。 そのツールを aqua で管理しているプロジェクト配下ならそれで良いですが、そうでない場合、本来 aqua 以外でインストールしたものを実行したくても実行できません。 例えば homebrew で jq を install していて、あるプロジェクトでは aqua を使ってバージョンを固定したものを使いたいが、それ以外では homebrew で install したものを使いたいといった場合に問題になります。

この問題を解決するため、 aqua ではツールを呼び出す際に PATH をチェックして aqua-proxy へのリンクとなっているものは除外するというハック(?)のようなことをしています。

install コマンドに --test option を追加し、 file.src の設定が正しいかテストできるようになりました​

地味な更新ですが、 aqua の設定を更新した際に CI でテストするのに便利です。 --test option なしだと、 warning は出力しますが、 exit code は 0 になります。

GitHub Release だけでなく、任意の URL から tool のダウンロード・インストールができるようになりました​

ちなみに、 GitHub Release で公開されてないようなツールでも、 GitHub リポジトリで versioning されていて Renovate の github_release data source で自動更新できるケースは少なくないと思います。

Breaking Change: inline_registry の設定の形式を変更しました​

小さな breaking change ですが、inline_registry の形式が変わりました。

AS IS

inline_registry:
- name: jq
  type: github_release
  repo_owner: stedolan
  repo_name: jq
  asset: 'jq-{{if eq .OS "darwin"}}osx{{else}}{{.OS}}{{end}}-{{.Arch}}'
  files:
  - name: jq

TO BE

inline_registry:
  packages:
  - name: jq
    type: github_release
    repo_owner: stedolan
    repo_name: jq
    asset: 'jq-{{if eq .OS "darwin"}}osx{{else}}{{.OS}}{{end}}-{{.Arch}}'
    files:
    - name: jq

aqua の設定の再利用性を高める Registry という仕組みを導入しました​

これが一番大きな更新です。 aqua を使うにはツールのインストール方法を YAML で記述しないといけませんが、 これはちょっとした手間ですし、新規ユーザーにとって障壁となるでしょう。

ツールとそのバージョンを定義したらインストールできてほしいものです。 ツールとそのバージョンの定義は aqua.yaml の packages の部分なので、それ以外の設定を如何に簡略化するかという話になります。

Registry はツールのインストール方法の設定を、プロジェクト固有のバージョン設定とは独立させ、再利用可能な形で共有する仕組みです。

Registry には現状 4 種類あります。

  • inline regisry: aqua.yaml の中に直接 install 方法を定義する。 v0.1.0 からサポートされている方法
  • github_content registry: GitHub Repository にあるファイルを Registry として参照する方法
  • local registry: GitHub Repository にあるファイルを Regisry として参照する方法
  • standard registry: 自分がメンテしている github_content registry のエイリアス

inline registry​

inline registry は従来からあるやつで、 aqua.yaml 内に定義する方法です。

inline_registry:
  packages:
  - name: jq
    type: github_release
    repo_owner: stedolan
    repo_name: jq
    asset: 'jq-{{if eq .OS "darwin"}}osx{{else}}{{.OS}}{{end}}-{{.Arch}}'
    files:
    - name: jq

シンプルではありますが、コピペする以外に再利用性がありません。

local registry​

local registry はローカルにあるファイルを参照する registry です。 絶対パスか、 aqua.yaml からの相対パスを指定します。

github_content registry​

ユーザーとしては次のように Registry を定義すればあとは packages で Registry を参照できます。 GitHub Access Token を環境変数 GITHUB_TOKEN として設定する必要があります。

registries:
- name: suzuki-shunsuke/aqua-registry
  type: github_content
  repo_owner: suzuki-shunsuke
  repo_name: aqua-registry
  ref: v0.2.0 # renovate: depName=suzuki-shunsuke/aqua-registry
  path: registry.yaml

packages:
- name: conftest
  registry: standard
  version: v0.27.0 # renovate: depName=open-policy-agent/conftest

Registry を公開する​

自分で Registry を公開したい場合は GitHub Repository に設定ファイルを置くだけで OK です。 e.g. https://github.com/suzuki-shunsuke/aqua-registry/blob/main/registry.yaml

Standard Registry​

Standard Registry も作りました。

https://github.com/suzuki-shunsuke/aqua-registry

jq や gh, kubectl, Terraform など有名なツールはこの Registry を使えばインストールできますが、 当然 PR も受け付けているので、追加してほしいツールがあれば PR を投げてください。

Official Registry を github_content Registry として利用することも当然できますが、 より簡潔に書けるように type: standard という Registry がサポートされています。

AS IS

registries:
- name: standard
  type: github_content
  repo_owner: suzuki-shunsuke
  repo_name: aqua-registry
  ref: v0.2.0 # renovate: depName=suzuki-shunsuke/aqua-registry
  path: registry.yaml

TO BE

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

上 2 つは等価ではありますが、後者のほうが簡潔です。