Speee開発基盤部、兼ヌリカエエンジニアの森岡です。 今回は、ECSを使ってPR毎に確認環境を構築する社内ツールであるwebapp-revieee をOSSとして公開しましたので、そのご紹介をさせて頂きます。
作ったもの
PRを作ると、そのPRに対応した確認環境がECS上に構築され、PRに構築した確認環境にアクセスするためのURLがコメントされます。 ここで構築された確認環境は、PRがcloseされると一緒に閉じられます。主にデザイナの画面確認や、制作物のPOレビューなどが捗ります。 この社内ツールは一つのプロダクトだけでなく、社内のすべてのプロダクトの確認環境を用意することが可能です。 この社内ツールは、Webapp Revieeeという名前で開発されました。
作った理由
今回このような社内ツールを作った背景として、確認環境の構築に時間的、金銭的コストを掛けたくない。 という理由があります。私が所属しているヌリカエというプロダクトにおいても、 確認環境がいくつか存在しています。しかもそれらの環境は、常に誰かが利用していて、 順番待ちが発生することが少なくありません。
この問題を解決する外部サービスとして、Heroku review appsというものが存在します。 当初このサービスの利用を検討したのですが、下記の理由で断念しました。
- Elasticsearchなどのミドルウェアのバージョンを指定できない
- 他のdynoと直接通信できないため、microservices の確認環境を構築できない
- 本番環境ともローカル環境とも異なる環境なので、Heroku特有の問題に悩まされることがある
- Enterpise でなければ、IP制限を入れることができない
また、OSSでもdtan4 さんが開発されているpausというものがあります。 こちらは docker swarmを使ってEC2上で動いているのですが、docker swarmのクラスタ管理が手間であったり、 containerのログ取得が出来ないといった問題が存在します。 現在ではECSやGKEを利用すれば、この問題に対応できそうだったので、僕たちは自作するという選択肢を取りました。 そして下記の理由からECSを採用しました。
- GKEとECSでは、実現できる機能に大きな差異は無い
- 弊社ではGCPよりもAWSを利用しているプロダクトが多い
- ユースケースを踏まえて料金を見積もったときに、AWSの方が20%ほどやすかった
Webapp Revieeeの使い方(理想)
Webapp Revieeeは、社内のプロダクトで単純なrailsアプリケーションならば、 webhookを受け取るためのbotをリポジトリに招待するだけで使えます。 また、ユーザーはdockerに対する知識が無くとも、簡単に確認環境を構築することが出来ます。
というシステムを作るという理想を持って、僕たちはWebapp Revieeeの開発を開始しました。
Webapp Revieeeの構成
Webapp Revieeeの構成図を上に乗せます。Webapp Revieeeは、app server, nginx, ECS, mysql instance, ECRの5つの要素からなります。 各要素の役割について、コンテナのデプロイと、確認環境へのアクセスを例に説明していきたいと思います。
コンテナのデプロイ
- app_serverは、GitHubにてPRが作られた際にwebhookを受取ります
- app_serverはPRが持つbranch情報を、起動するtaskに渡し、ECSのinstanceにデプロイします
- containerをデプロイした ECS instanceのIPと、containerのport番号を MySQL に保存します。
- 確認環境にアクセスするためのURLをGitHubの該当PRにコメントする
上記操作によって、確認環境がECS上に構築されます。 このとき、コンテナのentrypointは下記のようにしています。
タスク起動時にPRのbranch名を渡すことによって、任意のbranchでコンテナが起動するようにしています。
確認環境へのアクセス
- ユーザーは、GitHubのPRにてコメントされる確認環境のURLにアクセスする
- nginxはURLに該当するcontainerのアクセス情報をMySQLから取得して、ユーザーをそちらに流す
nginxからMySQLへのアクセスにはluaを使っています。
Webapp Revieee の使い方(現状)
- Docker Imageを作成しECRに登録
- Task Definitionの設定ファイルを作成
- GitHubリポジトリにbotを招待
- PRを作成
現状では、Docker ImageのECRへの登録をユーザーが行うようにしています。 理由としては、開発環境で必要な MySQL等の初期データ投入等、プロダクト側でImageの更新をハンドリングしたいからです。
Task Definitionの設定ファイル作成もユーザーにやって貰っています。 Docker Imageを作成する課程で、ほぼほぼ docker-compose.ymlを作ってもらえているはずなので、 そのdocker-compose.ymlを元にecs-cliを使って、Task Definitionを作る方法もあります。 しかし、今回は下記の理由により直接書いてもらう方法に落ち着きました。
ecs-cli compose
は現状では、docker-compose のver3に対応していない- memory制限やlogging driverの設定など、docker-composeの設定を手元とECS環境で書き分ける必要がある
- 自動化する前に素朴な仕組みで実現し、データを集めることで自動化するべき方向性を見極めたい
そこまでユーザー側が設定を完了させたのちに、botをGitHubリポジトリに招待して貰うことによって、本サービスは利用が可能となります。
今後の展望
僕たちのWebapp Revieeeは、ようやく社内で利用され始めた段階です。 現状ではまだまだ荒削りな状態で、運用や設定において手間であったり、 痒いところに手が届かない部分はあるかと思います。 今後は、僕たちのサービスを使ってくれる現場の声を聞きながら、自動化するべき点は自動化し、 エンジニアがいじりたいところはいじれるようにし、より便利に使ってもらえるように開発を進めていきたいと考えています。
同時に、Webapp RevieeeはOSSで開発しておりますので、アプリケーションのコードだけでなく、 本システムを構築する上で必要な設定も、どしどし公開していきたいと考えています。 Webapp Revieeeに対する要望やコードのイケてない部分、より良い実装方法等ありましたら、issue等で教えて頂けると幸いです。
最後に
本OSSはクリアコードの須藤さんに見て頂きながら、開発を進めていきました。 そのときの様子などは、クリアコードさんのOSS開発支援サービス事例の記事 にも記載されておりますので、そちらの方を参照下さい。
須藤さんには、OSSとしての開発の仕方だけでなく、適切なコミットメッセージの書き方、 コードレビューの仕方、Rubyでの設計など、様々な方面でご指導して頂きました。 本当にありがとうございます!