• 167 Words

    OPA で Table Driven Tests っぽいことをしてみる

    OPA で Table Driven Tests っぽく Policy を Test する方法について考えたので紹介します。 背景 先日 Open Policy Agent Rego Knowledge Sharing Meetup で発表する機会を頂きました。 発表の資料はこちら。 普段他社の事例を聞いたり OPA について話たりする機会がないので、非常に貴重な時間になりました。 その中で deeeet さんが Table Driven Tests っぽくテストしたいというようなことをおっしゃっていました。 だいたいこの辺: https://youtu.be/0YpJhrz6L0A?t=2990 その話を受けて改めて自分で考えてみたところ、できなくはないんじゃないかなという気がしたのでちょっとやってみることにしました。 サンプル せっかくなので簡単なサンプルを GitHub に用意しました。 https://github.com/suzuki-shunsuke/example-opa-table-driven-tests 今回は aws_cloud_watch_log_group の retention_in_days が設定されていることをチェックする Rule の Test をします。 Rule: https://github.com/suzuki-shunsuke/example-opa-table-driven-tests/blob/main/policy/cloudwatch_log_retention_in_days.rego Policy Test: https://github.com/suzuki-shunsuke/example-opa-table-driven-tests/blob/main/policy/cloudwatch_log_retention_in_days_test.rego テストケースを seeds という list で定義し、どれか一つでも false だったら fail するようにしています。 テストケースの中身は msg: テストケースを示すメッセージ。テストが失敗したときの trace に含める resource: rule の input exp: rule の評価結果の期待値 になっています。
    • 337 Words

    Terraform で空の AWS Lambda Function を作る方法

    Terraform で空の AWS Lambda Function を作ろうとした際にちょっとハマったのでやり方を書いておきます。 「空の Lambda Function」という表現は適切ではないかもしれませんが、 Lambda で実行するコードのデプロイは Terraform 以外のツールでやるけど、 Lambda Function の作成は Terraform で行うので、 dummy のコードを指定して Terraform で Lambda を作るという話です。 自分は今は lambroll というツールで Lambda をデプロイしています。 lambroll は Lambda Function も作ってくれるので Terraform で作る必要は必ずしもありません。 しかし Lambda Function に関連するリソースを Terraform で管理する場合、 Lambda Function も Terraform で作ると Lambda Function の ARN や Invoke ARN を参照できます。 また lambroll でデプロイする場合も先に Terraform で IAM Role を作成する必要がありますが、 Terraform で aws_lambda_permission のようなリソースを作成するには Lambda Function が先に作られている必要があるので、 互いに依存関係が発生し、面倒なことになります。
    • 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 問題の解消