Upgrade to Pro — share decks privately, control downloads, hide ads and more …

JAWS-UG コンテナ支部 #15 - Amazon ECSの開発環境を動的に管理するツール...

JAWS-UG コンテナ支部 #15 - Amazon ECSの開発環境を動的に管理するツールを作ってみました

PRごとに専用のECS環境を動的に作成、削除できるツールを紹介します。作成経緯や社内での活用について紹介し、今後のロードマップやOSS化について話します。また、サイバーエージェントのインフラ周りのツールのOSS化プロジェクトについて紹介します。

Torgayev Tamirlan (@prog893) - クラウド技術アドバイザ, サイバーエージェント 技術本部 サービスリライアビリティーグループ

Tamirlan 893 Torgayev

August 29, 2019
Tweet

More Decks by Tamirlan 893 Torgayev

Other Decks in Programming

Transcript

  1. ⾃⼰紹介 • 2018年 サイバーエージェント新卒⼊社 • Cloud Technologies Advisor = (SA+SRE+DevOps+Infra)

    / • AWA、REQU、タップル誕⽣、
 CROSSMEなど担当 • 好きなもの: Terraform、Python、 Elasticsearch、Serverless ❤ • 好きなAWSのサービス: ECS Torgayev Tamirlan @prog
  2. dev環境がまた増える 眠れない夜 疲労 涙 割り当て表管理 原始的コミュニケーション コンフリクト 残業 ⼿動デプロイ 汗

    prodまでのlead time延⻑ dev環境がまた増える イライラ Apply Failed dev環境10以上 誰も知らないエンドポイント 腐る環境 余分なコスト Toil 設定差分 Build Failed ※イメージです
  3. devxx ⽅式のデメリット • 「あっ、dev は私が使ってるから触らないで」のような
 原始的コミュニケーション • チャットベースなどの管理 • 「dev環境全部割り当て表」

    • 環境増減is⼿動 • 1環境 = ALB + ECS Service + Route レコード • 特にALBは、作成に時間もかかり、いるだけでprovisioningで課⾦される • 増減作業の⼿間 • お⾦がかかる • サーバシャットダウン忘れ、だるいからあえてシャットダウンしないなど • サーバ以外のリソース(LB、etc.)
  4. 動的devxx(仮) • devxx⽅式のメリットを活かしつつ、デメリットを解消 = コスト最適化しつつ、⾃動化する = ALB使い回し、それ以外はええ感じに⾃動化 • 1 環境

    ( = environment) のライフサイクルを考える = featureの追加、修正は1つのPRで完結する場合が多いので、環境とPRは1:1の関係 = PRが作成されたら環境を作成、クローズorマージされたら削除
  5. eden概要 • create/deleteの2コマンドのみ • 既存の環境へのcreateはTask Definitionの作成とdeployのみ • REST⾵ APIとCLIがあります •

    REST⾵ != RESTful • Reference (参照)となるECS Serviceを指定するとそれをパクってくれる • dev 的reference serviceはIaaC(Terraformなど)で管理想定 • 環境を作成するたびにDescribeを⾏う • dev を変更すれば、それ以降に作成された動的環境が新しい設定で作成される • 既存の環境を更新したければ、⼀旦delete
  6. edenがつくるもの . ECS Task Definition . ALB Target Group .

    ECS Service . ALB Listener Rule(共通ALBにHostHeaderルール追加のみ) . Route CNAME record(共通ALBを指すだけ) . Configファイルの更新(後述) (環境削除は逆順)
  7. { "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
  8. 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ファイルに記述
  9. eden導⼊ - 開発者の声 • 感想 • 「⾃動デプロイでlead timeが短縮できる」 • 「Terraformのdev

    以外のdevが消せる」 • 「利⽤が終わったdev環境にmaster流し直すとかしなくてもよくなった」 • Feedback • staleなPRの環境が⾃動的に削除されてほしい • どんな環境があるかの⼀覧がほしい
  10. Baikonur Project • Terraform Moduleや各種ツールの共通化、OSS化プロジェクト • https://github.com/baikonur-oss/docs • PR⼤歓迎!コントリビュータ募集中! •

    Terraform Moduleも随時募集中 • 相談やお問い合わせは、
 各レポジトリの Issue か@prog まで edenつくるの誰か⼿伝って…
  11. Baikonur eden • aws-eden-core • APIとCLIの共通部分 • aws-eden-cli • CLIツール

    • pip install aws-eden-cliでインストールできる • インストール後 eden で実⾏できる • eden API • Lambda + Terraform module
  12. 開発ロードマップ サービス側からのFBで出た要望を元に、改善して完成度を上げていく • 作成された環境のstateを持つ • DynamoDBで管理 • 「Target group name

    cannot be longer than ' ' characters」回避⽤branch名略称登録 • stale environment auto-cleaner • 放置されてそうなブランチのenvを消すやつ • e.g. ⽇以上デプロイがない開発環境を削除 • remote-ls • 環境⼀覧出すやつ
  13. まとめ • ECS Serviceとか環境⼀式を(literally)秒で作成、削除できるツール作った • かなり反響がよかった • 管理コスト、リソースコストが削減可能 • OSS化しました

    • が、ハッカソンのノリで作ったを綺麗に作り直さないといけない • 設計を考え直して、コードを清書したい • ⼿伝ってくれるニキいないかな