• 36 Words

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

    SRE チームの新メンバーのオンボーディングのサポート GCP dev からのリクエストに応じて権限付与したり対応 Terraform による GCP の管理 CI/CD の整備 Workload Identity Federation について調べた Terraform による IAM 管理の仕方を検討 Conftest opa fmt によるフォーマット(CI も導入) Policy Testing (CI も導入) Upgrade Terraform to v0.15.4 miam の Terraform 移行を検証
    • 65 Words

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

    SRE チームの新メンバーのオンボーディングのサポート Lambda の Monorepo 幾つか実際に Function 作った(developer support) 幾つかの Release Strategy の実装・検証 シンプルな GitHub Flow Git Flow をアレンジしたリリースフロー Canary Release WIP: AWS AppConfig を用いた Dark Launch IAM User の初期パスワード送信の自動化 Terraform Renovate による Terraform の patch update の自動化 Docker を使ったローカル開発環境の改善 ローカルで terraform init したら .terraform.lock.hcl が更新される問題の対応 https://techblog.szksh.cloud/terraform-providers-lock/ GCP の Terraform 管理 調査 WIP Conftest 社内の Rego の活用事例をまとめた opa fmt によるフォーマット(CI も導入) Policy Testing (CI も導入)
    • 143 Words

    PR で変更されたファイルや PR Label に応じて matrix build を実行する Github Actions の Workflow のサンプルを書いてみた

    GitHub Actions の勉強がてら Pull Request (以下 PR) で変更されたファイルや PR Label に応じて Matrix build を実行する Github Actions の Workflow のサンプルを書いてみました。 https://github.com/suzuki-shunsuke/example-github-actions-dynamic-matrix Monorepo で同じ Job を PR で変更されたものに対してだけ実行したい、 けど workflow をサービスごとに定義するのはめんどいみたいな場合に使えるかもしれません。 勉強がてらちょっと書いてみて軽く動作確認しただけなので、バグってる、あるいは実用的ではないかもしれません。 ここでは Monorepo の CI を GitHub Actions で実行する場合を考えます。 GitHub Actions では path filter を用いて workflow の実行有無を制御することができます。 そこでサービスごとに workflow を作成し、 path filter を設定することでそのサービスが更新されたときのみそのサービスの CI を実行するということが簡単にできます。 しかし多くのサービスが含まれる Monorepo で各サービスに同じ Job を実行したい場合を考えてみましょう。 その場合サービスを追加するたびに workflow を追加していく必要があります。 まぁ .github/workflows 配下に 1 つ YAML をコピペで作成するだけといえばそれまでなのですが、それすらも省略したいとしましょう。 Terraform の CI/CD を CodeBuild に移行した話では CodeBuild の Batch Build の buildspec を PR で変更されたファイルおよび PR Label に応じて動的に生成しています。 これの良いところは、サービスを追加したり、リネームしたり、削除したりしても CI をイジる必要がまったくないところです。
    • 164 Words

    terraform init で lock ファイルが更新される問題の対応

    Terraform v0.14 で local で terraform init すると lock ファイルが更新されてしまう問題に対応しました。 結論を最初に言うと、 100 以上の Terraform 環境をいい感じに v0.14 に upgrade した方法で紹介している方法で Renovate で Terraform Provider を update する際に terraform init -upgrade を実行して lock ファイルを更新してコミット・プッシュしているのですが、 その際に terraform providers lock -platform=darwin_amd64 を実行するようにしました。 Terraform v0.14 で lock ファイル .terraform.lock.hcl が導入されました。 Renovate で Terraform Provider を update する際にも lock ファイルを更新する必要があるので、 terraform init -upgrade を実行して lock ファイルを更新してコミット・プッシュしています。 なのですが、ローカルで terraform init を実行するとなんか lock ファイルが更新されることが良くありました。しばらく放置していたのですが、 developer から「なんかファイル更新されたんだけど、これコミットしていいの?」と聞かれ、このまま放っておいて困惑させたりもやっとさせたりするのは良くないなと思い、調べてみました。 lock ファイルについて .
    • 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 回目でようやく成功するということもありました。