Amazon API Gateway にカスタムドメインを設定する

概要

Amazon API Gateway に独自ドメインを設定しアクセス可能にします。
SSL証明書は AWS Certificate Manager を利用します。

前提条件

この記事の内容を実践する為に必要な前提条件です。

  • 公開可能済のAPI Gatewayが存在している事
  • 利用可能なドメインを取得している事
  • AWS Certificate ManagerでSSL証明書が準備されている事

前提条件1 API Gatewayの準備

API Gatewayの準備ですが、Serverless Framework を使うと簡単に用意出来るのでオススメです。
以前、 Serverless Frameworkのインストールと初期設定 という記事を書きましたので参考になると幸いです。

前提条件2 利用可能なドメインを取得する

Route 53でドメインを購入すると全てがAWSのサービスで管理出来る事になるのでオススメです。
ドメインの購入方法等は下記の記事に載せてありますので参考にして頂けると幸いです。

前提条件3 AWS Certificate ManagerでSSL証明書を準備する

手順に関しては難しくありません、 AWSのサービスでドメインを取得しALBでSSLで接続出来るようにする に取得方法を記載してあります。

1点だけ注意点があります。それは証明書を配置する region は必ず us-east-1 米国東部(バージニア北部) にする事です。

2017-06-15 現在の時点では AWS Certificate Manager の証明書を利用する為には、証明書が us-east-1 米国東部(バージニア北部) に配置されている必要があります。

API Gatewayにカスタムドメインの設定を行う

マネジメントコンソール → Amazon API Gateway → +カスタムドメイン名の作成 より設定を行います。

以下の情報を入力します。

  • ドメイン名: 任意のドメイン名を入力します
  • ACM 証明書: 作成した証明書を選択します
  • ベースマッピング: 作成したどのAPI Gatewayにマッピングさせるかを選択します

custom-domain1.png

「保存」を押すと作成が開始されます。(かなり時間がかかります)

しばらくすると下記のような形になります。
この「ディストリビューションドメイン名」という箇所をコピーしましょう。

custom-domain2.png

ディストリビューションドメイン名をRoute 53に設定する

DNSレコードの設定を行っていきます。

私の場合はAPI Gatewayに設定したドメインは 元々持っていたドメインのサブドメインとして設定を行いました。

その為、元々のHosted zoneにAレコードとして登録を行います。

Name: 設定したドメイン名を入力
Alias Target: 先程コピーしたディストリビューションドメイン名

custom-domain3.png

このあたりの方法に関しては AWSのサービスでドメインを取得しALBでSSLで接続出来るようにする でも方法を紹介しています。

動作確認

最後に動作確認を行います。

自動で割り当てられるURLで接続
curl -v https://i99999999i.execute-api.ap-northeast-1.amazonaws.com/development/other
設定したカスタムドメインで接続
curl -v https://api-gateway.hoge.org/other

両方で同じ内容が返ってくれば成功になります。

以上になります。最後まで読んで頂きありがとうございました。

続きを読む

AWS ALBはWebDAVを通してくれるのか?

長いので先に結論

結論を先に書くと、ALBはWebDAVを通してくれます。よかったですね。

素朴な疑問

AWSの新しいロードバランサ、Application Load Balancer(ALB)がリリースされました1
プロトコル面ではWebSocketやHTTP/2のサポートなどが目新しいところですけども、果たしてWebDAVは通るんだろうか?
と云うわけで調べてみたものの、意外にも類例が見つからなかったので試してみました。

やってみた

テスト構成

今回は以下の構成でテストを行いました。

構成図

セキュリティグループ、ターゲットグループ、ACM(SSL)の設定は割愛します。

EC2インスタンスの設定

下記構成のEC2インスタンスを2つ作成し、各サブネットに1つずつ配置しました。

EC2インスタンスのOSはAmazon Linux2を使用しました。
インストールしたパッケージはhttpd24のみです。
http24の設定ファイルには手を加えず、/etc/httpd/conf.d/webdav.confファイルを作成し下記内容を追加しています。

webdav.conf
DavLockDB /tmp/DavLock

Alias /dav/ /var/www/dav/

<Directory "/var/www/dav/">
    Dav on

    Options None
    AllowOverride None

    AuthType Basic
    AuthName WebDAVoverALBTest
    AuthUserFile /var/www/.htpasswd

    <RequireAll>
        Require valid-user
    </RequireAll>
</Directory>

WebDAVのローカルディレクトリは/var/www/dav/、HTTP上のディレクトリは/dav/になるよう設定しています。また/healthcheckでヘルスチェックできるようにしています。

ALBの設定

次にELBの作成に移ります。
まずはロードバランサタイプの選択から。もちろんここはALBを選びます。
ロードバランサタイプの選択

ロードバランサの設定は前述の構成通りに行います。
ステップ1

SSL証明書の設定。ここでは事前にACMで作成したものを使用しました。
ステップ2

セキュリティグループの設定。HTTPSが開いているだけのものを事前に作成してあります。
ステップ3

ルーティングの設定。
ステップ4

ターゲットの登録。EC2インスタンスは事前にターゲットグループへ登録済みです。
ステップ5

作成の確認。
ステップ6

ALBを作成しましたので、続いて「ルールの表示/編集」に移ります。
ロードバランサ一覧

ルールを追加し、/dev/fuga/へのアクセスは2つ目のターゲットグループへフォワードするよう設定します。
ルールの編集
ルール保存完了

手元の環境では、上記の設定でWebDAVの読み書きが2つのEC2インスタンスに振り分けられることを確認しました。

あとがき

今どきWebDAVを採用する機会は少ないでしょうし、ましてや同一ホスト名で複数サーバに振り分ける用途がどれだけあるかは分かりませんが、参考になれば幸いです。

注釈


  1. 「新しい」と云っても、すでに発表から10ヶ月(本稿執筆時点)経ちましたが‥‥‥ 

  2. 本稿執筆時点では2017.03 

続きを読む

AWS ソリューションアーキテクトプロフェッショナル 受けてきました&勉強法(2017/6版)

前書き

image.png

 前回 の続きです。ソリューションアーキテクトアソシエイト(SAA)に受かったので今度はプロフェッショナル(SAP)に挑戦しました。

AWS の資格試験はわかりにくい

ワークショップについて

 公式サイトから読み取れないので補足。以下のクラスがありますが、

レベル/分野 アーキテクト 開発 運用
アソシエイト取得済み Advanced Architecting on AWS DevOps Engineering on AWS 同左
アソシエイト未取得向け Architecting on AWS Developing on AWS Systems Operations on AWS
AWS 未経験者向け Amazon Web Services 実践入門 1 / 2 同左 同左

 前提事項は記載ありるものの、いきなり Advanced などを受けてもいいし、受けずに受験に挑んでも大丈夫です。アソシエイト未取得向けのを2つ受ける必要はなさそうなので、Architecting 受けてから Developing 受けたりするのは、けっこう内容の重複がある ので、お金がもったいない。
 その他のクラスは試験に出てくる頻度が低いので、興味があれば受ければいいやつです。

 ソリューションアーキテクトアソシエイト(SAA) だけは試験対策として半日のワークショップがありますので、時間とお金があれば受けるといいかと。

認定試験について

 おさらいですが。
image.png

 ワークショップと同じく、範囲がかぶっているので アソシエイト取れたらほかのアソシエイトもいけそう なので、資格の数を増やすにはよさそうです、プロフェッショナルはそう簡単にいかないですが。英語版の資格として Advanced Networking 、Big Dataが追加となっています。Security(Beta) もあった気がしますが、 Beta が取れていないのかな。いずれさらに上の階級にある Master が提供されるかもしれないという噂があったりします。

試験概要

 概要をざっくり記載します。アソシエイトの倍の時間でついでに受験料も倍です。合格ラインはやはり65%という噂です。1問あたり2分ちょっとで解き、3時間集中し続ける というなかなかヘビーな内容です。

TOPIC DATA
試験時間 170分間
問題数 80問
合格ライン 非公開
受験料 ¥32,400

出題範囲

 出題範囲を確認すると、アソシエイトでは高可用性がほとんどでしたが、Pro では求められるものが変わっていることがわかります。そのほか試験ガイドをざっと読みました。

TOPIC 出題率
高可用性および事業継続性 15%
原価計算 5%
デプロイメントマネージメント 10%
ネットワーク設計 10%
データストレージ 15%
セキュリティ 20%
拡張性と伸縮自在性 15%
クラウド移行およびハイブリッドなアーキテクチャ 10%

学習

セミナーを受講する

 前述の Advanced Architecting on AWS を受講しました。
 セミナーには AWS 社員の方や、AWS をすでに実務で利用されているかたが多くいて、私のような素人も半分くらいいる印象でした。私は実業務で AWS に触れたことが実はほとんどなく、本気の AWS 運用に必要な知識を持ち合わせていなかったので次のような観点が非常に勉強になりました。

  • ユーザ管理:IAM と ADやフェデレーションでの連携を考慮し、大規模運用を考える
  • コスト観点:一括請求やスポットインスタンスの選び方で、大幅なコスト削減を考える
  • 運用・監査:KMSを使用した暗号化、CloudLogs でのロギング、ClodWatch でのモニタリングで運用・監査への対応を考える
  • 可用性・セキュリティ:大規模&複数VPCのデザイン、MultiAZ、MultiRegion で可用性向上を実現する、DDoS からインフラを保護する

AWS 活用資料集(BalckBelt)、WhitePaper を読む

 アップデートもあるので、改めて時間を見つけて読みました。時間があるときは Webinar にも参加しました。 Webinar だと日々疑問に思っていることの質問を AWS の SA に直接質問できるので、すごくおトクです。

  • BlackBelt

    • Amazon EC2
    • Elastic Load Balancing
    • Auto Scaling
    • Amazon EC2 Container Service
    • AWS Elastic Beanstalk
    • AWS Lambda
    • Amazon EBS
    • Amazon S3
    • Amazon CloudFront
    • Amazon Glacier
    • AWS Storage Gateway
    • Amazon Elastic File System
    • AWS CloudTrail & AWS Config
    • AWS Support & Trusted Advisor
    • AWS Directory Service
  • WhitePaper

    • セキュリティのベストプラクティス
    • セキュリティプロセスの概要
    • リスクとコンプライアンス
    • AWS を用いた故障耐障害性の高いアプリケーションの構築
    • 新しいリージョンへの AWS リソースの移行
    • 災害対策目的での AWS の使用

本読む

 AWS 事例全集 といった AWS が配っている冊子もありますが数がひたすら多いので、勉強用としてこちらの本で一般的なアーキテクチャを学びました。

image
Amazon Web Services 定番業務システム12パターン 設計ガイド

試験に向けて

 以下、結果もあわせて書いていきます。

サンプル問題集にチャレンジ

ソリューションアーキテクト プロフェッショナル

 サンプル問題を解いた結果、微妙でした。アソシエイトは本試験とくらべて非常に簡単だったので、先が思いやられます。

結果

4/6問 正解

ソリューションアーキテクト以外もやってみる

 SysOpsアソシエイト、DevOpsアソシエイトのサンプル問題もやってみました。ソリューションアーキテクトとはちょっと毛色の違うサービス(CloudFormationとかSQSとか)が出てくるので復習になります。Pro は回答が書いていなかったのでやっていません。

SysOps結果

6/10問 正解

DevOps結果

6/9問 正解

模擬試験

 データ書いておきます。なお、アソシエイト合格者はバウチャーコードが利用できますので活用しましょう。問題文はコピーできます。

TOPIC DATA
試験時間 90分間
問題数 40問
合格ライン 明記なし
受験料 ¥4,320

結果

得点: 27%
結果: 不合格

 時間足りなさすぎました。結果を分析しますが全体的に悪すぎて手のうちようがない感じでした。。。

TOPIC 出題率 正解率(模擬結果) 模擬出題数(予測) 誤答数(予想)
高可用性および事業継続性 15% 33% 6 4
原価計算 5% 0% 2 2
デプロイメントマネージメント 10% 0% 4 4
ネットワーク設計 10% 50% 4 2
データストレージ 15% 50% 6 3
セキュリティ 20% 25% 8 6
拡張性と伸縮自在性 15% 16% 6 5
クラウド移行およびハイブリッドなアーキテクチャ 10% 25% 4 3

出題傾向を抑える

 ベストプラクティスが複数書いてあって、どれも正解だけどよりベストなものを選ぶという問題や、コスト/可用性/移行期間/既存システムとの連携 のどれが求められているのかといった、真の目的を把握しないと答えられない問題が多くありました。
 また、昔の AWS 構成を最新のサービスで置き換えるような問題もあるため、古くなった知識はアップデートが必要です。

模擬試験の復習と弱点克服

 CloudHSM とかの暗号化系、DirectConnect/StorageGateway などの低レイヤー系、TrustedAdvisor など課金系、STS/IAMロールなどの認証系、StepFunctions や SWF などフロー系、Redshift や Kinesis などのBigData系 は、アソシエイトでも踏み込んだ問題が出なかったので個人的に苦手でした。これらは BlackBeltで復習しました。
 また、コピーした模試の問題はを1つづつ調べ、答え合わせをしました。模擬試験については本試験でも出ることがあるので暗記するつもりで復習しました。英語で回答を解説しているサイトがあるので大いに活用しました。

本試験

結果

合格!

image.png

内訳

総合スコア: 66%

トピックレベルのスコア:
1.0 High Availability and Business Continuity: 91%
2.0 Costing: 75%
3.0 Deployment Management: 62%
4.0 Network Design: 37%
5.0 Data Storage: 91%
6.0 Security: 56%
7.0 Scalability & Elasticity: 69%
8.0 Cloud Migration & Hybrid Architecture: 28%

所感

 なんとかギリギリセーフでした。本試験、すごい疲れます。。。
 実務半年程度のペーペーなので試験勉強と実務知識が比例するわけじゃなく、試験としては問題数こなすのが一番という気がしました。本試験のほうが模試より簡単だったので絶望せずがんばりましょう。

 次は DevOps に挑戦したいです。

続きを読む

【AWS自分用メモ】新しいwebプロジェクトでやること

新しいwebプロジェクトに関して、やることを一覧。AWSは90種類以上のサービスがあり自分は一部しか把握していません。。。
これやったほうがいいよというサービスなどあれば教えていただけると嬉しいです。喜びます。

やることを簡単にまとめると
RDS,EC2はプライベートサブネットに配置
webサーバー2台構成で異なるAZに配置
ALBの前にWAFを使用
cloudwatchでダッシュボードやアラート作成

AWSサービス

使用サービス一覧(()内は必要であれば)
VPC IAM EC2 route53 (RDS) (cloudfront) (ACM) WAF Cloudwatch

◆VPC

構成:
・東京リージョン
・サブネットはプライベートサブネットとパブリックサブネットを各2つずつ、かつ各サブネット異なるAZ
・EC2インスタンスとRDSはすべてプライベートサブネットに作成
・クライアントのhttpリクエストは右のような流れ⇒【IGW-WAF-(cloudfront)-alb-ec2 (レスポンスはこの反対)】
・EC2がIGWを通る方法はNAT経由、右のような流れ⇒【EC2-NATGW-IGW】
・新規EC2インスタンスのsshアクセスは踏み台経由、のような流れ⇒【踏み台はユーザーと鍵認証-踏み台からsshコマンドでユーザーとパスワード認証】
・踏み台用VPC作成、プロジェクトごとのVPC作成後お互いにピアリング接続

踏み台VPC作成(踏み台がない新規AWSアカウントのみ、かつDefaultのVPC使うなら不要)

  • VPC作成
  • サブネット作成(パブリックサブネットを一つ作成)
  • IGW作成
  • ルートテーブル:ルートタブIGWをアタッチ,サブネットの関連付けタブで明示的にサブネットを当てる

新規プロジェクトのVPC作成

  • VPC作成
  • サブネット作成,PrivateSubnetをことなるAZで2つ,PublicSubnetを異なるAZで2つ作成=合計4つ作成
  • IGW作成
  • PCX作成 踏み台VPCと新規プロジェクトのVPCを作成。承認する必要あるので承認する。
  • NATゲートウェイ作成 EIP新規割り当て
  • ルートテーブル1つ作成 合計2つあるテーブルをPraivateとPublicに分けPraivateをメインにする
  • Praivateのルートテーブルのルートタブに作成したPCXとNATを登録、サブネットの関連付けタブで明示的にPrivateSubnetを2つ登録
  • Publicのルートテーブルのルートタブに作成したIGWを登録、サブネットの関連付けタブで明示的にPublicSubnetを2つ登録
  • 踏み台VPCのルートテーブルにPCXを登録

◆IAM

新規ロールをアタッチ。ポリシーは必要に応じて後でつけるので無し。

  • IAMロール作成

◆EC2

構成:
・webサーバーを2つ構成で冗長化(プライベートサブネットで各異なるAZに配置)
・必要に応じてautoscalling、リザーブドインスタンスの権利購入、など

踏み台VPCの構成

  • PublicSubnetにインスタンス作成
  • 作成したインスタンスにEIPを当てる

新規プロジェクトの構成

  • ポートセキュリティの作成 ポート:ssh,http,(https)
  • インスタンスの作成、プライベートサブネットで各異なるAZに配置、ロールの割り当て、セキュリティグループ割り当て、自動割り当てパブリックIP無効

  • ALBを作成 Publicサブネット異なるAZに配置、webサーバーを2つ登録、

  • ALBのロギング設定、セッションの維持、ヘルスチェックの変更

◆route53

  • お名前などのサービスからドメインの取得
  • route53に取得ドメインを登録
  • お名前などドメインをとったサービスからAWSのネームサーバーに変更
  • route53必要なサブドメインなど登録 (AレコードにAliasでELBのドメインを登録)
  • route53のオプション機能geolocationで国を制限

◆WAF

  • プロジェクトごとにあった設定
  • 設定後新規プロジェクトのALBに当てる

◆Cloudwatch

  • ダッシュボードの作成
  • アラートの作成

amazon linuxの中の設定

◆OS amazon linux

続きを読む

AWS ECS × New RelicによるコンテナのAPM監視

はじめに

『 ECS(AWSのコンテナマネジメントサービス)で起動したコンテナ上のアプリケーションをNew Relicで監視する 』をゴールとして、実施手順について解説したいと思います。ECSとALBの連携により、コンテナ起動に伴う各AWSサービスへの諸々の設定(サーバプールへの追加、ポートの払い出しetc..)を自動で行えるよう設定していきます。また、コンテナそれぞれにNew Relic Agentを手動でインストールするのは手間なので、起動時に自動でインストール実行できるよう、Dockerに仕込みたいと思います。

1. コンテナの作成

①. Dockerfileの作成

はじめにDockerfileを作成します。今回用意したDockerfileでは、起動時に下記2点を実行します。
1. HTTPサービスの起動及び監視対象PHPファイルの追加
2. New Relic APM Agentをインストールまで行う

Dockerfile
### CentOS Imageのダウンロード
FROM centos:centos6
### httpdのインストール、監視対象PHPファイルのアップロード##
RUN yum -y install httpd php
ADD phpinfo.php /var/www/html
### New Relic APM Agentのインストールおよびライセンスキーの設定
RUN rpm -Uvh http://yum.newrelic.com/pub/newrelic/el5/x86_64/newrelic-repo-5-3.noarch.rpm
RUN yum -y install newrelic-php5
RUN newrelic-install install
RUN sed -E -i 's/REPLACE_WITH_REAL_KEY/"Your New Relic APM License Key"/' /etc/php.d/newrelic.ini
### httpdの起動
CMD ["/usr/sbin/httpd", "-DFOREGROUND"]

②. コンテナイメージのビルド

次にコンテナイメージをビルドします。

# docker build -t nr-test-rp1 .
# docker images

コンテナを起動し、ビルドしたイメージが正常に動作することを確認します。

# docker run -d -p 8080:80 nr-test-rp1
# docker exec -it nr-test-rp1 bash

2. ALBの設定

AWS側でALBの設定を行います。
ALBと3で解説するECSの連携により、Auto Port Mapping機能が使用できます。
同機能により、ALB及びECSに対する下記設定を動的に行うことができます。

  • EC2ホストインスタンスの空きポートを動的にコンテナポートにマッピング
  • ECSが起動したコンテナをALBの負荷分散ターゲットとしてグルーピング
  • ALBに対してヘルスチェック/リスナー/ターゲットグループを自動設定

ALBの構成要素は下記のとおりです。それぞれ設定していきます。

  • リスナー
  • ターゲットグループ
  • ヘルスチェック

サービス > EC2 > ロードバランサーを選択し、『ロードバランサーの作成』を押下します。

SnapCrab_NoName_2017-4-27_15-53-34_No-00.png "ELB作成"

Application Load Balancerのラジオボタンを選択し、『次へ』を押下します。

SnapCrab_NoName_2017-4-27_15-54-44_No-00.png "ALB設定"

ステップ1: ロードバランサーの設定にて、下記の項目を設定します。

  • 名前
  • スキーマ
  • IPアドレスタイプ
  • リスナー
  • アベイラビリティゾーン

SnapCrab_NoName_2017-4-27_16-1-8_No-00.png "ALB設定"

ステップ2: セキュリティ設定の構成ではそのままページ下部の『次の手順』を押下します。

ステップ3: セキュリティグループの設定を行います。同ステップでは、ALB用のセキュリティグループを作成するため、HTTPの使用ポートである80番ポートを送信元:any(0.0.0.0/0)として設定します。(送信元については、今回テスト用としてany設定しておりますが、環境に適した任意の送信元を指定ください。)設定後、ページ下部の『次の手順』を押下します。
SnapCrab_NoName_2017-4-27_16-41-3_No-00.png "ALB設定"

SnapCrab_NoName_2017-4-27_16-4-7_No-00.png "ALB設定"

ステップ4: ルーティングの設定を行います。ターゲットグループ及びヘルスチェックの設定を行います。設定後、ページ下部の『次の手順』を押下します。

SnapCrab_NoName_2017-4-27_16-22-1_No-00.png "ALB設定"

ステップ5: ターゲットの登録ではターゲットインスタンスの登録を行わなず、そのままページ下部の『次の手順』を押下します。

ステップ6: 確認で設定内容を確認し、問題なければページ下部の『作成』を押下します。

これでALBの作成は完了です。

3. ECSの設定

ECSの構成要素は下記のとおりです。

  • ECRリポジトリ…コンテナイメージをアップロードするリポジトリ
  • クラスタ…コンテナのホストEC2インスタンスの指定&クラスタリング設定を行う
  • タスク定義…クラスタ上で起動するコンテナ=タスクに対して、リソース分配や使用ポートなどの起動設定を行う定義
  • サービス…サービス単位でコンテナを複数台起動することが可能、ALB/AutoScalingの設定が可能

①. リポジトリの設定 & Docker Imageのアップロード

はじめに、ローカルで作成したコンテナイメージをAWS上にアップロードするため、ECSリポジトリを作成します。
サービス > EC2 Container Service > リポジトリ を選択し、『リポジトリの作成』を押下します。

SnapCrab_NoName_2017-4-27_16-41-3_No-00.png "ECS-リポジトリ作成"

ステップ1: リポジトリの設定にて、リポジトリ名を設定し、ページ下部の『次のステップ』を押下します。

SnapCrab_NoName_2017-4-27_16-42-22_No-00.png "ECS-リポジトリ設定"

ステップ2: Docker イメージの構築、タグ付け、プッシュにて、ローカルから作成したECRリポジトリへのログイン、コンテナイメージのプッシュに関するコマンドが表示されるので、同表示に従い、コマンドを実行します。

SnapCrab_NoName_2017-4-27_16-43-33_No-00.png "ECS-リポジトリ設定"

コマンド実行後、レポジトリにイメージが追加されていることを確認します。

SnapCrab_NoName_2017-5-23_13-18-20_No-00.png "ECS-リポジトリ設定"

②. クラスタの設定

コンテナを搭載するホストEC2インスタンスの指定&クラスタリング設定を行います。

サービス > ECS > クラスターを選択し、『クラスターの作成』を押下します。

SnapCrab_NoName_2017-5-23_13-28-0_No-00.png "ECS-クラスタ設定"

クラスターの作成にて、下記の項目を設定し、『作成』を押下します。

  • クラスター名
  • EC2インスタンスタイプ
  • インスタンス数
  • リスナー
  • キーペア(ホストEC2にSSHアクセスしたい場合に設定)

  • VPC(ALBに設定したものと同じVPCを指定)

  • サブネット(同上)

  • セキュリティグループ(新規)

  • セキュリティグループのインバウンドルール(CIDR:0.0.0.0/0 , ポート:80)

  • IAMロール(ecsInstaceRoleポリシーが付与された既存のロール or 新しいロールの作成を選択。新しいロールの作成を選択した場合、ロールが自動作成される)

SnapCrab_NoName_2017-5-23_13-37-22_No-00.png  "ECS-クラスタ設定"
SnapCrab_NoName_2017-5-23_13-45-57_No-00.png  "ECS-クラスタ設定"

作成後、下記の通りクラスタが追加されていることを確認します。

SnapCrab_NoName_2017-5-23_13-53-41_No-00.png  "ECS-クラスタ設定"

動的ポートマッピング使用時には、ALB間の通信において、EC2ホストに割当られるポートレンジを全て許可しておく必要があるため、クラスタ配下のEC2ホストに設定されたセキュリティグループを編集します。

サービス > EC2 > インスタンスにて当該EC2ホストを選択、『説明』タブのセキュリティグループのリンクをクリックします。

当該セキュリティグループの『インバウンド』タブにある『編集』を押下し、ソースを2で設定したALBのセキュリティグループとした全ポート許可のルールを追加します。

SnapCrab_NoName_2017-5-23_15-2-55_No-00.png "ECS-クラスタ設定"

②. タスク定義の作成

コンテナの起動設定を定義するため、タスク定義を作成します。

サービス > ECS > タスク定義を選択し、『新しいタスクの定義』を押下します。

SnapCrab_NoName_2017-5-23_14-18-40_No-00.png "ECS-タスク定義"

タスク定義名を入力し、『コンテナの追加』を押下します。

コンテナの追加画面にて、下記の項目を設定し、『追加』を押下します。

  • コンテナ名
  • イメージ
  • メモリ制限 (割り当てるメモリ量)
  • ポートマッピング (Auto Port Mapping利用時はホストのポート番号を0に設定)

SnapCrab_NoName_2017-5-23_14-30-2_No-00.png "ECS-タスク定義"

コンテナの追加後、『作成』を押下します。

SnapCrab_NoName_2017-5-23_14-35-36_No-00.png "ECS-タスク定義"

③. サービスの作成

はじめにECSサービス用のIAMロールを作成します。
サービス > IAM > ロールを選択し、『新しいロールの作成』を押下します。
ロールタイプでAmazon EC2 Container Service Roleを選択します。

SnapCrab_NoName_2017-5-25_13-55-18_No-00.png "ECS-IAMロール作成"

ポリシーもそのままAmazonEC2ContainerServiceRoleをアタッチします。

SnapCrab_NoName_2017-5-25_13-56-29_No-00.png "ECS-IAMロール作成"

ロール名を入力し、『ロールの作成』を押下します。

SnapCrab_NoName_2017-5-25_14-0-0_No-00.png "ECS-IAMロール作成"

次にECSにてサービスを作成していきます。
サービス > ECS > クラスターを選択し、『サービス』タブの『作成』を押下します。

SnapCrab_NoName_2017-5-23_15-12-31_No-00![SnapCrab_NoName_2017-5-25_13-55-18_No-00.png "ECS-サービス作成"](https://qiita-image-store.s3.amazonaws.com/0/150903/745045c2-e48c-92eb-994b-4520d9cf97c3.png)<br>
.png

サービスの作成画面にて、下記の項目を設定し、『追加』を押下します。

  • タスク定義(3-②で作成したタスク定義を指定)
  • サービス名
  • タスクの数(起動するコンテナ数を指定)

SnapCrab_NoName_2017-5-23_15-16-50_No-00.png "ECS-サービス作成"

次に画面下部に移動し、『ELBの設定』を押下します。

SnapCrab_N![SnapCrab_NoName_2017-5-23_15-12-31_No-00.png "ECS-サービス作成"](https://qiita-image-store.s3.amazonaws.com/0/150903/3d7e0f3f-09db-993e-d1b5-d8e3b1de9e56.png)<br>
oName_2017-5-23_15-26-41_No-00.png "ECS-サービス作成"

下記項目を設定します。

  • ELBタイプ(Application Load Balancerを選択)
  • サービス用のIAMロール(作成したECSサービス用のIAMロールを指定)
  • ELB名(2で作成したALBを指定)

負荷分散用のコンテナという項目では、3-②で作成したコンテナを選択し、『ELBの追加』を押下します。

下記項目を設定し、『保存』を押下します。

  • リスナーポート(80:HTTPを指定)
  • ターゲットグループ(2で作成したターゲットグループを指定)

SnapCrab_NoName_2017-5-23_16-3-1_No-00.png "ECS-サービス作成"

作成したサービス画面でタスクが3台『Running』ステータスで起動していることを確認します。

SnapCrab_NoName_2017-5-23_16-9-10_No-00.png "ECS-サービス作成"

4. 挙動確認

①. アクセス確認

サービス > EC2 > ロードバランサ―の『説明』タブにてALBのDNSを確認します。
ブラウザにhttp://”ALBのDNS”/phpinfo.phpを入力し、アクセスできることを確認します。

②. New Relicからの監視確認

NewRelicのAPM画面でコンテナ上で起動するアプリケーションが追加されたことを確認します。

SnapCrab_NoName_2017-5-23_16-18-14_No-00.png  "New Relic画面"

当該アプリケーションを選択し、『Overview』画面下部に3台ホストが表示されることを確認します。

SnapCrab_NoName_2017-5-23_16-15-50_No-00.png

続きを読む

AWSのサービスでドメインを取得しALBでSSLで接続出来るようにする

概要

表題の通りですが、AWSのサービスのみで独自ドメインの取得を行いALBで公開を行います。
なお公開するWebサービスはSSLで接続可能にしますので、AWS Certificate Manager で証明書の取得も行います。

前提条件

ALB(Application Load Balancer) が作成されている必要があります。

※以前、ALB(Application Load Balancer)でWebサービスを冗長化する という記事を書きました。参考になれば幸いです。

ドメインの登録を行う

Route53のドメイン登録画面に遷移する

マネジメントコンソールからRoute53サービスの “Domain registration” に進みます。

domain-step1.png

“Register Domain”を選択します。

domain-step2.png

取得しようと思っているドメイン名が利用可能かどうかをチェックする

希望のドメイン名を入力し、”Check”を選択します。
トップドメインによって必要な登録料が変わってきます。
今回は検証用なので比較的易い.netを選択しました。

domain-step3.png

“Add to cart” を押して次の手続きに進みます。

必要事項を入力

必要事項を入力します。

domain-step4.png

デフォルトでチェックが入っていますが、”Hide contact information if the TLD registry, and the registrar, allow it” にチェックが入っているか確認を行います。

※ここにチェックが入っていると、whoisでドメインの管理情報が照会された時に、登録者であるAmazonの情報が表示されプライバシーを保護できます。

domain-step5.png

確認画面

“I have read and agree to the AWS Domain Name Registration Agreement” にチェックを入れて “Complete Purchase” をクリックします。

以上でドメインの申請は完了となります。

domain-step7.png

登録完了後しばらくすると、ドメイン登録時に入力したメールアドレスに「Verify your email address or your domain smsc-nsc.net will be suspended」 というタイトルのメールがAWSから届きます。

リンク内のURLをクリックしメールアドレスの検証を完了させましょう。

サブドメインの設定を行う

私が公開作成しようと思っているサービスは複数のサブドメインから成り立つ構成なので、サブドメインの登録を行い既に起動しているALBに対し任意のサブドメインを割り当てます。

Route53の「Hosted zones」を選択し先程登録したドメインを選択します。

subdomain-step1.png

「Create Record Set」を選択し新規レコードを作成します。

subdomain-step2.png

入力情報
Name: 登録したいサブドメイン名
Type: A - IPv4 addressを選択
Alias: Yesを選択
Alias Target: ALB(Application Load Balancer) を選択

subdomain-step3.png

「Create」を選択してから、しばらく待つと登録したサブドメインでALB(Application Load Balancer)にアクセス出来る事が確認出来るかと思います。

Certificate Managerで証明書を作成する

無料のSSL証明書を取得します。
証明書の更新が自動で料金も無料と魅力的ですが、いくつか制限があるので注意が必要です。
今回、私が利用する条件的には十分だったので問題はありませんでしたが、これらの条件のうちどれかが必須要件だった場合は別の手段で証明書を取得する必要があります。

  • AWS上の一部のサービスでしか使えない

  • EV SSL証明書としては利用出来ない

証明書の作成リクエストを送る

マネジメントコンソールから東京リージョンのCertificate Managerサービスにアクセスします。

CertificateManager-step1.png

「今すぐ始める」から証明書のリクエストを開始します。
今回は複数のサブドメインで運用を行うのでワイルドカード証明書を取得します。

*.hoge.net のように取得したドメインを入力します。

CertificateManager-step2.png

CertificateManager-step3.png

「確定とリクエスト」をクリックすると、ドメイン登録時に登録したメールアドレス宛に 「Certificate approval for Requestしたドメイン名」というタイトルのメールが送信されてきますので本文内のリンクから手続きに進みます。

CertificateManager-step5.png

“I Approve” をクリックすると手続きは完了となります。

CertificateManager-step5.png

CertificateManager-step6.png

ALB(Application Load Balancer)に作成した証明書を適応する

マネジメントコンソールからEC2サービス → ロードバランサーから証明書を適応するロードバランサーを選択します。

alb-step1.png

「リスナーの追加」から以下の内容を入力します。

プロトコル: HTTPS(セキュア HTTP)
デフォルトターゲットグループ: 作成済のターゲットグループ
AWS 証明書マネージャ (ACM) から、既存の証明書を選択する

alb-step2.png

しばらくすると対象のロードバランサーにHTTPSでアクセス出来る事が確認出来るハズです。

ちなみに私の場合はHTTPSアクセスが確認出来次第、HTTPのリスナーは削除するようにしました。

最後に

AWSのサービスを利用すると非常に簡単にSSLでWebサイトの公開が可能です。

EV SSLが必須の場合この方法は使えませんが、ちょっとしたサービスを作るのであれば良い選択肢だと思います。

最後まで読んで頂きありがとうございました。

続きを読む

いますぐ使う CloudFront

CloudFrontとは

台数不明で性能不明ですが、グローバルに配置された、キャッシュサーバー。

効果

CloudFrontをリバースプロキシキャッシュとして立ててみました。お問い合わせページなど動的ページを除いて、ほぼ全部のリクエストをCloudFrontが捌いてくれてます。

d0ff6181-11f1-d277-eee8-2d5999566133.jpg

※効果には個人差がございます

課金ポイント

  • 料金 – Amazon CloudFront | AWS

    • データ転送料金
    • キャッシュクリア料金
      • 1ファイル1回クリアが、月間1000回までは無料。以降は0.005 USD

        • リリースとかでこまめに大量のファイルをクリアすると、金かかる
        • キャッシュ有効期限は24時間。24時間ほっとけるならキャッシュクリア料金かからない

用語整理

  • ひとつのCloudFrontは「ディストリビューション」。

    • EC2やRDSが「インスタンス」と呼んだように。
  • キャッシュルールは「ビヘイビア」
  • キャッシュ元データを配信するサーバーを「オリジン」
    • ELB、EC2、S3、その他のサーバー
  • キャッシュクリアは「インバリデート」
    • 「無効化リクエスト」と書いてある文書もある

CloudFront の設置場所

CloudFront無しの構成

EC2のローカルディスクにすべてがあります。静的コンテンツ、動的ページ、すべてのアクセスを、EC2が捌く必要があります。ApacheとかNginxでキャッシュを効かせると、負荷は軽くなるかも。みたいな涙ぐましいノウハウがあったのです。

f65e1219-60fe-d83f-c483-73b133b04544.jpg

横に置く

昔のCloudFrontは、GETとHEADしか受け付けなかったため、JS/CSS/画像/添付ファイルなどを配信するS3を別立てにして、その手前にCloudFrontを置いていました。HTMLの実装では、cssとかjs、画像のタグに書くのリンクを xxxxxxxx.cloudfront.com にしておくことで、こうできます。図ではS3に置くことにしていますが、リリースでのCSSやJSの同期とか、何かと状況が複雑になりがちです。

40904824-cf46-b636-e04c-ee2462471b96.jpg

前に置く

CloudFrontの2013年10月のアップデート から、すべてのHTTPメソッドを受けてくれるため、ウェブアプリサーバーの手前に置くことができます。この場合は、静的コンテンツはCloudFrontのキャッシュでリクエストを捌き、動的ページはCloudFrontはスルーさせて、EC2で処理させます。

626b87d4-abd6-5ba8-6835-b3319f2722c0.jpg

今からやるなら「前に置く」構成

CloudFront無しの構成に導入するなら、断然「前に置く」構成です。

ウェブアプリのソース改修不要で、CloudFrontを適切に設定して配置するだけでOKなので、面倒がないです。

ただし、特定のページだけIP制限してたりすると、ApacheやNginxの設定を変更する必要があります。

とりあえずCloudFrontを立てる

必須項目だけ埋めて、あとで直せばOKです。

  • AWSコンソールにはいる
  • CloudFrontのページに行く
  • Create Distribution
    • Webを選ぶ(RTMPは動画配信とかに使う用)

      • Origin Settings

        • Origin Domain Name

          • ELBエンドポイントURL、BeanstalkエンドポイントURL、S3エンドポイントURL、EC2 DNS名など
          • IPアドレスでなければOK
      • Default Cache Behavior Settings
        • あとで変えるので放置
      • Distribution Settings
        • Alternate Domain Names(CNAMEs)

          • このディストリビューションに当てる予定のドメイン名。
          • 「前に置く」構成なら、これまでELBに当てていたドメイン名を指定。
          • 「横に置く」構成なら、空欄でOK
      • 他はあとで変えればOKなので放置
      • Create Distributionボタン押す
  • ディストリビューションは全世界に分散して立つのと、微妙にダサい仕様のため、しばらく時間がかかります

ビヘイビアの掟

  • ビヘイビアリストの上から順に評価されます。
  • Default (*)は、
    • 一番下から動かせません。
    • 削除できません。
    • どのビヘイビアにも当たらなかった場合のため存在します。
  • パスパターンにマッチしたら、そのビヘイビアだけに従って、キャッシュを見たり、オリジンにスルーしたりする
    • なので、ビヘイビアの上下の並び順は重要

ビヘイビアの設定方針

下記のどちらか。後からでも変更はできますが、どっちで行くかを考えるために、先に切り分けておくと良いです。

  • Default (*)を「キャッシュする」で書く。他のパスパターンは「キャッシュしない」で書く。
  • Default (*)を「キャッシュしない」で書く。他のパスパターンは「キャッシュする」で書く。

キャッシュしないページの設定

  • Path Pattern

    • 仮に http://hoge.example.com/contact/piyo.jpg みたいなとき

      • /contact/piyo.jpg
      • /contact/*.jpg
      • *.jpb
    • みたいに、そのキャッシュルールを適用するパスパターンを指定します。
  • Allowed HTTP Methods
    • 全部入りのを指定
  • Forward Headers
    • 「all」を指定
  • Object Caching
    • Customize
    • TTL(min, max, default)
      • ぜんぶゼロを指定
  • Forward Cookies
    • 「all」を指定
  • Query String Forwarding and Caching
    • 「forward all, cache based on all」を指定

キャッシュするページの設定

  • Path Pattern

    • 仮に http://hoge.example.com/contact/piyo.jpg みたいなとき

      • /contact/piyo.jpg
      • /contact/*.jpg
      • *.jpb
    • みたいに、そのキャッシュルールを適用するパスパターンを指定します。
  • Allowed HTTP Methods
    • GET,HEAD を指定
  • Forward Headers
    • 「Host」は必須。他にも必要なものがあれば追加。
  • Object Caching
    • Use Origin Cache Headers
    • Customizeにして、TTLを入れてもOK
  • Forward Cookies
  • Query String Forwarding and Caching
    • 「forward all, cache based on all」を指定

DNS設定

ビヘイビアふくめて、ディストリビューションの設定が完成したら、DNSの設定を書き換えます。

ディストリビューションには、「d1lxxxxxxxxx.cloudfront.net」のような、一意なドメイン名が発行されます。

Alternate Domain Names (CNAMEs)に入れたドメイン名のCNAMEとして、ディストリビューションのドメイン名を向けた、DNS CNAMEレコードを作成します。

動作確認

サイトにアクセスして、期待したとおりにビヘイビアが設定できているか、確認しましょう。

ChromeのデベロッパーツールのNetworkタブで、個々のファイルのレスポンスヘッダーに下記のようなのがあれば、CloudFrontを経由しています。

Via:1.1 41f313008af830d498dcb13814523bd7.cloudfront.net (CloudFront)
X-Amz-Cf-Id:xcP_6KiTFG_guNA9dRA-KOW6pg740-3mP1SvSrt2NqKGndWGPJKVuA==
X-Cache:Hit from cloudfront

X-Cacheに、キャッシュヒットしたかしてないかが記載されます。HitとMiss、ほかにもいくつかありますが、、、

  • X-Cache:Hit from cloudfront

    • CloudFrontにあるキャッシュが返っています
  • X-Cache:Miss from cloudfront
    • CloudFrontにキャッシュがなく、オリジンから返っています

HitとMissが想定と異なる場合は、ビヘイビアの調整が必要です。がんばりましょう。

その他、TIPS

制限、仕様

導入前に、CloudFrontというプロダクトの制限と仕様が、プロダクトの制限と仕様にマッチするのか、検討が必要です。

参考文書

続きを読む

Security-JAWS#5レポート

こんにちは、ひろかずです。

5/22にトレンドマイクロさんで開催されたSecurity-JAWS#5に行ってきましたので、一筆書きます。

月曜に関わらず、盛況な集まりでした。

お品書き

Session1:トレンドマイクロ株式会社 姜 貴日さん「Deep SecurityとAWS WAF、SNS、Lambdaを使ってうまいこと自動防御する」
Session2:三井物産セキュアディレクション株式会社 大橋 和正さん「インシデント別対策から見るセキュリティ運用体制〜Alert Logicのことも少し〜」
Session3:エフセキュア株式会社 河野 真一郎さん「脆弱性について疑似クラッキング(デモ)をやってみる ~脆弱性対策はとても大切。でも多くの人はそれに気づかないんだ〜」
Session4:洲崎さん「AWS使って社内CTFを開催してみた」

Session1:「Deep SecurityとAWS WAF、SNS、Lambdaを使ってうまいこと自動防御する」

トレンドマイクロ株式会社 姜(かん) 貴日さん

DeepSecurityとは

サーバ向け総合セキュリティ対策製品
IPS/IDS, セキュリティログ監視, アンチマルウェア, 変更監視
単一の機能ではなく、多層防御の考え方でセキュリティを確保する製品。
AWSコンソールとDeepSecurityManagerが連携して、インスタンスの増減を自動で反映する機能もある。

自動防御の仕組み

今回の構成は、AWS上にALB(AWS WAF)-EC2(ECS)を配置した構成。
SNSとLambdaを用意
SecurityGroupは、隔離用のもの(Outbound,Inboudなし)を用意しておく

シナリオ1(自動ブロック)

  • Deep Security Agentの侵入防御(IPS/IDS)で検知する。
  • Deep Security ManagerからイベントがSNS送信される。
  • SNSは、Lambdaに通知する。
  • Lambdaは、送信元IPをAWS WAFのIP Condition(Blocked)に登録する。

シナリオ2(自動隔離)

  • DeepSecurityAgentのアンチマルウェアで検知
  • イベントがSNS送信
  • SNSはLambdaに通知
  • Lambdaは、検知したインスタンスIDのSGを隔離用のものに差し替え、Auto Scaling Groupから切り離す。
  • Auto Scaling Groupの設定により、差し替え用インスタンスが起動される

まとめ

より、リアルに近い環境でのPoCを実施したい。
共同PoC大募集中!声かけてください!

QA

IPは、トレンドマイクロのデータベースと突き合わせるのですか?

  • 今は検知ベースです。

テンプレートは公開されていますか?

  • まだです(公開予定)

IPはころころ変わると思いますが、リフレッシュとか考えてますか?

  • そういうフィードバック大歓迎です!

DSaaSは、どこまでの規模感に対応できますか?

  • DSaaSは、中規模向け。大規模ならDSMがいい。(中規模って、どれくらい?100大規模?)
  • 国内で1000超えはない。100大規模は実績ある。

DSaaSのバージョンアップってどうなんだろう?

  • Manager側は自動でバージョンアップされます。

Session2:「インシデント別対策から見るセキュリティ運用体制〜Alert Logicのことも少し〜」

三井物産セキュアディレクション株式会社 大橋 和正さん
もともとオンプレメインのセキュリティエンジニア出身。
三井物産セキュアディレクションは、セキュリティ診断、SOC、セキュリティコンサルティングをやっている。
Alert Logicの拡販はじめました。

セキュリティ脅威の動向

IPA発表の10大脅威では、標的型攻撃、ランサムウェアが多く、公開サーバではインジェクション系が多い。
VerizonでもWebサーバに対する攻撃がダントツ

ランサムによる被害

WannaCryの詳細は三井物産セキュアディレクションのサイトで公開中!

Apache Struts2脆弱性をついた情報流出の事例

Twitterで気づく等、対応の遅れがあった

セキュリティインシデントとは?

コンピュータセキュリティに関係する人為的事象で、意図的および偶発的なもの
意図的脅威

  • パスワードリスト攻撃
  • サービス拒否攻撃
  • 情報の持ち出し(内部犯行)
  • サイト改ざん(ハクティビズム、マルウェア配布)

偶発的脅威

  • 設定ミス
  • プログラムのバグ
  • メール誤送信(情報漏えい)
  • PC紛失(情報漏えい)

なぜ事前準備が必要?

100%攻撃を防ぐことはできない

  • 攻撃技術の進歩(いたちごっこ)
  • 人間が使う以上、100%はない(オペミスはない)

天災には備えるのに、セキュリティインシデントへの備えはしないの?

  • 対応の遅れが、ユーザーからの信頼失墜に結びつく。

どのようなインシデントがあって、どのような対応をするのか準備しておく。

AWSにおけるセキュリティインシデントについて

クラウドvsオンプレ

アジリティと自動化
高可用性

おなじみAWS責任共有モデル

コンピューティング、ネットワーク、ストレージ等、クラウド基盤はAWSの責任範囲
OSレイヤ以上は、利用者側の責任ではあるが、SIerやベンダーと協力して対応して行く必要がある。
インシデントの種類をマッピングして、対応すべきセキュリティインシデントを明確にすることが大事。

Alert Logicについて

セキュリティの専門家がSOCで監視している。
リクエストとレスポンスのペイロードがコンソールで見れる。

Session3:「脆弱性について疑似クラッキング(デモ)をやってみる ~脆弱性対策はとても大切。でも多くの人はそれに気づかないんだ〜」

エフセキュア株式会社 河野 真一郎さん

セキュリティ営業3年目(2月からエフセキュア所属)
本社はフィンランド
衣装はガルパンモチーフ

まずは質問

脆弱性をついたクラッキングデモを実際に見たことある方ー!(会場は半々)

今回のシナリオ

標的型メールの添付ファイル(履歴書)を送りつけて、開いてしまった。

前提条件

アンチウィルス、メールサーバ前段のFirewallでは阻害されない

  • 標的型攻撃なので事前調査している想定

AWS接続が簡単なのは、デモのため。

デモ

開いた時点で、Windows7の一般権限は取れている。
攻撃ツールを使用してコマンドプロンプトを操作できる。
1分に一回だけ使える脆弱性をついてAdministoratorに昇格。
PowerShellでDomain Adminを取るまで約6分

OSのパッチ適用してる?

Linuxでも脆弱性管理をしていなければ、ハッカーにかかれば危ない。
OSのパッチ適用だけでは不十分(脆弱性は全体の約12%)
ミドルウェア、アプリケーションの脆弱性が85%をを占める。

宣伝

エフセキュアでは、Rapid Detection Serviceというサービスがある。
デモのような脆弱性がないかを見て欲しいひとはコンタクトして!

Session4:「AWS使って社内CTFを開催してみたよ」

洲崎さん
謎の勉強会ssmjpの運営やってます。

某社で社内CTFを開催しました

会社のHP
30人規模から70人規模に参加者が増えた
セキュリティエンジニアに楽しんで貰える
集合研修方式
Jeopardy形式
CTF終了後には問題と解説を配布(希望者には環境も)

ガジェット

状況を表示するLED看板
ラズパイでスコアサーバのWebAPIに定期的に投げる
スコアサーバは自作
運用管理ダッシュボードを用意
競技PCはWorkspacesを使いたいなー(NGだった)

得られた知見

AWSでイベントやるには申請が必要。
日本語NG。英語で申請。
EC2のみ。WorkspacesはNG。
申請時にはかなり細かく聞かれる。終わるときにはイベント設計が終わってるレベル。
申請から承認まで7日と言われたが、割とすぐに承認がおりた。

Docker(ECS)を使いたかった

時間の関係でEC2に
使えたらECRでデプロイが超ラクになる

監視サーバ

Zabbix Docker Monitoringを使ってみた。
TCPとWebサービスについて

実際にかかった金額

準備期間を含めて$2555だった。
Workspacesの検証がなければもっと安くあがっただろう

QA

参加者の平均年齢は?

  • 若手が多かったが、ベテランまで

運営は何人?

  • 5人。問題は2人で作った。大変だった。他の人も巻き込んでいきたい。

参加者スキルのピンきり具合

  • 満足度は70%(研修としては悪め)
  • 事前にフルイにかけたけど、ミスマッチした方は残念だった。
  • トップは、CTF運営経験者だった

正答率は?

  • 71.38%。8割の問題が解かれた。
  • 2割の問題が解かれなかった。(作った人は凹んでた。作ったのに解かれないのは悲しい。)

最後に

質疑応答も活発でした!
次回も楽しみですね!

今日はここまでです。
お疲れ様でした。

続きを読む

ALB(Application Load Balancer)でWebサービスを冗長化する

概要

ALBを使ってアプリケーションを冗長化する手順です。

HTTPS接続でアプリケーションにアクセス出来るところまでをこの記事で紹介します。

前提条件

以下の事前条件が必要です。

  • VPCの作成を行っておく
  • 最低でも2台のWebサーバインスタンスを起動させておく事
  • ロードバランサー用サブネットの作成が行われている事(後で説明します。)

事前準備その1(ロードバランサー用サブネットの作成)

以下は公式サイトに書かれている内容です。

ロードバランサーのアベイラビリティーゾーンを指定します。ロードバランサーは、これらのアベイラビリティーゾーンにのみトラフィックをルーティングします。アベイラビリティーゾーンごとに 1 つだけサブネットを指定できます。ロードバランサーの可用性を高めるには、2 つ以上のアベイラビリティーゾーンからサブネットを指定する必要があります。

今回検証で利用している東京リージョンには ap-northeast-1aap-northeast-1c の2つのアベイラビリティーゾーンが存在するので、それぞれでサブネットの作成を行います。

サービス → VPC → サブネット → 「サブネットの作成」より作成を行います。

ap-northeast-1a で サブネットを作成します。
以下のように入力を行います。

  • ネームタグ

    • account_api_alb_1a
    • 開発環境アカウント用APIのALB用と分かる名前を付けています。分かりやすい名前であれば何でも構いません。
  • VPC

    • 利用対象となるVPCを選択します。
  • IPv4 CIRD block

    • 192.0.30.0/24
    • ネットワークの設計方針にもよりますが今回は 192.0.30.0/24 を割り当てます。

alb_subnet_step1.png

続いて ap-northeast-1c でも同じ要領でサブネットを作成します。
※先程とほとんど同じなので、入力内容に関しての詳細は省略します。

alb_subnet_step2.png

事前準備その2(SSLの証明書の用意)

SSLで接続を可能にするのでSSL証明書の用意が必要です。

今回は検証なので自己証明書を利用する事にします。

以前、LAMP 環境構築 PHP 7 MySQL 5.7(前編) という記事を書きました。

こちらに載っている手順を参考に自己証明書を用意します。

ALB(Application Load Balancer)の新規作成

ここからが本題になります。
サービス → EC2 → ロードバランサー → ロードバランサーの作成 を選択します。

alb_step1.png

Step1 ロードバランサーの設定

基本的な設定を行っていきます。
名前を入力します。(今回はaccount-api-alb)という名前を付けました。

インターネットに公開するサービスを想定しているので、スキーマは「インターネット向け」を選択します。

ロードバランサーのプロトコルにHTTPSを追加します。

alb_step2-1.png

アベイラビリティーゾーンに先程作成したサブネットを割り当てます。

alb_step2-2.png

Step2 セキュリティ設定の構成

SSL証明書の設定を行います。

alb_step2-3.png

証明書の名前は分かりやすい名前でOKです。

プライベートキーには事前準備で作成した、プライベートキーを入れます。
-----BEGIN RSA PRIVATE KEY----- から -----END RSA PRIVATE KEY----- までを全てコピーして下さい。

パブリックキー証明書には -----BEGIN CERTIFICATE----- から -----END CERTIFICATE----- までの内容を全てコピーして下さい。

セキュリティポリシーは ELBSecurityPolicy-2016-08 を選択します。

※2017-05-22 現在、この手順で問題なく証明書の追加が出来るハズなのですが Certificate not found というエラーが発生しロードバランサーの作成に失敗してしまいます。

証明書のアップロードを aws-cli を使って事前に実施するようにしたら上手く行きました。

証明書のアップロード
aws iam upload-server-certificate --server-certificate-name self-certificate --certificate-body file://crt.crt --private-key file://private.key

file:// を付けるのがポイントです。これがないと上手くアップロード出来ませんでした。

--server-certificate-name には任意の名前を入力して下さい。

上手く行くと下記のようなレスポンスが返ってきます。

証明書アップロードのレスポンス
{
    "ServerCertificateMetadata": {
        "ServerCertificateId": "XXXXXXXXXXXXXXXXXXXXX",
        "ServerCertificateName": "self-certificate",
        "Expiration": "2018-05-22T04:14:02Z",
        "Path": "/",
        "Arn": "arn:aws:iam::999999999999:server-certificate/self-certificate",
        "UploadDate": "2017-05-22T05:58:44.754Z"
    }
}

アップロード完了後に「AWS Identity and Access Management(IAM)から、既存の証明書を選択する」を選んで先程アップロードした証明書を選択して下さい。

alb_step2-3.1.png

この問題については 既存の ELB に SSL 証明書を追加しようとすると Server Certificate not found for the key というエラーになる件の解決方法 を参考にさせて頂きました。

Step3 セキュリティグループの設定

セキュリティグループの設定を行います。

alb_step2-4.png

Step4 ルーティングの設定

ターゲットグループの新規作成を行います。

alb_step2-5.png

名前、プロトコル、ヘルスチェック用のURLの設定等を行います。

Step5 ターゲットの登録

ロードバランサーの配下で起動するインスタンスを選択します。

alb_step2-6.png

作成に必要な情報入力は以上となります。

確認画面に進み作成を行いしばらくすると、ロードバランサーが作成され利用可能な状態となります。

※サービス → EC2 → ロードバランサー より確認が出来ます。

alb_step3.png

動作確認

サービス → EC2 → ロードバランサー よりDNSが確認出来るので、動作確認を行います。

curl -kv https://account-api-alb-000000000.ap-northeast-1.elb.amazonaws.com/
*   Trying 0.0.0.0...
* TCP_NODELAY set
* Connected to account-api-alb-000000000.ap-northeast-1.elb.amazonaws.com (0.0.0.0) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: system
> GET / HTTP/1.1
> Host: account-api-alb-000000000.ap-northeast-1.elb.amazonaws.com
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Mon, 22 May 2017 07:26:02 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
< Connection: keep-alive
< Server: nginx/1.12.0
< X-Request-Id: 76c7e41f-1a4e-4328-972c-b98055e84395
< Cache-Control: no-cache, private
<
* Curl_http_done: called premature == 0
* Connection #0 to host account-api-alb-000000000.ap-northeast-1.elb.amazonaws.com left intact
{"code":404,"message":"Not Found"}

各Webサーバのログを確認すると、処理が振り分けられているのが、確認出来ます。

本番環境での運用に向けて

ここまで簡単に作成が出来ましたが実環境で運用を行うにはまだまだ考慮が必要な点が多いです。

  • SSL証明書を正式な物にする(自己証明書で運用とかはさすがに厳しいと思います)
  • 独自ドメインでのアクセスを可能にする
  • 各EC2のログに記載されているIPがロードバランサーの物になっている

※これらの手順は順次行っていく予定ですので、準備が出来次第記事を書く予定です。

最後まで読んで頂きありがとうございました。

続きを読む

Amazon ECSを用いたDocker本番運用の実現

はじめに

現在お手伝いしているアカウンティング・サース・ジャパンにて、ECSを使ったDockerの本番運用を始めたので、その一連の流れについてまとめました。

税理士向け会計システムを扱うアカウンティング・サース・ジャパンでは最近Scalaでの新規プロジェクトが立ち上がってきており、既存のプロジェクトはJavaであったり、Erlangであったりと様々な言語が用いられていますが、インフラ人員が少ないということもあり、なるべくシンプルなインフラ構成を実現する必要がありました。

そういった中、各アプリケーションをDocker化することでインフラとしては共通基盤としてのDockerクラスタのみの管理になり、運用コストが下がるのではないかという仮説からDocker化を進めることになりました。クラスタを実現するに辺りKubenatesなどの選択肢もありましたが、今回はECSを選択し、下記のようにAWSのマネージドサービスを最大限に活用しています。

  • オーケストレーションツール: Amazon EC2 Container Service (ECS)
  • サービスディスカバリ: Application Load Balancer (ALB)
  • Dockerレジストリ: Amazon ECR
  • ログ、メトリクス収集: CloudWatch, CloudWatch Logs
  • 監視: CloudWatch Alarms
  • Infrastructure as Code: CloudFormation
  • CIツール: Jenkins

各技術の選定理由

今回Docker化を行うに辺り、下記を優先的に技術選定を行いました。

  • 運用が楽であること
  • 構成がシンプルで、技術の学習コストが低いこと

まずは、オーケストレーションツールの選定です。候補に上がったのは、Docker Swarm、Kubernetes、ECSです。

DockerのSwarm modeは本番での運用例が技術選定時点であまり見当たらなかったので候補から落としました。次にKubernetesとECSですが、海外の事例などではどちらも多く使われているようです。

今回は多機能さよりも運用に手間がかからない方が良いと考え、マネージドサービスであるECSが第一候補にあがりました。ここは詳細に調査したというよりも、ある種勢いで決めています。その上でやりたいことが実現できるかどうか一つ一つ技術検証を行った上で導入判断を行いました。

同じようにマネージドサービスを優先的に使ったほうが良いという考えで、ログなどでもCloudWatchを使っています。

AWSインフラをコードで記述するものとしてはTerraformが良く取り上げられている気がしますが、個人的にはいくつかの理由でCloudFormationを推しているのでこちらを使っています。

CIツールですが、社内の標準であるJenkinsをそのまま使うことにしました。

全体構成

下記のような構成になっています。

スクリーンショット 2017-05-21 12.46.39.png

ざっくりと説明すると、developmentブランチにプッシュするとGithub HookでJenkinsがDockerイメージをビルドして、ECRにPushします。ユーザはJenkinsでDeployジョブを実行(あるいはBuildの後続ジョブとして自動実行)し、CloudFormationにyamlファイルを適用することでTask, Service, ALB, Route53設定, CloudWatch設定を一通り実行します。またECSのClusterはあらかじめCloudFormationテンプレートを作成して作っておきます。

Task/Serviceの更新についてはCloudFormationを経由しない方がシンプルかとは思いまいしたが、Service毎に管理するRoute53やCloudWatchと合わせて一つのテンプレートにしてしまうのが良いと判断しました。

ここまでやるなら専用のデプロイ管理ツールを作った方がとも思ったのですが、業務委託という立場で自分しかメンテができないものを残すものは躊躇されたため、あくまでAWSとJenkinsの標準的な機能を組み合わせて実現しています。

CloudFormationテンプレートの解説

上記の流れが全てなので理解は難しくないと思いますが、一連の処理で重要なポイントとなるのはCloudFormationテンプレートなのでこれについてだけ触れておきます。長いテンプレートなのでざっくりとだけ雰囲気を掴んでもらえればと思います。

ECSクラスタのテンプレート

cluster作成用のCloudFormationテンプレートは下記のようになっています。

gist:cluster.yaml

一見複雑に見えますが、Amazon EC2 Container Service テンプレートスニペットを参考に作ると簡単に作成できると思います。

(あまりそのまま書くと会社に怒られそうなため)省略していますが、実際にはここにECSクラスタの監視を行うCloudWatch Alarmなどを設定することで、監視設定までこのテンプレートだけで完了します。

ECSクラスタはインフラチーム側であらかじめ用意しておき、リソースが足りなくなったときなどには適宜インスタンス数を変更したりクラスタ自体を別途作ったりしていきます。オートスケーリングを導入すればそれすら必要なくなります(今回はDocker運用が初めてだったので知見がたまるまで手動での対応にしています)。

インフラ側としての責務はここまでで、下記のテンプレートで定義される個別のサービスについてはアプリ開発者側の責務として明確に責任境界を分けました。(もちろん実際にはサポートはかなりの部分でしています。)

これにより全員が今までよりインフラに近い領域まで意識するように個人の意識が変わっていくことを期待しています。

個別サービス用テンプレート

開発環境、ステージング環境、プロダクション環境などそれぞれで同一のテンプレートを使うようにし、パラメータを使用します。そのパラメータをJenkinsのジョブ内で注入することで実現します。VPCなどの環境で決まる値はJenkinsジョブで実行するスクリプト内で定義し、アプリケーションごとの値は environment.yaml というファイルを用意してスクリプトから読み込みます。

environment.yamlは例えば下記のようになっています。アプリケーション開発者は、特殊なことをしない限りは service.yaml をインフラチームが用意したservice.yamlをコピーして、environment.yamlだけ編集すれば良い形になっています。DSLですら無いのでアプリ側のメンバーも心理的な抵抗が少ないようで良かったです。

environment.yaml
images:
- xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/hoge-image
parameters:
  default:
    TaskMemory: 512
    TaskMaxMemory: 990
    ImageRepositoryUrl: xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/hoge-image
    ServiceDesiredCount: 1
  dev:
    ClusterName: dev-default
    JavaOpts: "-Xmx256MB"
  stg:
    ClusterName: stg-default
    JavaOpts: "-Xmx256MB"
  prod:
    ClusterName: default
    JavaOpts: "-Xmx1500MB -Xms1500MB"
    TaskMemory: 1990
    TaskMaxMemory: 1990
    ServiceDesiredCount: 2

そして service.yaml は下記のようなファイルです。

gist:service.yaml

これもAmazon EC2 Container Service テンプレートスニペットから作ればすぐにできるのではないかと思います。(もちろん全てのパラメータは一つ一つ値を検討します。)

こちらもCloudWatch周りや重要でないところは削除しています。色々と手で削ってるのでコピペだと動かない可能性大ですが雰囲気だけ掴んで貰えればと思います。

このファイルは全アプリケーションで同一ファイルを使うのではなく、アプリケーションごとにコピー/編集して利用します。全体の変更を行うときには全プロジェクトのファイルを更新しなければいけませんが、共通基盤がアプリケーション側を制約しないように、プロジェクト毎のyamlファイル管理としています。ファイルの配置場所は各Gitリポジトリに配置するのが理想ですが、現状ではDocker運用になれてくるまで全てのyamlファイルを管理するリポジトリを作成してインフラチーム側が主に編集する形を取っています。

デプロイ

あとは、このservice.yamlとenvironment.yamlを組み合わせてデプロイするRubyスクリプトでもJenkinsのPipelineのコードでも適当に書いてJenkinsのJobを登録すれば完了です。(environment.yamlファイルを読み込んで aws cloudformation create-stack でservice.yamlと共にパラメータとして渡すだけなので簡単です!)

新規アプリ開発時も社内標準のservice.yamlとenvironment.yamlをファイルを持ってきて、environment.yamlを修正した上で、Jenkinsにジョブを登録すればすぐにDockerクラスタへのデプロイ準備が整います。しかも、上記のテンプレート例では割愛していますが、テンプレートには監視項目/通知設定まで書かれているので、インフラ側で設定を行う必要もなく監視が開始されます。CloudFormation最高ですね。

おわりに

実際の運用ではミッションクリティカルなアプリケーションならではの品質管理のために、JenkinsのPipeline機能を利用して開発→検証→リリースまでのデプロイメントパイプラインを実現しています。

アプリケーションのSECRETなどコミットしない情報をどう管理するかも検討する必要がありますが、これは管理の仕方はチームによって異なると思ったため割愛しています。

また、ログ解析としてはS3に出されたALBのログをRedash+Amazon Athenaでエラー率やアクセス数を分析できるようにし、CPU使用率やメモリ使用率などのパフォーマンス状況をCloudWatchの内容をGrafanaで可視化しています。これによりログ収集の基盤などを作らずに必要な可視化を実現することができました。ベンチャーでは分析基盤の運用も大きなコストになってしまうため、こういった工夫も必要です。(もちろん重要なKPIについては別途分析する仕組みが整っています。)

今回の構成が最高とは思いませんが、ある程度満足行くところまではできたかなと思います。もっとよくできるよ!とか一緒にやりたいな!とかもっと詳細聞きたいな!いう方はぜひ @miyasakura_ までご一報ください。

続きを読む