Laravel/Vue.js勉強会を開催しました!

6/21(水)に Laravel/Vue.jsの勉強会を開催いたしました!

f:id:kotamat:20170622101837j:plain

会場は株式会社オルトプラス様

勉強会用にオフィスを無料で開放していただけるとのことで、今回使わせていただきました!

Laravel/Vue.jsともに人気が上昇中していたり、Laravelの公式がVue.jsをサポートし始めたりと、人口は増加しているにもかかわらず、他のフレームワークに比べて勉強会等がほとんど開催されていないということで、勉強会を開催することとなりました。

勉強会を公募した際、思った以上に反響が大きく、2日で80名を超える応募がありました。

[増席しました!]Laravel/Vue勉強会#1 - connpass

当日も強風、雨の足元の悪い中、30人以上の方にご参加頂きました。

今回はLaravel / Vue.jsを実際に導入されている4社の技術者の方々から実例やお話をしていただき、その後LT参加枠の方から3名LTをお話していただきました。

f:id:kotamat:20170622101206j:plain

f:id:kotamat:20170622095543j:plain

f:id:kotamat:20170622101245j:plain

 

f:id:kotamat:20170622101338j:plain

 

発表後は懇親会を行いました。

f:id:kotamat:20170622102301j:plain

f:id:kotamat:20170622102254j:plain

自社で導入されている方や、これから勉強されるという方等多種多様な方がいらっしゃいました。

今後も勉強会を開いていければと思いますので、興味のある方はご連絡いただければと思います!

 

## 最後に‥

弊社SCOUTERではLaravel / Reactを使ってサービスを展開しております。
興味のある方、ご応募お待ちしております!

Laravel

https://www.wantedly.com/projects/101401

React

https://www.wantedly.com/projects/101403

 

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

はじめに

株式会社SCOUTERの松本です。

この度弊社でもエンジニアの発信をするために開発者ブログをはじめました!

ブログは持ち回りで書いていくのですが、書くに当って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と同じようなコマンドで環境構築が可能

全体像

全体図はこんな感じです

f:id:kotamat:20170618222936p:plain

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のコンソールで設定を行います。

f:id:kotamat:20170618223152p:plain

yamlファイルをアップロードし

f:id:kotamat:20170618223215p:plain

パラメータを設定します。

f:id:kotamat:20170618223219p:plain

各パラメータの説明は下記です

  • AcceptCidrIp
    • アクセス元のIP、基本的に社内ネットワークになるかとおもいます
  • DesiredCapacity
  • InstanceType
  • KeyName
  • MaxSize
  • MyCertificateArn
    • CertificateManagerで設定した値

f:id:kotamat:20170618223233p:plain

起動完了後、出力のところに各値が出力されます。こちらはあとで使用します。

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

https://www.wantedly.com/projects/101403