はじめに
株式会社SCOUTERの松本(id:kotamat) です。
この度弊社でもエンジニアの発信をするために開発者ブログをはじめました！
ブログは持ち回りで書いていくのですが、書くに当ってwebhook等実装の検証をする必要が出てくるかと思います。ただ現状として
- 個々人はローカルで開発している
- そのため外部サービスからのアクセスを前提としたサービスの検証が難しい
- 各々にHTTPSのエンドポイントを提供し、検証環境をつくりたい
- とはいえ、各々の環境構築、管理を煩雑にしたくない
ということで、AWS ECS + ALB + ACMを使った環境構築を行いました。
CloudFormationを使用して上記環境を作ることで、環境構築・削除ができるようにしています。
出来ること
engineer_1.dev.example.com,engineer_2.dev.example.comのような形で、エンジニア毎にドメインを割り振れる- 各々のドメインに対して、Dockerのサービスベース(docker-compose.yml単位)でサービスを割り当てられる
- HTTPS化ができる
- エンジニアは
docker-compose up -dと同じようなコマンドで環境構築が可能
全体像
全体図はこんな感じです
ALBとなっているところは、下記のようになっています
- ALB、リスナーは一つ
- ターゲットグループはサービス毎に存在
- リスナーロールは443(HTTPS)と80(HTTP)それぞれサービスごとに存在
- HTTPSのリスナーロールには、CertificateManagerで生成した証明書を設定。
また、こちらは検証用の環境で、他の環境とは独立したものとなっているので、VPCは新規で作成します。
設定方法
事前準備
- ドメインをRoute53で管理するようにする
- *.dev.example.comに対する証明書をCertificate Managerを使用して作成
各種AWSサービスの起動
https://github.com/kotamat/ecs_dev のcloud-formation.ymlを参考にサービスを起動します。
yamlファイルの変更
ターゲットグループはサービス毎に存在
リスナーロールは443(HTTPS)と80(HTTP)それぞれサービスごとに存在
という仕様があるため、開発者に併せてそれぞれの設定を行う必要があります。
設定自体は###developers###というコメントアウトの間に格納しており、 初期ではengineer1.dev.example.comの設定をしているので、必要に応じて下記のように変更、追記をしてください。
kotamatに変更する場合)
### developers ### -#### engineer1 - engineer1ECSALBListenerRule: +#### kotamat + kotamatECSALBListenerRule: Type: AWS::ElasticLoadBalancingV2::ListenerRule DependsOn: ALBListener Properties: Actions: - Type: forward - TargetGroupArn: !Ref engineer1ECSTG + TargetGroupArn: !Ref kotamatECSTG Conditions: - Field: host-header - Values: [engineer1.dev.example.com] + Values: [kotamat.dev.example.com] ListenerArn: !Ref ALBListener Priority: 1 - engineer1ECSALBListenerRule: + kotamatECSALBListenerRule: Type: AWS::ElasticLoadBalancingV2::ListenerRule DependsOn: SSLALBListener Properties: Actions: - Type: forward - TargetGroupArn: !Ref engineer1ECSTG + TargetGroupArn: !Ref kotamatECSTG Conditions: - Field: host-header - Values: [engineer1.dev.example.com] + Values: [kotamat.dev.example.com] ListenerArn: !Ref SSLALBListener Priority: 1 - engineer1ECSTG: + kotamatECSTG: Type: AWS::ElasticLoadBalancingV2::TargetGroup DependsOn: ECSALB Properties: @@ -335,7 +335,7 @@ Resources: HealthCheckProtocol: HTTP HealthCheckTimeoutSeconds: 5 HealthyThresholdCount: 2 - Name: !Join [ "-", [ !Ref "AWS::StackName", engineer1ECSTG ] ] + Name: !Join [ "-", [ !Ref "AWS::StackName", kotamatECSTG ] ] Port: 80 Protocol: HTTP UnhealthyThresholdCount: 2 @@ -349,5 +349,5 @@ Outputs: Value: !Join ['', [!GetAtt [ECSALB, DNSName]]] ECSServiceRole: Value: !Ref ECSServiceRole - engineer1TG: - Value: !Ref engineer1ECSTG + kotamatTG: + Value: !Ref kotamatECSTG
CloudFormationの設定
まずはCloudFormationのコンソールで設定を行います。
yamlファイルをアップロードし
パラメータを設定します。
各パラメータの説明は下記です
- AcceptCidrIp
- アクセス元のIP、基本的に社内ネットワークになるかとおもいます
- DesiredCapacity
- インスタンスの希望数
- InstanceType
- インスタンスの種類 t2.micro等
- KeyName
- インスタンスアクセスのためのpemキー名
- MaxSize
- インスタンスの最大数
- MyCertificateArn
- CertificateManagerで設定した値
起動完了後、出力のところに各値が出力されます。こちらはあとで使用します。
Route53の設定
起動が完了したタイミングで、ロードバランサーが作成されるので、先程の出力のECSALBをRoute53の*.dev.example.comのAレコードへエイリアスとして設定します。
開発者側の設定
ecs-cliのインストール
ecs-cliインストールを参考にインストールを行います。
踏み台サーバーにECS, ECR管理ポリシーを与えたロールを与えるか、開発者に該当のポリシーを持ったIAMユーザを作成し、access-keyとaccess-secretを付与します。
先程取得したクラスタ名を使用し
ecs-cli configure -c <クラスタ名> --access-key <アクセスキー> --secret-key <シークレットキー>で登録します。
サービスの起動
ECSには動的ポートという便利な機能があります。
動的ポートを設定することで、コンテナポートを直接ターゲットグループに割り当てられるようになり、ホスト側のポートの競合を意識することなくサービスを展開できるようになります。
docker-compose.ymlを用意し、下記の変更を行います。
- hostのポート番号を
0とする(動的ポート) build等ECS側で使用できないものがある場合はECRにビルドしたイメージをpushし、imageとして使用する
変更を行ったら、下記コマンドを実行します。
ecs-cli compose --file docker-compose.yml service up --target-group-arn <ターゲットグループ名> --container-port <コンテナのポート> --role <サービスロール名>
コンテナが起動したらengineer1.dev.example.comにアクセスすることでサービスを見ることができるようになります。
まとめ
ECS ALB等を使用することで、開発検証環境を簡単に作成できるようになりました。
今回だとインスタンスがオンデマンドとなりますが、SpotFleetと組み合わせる事で、より安価に検証環境を作成できるようになるので、そちらもチャレンジしてみたいです。
最後に‥
弊社SCOUTERではLaravel / Reactを使ってサービスを展開しております。 興味のある方、ご応募お待ちしております！
Laravel
https://www.wantedly.com/projects/101401
React
