AmazonECRとEC2を使って手元でビルドしたDockerイメージをAWS上でサクッと動かす

ECR(EC2 Container Registry)に登録したDockerイメージをEC2上でコンテナとして起動するまでの一通りの流れを書いてみた
ECSも一通り検証終わっていて、サービスではそちらを使う予定だが、基礎を振り返るという意味でのまとめ。

Docker

ここ一ヶ月ひたすらdockerを触っているが、やはり手元の開発環境で動いたものが、別の環境でそのまま動くというのは他にないメリット。
これまでだと、開発環境でOK→STでまた一から作る→本番でも同じくみたいなことしてたけど、ホスト側にDockerエンジン入れるだけで、実際のプロセスは開発環境のものをそのまま移植出来るというところはかなり熱い。といった印象。

やること

  • ECRを使う準備
  • ECRへのDockerイメージの登録
  • EC2作成
  • EC2上にECRからpullしたDockerコンテナを立てる

ECRとは

正式名称 EC2 Container Registry
Amazonが提供するフルマネージドのDockerコンテナレジストリ。
Dockerイメージを管理して、ECS(EC2 Container Service)やEB(Elastic Beanstalk)に簡単にデプロイすることが出来るソリューション

ECR使うと何がうれしい

  • EC2インスタンスにIAMroleを付与するだけ、EC2側で面倒な認証をせずにdockerイメージを使える
  • S3がバックエンドなので、可用性高い
  • 自動的に暗号化されたり、https通信されるのでセキュリティも安心

ECRを使う準備(ローカルマシンで実施)

AWS Command Line Interface のインストール を参考にAWS CLIを手元のマシンにインストールしておく。

基本的には、AWS CLIで操作する。

1.リポジトリの作成&確認

$aws ecr create-repository --repository-name tst-shnagai
{
    "repository": {
        "registryId": "xxxxx",
        "repositoryName": "tst-shnagai",
        "repositoryArn": "arn:aws:ecr:ap-northeast-1:xxxxx:repository/tst-shnagai",
        "createdAt": 1496229520.0,
        "repositoryUri": "xxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai"
    }
}

リポジトリは、GUIから見ると、ECSサービスの中の[リポジトリ]に出来る

Amazon_EC2_Container_Service.png

2.ecrにログイン

セッションは12時間なので、感覚的に翌日には切れてる感じ。

## これで一発

$ $(aws ecr get-login --region ap-northeast-1)
Flag --email has been deprecated, will be removed in 17.06.
Login Succeeded

## $()の式展開を使わない場合

$ aws ecr get-login --region ap-northeast-1
docker login -u AWS -p eyJwYXlsb2FkIjoicURLTkxCTFhobUJuSTRxSDRNSUFBOEprc0txSnVuTVgrdzRzNkl4NU5rRDUxM0N...
### 標準出力の結果を貼り付けてログイン
$ docker login -u AWS -p eyJwYXlsb2FkIjoicURLTkxCTFhobUJuSTRxSDRNSUFBOEprc0txSnVuTVgrdzRzNkl4NU5rRDUxM0N...
Login Succeeded

ECRへのDockerイメージの登録(ローカルマシンで実施)

手元にある何かしらのDockerイメージをECRにpushする手順
手元で、Dockerイメージに対して、ECR用のタグづけを行ってから、ECRにpushする

1.docker tagコマンドでタグづけをする

今回は例として元々手元にある[apache_td]というdockerイメージに対して、ECRのルールに沿った名前でタグ付け(aliasつけるようなもの)する

## 元々のイメージ
$ docker image list |grep apache_td
apache_td                                                         latest              2c42dd3f5e5c        13 days ago         1.4GB

## タグ付けを実施
$ docker tag apache_td:latest  xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest

## imageIDは変わらないので、下記のような検索するとapache_tdがECRに対応したイメージとしてタグ付けされたことがわかる
$ docker image list |grep 2c42dd
xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai     latest              2c42dd3f5e5c        13 days ago         1.4GB
apache_td                                                         latest              2c42dd3f5e5c        13 days ago         1.4GB

2. 1でタグづけしたDockerImageをECRにpushする

$ docker push xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
The push refers to a repository [xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai]
47d1cbb6b480: Layer already exists
...
latest: digest: sha256:14b7a5d491fa694c00f026bbc6c6cd09e0ddc63d0e586569a0de42a8ce7ec5d1 size: 2411

GUIで、タグ名とプッシュされた日時を確認して無事イメージがアップされていることを確認する

Amazon_EC2_Container_Service.png

ここまでで、ECRへのDockerイメージの登録は完了!!

EC2インスタンスの作成

1.通常通りEC2インスタンスを作成する(OSはデフォルトでawscliが入っているamazon linuxだと楽)

ポイントは、IAMRoleに[AmazonEC2ContainerRegistryReadOnly]ポリシを付与しておくことのみ

IAM_Management_Console.png

2. dockerのインストール

AWSの公式ドキュメントに沿ってやるだけなので、コマンドだけ羅列
Docker のインストール

ec2-userでdockerコマンドがsudoなしでうてるとこまでやっておく。

$ sudo yum update -y
$ sudo yum install -y docker
$ sudo service docker start
### ec2-userでsudoなしでdockerコマンドを打てるようにするため
$ sudo usermod -a -G docker ec2-user
###再ログイン
$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce

EC2上にECRからpullしたDockerコンテナを立てる(EC2上で実施)

1. ECRへのログイン

IAMRoleがついていない場合は、ログインで弾かれる

$ $(aws ecr get-login --region ap-northeast-1)
Login Succeeded

2. ECRからDockerイメージをpullする

## ECRにアップロードしたイメージをpull
$ docker pull xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
latest: Pulling from tst-shnagai
996fe98f55d8: Pull complete
...
e6b377ddca6e: Pull complete
Digest: sha256:14b7a5d491fa694c00f026bbc6c6cd09e0ddc63d0e586569a0de42a8ce7ec5d1
Status: Downloaded newer image for xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest

## 手元のイメージとして登録されたことを確認
$ docker image ls
REPOSITORY                                                      TAG                 IMAGE ID            CREATED             SIZE
xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai   latest              2c42dd3f5e5c        13 days ago         1.4 GB

3. dockerコンテナを起動する

pullしてきたイメージからコンテナを起動する

## ホストの8080ポートにマッピングするtestという名前のコンテナを起動する
$ docker run -d --name test -p 8080:80 xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
dbbb74b6ebe95666d356250de8310c19403078f53e020069e9a6d10e479b2873

## -lオプションで最後に起動したコンテナを表示
$ docker ps -l
CONTAINER ID        IMAGE                                                                  COMMAND                  CREATED             STATUS              PORTS                  NAMES
dbbb74b6ebe9        xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest   "/bin/sh -c '/bin/..."   4 seconds ago       Up 4 seconds        0.0.0.0:8080->80/tcp   test

## 動作確認として、ホストの8080に対してcurlでリクエストしてみる
$ curl localhost:8080
version 1.2

まとめ

オーソドックスな、AWSでECRを使ってdockerコンテナを起動する一通りの流れをやってみた。dockerを手元で触ってる人だったら、特に躓くことなくやれる内容だと思う。
ECSは、基本オペレーション(この投稿でいうEC2以降の話)を抽象化して、クラスタというEC2集合体の上で、ELB,AutoScaling等を付加して使えるサービスなので、ココら辺をちゃんと理解してやるとやらないでは進みがだいぶ違うという印象を受ける。
裏で何が行われてるのかなという道理を理解することは大事。

続きを読む

AWS Summit Tokyo 2017 参加レポート Day3 (6/1)

会社の外部研修として『AWS Summit Tokyo 2017』に6月1日(木)~2日(金)の計2日間参加して来ました。

当エントリでは6月1日(Day3)に聴講した内容をレポートします。(Day4のレポートはこちら
※注)記事には個人的なメモや感想が含まれています。予めご承知ください。


基調講演(Key Note) (10:00 ~ 11:30)

ホストトーク:オープニング

by Werner Vogels 氏 (Amazon.com CTO)

  • AWSは急速に成長している

    • 成長率はIT企業の中でもTOP
    • 毎月のユーザー増加数 = 日本では10万以上
    • 各国のリージョン、AZ、エッジロケーションも随時拡大中
  • 本イベントを通してAWSを色々学んで行って欲しい。

気になったワードメモ

  • AWS Activate
  • One Amazon
  • Osaka リージョン開始

ゲストトーク:株式会社ソラコム

by 安川 健太 氏 (株式会社ソラコム 最高技術責任者)

SORACOMのサービス展開

IoTはネットワークセキュリティが課題
>3G/LTE網でInternetに出ないIoTネットワーク(デバイスとクラウドの直接接続)を提供

SORACOM Funnel
>デバイスからクラウドへのデータ転送を疎結合に管理
 利用例:デバイス>Funnel>Kinesis>Lambda>AWS IoT
  ⇒Funnelから先の切り替え(=新サービス追加など)が容易

ホストトーク:AWS – SUPER POWERS 1

by Werner Vogels 氏 (Amazon.com CTO)

「AWSは開発者に『SUPER POWERS※』を与える。」 (※ネタ元:スーパーマン)

SUPER POWER – ‘SPEED’ (超音速)

  • EC2新インスタンス:F1(FPGA利用可)
  • 今の時代 検索は必須>Elastic Search等ですぐに実装可
  • CloudはInfraへの関心を省き、Productに集中させてくれる>開発を加速
  • AWSは色々な選択肢を提供>ビジネスに合わせて適切なものを

ゲストトーク:NTT東日本

by 中村 浩 氏 (東日本電信電話株式会社 取締役)

CloudGateway re:connect
>FLETS光の高速・閉域網でAWSと再接続

社内で開発・利用して便利だったものを社外にも利用してほしい
クラウドと企業間の距離が一番近い国に

ホストトーク:AWS – SUPER POWERS 2

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘INVISIBILITY’ (目に見えない)

⇒開発者がインフラを気にしなくていい ⇒サーバーレス機能群紹介

  • AWS Lambda

    • サーバーレスコンピュート
  • AWS Step Functions
    • ビジュアルワークフローで分散アプリケーションのコンポーネント管理
  • AWS X-Ray
    • 分散アプリケーションの分析とデバッグ
  • Amazon DynamoDB Accelerator(DAX) :new:
    • 完全マネージド型インメモリキャッシュクラスタでクエリ超高速化

ゲストトーク:ソニーモバイルコミュニケーションズ

by 川西 泉 氏 (ソニーモバイルコミュニケーションズ株式会社 取締役 EVP)

SonyモバイルのIoTへの取り組み:『カーリングビジネスの実現』

製品紹介
– XPERIA Ear
– XPERIA Touch
– XPERIA Agent
  >http://av.watch.impress.co.jp/docs/news/1018278.html

スマートホームシステム
 AWS IoTを活用
 製品例:自宅のLED照明>センサーで子供の帰宅感知>仕事(外出)中の親に通知>LED付属のスピーカで会話

ホストトーク:AWS – SUPER POWERS 3

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘FLIGHT’ (飛び立つ)

IoTデバイスはサーバを必要としない

  • AWS Greengrass
     ⇒サーバ側の役目だった処理をローカルで構築可能に

これまでのデータベース=実機やベンダー由来の様々な制約や障害があった
クラウド+オープンソースのDBで”制約”から飛び立とう

  • AWS Database Migration Service
  • Amazon Aurora
    • 完全MySQL互換のRDB
    • PostgreSQL互換も提供開始

ゲストトーク:グリー株式会社

by 藤本 真樹 氏 (グリー株式会社 開発・人事統括 取締役 執行役員常務 CTO)

オンプレで10年運用してきた環境をクラウドへ移行した話

技術選択の判断は難しい、基準には色々な軸がある
敢えて上げるならば、”is that faster?”
>速さは裏切らない(コンピュータが速くて困ることは絶対にない)

⇒ AWS(の機能やサービス展開速度)はこれらに応えられる

ホストトーク:AWS – SUPER POWERS 4

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘X-RAY VISION’ (透視)

⇒ データの集計・可視化

  • Amazon Athena

    • S3に保存されたデータを標準SQLで簡単に分析
  • Amazon EMR
    • Hadoopなどのビッグデータフレームワークを手軽に実行・分析可能
  • Amazon Redshift
    • 複雑なクエリ・超高速パフォーマンスを提供するペタバイト級データウェアハウス
  • Amazon Redshift Spectrum :new:
    • S3のデータを直接クエリ可能
    • エクサバイト規模のクエリ>Hiveで5年想定の処理を155秒で完了

SUPER POWER – ‘PRECOGNITION’ (予見)

⇒ Amazon AI – 人工知能サービス

  • Amazon Machine Learning

    • カスタム予測モデルの学習
  • Amazon Rekognition
    • 画像から顔と感情を認識
  • Amazon Polly
    • 文章をリアルな音声に変換(感情付加など)
  • Amazon Lex
    • 自動音声認識・自然言語理解

SUPER POWER – ‘IMMORTALITY’ (不朽)

⇒ スタートアップ企業生き残りの鍵 =『デジタルトランスフォーメーション』

AWSは『イノベーション』を続ける


AWS 認定試験 (12:30 ~ 13:50)

Summit特設会場でソリューションアーキテクトアソシエイト試験を受験(特典の50%OFFクーポン目当てです ^^; )

試験終了後すぐに認定者限定ラウンジに行ってみましたが、ノベルティの折り畳み傘はとっくに品切れでした;;
やはり一日数量限定は午前中に行かないと無理な模様。( ⇒ Day4で無事GET!!)

限定ラウンジではお菓子や飲み物が無料、座ってPCなどの充電が出来て中々快適でした。
モニタなど設置して講演中のセッションを視聴できればいいなと考えましたが、逆に人が溢れて寛げなくなりそう?


Session:『AWS Shield と AWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション』 (14:20 ~ 15:00)

スピーカー:Prasad Kalyanaraman 氏 (Vice President, AWS Edge Services)

セッション概要(タイトルリンク先より引用)

AWS Edge Services では、Amazon CloudFront に加え、AWS Shield、 AWS Lambda@Edge などの革新的な新サービスを発表しています。本セッションでは、AWS Shield の DDoS 防御機能と、AWS Lambda@Edge の CDN 上でのスクリプト実行により、セキュリティを担保しつつ柔軟でカスタマイズ性の高いアプリケーションの実現方法をご紹介します。

エッジでのセキュリティ活用

セキュアコンテンツ配信にCloudFrontが使える
 >エンドユーザー付近をセキュア通信の終端にする

Lambda@Edge

=Lambda関数のデリバリーサービス
 ・Bot 判定
 ・バリデーション
 ・認証処理
  ⇒エンドユーザ付近で実行できる
 ・ユーザ毎にコンテンツカスタマイズ可能
  e.g.
   ・PC/モバイル判定>アクセス先分岐
   ・エッジでHSTSヘッダを埋込み

DDoS対策 (スクラビングセンター)

 >AWS Shield (全Edgeロケーションで使用可)
  >Standard
   ・エッジで攻撃を検知し、遮断
   ・リアルタイムで悪意のあるトラフィックを検出
   ・無料で自動適用
  >Advanced
   ・攻撃データの可視化、およびイベント後の分析と調査を容易に
   ・DDoS攻撃で請求金額が跳ね上がるのを防ぐ「DDoS コスト保護」
   ・専門サポート
   ・有料

AWS WAF

 >L7(アプリケーションレイヤー)防御
 >Lambdaで独自のセキュリティチェック可 (e.g. 特定のIPを一定時間ブロック等)


Session:『Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム』 (15:20 ~ 16:00)

スピーカー:松田 和樹 氏 (株式会社インティメート・マージャー 開発本部)

セッション概要(タイトルリンク先より引用)

インティメート・マージャーではビジネスの都合上、50 種類ものジョブワーカーを運用しております。増え続けるビジネス要件に対応するため、Amazon ECS と SpotFleet を軸に Amazon S3、Amazon SQS、Autoscaling を組み合わせることで、低コストかつスケーラブルな docker 基盤を構築致しました。本セッションでは、その docker 基盤を中心にお話しします。

公演に使用されたスライドが公開されてます。

構築背景

  • 20以上の社外システムとデータ受渡し

    • 異なるデータ形式
    • 異なる接続方式
  • データ肥大化
    • スケールする仕組みが必要
    • 特定のジョブのみスケールさせたい

第一世代

処理フロー

S3ファイルUP>イベントをSQS通知>Cloud Watchでキュー数監視>EC2のワーカーをAutoScaling (Spot)
 >SQSキュー&S3ファイルを取得し処理>後続処理は別のS3へ

課題

  • スポット高騰時など特定のワーカーが起動不可となる
  • リソース(InstanceType)効率が悪い
  • 待機時間が長い
  • スケーリング設定多く、運用負荷高い

第二世代

変更点

  • 全ワーカーの実行環境をコンテナに
  • docker基盤共用
  • ECS採用
  • spot fleet採用
  • ワーカー毎にコンテナをスケール

Amazon ECS

  • 52のサービスが稼働 ( 50種のワーカー + Mackerel(監視) + Fluentd(ログコレクタ) )
  • コンテナレジストリ ⇒ Amazon ECR

Spot fleet

  • 168 vCPU
  • 自動入札(一つ一つ設定も可能だが手間)
  • InstanceType:7種 主にC4、M4系

運用のポイント

ログのハンドリング

  • 目的で集約先使い分け

    • 常時監視 ⇒logdna
    • 長期分析 ⇒BigQuery
    • 直近データ分析、参照 ⇒Aurora

環境構築・デプロイ

  • Terraform採用
  • CircleCIからAPIでデプロイ
     ⇒docker対応CIサービスがおすすめ

強制ターミネート(Spotインスタンス)

  • コンテナ強制終了
  • 検知する仕組み必要
    • メタデータをポーリング⇒クラスタから退役

AMI

  • ECS-Optimized AMI 使用
  • AMIのカスタマイズはしない
  • 設定はcloud-initで

ECSの課題

  • クラスタ管理

    • agent方式⇒ラグが多々
    • ゾンビワーカー
  • docker全機能は使えない
  • コンソール画面がまだまだ
  • 学習コストそこそこ

ECSの強みは他AWSサービスとの連携


Session:『AWS で実現するセキュリティ・オートメーション』 (16:20 ~ 17:00)

スピーカー:桐山 隼人 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

クラウドは、今までやってきたことを効率的にするだけでなく、今までできなかったことを可能にします。本セッションでは、セキュリティをクラウド環境で実現することで可能となる、運用統合と自動化(オートメーション)をご紹介します。セキュリティ・オートメーションは、貴社の運用が変わるだけでなく、セキュリティ戦略そのものを見直すきっかけにもなります。オートメーションによる次世代のセキュリティを考えてみませんか?

※スライドは公開されていないようですが、ほぼこれと同じだったかと思います。

クラウド移行に関するアンケート

日:クラウドに移行しない理由 1位 ⇒セキュリティ
米:クラウドに移行した理由 1位 ⇒セキュリティ
 ⇒まだ正確な認識が普及していないせいと思われる

クラウドだからできるセキュリティ

オートメーションとは=戦略策定の基盤
AWSはセキュリティオートメーション前提に設計されている ⇒基盤として活用してほしい

  • 戦略策定

    • SFA、マーケティングに活用
    • やること やらないこと を決められる
  • 何を自動化すべきか? (考える主軸 ⇒)

    • 対策主体(人、組織、技術)
    • 対策対象(サーバ、ネットワーク、クライアント)
    • 対策場所(入口、内部、出口)

ガートナーの『適応型セキュリティアーキテクチャ』

サイクルを回す:
 防御⇒検知⇒対応⇒予測⇒~

 防御:CloudFront、WAF ~
 検知:VPC Logs、Auto Scaling ~
 対応:SNS、Lambda ~
 予測:EC2 Config、3rd party レピュテーション、Inspector ~

実用例

CloudFrontアクセス⇒WAF⇒LambdaでレピュテーションリストDL&判定
 ⇒Lambdaでセキュリティ評価⇒Amazon Inspector⇒SNS⇒LambdaでNACL/SG変更
 ⇒攻撃検知⇒ブロックログ⇒EBSなどsnapshot⇒CloudTrail(操作ログ)
全レイヤー、ノードのログが取れるので
 ⇒VPC Flow Logs/Elastic Search/Kibanaなどで可視化
攻撃者のドメイン生成は自動化されている:Domain Generation Algorithm(DGA)
 ⇒AWS WAF + Amazon MLで怪しいドメインを学習
Machine Learningでリスク分析
 ⇒設定変更などの意思決定まで自動化


Session:『Machine Learning on AWS』 (17:20 ~ 18:00)

スピーカー:志村 誠 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

AI や機械学習という言葉が話題になる遥か前から、Amazon では機械学習技術を活用したさまざまな取り組みを行ってきました。本セッションでは AWS の上でご利用いただける機械学習サービスについてご紹介するととともに、それらをどのように使い分けるか、また機械学習をどのように皆さまのサービスに役立てて行くかについてご紹介します。

どんなサービスで機械学習を活用するか?

ビジネス主体で考える(使いたい技術から考えない)

  • 良質なデータが継続的に入るか
  • 自動化の価値ある予測か
  • 費用対効果

機械学習はあくまでツール
需要に反し解決していない問題に対して検討する

代表的な活用例>
– レコメンド
– 異常検知
– 画像認識
– クラスタリング(ユーザの分類分けなど)

AWSで提供する機械学習サービス

グルーピング>

  • Service
  • platform
  • Engines
  • Hardware

AI Hardware

  • EC2:P2 instance

    • GPU特化
  • Greengrass
    • デバイスに学習モデル
    • エッジで推論処理

AI Engines

典型的な機械学習フレームワークをインストール済みのAMIを提供

AI platform

  • Amazon Machine Learning
  • Amazon EMR

AI Service

  • Polly
  • Rekognition
  • Lex

その他

Kinesis Analytics >異常検知
Elastic Search >検索を機械学習に利用
Data Pipeline >EMRのジョブをスケジューリング

ゴールを明確に

  • 解決すべき課題
  • アウトプット

続き⇒Day4

続きを読む

AWSでAuto Scaling + Capistranoでデプロイはしているが、ソースコードが更新されるたびにAMIを作り変える手順をちょっと楽にする

今回解決したい問題

現在CapistranoでAuto Scaling環境にデプロイしていますが、以下のような課題があります

  • Capistranoのデプロイ先のサーバが設定ファイルに直書きされている。Auto Scalingでスケールアウト・インするたびに書き直さなければいけない
  • ソースコードを更新するたびにAMIを作り直さなければいけない。それに付随してAuto Scalingの起動設定やAuto Scalingグループの設定変更が必要

上記を解決すれば、ソース更新後のデプロイがいつでも可能になり、スケールアウトしても最新のコードがインスタンスに反映されるようになります

環境

  • Bitbucket
  • Rails: 5.1.1
  • Ruby: 2.4.1
  • デプロイ系の各種Gem
    • capistrano (3.8.X)
    • capistrano-bundler (1.2.X)
    • capistrano-rails (1.1.X)
    • capistrano-rbenv (2.1.X)
    • capistrano3-delayed-job (1.7.X)
    • capistrano3-unicorn (0.2.X)
    • aws-sdk (2.9.29)

作業ログ

Auto Scalingされているインスタンスを自動で取得する設定

現在、config/deploy/環境.rbにデプロイ先がドメイン名とともに直書きされているので、aws-sdkを使ってAuto Scalingグループ名から取得できるようにします。

aws-sdkは設定を記述しない場合は、~/.aws/configなどから情報を取得するのですが、今回は特定ディレクトリ以下で異なるAWS設定を使いたいためdirenvで設定をわけます。

Railsアプリディレクトリ直下でdirenv edit .と実行し、以下の設定を記述します。xxxとyyyは各自変えてください。

export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=yyy
export AWS_DEFAULT_REGION=ap-northeast-1
export AWS_DEFAULT_OUTPUT=json

次に、Capistrano側に変更を加えます。まずAWSのAuto Scalingグループからインスタンスの情報を取得するためにlib/capistrano/helpers/aws_utils.rbに以下の記述をします。なお、aws-sdkはGemfileに記載されているものとしてすすめます。

lib/capistrano/helpers/aws_utils.rb

require 'aws-sdk'

module AWSUtils
  def self.auto_scaling_dns_list(group_name)
    instances_of_as = auto_scaling_instances(group_name)

    instances_ids = instances_of_as.map(&:instance_id)
    instances_of_ec2 = instances_ids.map do |instance_id|
      Aws::EC2::Resource.new.instance(instance_id)
    end.sort_by { |v| [v.launch_time, v.id] }
    instances_of_ec2.map(&:public_dns_name)
  end

  def self.auto_scaling_instances(group_name)
    as = Aws::AutoScaling::Client.new
    instances_of_as = as.describe_auto_scaling_groups(
      auto_scaling_group_names: [group_name],
      max_records: 1
    ).auto_scaling_groups[0].instances

    return [] if instances_of_as.empty?
    instances_of_as
  end
end

次に、config/deploy/環境.rbに以下の記述を追記し、既存のserverの記述を削除します。
userやrolesなどは適宜かえてください。auto_scaling_dns_listで返ってくるリストは、インスタンス起動順にソートされているので必ず古いインタスンスでmigrationなどが実行されるようになっています。

config/deploy/環境.rbに追記

group_name = 'auto_scalning_test'
AWSUtils.auto_scaling_dns_list(group_name).each_with_index do |dns, i|
  roles = i.zero? ? %w[web app db] : %w[web app]
  server dns, user: 'ec2-user', roles: roles
end

最後にCapfileに以下の記述を追記し、deployスクリプトからAWSUtilsが使えるようにします

Capfile

Dir.glob('lib/capistrano/helpers/*.rb').each { |r| import r }

スケールアウトした際に最新のコードが適用されるようにする

以下のように解決します。以下増えたインスタンス自身が起動後に自動で行います。

  1. 最新ソースコードを特定のディレクトリにpullする
  2. 最新のソースコード上からlocalhost(自インスタンス)に向けてデプロイする

最初に、localhostにsshでログインできるようにします。~/.ssh/id_rsa~/.ssh/id_rsa.pubは存在している前提です。

~/.ssh/configに以下を追加

Host *
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
# 権限をかえる
chmod 400 ~/.ssh/config 

# ローカルホストに繋げれるか確かめる
ssh localhost

次に、ソースコードをpullできるためにはBitbucketに鍵が登録されている必要があります。~/.ssh/id_rsa.pubを以下のように追加します。

image.png

次に、特定ディレクトリ以下に最新ソースコードをcloneします。今回は、/home/ec2-user/deploy/プロジェクト名のフォルダにcloneしました。

インスタンスが新規作成されたときのユーザデータを作ります。Auto Scalingの起動設定を作成するときに以下のユーザデータを追記しておきます。
ユーザデータのログは/var/log/cloud-init-output.log/var/log/cloud-init.logに出力されるのでうまくスクリプトが起動できなければそちらをみてデバッグします。

#!/bin/bash -ex
su - ec2-user /home/ec2-user/bin/self-deploy.sh production

上記のユーザデータで実行される/home/ec2-user/bin/self-deploy.shは以下のスクリプトとなります。作成後、chmod 755 ~/bin/self-deploy.shで権限をかえておきます。

/home/ec2-user/bin/self-deploy.sh

#!/bin/bash

####################################
# /home/ec2-user/bin/self-deploy.sh
####################################

# path
app_path=/var/www/aws-rails-cap-autoscale/current
deploy_path=/home/ec2-user/deploy/aws-rails-cap-autoscale

# environment
rails_env=$1

# change directory
cd $deploy_path

#️ export $PATH
export PATH

# update rails app for deploy
echo "=== [${rails_env}] update rails app for deploy ==="
git fetch origin master
git reset --hard origin/master
echo ""

# bundle install for deploy
echo "=== [${rails_env}] bundle install for deploy ==="
bundle install --path vendor/bundle --without production staging --quiet -j8
echo ""

# self-deploy
echo "=== [${rails_env}] self-deploy to localhost ==="
bundle exec cap local_${rails_env} deploy
echo ""

Capistrano側にconfig/deploy/local_production.rbを以下のように記載します。

config/deploy/local_production.rb

server 'localhost', user: 'ec2-user', roles: %i[web app db]

set :stage, :production
set :rails_env, :production

最後に上記を適用した、EC2のAMIイメージを作成し、Auto Scalingを更新すればスケールアウト後に自動で最新コードが適用されます。

まとめ

今回の作業でデプロイが結構楽になりましたが、まだ以下のような、今後解決したい課題があるのでいずれやろうと思います。

  • デプロイするたびにbundlerが2回はしるのでやや時間がかかる。rsyncなどで踏み台サーバから更新する

参考

続きを読む

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

続きを読む

CodedeployのLifeCycleに関するメモ

CodedeployのLifeCycleに関する雑な理解

大きくアプリケーション周りのライフサイクル(7つ)とロードバランサーに関係するライフサイクル(6つ)がある。初回デプロイ時にはDownloadBundleされる前のApplicationStopはrunscriptがないので実行されない。

Application周りのライフサイクル(Application止めて、正常稼働確認まで)

  • ApplicationStop
  • DownloadBundle
  • BeforeInstall
  • Install
  • AfterInstall
  • ApplicationStart
  • ValidateService

LB周りのライフサイクル

  • BeforeBlockTraffic
  • BlockTraffic
  • AfterBlockTraffic
  • BeforeAllowTraffic
  • AllowTraffic
  • AfterAllowTraffic

runscriptの実行可否一覧

IP:InPlaceDeployment
BG:Blue/GreenDeployment
BGR:Blue/GreenDeployment Rollback
CLB:ClassicELB

◯:runscriptは実行される
△:runscriptは場合によって実行される(2回目以降のデプロイから)
×:runscriptは実行されない
太字:runscriptは実行されない。codedeploy占有。

LifeCycleEvent IP(LB無し) IP+CLB IP+ALB BG(Blue) BG(Green) BGR(Blue) BGR(Green)
1.ApplicationStop × × ×
2.DownloadBundle × × × × × × ×
3.BeforeInstall × × ×
4.Install × × × × × × ×
5.AfterInstall × × ×
6.ApplicationStart × × ×
7.ValidateService × × ×
8.BeforeBlockTraffic × × × ×
9.BlockTraffic × × × × × × ×
10.AfterBlockTraffic × × × ×
11.BeforeAllowTraffic × × × ×
12.AllowTraffic × × × × × × ×
13.AfterAllowTraffic × × × ×

runscript内で使える環境変数

個人的にDEPLOYMENT_GROUP_NAMEくらいしか使わない。

  • APPLICATION_NAME
  • DEPLOYMENT_ID
  • DEPLOYMENT_GROUP_NAME
  • DEPLOYMENT_GROUP_ID
  • LIFECYCLE_EVENT

個人的Tips

  • runscriptの名前にイベントの順序ごとに番号つける。1_application_stop.sh等にしておくと順序悩まない。
  • とりあえずEC2のUSERDATAやAutoScalingのLaunchConfigurationに以下のコード入れて置くと楽。
#!/bin/bash
REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//')
yum install -y aws-cli
cd /home/ec2-user/
aws s3 cp s3://aws-codedeploy-${REGION}/latest/install . --region ${REGION}
chmod +x ./install
./install auto

参考

Lifecycle Event Hook Availability

続きを読む

【AWS】Elastic Beastalk

はじめに

タダです。
AWS認定試験勉強のためにElastic Beanstalkのドキュメントを読んだ自分用メモになります。
※違う内容書いているなどありましたらご指摘いただけると幸いです。
※随時アップデートがあれば更新していきます。

サービスの概要

  • Elastic Beanstalkは、ソースコードをアップロードするだけで、ソースコードを実行する環境のプロビジョニング、ロードバランサー、スケーリング、モニタリングなどの細かい作業はサービスを管理するサービス

    • サポートするのは、PHP、Java、Python、Ruby、Node.js、Docker
  • 構成できるのは、ウェブサーバー環境とワーカー環境
    • ウェブサーバー環境は、ELB + AutoScalingでスケーラブルな環境を構成し、環境毎にDNS名を付与する
    • ワーカー環境は、SQS + AutoScalingでスケーラブルなバッチ処理基盤を構成する
      • Sqsdはワーカーホスト内で動作するデーモン

        • 200 OKならSQSのメッセージを削除
        • 200 OK以外ならVisibilityTimeout(SQSの設定)後にSQSからメッセージが取得可能(リトライ)
        • 応答なしならInactivity Timeout(Elastic Beanstalkの設定)後にSQSからメッセージが取得可能(リトライ)
      • 定期的なタスク実行も可能(cron.yamlで定義)

特徴

  • デプロイオプションを使って、簡単に新しいアプリケーションバージョンを実行している環境にデプロイできる
  • CPU平均使用率、リクエスト数、平均レイテンシーなどCloudWatchモニタリングメトリクスにアクセスできる
  • アプリケーションの状態が変化したり、アプリケーションサーバが追加または削除されたりした際にはSNSをつかって通知が行われる
  • アプリケーションサーバにログインせずにサーバのログファイルのアクセスできる
    • S3に保管される
  • AMI、オペレーティングシステム、言語やフレームワーク、およびアプリケーションサーバーまたはプロキシサーバーなどアプリケーションを実行する基盤となるプラットフォームに対する定期的な自動更新を有効にできる
  • アプリケーションサーバ設定(JVM設定など)を調整して環境変数を渡す

サービスの構成要素

  • アプリケーション : トップレベルの論理単位

    • バージョン、環境、環境設定が含まれている入れ物
  • バージョン : デプロイ可能なコード
    • S3上でのバージョン管理
    • 異なる環境に異なるバージョンをデプロイ可能
  • 環境:Webサーバ、ワーカーに応じて構築されるインフラ環境
    • バージョン(ソースコード)をデプロイ
  • 環境設定:その環境に関連するリソースの動作を定義するパラメーター
    • EC2インスタンスタイプ、AutoScalingの設定など
       
      ## 環境のタイプ
  • ロードバランシング、AutoScaling環境
    • 高い可用性と伸縮自在性を兼ね備えた構成
    • ウェブサーバー環境:ELB + AutoScaling
    • ワーカー環境:SQS + AutoScaling
  • シングルインスタンス環境
    • EC21台構成(AutoScalingでmax,minが1に設定されている)
    • 開発環境などの構築のために低コストで構築可能

環境設定

環境に関連するリソースの動作を定義する設定パラメーター

  • 直接設定

    • マネジメントコンソールまたはElastic Beastalk CLI(eb createオプションで実施)
  • 保存済み設定
    • 環境の作成中または実行中の環境に適用できる設定をS3に保存して流用できる(ステージングで使った設定を本番に適用)
  • デフォルト値
  • .ebextensions
    • ウェブ環境のソースコードに.ebextensionsを追加することで環境を設定し、環境に含まれるAWSリソースをカスタマイズできる(JVM設定など)
    • 環境で使用しているリソースのカスタマイズが可能
    • 環境に対する様々な操作を自動化、集約可能
~/workspace/my-app/
|-- .ebextensions
    |-- environmentvariables.config
    |-- healthchekckurl.config
|-- .elasticbeanstalk
    |-- config.yml
|-- index.php

.ebextensionsで実行可能な操作

  • packages:yum,rpmでのパッケージのインストール
  • sources:外部からのアーカイブをダウンロードした場所に展開する
  • users/groups:任意のユーザー/グループを作成
  • commands:デプロイ処理前に実行すべきコマンドやスクリプトを指定
  • container_commands:新バージョンの展開後に実行すべきコマンドやスクリプトを指定
  • option_settings:環境変数の設定
  • Resouteces:追加のリソースを定義(SQSのキュー、DynamoDBテーブル、CloudWatchのアラーム)

.ebextensions Tips

  • セクションごとにファイルを分割する
  • インストールするパッケージのバージョンを明記
    • インスタンスによって異なるバージョンになることを防止
  • カスタムAMIとのトレードオフを検討

Dockerサポート

  • Dockerを構成する場合、Single Container(EC2の中にDockerを実行)またはMulti Container(ECS)を利用可能
  • DockerをElastic Beanstalkでデプロイする場合、Dockerrun.aws.jsonで定義して実行する
{
  "AWSEBDockerrunVersion": "1",
  "Image": {
    "Name": "janedoe/image",
    "Update": "true"
  },
  "Ports": [
    {
      "ContainerPort": "1234"
    }
  ],
  "Volumes": [
    {
      "HostDirectory": "/var/app/mydb",
      "ContainerDirectory": "/etc/mysql"
    }
  ],
  "Logging": "/var/log/nginx"
}

デプロイ形式

Elastic Beastalkのデプロイ形式を以下にまとめる

メソッド 概要
All at once 同時にすべてのインスタンスに新しいバージョンをデプロイする。環境内のすべてのインスタンスは、デプロイが実行される間、短時間だがサービス停止状態になる。
Rolling バッチに新しいバージョンをデプロイする。デプロイフェーズ中、バッチはサービス停止状態になり、バッチのインスタンスによる環境容量への負荷を低減する。
Rolling with additional batch バッチに新しいバージョンをデプロイするが、デプロイ中に総容量を維持するため、インスタンスの新しいバッチをまず起動する
Immutable 変更不可能な更新を実行し、新しいバージョンをインスタンスの新しいグループにデプロイする。

モニタリング

  • 基本(ベーシック)ヘルスレポート

    • 環境のヘルスステータス
    • ELBのヘルスチェック
    • CloudWatchメトリクス
  • 拡張ヘルスレポート
    • OSレベルのメトリクス
    • アプリケーションレベルのメトリクス

拡張ヘルスレポートの主なメトリクス

  • EnvironmnetHealth
  • インスタンスの状態
  • リクエスト総数及び各レスポンスコード毎の数
  • x%の完了のかかった平均時間
  • LoadAverage1min: 1分間のLoad値の平均値
  • RootFilesystemUtil: 使用ディスク容量の割合
  • CPU使用状況詳細

他のAWSサービスとの統合

  • CloudFront

    • Elastic Beanstalkでデプロイしたら、CloudFrontから配信する
  • DynamoDB
    • Elastic BeastalkでDynamoDBのテーブルを作成し、データを書き込む
  • Elasticache
    • セキュリティグループでElastic Beastalkでアクセスできるように設定する
  • RDS
    • セキュリティを高めるために、接続情報をS3に保存し、デプロイの間にデータを取得するようにElastic Beastalkを設定する
    • 設定ファイル(ebextensions)を使用して環境内のインスタンスを設定し、アプリをデプロイする時にS3からファイルを安全に取得できる
  • S3
    • S3バケットは、アプリケーションのバージョン、ログ、その他のサポートファイルファイルを保存する

メンテナンスウィンドウ

メンテナンスウィンドウは、管理プラットフォームの更新が有効化されており、プラットフォームの新バージョンが公開されている場合にElastic Beanstalkでプラットフォームの更新が開始される毎週2時間の時間帯が割り当てられる

EB CLIについて

コマンドラインインターフェースとして、EB CLIがある

  • eb create

    • 初期環境を作成する
  • eb status
    • 環境のステータスを確認する
  • eb health
    • 環境内のインスタンスのヘルス情報とその環境全体の状態を表示する
  • eb events
    • 環境のイベントのリストを確認する
  • eb logs
    • 環境のインスタンスからログを取得する
  • eb open
    • ブラウザでウェブサイトのユーザー環境を開く
  • eb deploy
    • デプロイする
  • eb config
    • 実行する環境に利用可能な設定オプションを確認する
  • eb terminate
    • 環境のターミネート

参考

更新日時

  • 2017/05/01 初回投稿
  • 2017/05/05 環境設定の項目を更新、Dockerサポートを追加

続きを読む

【AWS】ELB(CLB)

はじめに

タダです。
AWS認定資格の試験勉強のためにELBの情報をまとめた自分用メモになります。
あくまで個人用のメモになるので、その点はご了承ください。
※違う内容書いているなどありましたらご指摘いただけると幸いです。
※本記事では、Classic Load Balancerの情報をまとめていきます。
※随時アップデートがあれば更新していきます。

サービス概要

ELBは2つのタイプに分けられる

  • Classic Load Balancer

    • アプリまたはネットワークレベルのいずれかの情報に基づいてルーティングする
    • 複数のEC2インスタンス間でシンプルなトラフィックのルーティングに適する
  • Application Load Balancer
    • リクエストパスまたはホストベースでルーティングする
    • 複数のサービスにルーティングしたり、同じEC2インスタンスの複数のポート間で負荷分散するのに適する

特徴

  • スケーラブル

    • ELB自体も負荷に応じてスケールアウト
  • 可用性向上
    • 複数AZへの振り分け、インスタンスのヘルスチェック
  • マネージドサービス
  • ルーティング方式
    • 基本はラウンドロビン
  • コネクションタイムアウト
    • クライアントからの無通信状態が続くと接続を自動で切断する(デフォルト60秒)
  • ELB自体のスケーリング
    • じんわりとしたトラフィックの増加には対応できる

      • 逆に急激なトラフィックの増加にはスケーリング対応できないため、事前にPre-Warming(暖機運転)の申請をAWSに行う
  • スティッキーセッション
    • 同じユーザーから来たリクエストをすべて同じEC2に送信
    • アプリケーションでのセッション情報、一時ファイルなどをEC2が保持する構成の場合に必要
    • HTTP/HTTPSでのみ利用可能
    • EC2の増減を柔軟に管理できるようセッション情報は別のDBやキャッシュサーバに保持させるのが好ましい
  • Connection Draining
    • EC2インスタンスとELB間の登録解除、ヘルスチェック失敗した時にルーティングを中止して、処理中のリクエスト終わるまで一定期間まつ
  • X-Forwarded-For
    • HTTPまたはHTTPSロードバランサーを使用する場合に、クライアントの IP アドレスを識別するのに役立つ
  • Proxy Protocol
    • ELBはProxy Protocolバージョン1をサポートしている
    • Proxy Protocolヘッダーはバックエンド接続用にTCPを使う場合、クライアントのIPアドレスを識別するのに役立つ
    • 有効化する場合の前提条件は以下の通り
      • ELBの背後にプロキシサーバがいないこと
      • インスタンスでProxy Protocol情報を処理できるか確認する
      • リスナー設定でProxy Protocloがサポートされているかを確認する
  • 他のサービスとの連携機能
    • AutoScaling
    • Route53
    • CloudFormation
    • OpsWorks
    • Elastic Beanstalk
    • CloudWatch
    • EC2
    • S3など

サポートプロトコル

Classic Load Balancerのサポートプロトコルは、以下の通り

  • HTTP
  • HTTPS
  • SSL(セキュアTCP)
  • TCP

ロードバランサーのタイプ

ロードバランサーのタイプとして、外向けロードバランサーと内向けロードバランサーがある

  • 外向けロードバランサー : インターネットからアクセスできるELB
  • 内向けロードバランサー : VPC内やオンプレ環境からのみアクセスできるELB

モニタリング

ELBの監視を行う場合は以下の方法がある

  • CloudWatchメトリクス
  • ELBのアクセスログ
    • ELBへのリクエストの詳細情報をキャプチャしているので、確認する
  • CloudTrailログ

トラブルシューティング

よくELBのトラブルシューティングでHTTPステータスから設定不足を確認することがあるので、ドキュメントの情報をまとめる

  • HTTP 400: BAD_REQUEST

    • 原因:クライアントが誤ったリクエストをしてしまったため発生
    • 解決策:直接インスタンスに接続し、クライアントリクエストの詳細をキャプチャする
  • HTTP 405: METHOD_NOT_ALLOWED
    • 原因:リクエストヘッダー内のメソッドの長さが127文字を超える
    • 解決策:メソッドの長さを確認する
  • HTTP 408: Request Timeout
    • 原因:指定されたコンテンツのサイズが実際に創始されたコンテンツサイズと一致しないや、クライアントとの接続が閉じているため発生
    • 解決策:リクエストを生成しているコードを調べ、リクエストをより詳細に調べることのできる登録済みインスタンスに直接送信する、レスポンスが送信される前にクライアントが接続を閉じないようにする
  • HTTP 502: Bad Gateway
    • 原因:インスタンスからの応答の形式が適切でないか、ロードバランサーに問題がある
    • 解決策:インスタンスから送信された応答が HTTP 仕様に準拠していることを確認する
  • HTTP 503: Service Unavailable
    • 原因:ロードバランサーにリクエストを処理する能力が不足または、登録されたインスタンス(正常なインスタンス)が存在しない
    • 解決方法:前者の場合は一時的な問題のため、一旦放置氏それでも解決しない場合はAmazon Web Servicesサポートへ問い合わせ
    • 後者の場合、正常なインスタンスを登録する
  • HTTP 504: Gateway Timeout
    • 原因:アプリケーションの応答が、設定されているアイドルタイムアウトよりも長くかかっているまたは、録されたインスタンスがELBへの接続を終了させている
    • 解決策:前者は、ELB側のアイドル接続のタイムアウト設定を伸ばす
    • 後者の場合は、MWのKeepAlive設定を有効にしてELBのタイムアウト設定よりも大きい値を定義する

参考

更新日時

2017/05/01 初回投稿

続きを読む

【AWS】OpsWorks スタック

はじめに

タダです。
AWS認定資格の試験勉強のためにCloudFormationの情報をまとめた自分用メモになります。
あくまで個人用のメモになるので、その点はご了承ください。
※違う内容書いているなどありましたらご指摘いただけると幸いです。
※随時アップデートがあれば更新していきます。
※本記事では、OpsWorks スタック中心のまとめになります。

サービス概要

  • OpsWorksはChefを使ったAWSリソース(EC2、ELB、RDSなど)やEC2上のアプリケーションの設定・管理を行うためのサービス
  • Chefサーバーは不要で、OpsWorksスタックは、インスタンスのヘルスチェックをモニタリングし、自動復旧および Auto Scaling を使用して、必要な場合に新しいインスタンスをプロビジョニングする
  • Chefのcookbookレシピを使って、インフラの管理を自動化、アプリケーションの継続的なインストール、構成、管理、デプロイ、スケールが可能なのがChef Automate
    • Chefサーバありきだが、管理はAWS

OpsWorksエージェント

  • OpsWorksスタックで必要

    • OpsWorksの一連のコマンドを取得し、エージェントがChef Clientのローカルモードでレシピを実行

利用メリット

アプリケーションのモデル化とサポート
管理作業を自動化

CloudFormation/Elastic Beastalkとの違い

  • OpsWorksは、DevOps環境を提供することを目的におき、デプロイ、モニタリング、自動スケーリング、自動化の主要なアクティビティに対して統一された設定管理を行う
  • CloudFormationはAWSリソースのプロビジョニングと管理をJSON/YAMLで行うことを目的とする
  • Elastic BeastalkはJava、.NET、PHP、Node.js、Python、Ruby、Go、Docker で開発されたウェブアプリケーションとウェブサービスをデプロイおよびスケーリングする

制限

デフォルトでは、最大40スタックを作成できる
最大40のレイヤー、最大40のインスタンス、最大40のアプリケーションを保持できる
 

専門用語

  • スタック

    • OpsWorksの管理対象をまとめたコンポーネントで、属する全員インスタンスの構成を管理する
  • レイヤー
    • 1つ以上の Layer を追加することにより、スタックのコンポーネントを定義する
    • レイヤーは、アプリケーションへのサービス提供やデータベースサーバーのホストのような特定の目的を果たす一連のEC2インスタンスを表す
  • インスタンス
    • インスタンスのスケーリングタイプは3つある

      • 24/7インスタンス(常時稼働)
      • load-basedインスタンス
        • 負荷に対してサーバを起動することができる
        • メトリックスの閾値は次のものを定義し、インスタンスの増減をコントールできる
          • [Average CPU] – Layer の平均 CPU 使用率 (合計に対する割合)
          • [Average memory] – Layer の平均メモリ使用率 (合計に対する割合)
          • [Average load] – Layer の平均負荷
      • time-basedインスタンス
        • 時間ベースのスケーリングにより指定したスケジュールでインスタンスを起動、停止できる
        • 特定の時間または特定の曜日にレイヤーによりオンラインにされるインスタンス数を制御できる
  • App
    • アプリケーショサーバにデプロイするアプリケーション
  • レシピ
    • Chefレシピを実行して、アプリケーションの設定、アプリケーションのデプロイ、スクリプトの実行などを行う

スタックコマンド

スタック全体の構成を変更・管理するためのコマンドで以下のようなものがある
実行方法はAWSマネジメントコンソールやCLI、SDKなど

  • Update Custom Cookbook

    • リポジトリにある更新されたCookbookをそれぞれのインスタンスに展開する
  • Execute Recipes
    • 指定したレシピを指定したインスタンス上で実行する
  • Setup
    • Setupのレシピを実行する
  • Configure
    • Configureのレシピを実行する
  • Upgrade Operationg System
    • (Linuxのみ)Amazon Linuxを最新バージョンにアップグレードする

ライフサイクル

OpsWorksのインスタンスで自動的に行う処理をさす

  • Setup : 新しいインスタンスが正常にブートした後に発生する

    • ex: ロードバランサーをインストール、アプリケーションサーバをインストール、データベースをインストール
  • Configure : インスタンスがオンライン状態に移行したときとオンライン状態から移行した時にスタックのすべてのインスタンスで発生する
    • ex: アプリケーションサーバのIPをアップデート、DB接続先をアップデートして再起動、アプリケーションサーバのIPのACLをアップデート
  • Deploy : ユーザーがアプリケーションをデプロイする時に発生する
    • ex:アプリケーションコードをアップデートして再起動
  • Undeploy : アプリケーションを削除する時に発生する
    • ex:アプリケーションを削除して再起動
  • Shutdown : インスタンスの終了
    • コネクションをDrainする、ログを保存、スナップショットの保存

Opsworksと他サービスとの連携

モニタリング

スタックは次の方法で監視可能

  • CloudWatchによるスタックのインスタンスごとに詳細モニタリング
  • CloudTrailによるAPI監視
  • CloudWatch Logsでスタックのシステム・アプリケーション・カスタムログを監視する

セキュリティおよびアクセス許可

  • VPC内に展開可能
  • AWSリソースにアクセスするためのACLやインスタンスへの接続管理はIAM(ユーザー、許可、ロール)で行う

参考

更新日時

  • 2017/05/01 初回投稿

続きを読む

【AWS】CloudFormation

はじめに

タダです。

AWS認定資格の試験勉強のためにCloudFormationの情報をまとめた自分用メモになります。
あくまで個人用のメモになるので、その点はご了承ください。
※違う内容書いているなどありましたらご指摘いただけると幸いです。
※随時アップデートがあれば更新していきます。

CloudFormationとは

AWSリソースを作成したり、管理するのが役立つツールです。JSONやYAML形式でリソース定義できる

CloudFormationを使う主なメリットは以下の通り

  • AWSリソース管理が簡略化
  • インフラリソースを素早く展開/複製
  • インフラリソースの制御や変更も簡単

Elatic Beanstalkとの違い

  • Elatic Beanstalkはアプリを簡単にデプロイ及び実行できる環境を提供する

    • アプリのライフサイクルを管理するためのサービス
  • CloudFormationはAWSリソースの作成をサポートする
    • Elatic Beanstalkもサポートしている

CloudFormationの概念

  • テンプレート

    • YAMLまたはJSON形式のテキストファイルでAWSリソース作成のための設計図

      • 5種類の要素で構成される

        • テンプレートパラメータのオプションリスト
        • 出力値のオプションリスト
        • 静的な設定値を見るのに使用するデータテーブルのオプションリスト
        • AWS リソースとそれらの設定値のリスト
        • テンプレートファイルフォーマットのバージョン番号
    • 具体的には以下のようなものがテンプレート例
{
  "AWSTemplateFormatVersion" : "2010-09-09",
  "Description" : "A sample template",
  "Resources" : {
    "MyEC2Instance" : {
      "Type" : "AWS::EC2::Instance",
      "Properties" : {
        "ImageId" : "ami-2f726546",
        "InstanceType" : "t1.micro",
        "KeyName" : "testkey",
        "BlockDeviceMappings" : [
          {
            "DeviceName" : "/dev/sdm",
            "Ebs" : {
              "VolumeType" : "io1",
              "Iops" : "200",
              "DeleteOnTermination" : "false",
              "VolumeSize" : "20"
            }
          }
        ]
      }
    }
  }
}
  • スタック

    • CloudFormationの関連リソースは、スタックと呼ばれます。これを作成、変更、更新することでリソース制御を行う
    • スタックの更新には2つの方式がある
      • 直接更新(in place)と変更セットの作成(blue-green)と実行
  • 変更セット
    • スタックの更新をおこなう時の概要が変更セットと呼び、影響度を確認するためのスタック

変更セットについて

変更セットの作成

更新元のスタックをもとに変更セットを作成します
Cloudformation -> [Actions],[Create Change Set For Current Stack]を選択
その他のパラメーターは、スタックを作成するのと同じ操作で行う
CLIだと、以下のように実行する

aws cloudformation create-change-set --stack-name arn:aws:cloudformation:us-east-1:123456789012:stack/SampleStack/1a2345b6-0000-00a0-a123-00abc0abc000
--change-set-name SampleChangeSet --use-previous-template --parameters ParameterKey="InstanceType",UsePreviousValue=true ParameterKey="KeyPairName",UsePreviousValue=true ParameterKey="Purpose",ParameterValue="production"

変更セットの実行

変更セットに記述された変更をスタックに加えるには、変更セットを実行する
※変更セットを実行するとスタックに関連付けられた変更セットは削除される点は注意。
CLIだと、以下のように実行する

aws cloudformation execute-change-set --change-set-name arn:aws:cloudformation:us-east-1:123456789012:changeSet/SampleChangeSet/1a2345b6-0000-00a0-a123-00abc0abc000

CloudFormationのベストプラクティス

  • スタックは共通リソースの所有者でグルーピング

    • リソース利用の制限は行わないようにする
  • クロススタック参照で共有リソースをエクスポート
    • ネットワークリソース系
  • アクセス制限はIAMで
  • スタックの制限は200なので、注意
  • テンプレートの再利用
  • 他のスタックにネストされたテンプレートの参照
  • テンプレートに認証情報を埋め込まない
    • 埋め込んでもNoEchoプロパティを使う
  • cfn-init ヘルパースクリプトと AWS::CloudFormation::Init を使ってEC2にソフトウェアをインストールする
  • ヘルパースクリプトは常に最新のものを使う
  • テンプレートを使用する前に検証する
    • aws cloudformation validate-template
  • CloudFormationで全てのリソースを管理する
  • スタックを更新する前に変更セットを作成する
  • CloudTrailとロギング
  • コードの確認とリビジョン管理
  • Elastic Compute Cloudのパッケージは最新化する

CloudFormationのテンプレート

JSONかYAMLのどちらかでテンプレートを作成します。

テンプレートのセクション

  • Format Version(任意)

    • テンプレートバージョンを指定する
  • Desription(任意)
    • 説明文
  • Metadata(任意)
    • テンプレートに関する追加情報を提供するオブジェクト
  • Parameters(任意)
    • テンプレートに渡すことができる値を指定する

      • データ型、デフォルト値、最大最小値など型が設定可能
    • テンプレートのResources、Outputsセクションのパラメーターを参照できる
  • Mappings(任意)
    • 条件パラメーター値の指定に使用できる、キーと関連する値のマッピング(検索テーブルに類似したもの)
  • Conditions(任意)
    • 特定のリソースが作成されるかどうかや、スタックの作成または更新中に特定のリソースプロパティが値を割り当てられるかどうかを制御する条件を定義する
  • Transform(任意)
    • サーバレスアプリケーションの場合、使用するAWS SAMのバージョンを指定する
  • Resources(必須)
    • スタックで作成するリソースとそのプロパティを指定する

      • EC2やELBやRDSなど起動するサービスを指定し、リソース毎に決められたプロパティを指定する
  • Outputs(任意)
    • スタックのプロパティを確認すると返される値について説明する
  • Function
    • パラメータの参照やMapの参照などの際はFunctionを使う(Parameterの取得に利用するRef関数もFunctionの一つ)

      • Ref: パラメータの参照
      • Fn::Base64 : 文字列をBase64でエンコードする
      • Fn::FindInMap : Mapから値を取り出す
      • Fn::GetAtt :リソースに付随する値を取得する
      • Fn::GetAZs : 指定したリージョンのAZを取得する
  • 疑似パラメータ参照
    • 予め定義されたパラメータ群をRef関数で参照できる

      • AWS::Region,AWS::StackId,AWS::StackNameなど

スタックの出力値のエクスポート

  • スタック間で情報を共有するにはスタックの出力値をエクスポートする

    • 同じAWSアカウントとリージョンの他のスタックは、エクスポートされた値をインポートできる
    • WebサーバのサブネットやSecurityGroup IDをエクスポートする単一ネットワーキングスタックがあったとして、Webサーバのあるスタックは、それらのネットワーキングしリソースをインポートできる

テンプレート作成ツール

  • CloudFormer

    • 構築済みの環境からテンプレートを作成するWebツール
  • CloudFormation Designer
    • テンプレート内のリソースを可視化
  • Hava
  • Cloudcraft

CloudFormationの運用

  • 個別テンプレート、1スタック
  • 個別テンプレート、個別スタック
  • スタック間の連携

CloudFormationのリソースについて

リソース属性

CreationPolicy

  • CloudFormationが指定数の成功シグナルを受信するかまたはタイムアウト期間が超過するまでは、ステータスが作成完了にならないようにする

    • AutoScalingCreationPolicy
    • ResourceSignal

DeletionPolicy

  • スタックが削除された際にリソースを保持または (場合によっては) バックアップできる

    • Retain

      • スタック削除したくない場合は指定する

DependsOn

  • 特定のリソースが他のリソースに続けて作成されるように指定できる

UpdatePolicy属性

  • CloudFormationがAWS::AutoScaling::AutoScalingGroup リソースに対する更新を処理する方法を指定できる

    • AutoScalingReplacingUpdate

      • AutoScaling グループの置き換え更新を処理する方法を指定する時に使う
    • AutoScalingRollingUpdate
      • ローリング更新を使う場合指定する
    • AutoScalingScheduledAction
      • スケジュールされたアクションが関連付けられているAutoScalingグループを含むスタックを更新する時に使う

CloudFormationヘルパースクリプト

スタック作成の時にEC2インスタンスでソフトウェアをインストールしたりサービスを開始したりするために使用できるPythonヘルパースクリプトのセットがある

  • cfn-init

    • リソースメタデータの取得と解釈、パッケージのインストール、ファイルの作成およびサービスの開始で使用される
  • cfn-signal
    • スタック内の他のリソースと準備できたアプリケーションを同期できる
  • cfn-getmetadata
    • リソースに定義されたすべてのメタデータ、またはリソースメタデータの特定のキーやサブツリーへのパスを簡単に取得できる
  • cfn-hup
    • メタデータへの更新を確認し、変更が検出された時にカスタムフックを実行するデーモン

参考情報

サービス概要
よくある質問
ドキュメント
SlideShare

更新日時

  • 2017/04/30 初回投稿

続きを読む