• 279 Words

    skaffold を使って GitOps する

    skaffold を用いてマニフェストを動的に生成しつつ GitOps する方法を考えたので紹介します。 なお、現時点ではあくまで考えてみただけで実際に導入したりはしていません。 GitOps はマニフェストを Git リポジトリにコミットしないといけないわけですが、 Docker image をビルド、プッシュし、マニフェストの image tag を書き換えるという一連の処理をどうやってやるのがいいのか 個人的に考えていました。 自分は FluxCD には詳しくないのですが、 FluxCD では registry をポーリングして自動で最新のタグに書き換える機能があるそうですね。 https://toolkit.fluxcd.io/guides/image-update/ ただし、まだ alpha であることと、 semver に従っていないといけないようです。 これだと master branch が update されるたびに image をビルドして sha でタグを付与するみたいな運用は難しそうです。 Skaffold だとマニフェストの image tag を自動で書き換えてくれる機能があります。 加えて skaffold render コマンドを使うと manifest の apply はせずにファイルへの出力だけやってくれます。 出力された manifest を Git リポジトリに commit, push すれば GitOps が実現できそうです。 How リポジトリを 2 つ用意します。 app: アプリケーションのコードとマニフェストを管理するリポジトリ manifest: GitOps が連携するマニフェストを管理するリポジトリ app は Monorepo になっているとします。ディレクトリ構成は次のような感じをイメージしています。
    • 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.
    • 315 Words

    2019-10 から今(2020-12-31)に至るまで仕事でやっていること

    2019-10-01 から今の職場で SRE として働いています。 その中で自分がどういうことをやっているかという話をします。 2020-12-31 現在の内容です。 要約 プロダクト横断的な SRE チームで、プロダクトのプラットフォームを運用・開発している 特に CI/CD の改善が得意 developer に CI/CD をいわばサービスとして提供しており、 DX の改善に取り組んでいる Monorepo の負の側面(CIが遅い、関係ないTestがこけるetc)の解消にも取り組んでいる 自分が直面している課題を解決する OSS を色々開発している キーワード SRE Monorepo CI/CD Developer Experience Terraform Go / Shell script k8s CircleCI / CodeBuild Conftest Renovate より具体的にやっていることを書いた記事 個人ブログ https://techblog.szksh.cloud/job-2020-10-01-10-31/ https://techblog.szksh.cloud/job-2020-07-01-09-30/ https://techblog.szksh.cloud/job-2020-04-01-06-30/ https://techblog.szksh.cloud/job-2020-01-01-03-31/ https://techblog.szksh.cloud/job-2019-10-01-12-31/ 会社ブログ Renovate の Tips Terraform の CI/CD を CodeBuild に移行した話 巨大な .circleci/config.yml を分割した話 Docker Hub の Rate Limit 問題に対応した話 CI の修正をリリース前に本番と同じ条件下で検証出来る仕組みを構築した話 何をやっているか プロダクト横断的な SRE チームで、プロダクトのプラットフォームを運用・開発しています。
    • 62 Words

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

    2020-11-01 から 2020-11-30 にかけて仕事でやったことを書ける範囲で書きます。 github-ci-monitor を導入し、 CI の失敗を通知 https://github.com/suzuki-shunsuke/github-ci-monitor Terraform Upgrade AWS Provider: Renovate で自動更新する仕組みの改善 Upgrade Terraform from v0.12 to v0.13 tfsec の導入 PR の label によって CI(plan/apply) の実行対象を追加できるようにした CircleCI から CodeBuild への移行 tfmigrate の検証 Monorepo の CI の高速化 (CircleCI) k8s manifest の test を、変更があったものに対してだけ実行するようにした kube-linter の導入 Renovate https://quipper.hatenablog.com/entry/2020/12/10/080000 additionalBranchPrefix によるブランチの分割 depName を使ったリファクタリング .circleci/config.yml の分割 ブログの執筆 Docker Hub の Rate Limit 問題に対応した話
    • 62 Words

    Renovate の PR に便利なリンクを追加

    Renovate による PR をレビューする際、差分がなんなのか分かりづらいときがあります。 例えば data source が github-release の場合、 PR の description に Release Note が含まれており、コードの差分も link があるので便利です。 一方 helm data source の場合、 そういったものがなく差分がなんなのか分からないことがあります。 そういう場合、 prBodyNotes を利用して link を追加すると便利です。 例えば、 datadog helm chart の場合 { "datasources": ["helm"], "packageNames": ["datadog"], "prBodyNotes": [ "[compare](https://github.com/DataDog/helm-charts/compare/datadog-{{currentVersion}}...datadog-{{newVersion}})" ] } とすると、 PR の description にリンクが追加されます。地味ですが便利です。 Release page へのリンクを追加しても便利かもしれませんね。 ex. https://github.com/suzuki-shunsuke/test-renovate-2/pull/28 template で使える変数は https://docs.renovatebot.com/templates/ を参照してください。 helm chart ごとに設定を書かないといけないのが面倒ですが、仕方ないですね。
    • 147 Words

    Renovate と Dependabot の比較

    普段 Renovate を主に使っている自分が、 Dependabot と Renovate の違いについて調べてみました。 普段 Renovate を主に使っているので、 Renovate 寄りの内容になっています。 気分を害する人がいましたら申し訳ありません。 Dependabot の理解が浅いので間違ってたら指摘してもらえると助かります。 2020-12-01 時点の情報です。 設定項目の数 https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuration-options-for-dependency-updates#directory https://docs.renovatebot.com/configuration-options/ まずは設定のドキュメントを見比べると、 Renovate のほうが設定項目が多いです。 Renovate はよく言うと設定項目が多く、柔軟な設定ができるといえる一方、すべての設定を理解し使いこなすのは難しいです。 決して日本語の情報も多くないので、色々試行錯誤したりすることもあります。 Dependabot の場合、設定がそんなに多くなく割と分かりやすい印象があります。 scheduling https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuration-options-for-dependency-updates#scheduleinterval https://docs.renovatebot.com/configuration-options/#prhourlylimit https://docs.renovatebot.com/configuration-options/#schedule Dependabot は schedule の設定が必須です。 Renovate でも schedule の設定は出来ます。 Dependabot は 1 個 1 個設定しないといけない? Renovate は renovate.json さえ作れば中身がほぼ空でも勝手に update されます。 逆に対象を絞りたかったら明示的に指定する必要があります。 一方で Dependabot は対象を 1 つ 1 つ指定しないといけないようですね。 もちろん、これは必ずしも悪いことではないですし、良い面もあります。 設定が明示的に書かれていたほうが挙動を理解しやすいですしね。 ただし、数が多いと大変ですし、サービスを追加するたびに設定を追加しないといけなさそうです。 Renovate は .circleci/config.yml などの update もサポート https://docs.
    • 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 の開発 オペレーション