• 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 .
    • 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 が無事マージされました。
    • 457 Words

    terraformer で雑に生成した tf ファイル と state を分割したくてツールを書いた

    terraformer で雑に生成した Terraform の設定ファイル (以下 tf ファイル) と state を分割したくてツールを書きました。 tfmigrator 経緯 miam から Terraform へ移行したい miam というツールで管理されている大量のリソースを Terraform で管理したくなりました。 多くの AWS Resource は Terraform で管理されていますが、 IAM に関しては miam で管理されています。 なぜ Terraform ではなく miam で管理されているかというと、当時のことは自分には分かりませんが、歴史的な経緯もあると思います。 昔は今よりも Terraform の表現力が豊かではなく、 Ruby で自由にかける miam のほうが扱いやすかったとか、 miam だと miam でリソースを管理することを強制できるため、権限管理を厳格にやるという観点では都合が良いという点もあるかと思います。 ではなぜ Terraform で管理したくなったかというと、 一番大きな理由は miam で頻繁に rate limit に引っかかるようになったからです。 Terraform にしろ miam にしろ CI/CD で test, apply が実行されるようになっています。 miam では毎回全部のリソースを対象に処理が実行されるため、リソースの数が増えるにつれて rate limit に引っかかりやすくなります。 CI を rerun すれば成功するのですが、悪いときは 3 回連続で rate limit に引っかかり、 4 回目でようやく成功するということもありました。
    • 64 Words

    tfnotify を fork した

    mercari/tfnotify を Fork して 2 つほど OSS を作りました。 https://github.com/suzuki-shunsuke/tfnotify - tfnotify と互換性あり https://github.com/suzuki-shunsuke/tfcmt - tfnotify と互換性がない 開発の経緯 これまで tfnotify を便利に使わせてもらってたのですが、幾つか改善したいと思うところがあり、本家に PR を投げました。 しかし残念ながらこれまでのところ反応がなく、そこまで本家が活発ではないこと、また他にも色々改修したいところがあったことから、自分でフォークしてメンテすることにしました。 最初は互換性を維持しながら suzuki-shunsuke/tfnotify を開発していました(今もしています)。 しかし、開発を進めるに連れ、自分にとって必要のないプラットフォームなどに関するコードが邪魔であると感じ、それらを消したバージョンを別に開発することにしました。 互換性がなくなることから、名前も変えて tfcmt としました。 https://github.com/suzuki-shunsuke/tfcmt こういった経緯から、 tfcmt のほうを優先的に開発していますが、 tfcmt で実装した機能を後から suzuki-shunsuke/tfnotify にも実装してたりもします。 Fork 元のバージョン suzuki-shunsuke/tfnotify は mercari/tfnotify v0.7.0 fb178d8 をフォークしました。 一方 tfcmt は suzuki-shunsuke/tfnotify v1.3.3 をフォークしました。 mercari/tfnotify との違い 本家との違いは Release Note とドキュメントを参照してください。 suzuki-shunsuke/tfnotify https://github.com/suzuki-shunsuke/tfnotify/releases https://github.com/suzuki-shunsuke/tfnotify/blob/master/COMPARED_WITH_TFNOTIFY.md suzuki-shunsuke/tfcmt https://github.com/suzuki-shunsuke/tfcmt/releases https://github.
    • 92 Words

    Terraform の Docker Provider の Collaborator になりました

    先日 kreuzwerker/terraform-provider-docker の Collaborator になりました。 kreuzwerker/terraform-provider-docker は Terraform の Docker Provider であり、 Docker コンテナや image, network などを管理できます。 元々は Hashicorp の Official Provider であった terraform-providers/terraform-provider-docker が kreuzwerker/terraform-provider-docker に移管され、 Community Provider になりました。 元のリポジトリは hashicorp org に移され archive されています。 Collaborator になった経緯 リポジトリが移管される際に、メンテナを募集していて過去に contribution していた自分にも声をかけていただきました。 https://github.com/hashicorp/terraform-provider-docker/issues/306 Contributor になった経緯 自分がこの provider に contribution した経緯は、 Terraform の Hands on を書くのに丁度よい provider を探していたことでした。 Hands on の題材として Docker コンテナを作ったりできたらいいんじゃないかなと思って Docker provider を試してみました。 しかし当時の docker_container リソースは read をちゃんとサポートしていませんでした。 なので import や update がまともに動きませんでした。 それを見かねて修正して PR を投げたのが最初です。