• 150 Words

    Terraform Module の Template という使い方

    Terraform Module の使い方として Terraform Module のテンプレートをコピペして使うというアプローチを紹介します。 Terraform の設定ファイル(以下 tfファイル) を書く際、毎回一から書くのは大変です。 多くの場合、既存のコードを再利用したほうが楽でしょう。 Terraform のコードの再利用の仕組みとして、 Module があります。 Module は勿論便利なのですが、使い方には注意が必要で、「安易に Module 化するな。使うな」というふうな考え方もあるでしょう。 自分も基本的に同意見で、 Module を共用するようになると Module への変更がしづらくなったり、パラメータがどんどん増えて複雑になったりします。 例えば次のように共用の local Module を作成するアプローチがあります。 modules/ lambda-base/ README.md main.tf variables.tf outputs.tf services/ foo/ staging/ main.tf # リポジトリ直下の modules/lambda-base を参照 production/ main.tf # リポジトリ直下の modules/lambda-base を参照 こうすると modules 配下の Module を変更した際にその Module を使っているすべてのサービスに影響が出てしまい、 サービスのオーナーが様々だったり、曖昧だったり不在だったりすると変更が難しいですし、どんどん Module が複雑になったりします。 Module を別のリポジトリでバージョニングして管理し、バージョンを指定するようにするというやり方もありますが、 結構複雑というか考えることが多いアプローチだとは思います。 Terraform にそこまで詳しくない developer にも書いてもらうとなると、シンプルなアプローチにするのが望ましいでしょう(当然これは組織によりますが)。 そこで Module のテンプレートを用意し、 Module を使いたくなったらそれをコピペして使うというアプローチがあります。 例えば lambda-base という Module の Template を foo というサービスの staging 環境と production 環境で使う場合、次のような感じになります。
    • 53 Words

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

    ブログの執筆 100 以上の Terraform 環境をいい感じに v0.14 に upgrade した方法 Pull Request の terraform plan の実行結果を S3 に保存して安全に apply Terraform のドキュメント作成 CI/CD でやってること ローカルでの開発環境 setup etc CI の改善 CircleCI の job の branch filter を設定して余計な job が実行されないようにした (進行中) デプロイをサービスごとに分割 (進行中) Lambda を爆速でデプロイするためのプラットフォームづくり Terraform + lambroll + AWS CodeBuild MongoDB upgrade (Atlas) On Boarding のドキュメントの整理
    • 21 Words

    仕事でやったこと 2021-02-01 ~ 2021-02-28

    Terraform リポジトリの統合 Terraform を v0.14 へ upgrade デプロイをサービスごとに分割 CircleCI の設定ファイルの分割 https://quipper.hatenablog.com/entry/2020/12/01/080000 と同様のことを別のリポジトリでもやった Renovate の設定を改善し、安全性と運用の負担軽減、オープンなままの PR の削減 miam の Rate Limit 問題の解消
    • 33 Words

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

    CI: PR コメントの非表示 github-comment, tfcmt 非表示以外にも細かな改善入れている Renovate label を設定 Renovate の PR に便利なリンクを追加 Terraform apply こけたときに plan 再実行して S3 に保存している plan file 及び PR コメントを更新 tfnotify を tfcmt にリプレース tfnotify を fork した
    • 116 Words

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

    2020-12-01 から 2020-12-31 にかけて仕事でやったことを書ける範囲で書きます。 AWS SAM Application の開発 Renovate の PR にリンクを追加 Terraform Terraform の CI に関して日々行っている改善点・変更点をチームにシェア Docker Compose を用いてローカルで開発しやすいように改善 ドキュメント・コードコメントの追加 リファクタリング 不要なコードの削除 不要な secret を削除 不要な変数の削除 data.terraform_remote_state を local values に置換 なぜか環境変数でパラメータを渡していた箇所を、 local value に置換 CI に tflint の導入 対象の build が 1 つの場合 batch build を実行しないようにする Terraform の CI/CD を CodeBuild に移行した話 の改良 Batch Build の起動に時間がかかる問題の解消 master の HEAD じゃなくても apply できるようにする plan file を S3 に保存 refactor: tfsec で設定ファイルを使うようにする Renovate の PR が多すぎて鬱陶しい問題の対応 automerge されるものは reviewer を設定しないようにした prConcurrentLimit を 1 にした branch protection Require branches to be up to date before merging を無効化 kube-linter Rule に基づいて manifest の修正 miam でリソースが削除されそうなときに警告をするようにした ブログの執筆 Renovate の Tips Terraform の CI/CD を CodeBuild に移行した話 巨大な .
    • 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 回目でようやく成功するということもありました。
    • 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 問題に対応した話