ACKを活用して 使い捨てAWS検証環境を構築している話

https://mixi.connpass.com/event/293351/
こちらの勉強会の資料です。

Transcript

1. © Chatwork ACKを活用して 使い捨てAWS検証環境を構築している話 Chatwork株式会社
2. 自己紹介 2 • 古屋 啓介 ◦ Chatwork株式会社 プロダクト本部 SRE部 ◦ AWS Community Builders (container) ◦ JAWS-UG SRE支部運営 ◦ ドラム叩きます
3. 前提と課題 やったこと まとめ 1 2 AGENDA アジェンダ 3
4. 前提と課題 1
5. （おさらい）前提 5 • Chatworkのインフラ構成 ◦ 大部分のアプリがEKS上で稼働 ◦ その他Aurora、Dynamo DB、SQSあたりがよく使われる
6. 開発環境におけるアプリケーション動作確認用インフラ 6 • ローカル ◦ 手元のマシンでdocker-composeなどを駆使 • 検証環境 ◦ 開発者が自由に使える検証用AWSアカウント（共用） ◦ 本番と同じフロー（Argo CD）でEKSにデプロイ＆動作確認
7. 開発検証環境の課題 7 検証用EKSクラスタが1つしかなく、同じアプリを複数起動できない AWS環境で検証したい場合は専有（順番待ち）する必要あり
8. モチベーション 8 これ、なくしたいな？
9. 機運 9 • Argo CDの統合でApplicationSetが利用可能に ◦ 1つのEKS内でアプリケーションが容易に複製可能 統合Argo CD、できたで さすさか神（さすが坂本さん、神です）
10. ということで 10 よっしゃ じゃあPR作ったらなんか環境ばーんって できるやつ（流行ってるし）やってみよう！
11. やったこと 2
12. • Argo CD ApplicationSet Pull Request Generatorの活用 • AWS Controllers for Kubernetes（ACK）の活用 やったこと 12
13. 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: # 接続先リポジトリの設定など
14. 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に登録
15. 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
16. 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マニフェストで管理できちゃう！
17. • どこで使うの？ ◦ IRSA ▪ PR Generatorで作ったアプリのNSを分けたく、SAも専用のものが必要 ▪ IAM Role、IAM Policyも専用にしておきたい = 都度ACKで作成したい ◦ 専用のAWSリソースを作りたいとき ▪ PR番号のprefixをつけた各種AWSリソースを作成し、既存の環境と分離する ▪ DynamoDB、SQSが（現状）対象 ACKの活用（2/4） 17
18. • どうやって使うの？ ◦ 各種Controllerをデプロイする（AWSリソースごとにControllerがある） ▪ IAM、DynamoDB、SQS ▪ 詳しくはドキュメントをどうぞ ◦ 各リソースのマニフェストを用意する ◦ PR環境用なのでACK用のPR Generator ApplicationSetを用意する ACKの活用（3/4） 18
19. • 工夫したポイント ◦ 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の定義 — …
20. • 今までのやつらをどうやって組み合わせるの？ ◦ コマンド1つでこれらを作成するようにGitHub Actionsで頑張る ◦ Repository Dispatchを活用 ▪ Debugつらみ ぐるー（1/2） 20
21. ぐるー（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. おかたづけ 22 • 削除方法 ◦ 以下をまたGithub Actionsで頑張る... ▪ アプリ側のPR closeをきっかけにマニフェスト側のPRを閉じる ▪ ArgoCD Applicationを消す（と、諸々のリソースも全部消える） ▪ （マニフェスト側のPRを先に閉じとかないと無限に復活する）
23. 作ってみて、どう？ 23 • 坂本さんの名言 • 開発の方からも喜びの声をいただきました
24. • DBも個別にしたい ◦ 今は全PR環境が共通のAuroraにアクセス ◦ でもAuroraをACKで、は辛そうなのでMySQLコンテナかな... • 細かい改善ポイントもろもろ ◦ manifest側のbranch消えないから消さないと... ◦ 定期的にゴミが残ってないかチェックしたい... 今後 24
25. まとめ 3
26. ACKを活用して使い捨てAWS検証環境を構築している話 26 • 「test web使います」をなくしたかった • ACKとPR Generatorを活用してPR環境を作れるようにした • いい感じにできたっぽい！
27. ブログもさっき公開したよ 27 Chatwork Creator's Note で検索！
28. 働くをもっと楽しく、創造的に