• 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 を投げたのが最初です。
    • 85 Words

    仕事でやったこと 2020-10-01 ~ 2020-10-31

    2020-10-01 から 2020-10-31 にかけて仕事でやったことを書きます。 勿論全部は書けないのでいくつかピックアップして書きます。 Terraform CodeBuild Batch Build による dynamic な build pipeline の導入 Conftest の実行方法を修正 https://www.openpolicyagent.org/docs/latest/terraform/ tf ファイルに対して conftest を実行するのではなく、公式の方法に従ってテストするようにした aws_cloudwatch_log_group.retention_in_days が設定されているか Conftest でテスト コスト削減 tfnotify が parse に失敗した場合、 github-comment でコメント https://techblog.szksh.cloud/post-tfnotify-parse-error/ Docker Hub 認証するようにした Docker Hub の Rate Limit 問題に対応した話 kustomize build のテスト(失敗したら PR にコメントをして、なぜ失敗したか分かるようにした) 元々 kustomize build に失敗して CI がこけても、なぜこけたのか分かりにくく、 SRE に問い合わせが来て調べるみたいなことがあった どの k8s manifest の kustomize build に失敗したのか、 PR に分かりやすくコメントするようにした CI で kubectl apply –server-dry-run によるテストを導入 Monorepo 差分検知・デプロイパイプラインの改善 Renovate automerge の導入 renovate-approve 便利 CI で renovate-config-validator による validation の導入 https://docs.
    • 32 Words

    仕事でやったこと 2020-07-01 ~ 2020-09-30

    2020-07-01 から 2020-09-30 にかけて仕事でやったことを書きます。 勿論全部は書けないのでいくつかピックアップして書きます。 Terraform CircleCI から CodeBuild への移行 Security + DX 10月以降も継続 tfnotify の導入 Monorepo で導入するには一工夫が必要 コメントが消える挙動がドキュメント化されてなくて軽くハマった Renovate の導入 Regex Manager 便利 Monorepo 差分検知・デプロイパイプラインの改善 DataDog からのアラートのハンドリング業務の改善 どんなアラートがあって、どう対応したかなどのナレッジの共有の改善 割とアナログな手法だが、ちゃんと work している
    • 59 Words

    仕事でやったこと 2020-04-01 ~ 2020-06-30

    2020-04-01 から 2020-06-30 にかけて仕事でやったことを書きます。 勿論全部は書けないのでいくつかピックアップして書きます。 Monorepo CI で kustomize build の diff を PR にコメント Conftest で k8s manifest の validation の導入 Go で書かれた差分検知のコードのリファクタリング CI の高速化・コスト削減 GitOps GitOps を導入するためのツールの開発のサポート Terraform input variables を local value に置き換え GuardDuty の導入 Terraform で IaC False Positive なアラートが多くてハンドリングできてない ブログの執筆 CI の修正をリリース前に本番と同じ条件下で検証出来る仕組みを構築した話 Argo Workflows の検証 MongoDB Atlas への移行サポート Go で Restore Job の開発 オペレーション
    • 110 Words

    仕事でやったこと 2020-01-01 ~ 2020-03-31

    2020-01-01 から 2020-03-31 にかけて仕事でやったことを書きます。 勿論全部は書けないのでいくつかピックアップして書きます。 Monorepo 更新検知のシェルスクリプトを Go でリプレース CI の修正をリリース前に本番と同じ条件下で検証出来る仕組みを構築した話 CircleCI のコードリストアの改善(コスト削減・高速化) リポジトリが非常にでかいので全部 checkout, restore すると時間がかかる Job ごとに必要最小限のコードだけをリストアすることで高速化 サーバの OS upgrade Ansible CI の更新検知で、 PR の label で対象を指定できるようにした(コードに変更がなくてもテストが実行できるようにした) たまにテストしたいときはある それまではてきとうにコードを修正しないとテストが実行されなかったが、 PR の label で対象の playbook を指定できるようにした key=value 形式を YAML に変換 https://www.ansible.com/blog/ansible-best-practices-essentials Use Native YAML Syntax .circleci/config.yml のリファクタリング job を parameterize して共通化したり parameterize された command を使って共通化したり コード量の大幅な削減 Terraform CircleCI の環境変数を設定することで、 master での CI を一時的に禁止できるようにした State を弄ってたりするときに予期せぬ apply が実行されないようにするため master branch の CI が終わるまで wait master の CI が走っている間に PR の CI でまだ apply されていないリソースが差分として出るのを防ぐ shfmt, shellcheck の導入 CI/CD でシェルスクリプトを書いているので、それらを lint State Locking の導入 Terraform Cloud の検証 結果、見送り すでに CI/CD pipeline を構築している自分たちにとっては、わざわざ移行するメリットが薄いと判断 MongoDB upgrade Jenkins Alternative の検証 RunDeck Argo Workflows 結局、ローカルで検証した程度
    • 63 Words

    仕事でやったこと 2019-10-01 ~ 2019-12-31

    2019-10-01 から 2019-12-31 にかけて仕事でやったことを書きます。 勿論全部は書けないのでいくつかピックアップして書きます。 Terraform terraform fmt の導入 Terraform の upgrade v0.11 => v0.12 State の分割 3 => 40 弱(正確な数は忘れた) Conftest による lint: Remote Backend のパスを間違えるとまずいので test を導入 新しいサービスを追加するときのための generator (シェルスクリプト)を開発 CODEOWNERS の設定 突撃隣の Terraform リリースブランチをやめて GitHub Flow に移行 古いリビジョンで apply の実行の禁止(CI がこけるようにした) Ansible CI の高速化 Jenkins job を CircleCI の scheduled job にリプレース(脱 Jenkins) ローカルでの開発環境の改善 コンテナを使い回せるようにする goss に置き換えて高速化 CI の改善 高速化(無駄な処理の削減)
    • 491 Words

    Splitting .circleci/config.yml

    In this post I introduce how to split a huge .circleci/config.yml. CircleCI doesn’t support to split .circleci/config.yml, so we manage all workflows and jobs configuration into one file .circleci/config.yml. If the repository is Monorepo, the more the number of services increases, the more the size of .circleci/config.yml becomes large and it’s hard to maintain .circleci/config.yml. By splitting .circleci/config.yml per service, it makes easy to maintain .circleci/config.yml and we can configure split file’s CODEOWNERS.
    • 229 Words

    github-ci-monitor: CI のステータスを DataDog で監視

    自作の OSS github-ci-monitor の紹介です。 GitHub リポジトリの CI のステータスを定期的に取得し、 DataDog に送ることで、 CI のステータスを監視するツールです。 現状は AWS Lambda で動かすことを想定していますが、他の方法でも動かせるようにするつもりです。 Motivation モチベーションは、 PR をマージしたあとに CI がこけた場合に通知が欲しいというものです。 マージしたあとに CI が一瞬で終わるなら無事終わるのを見届けてもいいんですが、 数分かかると待ってるのも時間がもったいないです。 しばらくしたあとに結果を確認すればいいんですが、それも面倒くさいですし、普通に忘れます。 そうするとデプロイしたつもりが実は CI がこけてたなんてことが普通にあります。 そういうことにすぐ気づけるよう、 Slack に通知がほしいと思っていました。 仕組み 仕組みは単純です。 GitHub API で各リポジトリのステータスを取得し、 DataDog API でステータスを送信しています。 DataDog API は Service Check API を使っています。 status は以下のようになります。 0: 正常 1: 異常 3: ステータスの取得に失敗 また以下の tag が付きます。 owner: リポジトリのオーナー repo: リポジトリ名 ref: ブランチ名 各リポジトリのステータスは現状 3 つをサポートしています。
    • 168 Words

    matchfile - 変更されたファイルの一覧から必要なタスクを導出するための CLI ツール

    自作の CLI ツール matchfile について紹介します。 https://github.com/suzuki-shunsuke/matchfile この記事の執筆時点で最新バージョンは v0.1.1 です。 変更されたファイルの一覧から実行する必要のあるタスクを導出するための CLI ツールです。 Go で書かれていて、バイナリをダウンロードしてくれば使えます。 Pull Request (以下 PR) の CI では PR で変更されたファイルに応じて 必要なタスク(build, test, lint, etc) だけを実行したかったりします。 そこで、 PR で変更されたファイルパスのリスト と タスクが依存するファイルパスの条件 を元に、そのタスクを実行する必要があるか判定するためのコマンドとして matchfile を開発しました。 ただし、 matchfile の機能としては PR や CI とは独立しているので、もっと別の目的でも使えるとは思います。 matchfile は PR で変更されたファイルパスのリスト や タスクが依存するファイルパスの条件 を取得したりする機能はありません。 PR で変更されたファイルパスのリスト は ci-info という自分が作った別のツールを使うと取得できます。 タスクが依存するファイルパスの条件 はタスクに大きく依存するので matchfile はカバーしていません。 matchfile の使い方としては $ matchfile run <PR で変更されたファイルパスのリストが書かれたファイルへのパス> <タスクが依存するファイルパスの条件が書かれたファイルへのパス> で、 PR で変更されたファイルパスのリスト のうち一つでも タスクが依存するファイルパスの条件 にマッチすれば true を、マッチしなければ false を標準出力します。 コマンドの exit code で結果を表現することも考えられましたが、そうすると set -e しているときに若干面倒くさいので、標準出力で表現しました。
    • 262 Words

    なぜ buildflow を作ったのか

    buildflow というツールを開発しているので buildflow というタグをつけて何回かに分けてブログを書きます。 この記事では なぜ buildflow を作ったのかについて説明します。 開発者である自分の好みや置かれた環境などが所々に反映された内容になっています。 解決したい課題 自分は CI/CD の DX の改善に業務として取り組んでいます。 リポジトリはたくさんあり、横断的にメンテナンスしています。 幾つかのリポジトリはモノレポになっており、 CI の複雑さが増していたり、 CI の実行時間が長かったりします。 現在の CI/CD には以下のような問題があると感じています(他にもあるんですが、 buildflow と関係ないので割愛)。 実行時間が長い PR とは関係ない処理(test, build, etc) が実行されている 金銭的に高い 実行時間が長いので無駄にお金がかかっている CI サービスによっては並列度を上げることで実行時間が縮む場合があるが、それでもその分お金がかかる PR とは直接関係ないところで失敗する PR とは関係ない処理(test, build, etc) が実行されていて、それらが flaky で失敗する メンテナンス性が悪い 属人化気味 何をやっているのか分かりにくい 同じような機能を複数のリポジトリで実装・メンテしたくない これらの問題を解決するために buildflow を開発しました。 buildflow で必要な処理だけを実行する buildflow では PR の情報を自動で取得し、それらに応じて実行する処理を変更できます。 変更されたファイルに応じてだけでなく、 label や PR の author などでも変更できます。 Tengo script を用いて柔軟なロジックを実装できます。 JSON や YAML の読み込みもサポートしているので、依存関係などの設定を別ファイルで管理することも出来ます。