• 63 Words

    2021-09 やったこと

    仕事 今月は有休消化やシルバーウィークもあり、稼働が少なく、あまり仕事が進まなかったです。 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.
    • 136 Words

    aqua で組織・チームのツール群を管理

    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 という環境変数に : 区切りで設定ファイルへのパスを設定することで先頭から順に設定ファイルを参照するようにしました。 設定ファイルの優先順位は高い方から順に次のようになります。 -c で指定した場合はそのファイル、そうでなければカレントディレクトリから探索して最初に見つかったファイル AQUA_GLOBAL_CONFIG global configuration (デフォルトは ~/.aqua/global/[.]aqua.y[a]ml) イメージとしては プロジェクト(リポジトリ)の設定 組織の設定 個人の設定 という感じです。 例えば GitHub Organizations に aqua-config というリポジトリを作成し、以下のようなファイルを用意したとしましょう。 all.
    • 166 Words

    aqua の設定ファイルをインタラクティブに生成する generate コマンド

    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 を実行してみます。
    • 465 Words

    aqua v0.1.0 から v0.5.0 での変更点

    先日 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 という仕組みを導入しました standard Registry を公開しました https://github.
    • 153 Words

    2021-08 やったこと

    仕事 AWS IAM User を削除する際に force_destroy が true になっているか Conftest でテスト Terraform の State 分割 Terraform Modules を別リポジトリで管理して versioning git-secrets を secretlint に移行 git-secrets がメンテされてなくて、既知バグが放置されているから CI で terraform fmt によるフォーマットの自動化 WIP: AWS WAF の COUNT, BLOCK ログを Firehose で抽出 WIP: AWS CodeBuild で Provisioning Error が発生したら自動で Retry WIP: AWS CodeBuild のための GitHub App の開発 WIP: AWS SSO について調査 OSS Contribution Renovate の GitHub Actions のドキュメントの修正をしました。 ドキュメント中に書かれたバージョンを Renovate で自動 update するようにしました。
    • 636 Words

    aqua - CLI ツールのバージョン管理

    2021-09-04 追記: aqua v0.1.0 から v0.5.0 での変更点 aqua という OSS を開発しているので紹介します。 記事の内容は aqua v0.1.0 に基づきます。将来的に仕様が変わる可能性があります。 aqua とは aqua は CLI ツールのバージョン管理のための CLI です。 aqua で管理する主な対象は GitHub Release で公開されているツールです。 YAML の設定ファイルを書いてコマンドを実行すると指定したツールをインストールすることができます。 例えば以下のような設定ファイルを書き、 aqua install というコマンドを実行すると jq, conftest などが GitHub Release からダウンロードされ、インストールされます。 packages: - name: jq registry: inline version: jq-1.6 - name: conftest registry: inline version: v0.27.0 inline_registry: - name: jq type: github_release repo_owner: stedolan repo_name: jq asset: 'jq-{{if eq .OS "darwin"}}osx-amd64{{else}}{{if eq .
    • 483 Words

    AWS CodeBuild を実行する Github App を作る

    GitHub Repository の CI に CodeBuild を使う場合、 CodeBuild の Webhook integration (以下 CodeBuild GitHub integration と呼ぶことにします) を使うのが一番自然でしょう。 基本的なユースケースならこれでよいのですが、 GitHub App を活用することでより高度な CI を実現することができます。 解決したい課題 Batch Build の課題 起動・終了が遅い 全 build が成功した Batch Build を Retry できない Web UI がわかりにくい 余計な build が起動する build 単体を Retry できない build ごとに条件設定とかできない buildspec を動的に生成できない CodeBuild GitHub integration の課題 Build Project ごとに Repository Webhook が 1 つ作られる webhook 1 repository あたり 20 個までしか作れない (これを裏付ける客観的なソースはないですが) webhook の数が増えると build の動作が不安定になるのを観測しています Filter の条件が限られている(例えば PR label で filter とかできない) 複数の build を実行できない(Batch Build も 1 つとみなした場合の話) CodeBuild の課題 Retry した場合 webhook で起動したときの環境変数が設定されない GitHub App Amazon API Gateway と Lambda を使って GitHub App を構築します。 Lambda で webhook を受け取り、 AWS SDK を使って build を実行します。
    • 239 Words

    2021-07 やったこと

    今まで仕事に限定して書いてきましたが、 OSS 活動なんかにも触れてもいいんじゃないかと思ったので分かる範囲で書きます。 仕事 Docker Image を Docker Hub から ECR へ移行 Terraform .terraform.lock.hcl を CI の中で自動で更新(commit, push)できるようにした Terraform に詳しくない人も使うので、自動化したほうが良いと判断 tfmigrate を CI に導入 (in progress) Terraform Modules を Terraform の Monorepo とは別リポジトリで管理して versioning するようにした Route53 の管理を Roadworker から Terraform へ移行 tfmigrate を使ったリファクタリング Event Open Policy Agent Rego Knowledge Sharing Meetup で登壇 https://gist.github.com/suzuki-shunsuke/9372337aa62a6f8394bb136582ec068e OSS Contribution AWS AppConfig を Terraform で管理できるようにする PR が無事マージされました。
    • 167 Words

    OPA で Table Driven Tests っぽいことをしてみる

    OPA で Table Driven Tests っぽく Policy を Test する方法について考えたので紹介します。 背景 先日 Open Policy Agent Rego Knowledge Sharing Meetup で発表する機会を頂きました。 発表の資料はこちら。 普段他社の事例を聞いたり OPA について話たりする機会がないので、非常に貴重な時間になりました。 その中で deeeet さんが Table Driven Tests っぽくテストしたいというようなことをおっしゃっていました。 だいたいこの辺: https://youtu.be/0YpJhrz6L0A?t=2990 その話を受けて改めて自分で考えてみたところ、できなくはないんじゃないかなという気がしたのでちょっとやってみることにしました。 サンプル せっかくなので簡単なサンプルを GitHub に用意しました。 https://github.com/suzuki-shunsuke/example-opa-table-driven-tests 今回は aws_cloud_watch_log_group の retention_in_days が設定されていることをチェックする Rule の Test をします。 Rule: https://github.com/suzuki-shunsuke/example-opa-table-driven-tests/blob/main/policy/cloudwatch_log_retention_in_days.rego Policy Test: https://github.com/suzuki-shunsuke/example-opa-table-driven-tests/blob/main/policy/cloudwatch_log_retention_in_days_test.rego テストケースを seeds という list で定義し、どれか一つでも false だったら fail するようにしています。 テストケースの中身は msg: テストケースを示すメッセージ。テストが失敗したときの trace に含める resource: rule の input exp: rule の評価結果の期待値 になっています。