エンジニア一人ひとりの検証環境をAWSECSを使って実装してみる

はじめに

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に変更する場合)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 ### 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インストール](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ECS_CLI_installation.html)を参考にインス[トールを行います。

踏み台サーバーに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と組み合わせる事で、より安価に検証環境を作成できるようになるので、そちらもチャレンジしてみたいです。

Contents