[2017夏版] AWS Start-up ゼミ参考資料リンク集をマークダウンに起こしました

TL;DR

こんにちは。AWSリハビリ中のnntsuguです。

[AWS Start-up ゼミ] よくある課題を一気に解説!〜御社の技術レベルがアップする 2017 夏期講習〜

先日参加させていただいたAWS Stat-upゼミ、講師のSA塚田さんの資料がとても良かった。
AWS上でサービスを構築運用する上での勘所がユースケースベースで整理されていて、モヤモヤしていた部分がかなりスッキリししました。

資料内にある参考資料や動画へのLink、とても勉強になるのですが、

  • PDFやSlideShareだとスマホから参照しづらい
  • 未読管理をしやすくするため

マークアップに起こしました。

毎朝ジムで走りながら参考資料の動画を見て聞いています。とても捗ります。

参考資料は主にBlack Beltの資料&動画アーカイブ、AWS Summit/Dev Dayの資料で構成されています。

ユーザ動向を分析したい

CI/CDをちゃんとしたい

コンテナを使いたい

運用監視ちゃんとしたい

システム負荷下げたい

(モバイルアプリの)Growth Hackしたい

コスト下げたい

  • AWS Black Belt Online Seminar資料&動画

    • クラウドのためのアーキテクチャ設計-ベストプラクティス-(資料|動画)
    • Auto Scaling (資料 | 動画)
    • Amazon EC2 Spot Instances (資料 | 動画)
    • サーバーレスによるアーキテクチャパターンのご紹介 (資料 | 動画)
  • AWS Summit/Dev Day講演資料 (2016 | 2017)
    • AWS のコスト最適化入門 (2017)(資料 | 動画)
    • [インティメート・マージャー様] AWS Summit 2017 講演資料 Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョ
      ブワーカーシステム(資料 | 動画)
    • AWS Well-Architected フレームワークによるクラウド ベスト プラク
      ティス (2017) (資料 | 動画)

その他

IPOとBuy Out、デューデリジェンス

続きを読む

AWS SDK for Java がデフォルトで参照する credential

aws-sdk-java 1.11.179 を参照して書いています。

AWS SDK for Java はデフォルトでいろんな場所から認証情報を読み込みます。
DefaultAWSCredentialsProviderChain の JavaDoc を見ると結構書いてあります。これと各 Provider の実装を見ながらどうなっているか見ていきます。

次のものを順番に試して最初に見つかった認証情報を利用するようになっています。

  1. 環境変数 EnvironmentVariableCredentialsProvider

    • AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY 環境変数 (Java 以外の SDK でも利用しているのでこちらのほうがオススメ)
    • AWS_ACCESS_KEYAWS_SECRET_KEY 環境変数
    • AWS STS を利用する場合は AWS_SESSION_TOKEN 環境変数
  2. Java システムプロパティ SystemPropertiesCredentialsProvider
    • aws.accessKeyIdaws.secretKey システムプロパティ
    • AWS STS を利用する場合は aws.sessionToken システムプロパティ
  3. プロファイル認証情報 ProfileCredentialsProvider
    • デフォルトのファイルは ~/.aws/credentials
    • ファイルの場所は AWS_CREDENTIAL_PROFILES_FILE 環境変数で指定できる
    • 昔使われていた ~/.aws/config も一応読みこまれる
    • ファイル内には複数の認証情報を記載できる。デフォルトでは default プロファイルが読み込まれる
    • AWS_PROFILE 環境変数、あるいは aws.profile システムプロパティでプロファイルを指定できる
    • 再読込ロックが獲得できれば5分に一度再読込される
    • 再読込ロックが獲得できなくても10分に一度再読込される
  4. EC2コンテナ内で利用可能な認証情報 EC2ContainerCredentialsProviderWrapper

環境変数やシステムプロパティを使ってかなりの設定ができるので、ほとんどの場合でデフォルトのままで十分です。自前で Credentials provider chain を作ると却って柔軟性が落ちて辛いということになりかねません。環境変数やシステムプロパティが利用できず、どうしてもカスタムしたいときは DefaultAWSCredentialsProviderChain を鎖の最後につなげておけば良いでしょう。

続きを読む

AWS ECSにdockerのローカルイメージをデプロイする

目次

  • はじめ
  • 前提条件
  • 手順
    • AWS CLIの準備
    • AWS ECSの準備
    • コンテナの中で動かしてみる
  • まとめ

前提条件

-AWSコンソールにログインできる
-dockerについて理解している

手順

  1. AWS CLIの準備
  2. AWS ECSの準備
  3. コンテナの中で動かしてみる
  4. sshで接続してみる

AWS CLIの準備

ここはターミナルでの操作になります。まずインストールですが、これはここをみれば大体わかると思います。
http://docs.aws.amazon.com/ja_jp/streams/latest/dev/kinesis-tutorial-cli-installation.html

インストールが終わったら、今度はaws configureの設定を行いましょう。

$aws configure
AWS Access Key ID [None]: <自分のAccess key ID>
AWS Secret Access Key [None]: <自分のSecret Access key>
Default region name [None]: <自分の住んでいるところから近いregion 東京なら:ap-northeast-1>
Default output format [None]: json //ここはjsonのままでと思います。

これでいろいろ下準備はおわりですね。そして次は今回使うAWS ECS(https://aws.amazon.com/jp/ecs/ )を使っていきます。

AWS ECSの準備

場所 : AWSコンソール → サービス → ECS

準備として、上記の場所にリポジトリメニューがあると思うので、そこから適当なリポジトリ名をつけます。
このリポジトリにローカルにある指定のイメージをpushしていきましょう。リポジトリ作ったならチュートリアルみたいのがでてるとは思います。

1. まずdockerにログインコマンド発行

aws ecr get-login --no-include-email --region <リージョン名>

2. 発行されたdockerログインコマンド(めちゃ長いやつ)を叩く

3. dockerのtagをつける(おそらく自由に変更可能)

docker tag test:latest 068701748150.dkr.ecr.ap-northeast-1.amazonaws.com/test:latest

4. タグをつけたイメージをプッシュ

docker push 068701748150.dkr.ecr.ap-northeast-1.amazonaws.com/test:latest

これでアップロードの過程がターミナルに出ると思います。終わったらリポジトリの準備はおわりです!

コンテナの中で動かしてみる

次はクラスター、サービス、タスクを作成して、実際にコンテナを起動していきます。

1. キーペアを生成する。

場所 : サービス→EC2→キーペア

キーペアはリージョンごとに違います。必ずAWSコンソールの右上が東京になっているか確認してください。
生成したあとは、任意のディレクトリに保管。

2. タスクを定義する。

場所 : サービス→ECS→タスク定義

タスク定義名を設定し、コンテナの追加からプッシュしたリポジトリのイメージを選択する。これによって、このタスクが実行された時、ローカルと同じ内容をECS
内のコンテナに立ち上げてくれます。

3. クラスター作成

場所 : サービス→ECS→クラスター→クラスター作成

ssh接続に必須なのはキーペアの項目です。先ほど生成したものに設定してください。
他のインスタンスタイプやVPC関連のものは適宜、必要なものに設定してください。
また原則クラスターの設定は作成した後、変更できないようなので注意したほうがいいですね。

4.クラスターの持つサービスを生成する。

場所 : サービス→ECS→クラスター→サービス(タブ)→作成

ここでは、サービスの持つタスク数、サービス名を登録し、どのタスクを実行するか選択しましょう。
タスク定義の項目は定義されているものがでてくるので、ちゃんと定義したものを選択しましょう。
 作成した後は、自動的にその設定されたタスクをサービスが実行してくれます。タスクタブにあるのがACTIVEになって入れば成功です。

これで、クラスター、サービス、タスクの設定は終了です。最後にsshについてです。

ECSにsshで接続する。

1. セキュリティグループにsshを追加

場所 : サービス→EC2→セキュリティグループ→自分のインスタンス→インバウンド→編集

sshで接続するにはそのポートを開いておかないとだめです。なので、sshの22番ポートを開いておきましょう。

2. sshで繋ぐ

ssh -v -i <キーペアのパス> ec2-user@<インスタンスのパブリックIPかパブリックDNS>

先ほど保存したキーペアデータのパスとECSインスタンスのパブリックIPかパブリックDNSを末尾につけることでsshで入れます.
ユーザーはデフォルトで用意されているec2-userがあるのでそれを使いましょう。
パブリックIPかパブリックDNSはサービス→ECS→クラスター→作ったクラスター→ECSインスタンス(タブ)→自分のインスタンスを選択することで見れます。

これで無事デプロイし、sshで接続までができました!

まとめ

EC2と違い、いきなりECSをやると混乱することもありそうです。キーペア生成の位置もEC2の方で生成するので….
なのでAWSコンソールになれるのもAWSに強くなるのには必要不可欠かもしれないですね!

続きを読む

Product Advertising API (PA-API) に専用のIAMでアクセスする

昔まだAWSが出来て間もない時代(かろうじてS3があったくらい)にPA-APIを使ったアプリを作っていたのですが、最近またPA-APIを使おうかなと思って調べたところ、未だにPA-APIを使うアプリでは認証にアマゾンのルートアカウントのアクセスキーとシークレットを使えという記事が出てきました。

PA-API以外に使うものがあんまりなかった時代ならいざしらず、AWSがこんなに使われてる現状でも未だにPA-APIにそれ用の権限とか存在しないのか…??と思ってよくよく調べてみると、最近それ用のIAMポリシーができたよう(いつできたのかは不明)なので、それを設定して使うことにしました。

これがなかったら、さすがにAWSをバリバリ使ってるアカウントのルートアカウントをPA-APIのアプリに使いたくなかったので、専用のAWSアカウントを作るところでした。

これはなにか?

PA-API用ポリシーを作って、PA-API用のIAMユーザに紐付ける手順、及びそのユーザのアクセスキー及び秘密鍵を使ってPA-APIから値を取得できるかの確認。

ポリシーの作成

まずはAWSのWebコンソールからPA-API専用のポリシーを作ります。

Pasted_Image_2017_07_30_18_03.png

「独自のポリシーを作成」を選択します。

Pasted_Image_2017_07_30_18_04.png

PA-APIに対するFullAccess権限を設定したポリシーにします。ポリシー名は適当なものを。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ProductAdvertisingAPI:*",
            "Resource": "*"
        }
    ]
}

image.png

念の為ポリシーの検証をしておいて、問題なければポリシーの作成です。

PA-APIアクセス用ユーザの作成

次に上記で作成したポリシーを紐付けるユーザを作成しましょう。

Pasted_Image_2017_07_30_18_13.png

適当な名前をつけて「プログラムによるアクセス」にチェックを入れます。

image.png

「既存のポリシーを直接アタッチ」を選んで、先程作成したPA-API用のポリシーにチェックを入れます。

image.png

次の画面で確認して、問題なければ更に次の画面でcredentials.csvをダウンロードしておきましょう。

実際にアクセス可能な確認

取得したアクセスキーと秘密鍵が実際にPA-APIへのアクセスに使えるか念の為チェックしておきましょう。

rubyだとamazon-ecsというgemがPA-APIにアクセスするのによく使われているようです。

associate_tagAWS_access_key_idAWS_secret_keyのところは自分のものに置き換えてください。

require 'amazon/ecs'

Amazon::Ecs.options = {
  associate_tag: 'xxxxxxxxxxxxxx',
  AWS_access_key_id: 'xxxxxxxxxxxxxxxxxx',
  AWS_secret_key: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  country: :jp
}

# Nintendo SwitchのASINを指定してみます
res = Amazon::Ecs.item_lookup('B01NCXFWIZ', response_group: 'Small')

p res.items.map {|item| item.get('ItemAttributes/Title') }
# => ["Nintendo Switch Joy-Con (L) ネオンブルー/ (R) ネオンレッド"]

OK、ちゃんと取れてるようですね。

参考

続きを読む