© Chatwork ACKを活用して 使い捨てAWS検証環境を構築している話 Chatwork株式会社

自己紹介 2 ● 古屋 啓介 ○ Chatwork株式会社 プロダクト本部 SRE部 ○ AWS Community Builders (container) ○ JAWS-UG SRE支部運営 ○ ドラム叩きます

前提と課題 やったこと まとめ 1 2 AGENDA アジェンダ 3

前提と課題 1

（おさらい）前提 5 ● Chatworkのインフラ構成 ○ 大部分のアプリがEKS上で稼働 ○ その他Aurora、Dynamo DB、SQSあたりがよく使われる

開発環境におけるアプリケーション動作確認用インフラ 6 ● ローカル ○ 手元のマシンでdocker-composeなどを駆使 ● 検証環境 ○ 開発者が自由に使える検証用AWSアカウント（共用） ○ 本番と同じフロー（Argo CD）でEKSにデプロイ＆動作確認

開発検証環境の課題 7 検証用EKSクラスタが1つしかなく、同じアプリを複数起動できない AWS環境で検証したい場合は専有（順番待ち）する必要あり

モチベーション 8 これ、なくしたいな？

機運 9 ● Argo CDの統合でApplicationSetが利用可能に ○ 1つのEKS内でアプリケーションが容易に複製可能 統合Argo CD、できたで さすさか神（さすが坂本さん、神です）

ということで 10 よっしゃ じゃあPR作ったらなんか環境ばーんって できるやつ（流行ってるし）やってみよう！

やったこと 2

● Argo CD ApplicationSet Pull Request Generatorの活用 ● AWS Controllers for Kubernetes（ACK）の活用 やったこと 12

PR Generatorの活用（1/3） 13 ● PR Generatorとは？ ○ ApplicationSetで「何をフックにApplicationを作るか」の一種 ○ 指定したリポジトリのPRを検知してArgo CD Applicationを作成する apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: myapps spec: generators: - pullRequest: requeueAfterSeconds: 1800 github: # 接続先リポジトリの設定など

PR Generatorの活用（2/3） 14 ● つまり？ ○ manifestリポジトリでPR作ったらアプリが自動展開される ● 工夫したポイント ○ アプリ名は一意になるようにPR IDのprefixをつける ■ test-[PR ID]-web とか ○ アプリの展開先クラスタ名やエンドポイントはParameter Storeから取得 ■ Cluster Generatorと異なりアプリの展開先クラスタを明示する必要あり ○ アプリケーションへのアクセスは一意のドメイン + external-dnsで確保 ■ PR IDなどを使ってPR環境ごとに異なるドメインをRoute 53に登録

PR Generatorの活用（3/3） 15 ● PR Generatorでここまでできた Manifest (helmfile) Charts EKS (manager) Sync EKS (app) kubectl apply helmfileから生成された Manifest 1. PRを作成する 2. PRを検知して Applicationを作成する 3. アプリがデプロイされる Watch PR

ACKの活用（1/4） 16 ● ACKとは？ ○ Kubernetesマニフェスト形式でAWSリソースを管理できる ● 何が嬉しいの？ ○ AWSリソースを宣言的に定義 & GitOpsできる ○ こういうインスタントな利用に向いてそう apiVersion: s3.services.k8s.aws/v1alpha1 kind: Bucket metadata: name: bocchi-the-rock spec: name: bocchi-the-rock S3バケットをKubernetesマニフェストで管理できちゃう！

● どこで使うの？ ○ IRSA ■ PR Generatorで作ったアプリのNSを分けたく、SAも専用のものが必要 ■ IAM Role、IAM Policyも専用にしておきたい = 都度ACKで作成したい ○ 専用のAWSリソースを作りたいとき ■ PR番号のprefixをつけた各種AWSリソースを作成し、既存の環境と分離する ■ DynamoDB、SQSが（現状）対象 ACKの活用（2/4） 17

● どうやって使うの？ ○ 各種Controllerをデプロイする（AWSリソースごとにControllerがある） ■ IAM、DynamoDB、SQS ■ 詳しくはドキュメントをどうぞ ○ 各リソースのマニフェストを用意する ○ PR環境用なのでACK用のPR Generator ApplicationSetを用意する ACKの活用（3/4） 18

● 工夫したポイント ○ IRSA用のPR GeneratorだけGithubのポーリング間隔を短めに設定 ■ アプリケーションより先にSAの作成とIRSA設定をしたい ○ helmfile + raw manifests最強 ■ IRSAに必要なIAM Role, Policy, SA, NSをまとめて宣言 ACKの活用（4/4） 19 apiVersion: v1 kind: Namespace metadata: name: xxx --- apiVersion: iam.services.k8s.aws/v1alpha1 kind: Policy # IAM Policyの定義 — …

● 今までのやつらをどうやって組み合わせるの？ ○ コマンド1つでこれらを作成するようにGitHub Actionsで頑張る ○ Repository Dispatchを活用 ■ Debugつらみ ぐるー（1/2） 20

ぐるー（2/2） 21 開発者 Application PR Manifest (helmfile) Charts ECR EKS (manager) Sync 1. Comment 2. Build 4. Update & Create PR 3. Push 6. kubectl apply helmfileから生成された Manifest 5. Polling EKS (app)

おかたづけ 22 ● 削除方法 ○ 以下をまたGithub Actionsで頑張る... ■ アプリ側のPR closeをきっかけにマニフェスト側のPRを閉じる ■ ArgoCD Applicationを消す（と、諸々のリソースも全部消える） ■ （マニフェスト側のPRを先に閉じとかないと無限に復活する）

作ってみて、どう？ 23 ● 坂本さんの名言 ● 開発の方からも喜びの声をいただきました

● DBも個別にしたい ○ 今は全PR環境が共通のAuroraにアクセス ○ でもAuroraをACKで、は辛そうなのでMySQLコンテナかな... ● 細かい改善ポイントもろもろ ○ manifest側のbranch消えないから消さないと... ○ 定期的にゴミが残ってないかチェックしたい... 今後 24

まとめ 3

ACKを活用して使い捨てAWS検証環境を構築している話 26 ● 「test web使います」をなくしたかった ● ACKとPR Generatorを活用してPR環境を作れるようにした ● いい感じにできたっぽい！

ブログもさっき公開したよ 27 Chatwork Creator's Note で検索！

働くをもっと楽しく、創造的に