Download to read offline
![{
"environments": [
{
"env": "dev",
"name": "dev-dynamic-test",
"api_endpoint": "api-test.dev.example.com"
}
]
}
Configファイル](https://image.slidesharecdn.com/1-190829052822/85/JAWS-UG-15-Amazon-ECS-31-320.jpg)
![{
"environments": [
{
"env": "dev", // 固定、NativeでのAPNS等、外部APIのdev/stg/prd切り替え用
"name": "dev-dynamic-test",
"api_endpoint": "api-test.dev.example.com"
}
]
}
// 同一環境で複数のendpointもできます…
// api_endpointのキー名が変えられます…
Configファイル
static
prefix
branch
name
動的環境専用Zone
branch
name
static
prefix](https://image.slidesharecdn.com/1-190829052822/85/JAWS-UG-15-Amazon-ECS-32-320.jpg)
Uploaded byTamirlan Torgayev
JAWS-UG コンテナ支部 #15 - Amazon ECSの開発環境を動的に管理するツールを作ってみました
PRごとに専用のECS環境を動的に作成、削除できるツールを紹介します。作成経緯や社内での活用について紹介し、今後のロードマップやOSS化について話します。また、サイバーエージェントのインフラ周りのツールのOSS化プロジェクトについて紹介します。 Torgayev Tamirlan (@prog893) - クラウド技術アドバイザ, サイバーエージェント 技術本部 サービスリライアビリティーグループ
![[AWSマイスターシリーズ] AWS Elastic Beanstalk](https://cdn.slidesharecdn.com/ss_thumbnails/20131009aws-meister-regenerate-elasticbeanstalk-public-131014212455-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![Serverless Ninja Warriors [panel]](https://cdn.slidesharecdn.com/ss_thumbnails/20170908cross-170908151608-thumbnail.jpg?width=640&height=640&fit=bounds)
JAWS-UG コンテナ支部 #15 - Amazon ECSの開発環境を動的に管理するツールを作ってみました
- 1. Amazon ECSの開発環境を動的に 管理するツールを作ってみました 株式会社サイバーエージェント 技術本部サービスリライアビリティグループ クラウド技術アドバイザ Torgayev Tamirlan (@prog )
- 2. ⾃⼰紹介 • 2018年 サイバーエージェント新卒⼊社 •Cloud Technologies Advisor ＝ (SA+SRE+DevOps+Infra) / • AWA、REQU、タップル誕⽣、 CROSSMEなど担当 • 好きなもの: Terraform、Python、 Elasticsearch、Serverless ❤ • 好きなAWSのサービス: ECSTorgayev Tamirlan @prog
- 3.
- 4.
- 5. ECSを導⼊ • ECS簡単じゃん、楽じゃん、最⾼ • 導⼊してみよう •ええ感じやし、このままオンプレからAWSに移設しよう！ • わーい＼(^o^)∕
- 6.
- 7.
- 8.
- 9.
- 10. チーム開発 • localでfeature作った！ • リアルなDBとか周辺サービスとつなぎこんで、 AWS上でどう動くかマージする前に確認したい •x ⼈ • さらにiOS/Androidのdevアプリで動き⾒たい
- 11.
- 12.
- 13. 理想 • A/B testing(Feature Flags)、microservices、、etc. • ⼤きなアーキテクチャ変更... • いきなり導⼊するの難しい 😢
- 14. 現実：devxx⽅式 • オンプレ、VPS、EC などではよくみるアレ •同じdev環境を複数⽤意 • dev , dev , ..., devxx • これを「devxx⽅式」と私が勝⼿に呼んでます
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22. devxx ⽅式のメリット • オンプレ、VPS、物理サーバ運⽤経験者にとって学習コスト低い •横に全く同じサーバを⼀時的に増やして、Ansible的なのを流してDNS設定するだけ • 使ってないサーバはシャットダウンしておくなど • 使ってない環境のサーバはシャットダウンしてあればコストがかからない • 導⼊コスト低 • Feature Flagなどではないので環境を横でつくるだけ • コードの修正もいらない • ⼀つ⼀つの環境が完全に分離されている
- 23. devxx ⽅式のデメリット • 「あっ、devは私が使ってるから触らないで」のような 原始的コミュニケーション • チャットベースなどの管理 • 「dev環境全部割り当て表」 • 環境増減is⼿動 • 1環境 = ALB + ECS Service + Route レコード • 特にALBは、作成に時間もかかり、いるだけでprovisioningで課⾦される • 増減作業の⼿間 • お⾦がかかる • サーバシャットダウン忘れ、だるいからあえてシャットダウンしないなど • サーバ以外のリソース（LB、etc.）
- 24.
- 25. devxx ⽅式の⾃動化を考える • CloudFormation/Terraform/CDK •⼿動で今これでやっている • IaaCのソース⾃体がGit管理で、⾃動コミットとか⾃動apply怖い、やりたくない • ⾃前ツール • dev環境の増減するところをあえてIaaCで管理しないスタイル • さぁどうつくる
- 26. 動的devxx（仮） • devxx⽅式のメリットを活かしつつ、デメリットを解消 = コスト最適化しつつ、⾃動化する =ALB使い回し、それ以外はええ感じに⾃動化 • 1 環境 ( = environment) のライフサイクルを考える = featureの追加、修正は1つのPRで完結する場合が多いので、環境とPRは1:1の関係 = PRが作成されたら環境を作成、クローズorマージされたら削除
- 27. Introducing eden ECS DynamicEnvironment Manager
- 28. eden概要 • create/deleteの2コマンドのみ • 既存の環境へのcreateはTaskDefinitionの作成とdeployのみ • REST⾵ APIとCLIがあります • REST⾵ != RESTful • Reference (参照)となるECS Serviceを指定するとそれをパクってくれる • dev 的reference serviceはIaaC（Terraformなど）で管理想定 • 環境を作成するたびにDescribeを⾏う • dev を変更すれば、それ以降に作成された動的環境が新しい設定で作成される • 既存の環境を更新したければ、⼀旦delete
- 29. edenがつくるもの . ECS TaskDefinition . ALB Target Group . ECS Service . ALB Listener Rule（共通ALBにHostHeaderルール追加のみ） . Route CNAME record（共通ALBを指すだけ） . Configファイルの更新（後述） （環境削除は逆順）
- 30. Configファイル is 何 •開発アプリケーション（Web or Native）に、 どんな環境があるかを知らせるためのJSONファイル • 隠しメニューを出すとJSONから⽣成された環境⼀覧が出る • 環境が切り替えられる
- 31. { "environments": [ { "env": "dev", "name":"dev-dynamic-test", "api_endpoint": "api-test.dev.example.com" } ] } Configファイル
- 32. { "environments": [ { "env": "dev",// 固定、NativeでのAPNS等、外部APIのdev/stg/prd切り替え用 "name": "dev-dynamic-test", "api_endpoint": "api-test.dev.example.com" } ] } // 同一環境で複数のendpointもできます… // api_endpointのキー名が変えられます… Configファイル static prefix branch name 動的環境専用Zone branch name static prefix
- 33.
- 34.
- 35.
- 36. eden導⼊ - CLI •まずはCLIから • 環境作成3秒、削除2秒ぐらい • なお、既存の環境へのcreateはdeployするだけになるのでチョッパヤ • Task⼊れ替えはまた別の話…
- 37. eden導⼊ - API •eden REST API をデプロイした • ALB、Lambda、Python . + Flask、全部で1300⾏ぐらい • CIで、ビルドとECRへのpushが終わった直後に条件分岐追加 • commit: GET eden.example.com/v /create?branch=foo&image_uri=xxxxxx • merge: GET eden.example.com/v /delete?branch=foo • Native devアプリの環境選択メニュー変更 • Configファイルの中⾝を元に⽣成するよう変更 • dev (パクり元)/stg/prdはedenで管理されないので、⼿でConfigファイルに記述
- 38. eden導⼊ - 開発者の声 •感想 • 「⾃動デプロイでlead timeが短縮できる」 • 「Terraformのdev 以外のdevが消せる」 • 「利⽤が終わったdev環境にmaster流し直すとかしなくてもよくなった」 • Feedback • staleなPRの環境が⾃動的に削除されてほしい • どんな環境があるかの⼀覧がほしい
- 39.
- 40.
- 41.
- 42.
- 43. Baikonur Project • TerraformModuleや各種ツールの共通化、OSS化プロジェクト • https://github.com/baikonur-oss/docs • PR⼤歓迎！コントリビュータ募集中！ • Terraform Moduleも随時募集中 • 相談やお問い合わせは、 各レポジトリの Issue か@prog まで edenつくるの誰か⼿伝って…
- 45.
- 46.
- 47.
- 48. Baikonur eden • aws-eden-core •APIとCLIの共通部分 • aws-eden-cli • CLIツール • pip install aws-eden-cliでインストールできる • インストール後 eden で実⾏できる • eden API • Lambda + Terraform module
- 49. 開発ロードマップ サービス側からのFBで出た要望を元に、改善して完成度を上げていく • 作成された環境のstateを持つ • DynamoDBで管理 •「Target group name cannot be longer than ' ' characters」回避⽤branch名略称登録 • stale environment auto-cleaner • 放置されてそうなブランチのenvを消すやつ • e.g. ⽇以上デプロイがない開発環境を削除 • remote-ls • 環境⼀覧出すやつ
- 50. 開発ロードマップ (cont.) • ここまでできたら、他のサービスへの導⼊ができる •導⼊サービス増やしていく • そしてまたFBもらって開発を回す
- 51. まとめ • ECS Serviceとか環境⼀式を（literally）秒で作成、削除できるツール作った •かなり反響がよかった • 管理コスト、リソースコストが削減可能 • OSS化しました • が、ハッカソンのノリで作った💩を綺麗に作り直さないといけない • 設計を考え直して、コードを清書したい • ⼿伝ってくれるニキいないかな👀
- 52.