20200214のAWSに関する記事は16件です。

AWSの10分間チュートリアルをやってみる 8.Deploy and Monitor an Application from the Command Line

こんにちは。トリドリといいます。
新卒で入社した会社でJavaを数年やった後、1年ほど前に転職してからはRailsを中心に使用してアプリケーションの開発をしているしがないエンジニアです。

今回、AWSの勉強をするために公式の10分間チュートリアルをやってみることにしたので、備忘のために記事に残していこうと思います。
AWSに関しては、1年ほど前転職活動をしていた時期にEC2とRDSを少し触っていた以外ほとんど触ったことが無い初心者です。
(ただし、このときにアカウントを作ったので、12ヶ月の無料枠は切れていました)

前回は、Elastic BeanstalkをCLIで使用するためのユーザーの作成やCLIのインストールを行う、「Set up the Elastic Beanstalk Command Line Interface」というチュートリアルをやりました
今回は、その続きで実際にElastic Beanstalkを操作する、「Deploy and Monitor an Application from the Command Line」をやっていきます。

Deploy and Monitor an Application from the Command Line

(https://aws.amazon.com/jp/getting-started/tutorials/deploy-app-command-line-elastic-beanstalk/)

このチュートリアルでは、サンプルアプリケーションを作成した上でEB CLIを使用してデプロイ・モニタリング・終了を行います。

Step 1. Setup your application

まずはサンプルアプリケーションを作成します。

a.

sample-appというディレクトリを作成し、作成したディレクトリに移動します。

b.

新しいElastic Beanstalkのアプリケーションを作成するため、ターミナルに

eb init

と入力します。

c.

リージョンの選択肢が表示されるので、近いリージョンの数字を入力します。

d.

リージョンを選択すると、資格情報の入力を求められます。
前回のチュートリアルで作成したアクセスIDとシークレットキーを入力します。

e.

チュートリアルでは次の手順でプラットフォームの選択をしていますが、その前に次のようにアプリケーション名の入力を求められました。

Enter Application Name
(default is "sample-app"): 

デフォルトはsample-appということなのでそのままEnterを押します。

Application sample-app has been created.

と表示されます。
その後にチュートリアルの通りプラットフォームの選択に移ります。
チュートリアルではNode.js1でしたが、現在はPython(BETA)1になっているなど選択肢が増えていました。
今回はチュートリアルと同じくNode.jsを選択します。

f.

インスタンスにSSHのセットアップをするか聞かれます。
今回はチュートリアルに従ってSSHのセットアップをしないで、アプリケーションのセットアップを終了します。

Step 2. Deploy your application

続いて、アプリケーションを作成しデプロイしていきます。
今回はAuto Scalingグループ内のインスタンスにデプロイし、Elastic Load Balancingのロードバランサーを使用します。

a.

eb create

でAWSリソースの作成を開始します。

b.

環境名を入力します。
ステップ1のe.のアプリケーション名同様、デフォルトでsample-app-devとなっているので、そのままEnterを押します。

c.

次にDNS名を入力します。
チュートリアルでは一意にする必要があるとなっていますが、デフォルトのsample-app-devでも大丈夫でした。

d.

ロードバランサーの種類を選択します。
チュートリアルではデフォルトがclassicなのですが、現在はapplicationになっています。
classicは以前のチュートリアルでもでてきたEC2-Classicネットワークで推奨されていた設定です。
現在はこのネットワークを使用することは無いので、デフォルトのapplicationを選択します。

e.

1回目の起動でしたが、この手順でチュートリアルに記載されているElastic Beanstalk service roleについての確認は表示されませんでした。

代わりに、次のようにスポットフリートリクエストを使用するかどうかが表示されました。

Would you like to enable Spot Fleet requests for this environment?
(y/N):

今回はスポットインスタンスを使用しないので、Nを入力します。

f.

NOTE: The current directory does not contain any source code. Elastic Beanstalk is launching the sample application instead.
Do you want to download the sample application into the current directory?
(Y/n): Y

このステップのメッセージはWARNINGではなくNOTEに変わっています。
また、サンプルアプリケーションをダウンロードするかどうか確認されるようになっているので、Yを入力します。

g.

ダウンロードが完了すると自動的にデプロイが開始されます。
チュートリアルに記載の通りSuccessfully launched environmentと表示されればデプロイは完了です。

Step 3. Monitor your application

このステップではデプロイされたアプリケーションの確認とアプリケーションの状態のモニタリングを行います。

a.

eb open

を実行すると、ブラウザでアプリケーションのURLが開きます。
チュートリアルの通りCongratulationsの画面が開けばOKです。

b.

アプリケーションの状態を確認するには、

eb status

を実行します。
実行するとチュートリアルの画像の通り、アプリケーション名やリージョンの情報やアップデート日時・ステータスなどの状態が表示されます。
多くの情報はAWSコンソールのElastic Beanstalkダッシュボードでも確認することができるものです。
image.png

c.

アプリケーションのヘルス状態を詳細に確認するには、

eb health

を実行します。

こちらはAWSコンソールでは、Elastic Beanstalkダッシュボードからアプリケーションの詳細を開き、ヘルスメニューで見ることができます。
image.png

Step 4. Terminate your application

最後にアプリケーションを終了します。

a.

アプリケーションの終了をするためには

eb terminate --all

を実行します。

実行すると次のようなメッセージが表示され、AWSコンソールから終了するとき同様にアプリケーション名を入力する必要があるようになっています。

To confirm, type the application name: 

チュートリアルの通り、The application has been deleted successfully.が表示されれば終了は完了です。

まとめ

今回はEB CLIを使用してアプリケーションのデプロイ・モニタリング・終了を実行しました。
第5回第6回でAWSコンソールから実施したもののうち更新のみ今回のチュートリアルには含まれていなかったので、また別途調べてみようと思います。

次はRecommended Nextから「Docker コンテナのデプロイ」に進む予定です

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Terraformでmoduleを使ってみる。

Terraformにはモジュールで処理を使いまわせる機能がありますが
IaC初心者には理解が難しかったので備忘録がてらメモです。

https://www.terraform.io/docs/configuration/modules.html

ディレクトリ構造

work/
├── module
│   └── ec2_module.tf
└── test.tf

ec2_module.tf

モジュールの中身

##########################################################
///moduleでリソースを作成するときに指定する変数
##########################################################
variable "ami_id" {}
variable "instance_type" {}
variable "tags_name" {}

##########################################################
///実際にresourceを作成する部分
##########################################################

resource "aws_instance" "web" {
  ami           =  var.ami_id
  instance_type =  var.instance_type

  tags = {
    Name = var.tags_name
  }
}

test.tf

モジュールを呼び出す部分

##########################################################
///local変数
##########################################################
locals {
   instance = "t3.micro"
}
##########################################################
///ec2のmoduleを使用する部分(sourceでmoduleの場所を指定し、入力を渡す)
##########################################################

///moduleを使用する際には、モジュール本体は別ディレクトリに配置する必要がある。

module "ec2_1" {
  source        = "./module"
  ami_id        = data.aws_ami.ubuntu.id ///データソースで定義した部分
  instance_type = local.instance ///local変数で定義した部分
  tags_name     = "ec2_1"  
}

module "ec2_2" {
  source        = "./module"
  ami_id        = data.aws_ami.ubuntu.id
  instance_type = local.instance
  tags_name     = "ec2_2" 
}

##########################################################
///使用するamiをfilterして指定する
##########################################################

///データソースを使用すると、Terraform構成の他の場所で使用するためにデータを取得または計算できます。
data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

実行してみる

terraformでmoudleを使用するには
terraform init か terraform get が必須です。

[vagrant@terraform work]$ terraform init
Initializing modules...       ←こんな感じでモジュールを呼び出す         
- ec2_1 in module
- ec2_2 in module

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (hashicorp/aws) 2.49.0...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 2.49"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
[vagrant@terraform work]$

あとはいつも通り、planしてapplyしてあげれば作成できます。
あまりコードを書いた経験のないエンジニアだと最初理解に苦しむかもしれませんが(実体験)、
結構簡単なことしかしていないです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

RubyでS3内の5GB以上のファイルをコピーする

S3で5GB以上のファイルをコピーするには、普通のコピーでは出来ずMultipart Copyを使う必要があります。
RailsサーバからS3内の5GB以上のファイルを同じS3内にコピーする記事が無かったのでやり方を書きます。

gemのインストール

gem 'aws-sdk'

コピー処理

Aws::S3::Resourceのcopy_toを使用します。
Aws::S3::Clientのcopy_objectだと恐らくMultipart Copyが出来ません。

s3 = Aws::S3::Resource.new(
      region: 'reagion_name',
      access_key_id: 'access_key',
      secret_access_key: 'secret_key',
    )
bucket = s3.bucket('bucket_name')
object = bucket.object("src/file") # コピー元のobject key
object.copy_to(bucket: 'bucket_name', key: "target/file", multipart_copy: true) # コピー先のobject key

参考

https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3/Object.html

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Serverless Frameworkを使ったLambda+Pythonのローカル開発環境を構築

Windows上にServerless Frameworkを使ったLambda+Pythonのローカル開発環境を構築した時のメモ。実際にAWSにデプロイせずにローカルで単体テストまでできる環境を構築します。

Pythonのインストール

本家のWindows用ダウンロードサイトから最新版(執筆時点では3.8.1)をダウンロードし、実行する。

最初の画面で「Add Python 3.8 to PATH」にチェックを入れて「Install Now」で標準インストールする。最後の画面で「Disable path length limit」をクリックして、パス文字列長の制限を解除しておく。

>python --version
Python 3.8.1

バージョンが正しく表示されればOK。

pipenvのインストール

Pythonのパッケージ管理システムpipを使ってインストールする。

>pip install pipenv
(略)
Successfully installed appdirs-1.4.3 certifi-2019.11.28 distlib-0.3.0 filelock-3.0.12 pipenv-2018.11.26 six-1.14.0 virtualenv-20.0.1 virtualenv-clone-0.5.3

>pipenv --version
pipenv, version 2018.11.26

Node.jsのインストール

Serverless FrameworkはNode.jsで作られているため、Node.jsのインストールをする。

本家のダウンロードサイトから最新版のWindows用インストーラー(執筆時点では12.15.0)をダウンロードし、実行する。
オプションは特に変更しないでデフォルトのままインストールする。

>node --version
v12.15.0

Serverless Frameworkのインストール

Node.jsのパッケージ管理システムnpmを使ってインストールする。

>npm install -g serverless
(略)
+ serverless@1.63.0
added 527 packages from 335 contributors in 21.542s

>sls --version
Framework Core: 1.63.0
Plugin: 3.3.0
SDK: 2.3.0
Components Core: 1.1.2
Components CLI: 1.4.0

プロジェクトの作成

Serverless Frameworkのプロジェクトを作成。テンプレートはAWSのPython3用。

>sls create -t aws-python3 -p helloworld
(略)
Serverless: Successfully generated boilerplate for template: "aws-python3"

-tは使用するテンプレートの指定。AWS上のLambdaでPython3を使って開発するのでaws-python3を指定する。
-pはプロジェクトディレクトリのパス(-nを指定しなければ、そのままプロジェクト名にもなる)

カレントパスの下にhelloworldというプロジェクトディレクトリが作成され、Serverless Frameworkの設定ファイルserverless.ymlとLambda関数の実装が書かれているhandler.pyと.gitignoreが作成される。

Python仮想環境の作成

プロジェクトごとにPythonライブラリを管理するため、プロジェクトディレクトリの中に入り、このプロジェクト用の仮想環境を作る。

>cd helloworld
>pipenv install
Creating a virtualenv for this project…
(略)
Successfully created virtual environment!
(略)
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.

サンプル関数の実行

テンプレートに最初から定義されているhelloという名前のLambda関数をローカル実行してみる。

>sls invoke local -f hello
{
    "statusCode": 200,
    "body": "{\"message\": \"Go Serverless v1.0! Your function executed successfully!\", \"input\": {}}"
}

handler.pyに記述されたhello関数が実行され、レスポンスが返った。
invoke localで実行しているため、ローカル実行となる。

これでひとまずLambda + Pythonでローカル開発する環境が完成。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

python3でAPIをコールする。

pythonのurllib.requestモジュールを用いてAPIをコールするメモ。

下準備

  • 適当なlambdaとAPI Gatewayを用意。

lambdaは受け取ったeventを返却するようにする。

import json

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': event
    }

API Gatewayでは各種メソッド(GET、POST、PUT)を用意。

  • メソッドリクエスト → APIキーの必要性trueに指定。
  • 統合リクエスト → lambda関数を指定。

[APIのデプロイ]を実行し、URIを取得。(API Gatewayで何かの更新をしたのなら都度デプロイすること!でないと反映されない。←めっちゃこれハマる。)

[使用量プラン]から[作成]を選び、APIステージを選択、レート・バースト・クォータを設定、APIキーを作成する。

本題のAPIを叩くlambda

import json
import urllib.request, urllib.error

request_url = "https://xxxx.execute-api.ap-northeast-1.amazonaws.com/stage"

api_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxx"

def lambda_handler(event, context):
    headers = {'x-api-key': api_key, "Content-Type":"application/json"}

    request_json = {
        "key":"val"
    }

    req = urllib.request.Request(url=request_url, method="GET", headers=headers, data=json.dumps(request_json).encode())

    with urllib.request.urlopen(req) as res:
        body = res.read().decode()

    return json.loads(body)

参考

以下を加筆修正
https://qiita.com/j_tamura/items/5a22b102a58d1fa93a78

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2概要

EC2の構成要素

役割 AWS
OS AMI
CPU インスタンスタイプ
Memory インスタンスタイプ
SSD EBS
NIC(※1) ENI(※2)

※1.Network Interface Cardの略
※2.Elastic Network Interfaceの略

AMI

  • Amazon Machine Imageの略
  • EC2インスタンスが起動するための設定ファイル
    • どのOSやミドルウェア、アプリをインストールするか
    • どのユーザがAMIを起動できるかという設定
    • EBSのボリューム設定
  • 異なるリージョンにコピーすることもできる
  • ひとつのAMIでEC2を何台も複製できる
  • OSやアプリケーションの情報が設定されている
  • OSはAmazon Linuxが一般的
    • 各種Linuxディストリビューション
    • Windows Server

インスタンスタイプ

  • CPU、メモリなどの構成パターン
  • インスタンスファミリーで分類され、さらにインスタンスサイズで選択肢が複数ある

EBS

  • ディクスストレージを指す
  • AZで自動で冗長化

EBS種類

種類 特徴
汎用SSD デフォルト。基本コレを使う
プロビジョンド IOPS SSD(iol) 高性能DBへ接続する時など
スループット最適化HDD データウェアハウス,ビッグデータ,ログ処理など
Cold HDD(sc1) 安い アーカイブ保管

EBSのスナップショット

  • EBSをバックアップとして取得したファイル
  • 保管場所はS3
  • スナップショット自体をEC2に付け外しはできない
  • 増分バックアップ方式
    • バックアップ時間が短い
    • 容量を逼迫しない
  • AZ内で自動で冗長化されるため高い耐久性がある
    • AZを跨いだコピーはS3を経由する必要がある

キーペア,インスタンスメタデータ,ユーザデータ,Cloud-init

キーペア

  • ログインの管理を行う。秘密鍵と公開鍵のペアのこと。
  • 公開鍵で暗号化したら秘密鍵でしか開けることはできない
  • 秘密鍵はpem形式になっており、外部からアクセスできないようにする
  • 秘密鍵を失った場合は、AMIとしてバックアップし、起動する時に新しいキーペアを作成する。

インスタンスメタデータ

  • EC2インスタンスに埋め込まれている自分の情報。
  • EC2が起動中の場合、以下のようなcurlコマンドで自身の情報を取得することができる
    • curl http://xxx.com/latest/meta-data
    • 使用しているAMIのIDやローカルのIPアドレス、所属しているサブネットIDなどが取得できる。

ユーザデータ

  • インスタンス起動時に一回だけ実行するスクリプト
  • 再起動時に実行されるものではない
  • rootユーザで実行され、作成されたファイルもroot権限
  • 操作はインタラクティブではない。
    • 例.yumコマンドのオプション無しなどは使えない

Cloud-init

  • クラウド系インスタンスの初期構築を手助けするオープンソースのアプリケーション
  • Amazon Linuxにはデフォルトで/etc/cloud/配下に設定ファイルが存在し、インスタンス作成時にどういった動きをするか指定できる

引用

https://www.youtube.com/watch?v=k1mhE5CrO2k&list=PLtpYHR4V8Mg_-RE0VBPeEqIDfFbzz-1ea&index=1
https://www.youtube.com/watch?v=zAQ6ws5kzEg&list=PLtpYHR4V8Mg_-RE0VBPeEqIDfFbzz-1ea&index=2
https://www.youtube.com/watch?v=1MMXigDxTdc&list=PLtpYHR4V8Mg_-RE0VBPeEqIDfFbzz-1ea&index=3

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CognitoにSDKやAWSCLI無しでアクセスする(curlなど)

はじめに

AWSのAPIGatewyの認証としてLambdaAuthorizerは使用したことがありますが、Congnito認証は使用したことが無かったため試してみました。

またクライアントがCognitoにアクセスする際、ググるとほとんどがSDKやAWSCLIを使用していました。AWSのサポートに「curlなどで普通にアクセスできないのか?」と質問をしたところ、以下の情報を教えて貰えました。

Cognito UserPool へのサインイン時には、以下の InitiateAuth API が呼ばれているため、Cognito UserPool のエンドポイントに対して InitiateAuth を curl コマンドで呼び出すことで、実現すること自体は可能です。

InitiateAuth - Amazon Cognito Identity Provider

Amazon Cognito ID エンドポイントとクォータ - AWS 全般のリファレンス

これらの情報をもとに、Cognito認証に最低限必要と思われるcurlでも叩けるようなAPIリクエストのサンプルをまとめておきます。

共通で必要な情報

Endpoint(東京リージョンの場合)
https://cognito-idp.ap-northeast-1.amazonaws.com/

Method
POST

Header
Content-Type: application/x-amz-json-1.1
X-Amz-User-Agent: test-requets ※これは無くても大丈夫

サインイン

Request

Header
X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth

Body

{
    "AuthFlow": "USER_PASSWORD_AUTH",
        "ClientId": "${クライアントID}",
        "AuthParameters": {
            "USERNAME": "${ユーザ名}",
            "PASSWORD": "${パスワード}"
        }
}

Response

Body(初回サインイン時)
初回サインイン時は仮パスワード状態であり、まだトークンは貰えません。
そのかわりに、パスワード変更時に必要なセッション情報が渡ってきます。

{
    "ChallengeName": "NEW_PASSWORD_REQUIRED",
    "ChallengeParameters": {
        "USER_ID_FOR_SRP": "${ユーザ名}",
        "requiredAttributes": "[]",
        "userAttributes": "{\"email_verified\":\"true\",\"email\":\"${メールアドレス}\"}"
    },
    "Session": "${セッション情報}"
}

Body通常サインイン時

初回パスワード変更

Request

Header
X-Amz-Target: AWSCognitoIdentityProviderService.RespondToAuthChallenge

Body

{
    "ClientId": "${クライアントID}",
    "ChallengeName": "NEW_PASSWORD_REQUIRED",
    "ChallengeResponses": {
        "NEW_PASSWORD": "${新しいパスワード}",
        "USERNAME": "${ユーザ名}"
    },
    "Session" : "${初回サインインのレスポンスに詰まっているセッション情報}"}

Response

Body

{
    "AuthenticationResult": {
        "AccessToken": "${アクセストークン}",
        "ExpiresIn": 3600,
        "IdToken": "${IDトークン}",
        "RefreshToken": "${リフレッシュトークン}",
        "TokenType": "Bearer"
    },
    "ChallengeParameters": {}
}

トークンの更新

Request

Header
X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth

Body

{
    "AuthFlow": "REFRESH_TOKEN_AUTH",
        "ClientId": "${クライアントID}",
        "AuthParameters": {
            "USERNAME": "${ユーザ名}",
            "REFRESH_TOKEN": "${リフレッシュトークン}"        
        }
}

Response

Body

{
    "AuthenticationResult": {
        "AccessToken": "${新しいアクセストークン}",
        "ExpiresIn": 3600,
        "IdToken": "${新しいIDトークン}",
        "TokenType": "Bearer"
    },
    "ChallengeParameters": {}
}

パスワード変更(初回以外)

Request

Header
X-Amz-Target: AWSCognitoIdentityProviderService.ChangePassword

Body

{
   "AccessToken": "${アクセストークン}",
   "PreviousPassword": "${今までのパスワード}",
   "ProposedPassword": "${新しく設定したいパスワード}"
}

Response

Body
HTTPステータスコード: 200

{}

※書き漏れではなく空の{}が返ってきました。

その他メモ(そのうち別記事にする予定)

トークンの有効期限が切れた際のレスポンス

ステータスコード: 401
特徴的なヘッダ(x-amzn-ErrorType): UnauthorizedException
body:

{
    "message": "The incoming token has expired"
}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSにおけるサーバ構築手順メモ

アプリケーションサーバを構築する際、いつも忘れるので

インスタンスを立てる

AWSサービスよりEC2を選択し、左サイドバーのインスタンスを選択
* 既存のイメージからインスタンスを立てる場合は、イメージ > AMIを選択し任意のAMI上で右クリック > 起動を選択
1. インスタンスタイプの選択
2. インスタンスの設定
3. ストレージの追加
4. タグの追加
5. セキュリティグループの設定
6. 確認

ロードバランサーの作成

ロードバランサーは、クライアントにとって単一の通信先として機能し、正常な登録済みターゲットに受信トラフィックを分散

左サイドバーから、ロードバランシング > ロードバランサーを選択
ロードバランサーの作成を押下
Application Load Balancerの欄で作成を押下
1. ロードバランサーの設定
2. セキュリティ設定の構成
3. セキュリティグループの設定
4. ルーティングの設定
5. ターゲットの登録
6. 確認

Route53の設定

可用性と拡張性に優れたクラウドDNS

AWSのサーブルよりRoute53を選択
ホストゾーンの作成を行う
作成したホストゾーンにレコードセットを登録していく
レコードセットの編集において、ロードバランサーのDNS名を記述する

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSCLI Version2 実行環境

AWS CLI V2 リリース

AWSCLIのV2がリリースされていたので試してみました。

環境構築

Dockerコンテナを作成して、AWS CLI V2が使用できる環境にしています。

Dockerfile作成

まずは、Dockerfile作成します。

# OS Debian GNU/Linux 10 (buster)
FROM python:latest

# aws help を使用できるようにする為
RUN apt-get update && apt-get install -y \
    less \
    groff-base

# awscli v2 インストール
RUN python -m pip install git+https://github.com/boto/botocore.git@v2
RUN python -m pip install git+https://github.com/aws/aws-cli.git@v2

# jq インストール
RUN cd /bin && wget http://stedolan.github.io/jq/download/linux64/jq && chmod 755 jq

ENV PATH $PATH:/root/.local/bin

起動シェル作成

次は、毎度dockerコマンドを打つのも面倒なので、シェルを作成します。
:warning:このファイルはクレデンシャル情報を直接、記述しているので間違ってもgitとかにはプッシュいないようにしてください。

run.sh
#!/bin/sh
docker build -t aws-cli-v2 .

AWS_ACCESS_KEY_ID="[自分のアクセスキー]"
AWS_SECRET_ACCESS_KEY="[自分のシークレットキー]"
AWS_DEFAULT_REGION="ap-northeast-1"

docker run -it \
    -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
    -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \
    -e AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION \
    -v $(pwd):/data \
    aws-cli-v2 /bin/bash

実行コマンド

あとはシェルを叩き、数秒待てばawscliV2の環境が完成すると思います。

$ cd [任意のディレクトリ]
$ sh run.sh

AWS CLI V2で追加機能

わかる範囲の追加機能

  • クレデンシャルのインポート
  • リソース名の補完
  • 自動プロンプト
  • ウィザード
  • YAML 形式の出力

適宜、更新しようかなと思います。
今のところ、この人の記事見れば、なんとなくわかります。
- [アップデート] リソース名の補完など強力な機能追加!AWS CLI v2 が GA されました!
- AWS公式はこちら

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CDKで既存VPCと既存Subnetを名指しで使う

今日も元気にビルドを失敗していくスタイル。

前回、「AWS CDKでVPC作ろうとしたら作れなかったとき」ではSubnetがうまく作れなくて泣いてたじゃないですか。
今度は既存のVPCと既存のSubnetを使いたかったんですよ。本当にそれだけなんです、CloudForamtionなら三秒で出来るじゃないですか?????

やりたいこと

既存のVPCと既存のSubnetを使いたい。

CloudForamtionで書くとき

例えばALBとセキュリティグループの設定に使う時とか、こういう感じでできるじゃないですか。
なんかこう、VpcIdとSubnetsにはそれぞれのIDをそのまま書けばさらっと設定してくれるじゃないですか。

Resources:
  SecurityGroup:
    Type: "AWS::EC2::SecurityGroup"
    Properties:
      GroupDescription: !Sub ${AWS::StackName}-alb
      SecurityGroupIngress:
        - CidrIp: "0.0.0.0/0"
          IpProtocol: "TCP"
          FromPort: 80
          ToPort: 80
      VpcId: !Ref VpcId

  LoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Subnets: !Ref Subnets
      SecurityGroups:
        - !Ref SecurityGroup

CDKで既存のVPCをSubnetを指定しつつ取り込む

真剣に一週間くらい悩んでしまったんですけど、結論だけ書くとこうです。

from_vpc_attributesを使って既存のVPCを取り込みます。このときSubnetを指定しておくと、指定したSubnetだけ取り込んでくれます。
既存VPCだけ取り込むならfromLookupでもいいんですが、Subnetを指定する方法がsubnetGroupNameTagしかなさげな感じ。(ID指定できるやろって情報あれば教えてください)
今回はSubnetもIDで指定したいのでこんな感じになります。

from aws_cdk import (
    aws_ec2 as ec2,
)

VPCID='vpc-xxxxxxxx'
vpc=ec2.Vpc.from_vpc_attributes(
    self, f"vpc{id}",
    vpc_id=VPCID,
    availability_zones=['ap-northeast-1b', 'ap-northeast-1c'],
    publicSubnetIds=['subnet-xxxxxxxx', 'subnet-xxxxxxxx'],
    private_subnet_ids=['subnet-xxxxxxxx', 'subnet-xxxxxxxx']
)

で、Subnetを実際に使用するにはこの記述で引っ張ってこれます。
ドキュメントでISubnetで指定しろって書いてあるとこに使うといいです。

# パブリック
ec2.SubnetSelection(subnet_type=ec2.SubnetType.PUBLIC, one_per_az=True)
# プライベート
ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE, one_per_az=True)

参考URL

AWS CDK(class Vpc)
https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ec2.Vpc.html#static-from-wbr-lookupscope-id-options

CDKのドキュメントはTypeScriptのが一番読みやすいのでTSの方でざっくり確認してからPythonのドキュメント読むんですが、Pythonのドキュメントどうして読みづらいんですかね。慣れですかね。
boto3のドキュメントもだいぶ読みづらい。

おわり

CDK面白いのでもっと流行ってほしいですね!!私はPythonが好きですよ!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Cloudformationでcognitoを作ったときにハマったメモ

またくだらないことでハマったのでメモ。
今思えば、普通に頭悪い。

やりたいこと

  • Cloudformation使いたい
  • ALBにCognito組み合わせたい

具体的には
1. ALBを叩きに来たアクセスをCognitoに飛ばしたい
2. Cognitoの認証をパスしたら、ALBの後ろにいるEC2へforwardさせたい

とりあえずyaml書く。

ALBとCognitoの連携は、ElasticLoadBalancingV2Listenerで指定。

(中略)
  hogeALBLISTENER:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties: 
      #Certificates: 
      #  - Certificate
      DefaultActions: 
        - AuthenticateCognitoConfig: 
              UserPoolArn: "arn:aws:cognito-idp:ap-northeast-1:xxxxx:userpool/hoge"
              UserPoolClientId: "hogeid"
              UserPoolDomain: "https://hoge.auth.amazoncognito.com"
          Type: 
            - "authenticate-cognito"
            - "forward"
          TargetGroupArn: !Ref 'hogeALBTG'

      LoadBalancerArn: !Ref 'hogeALB'
      Port: 443
      Protocol: "HTTP"

…これじゃ通らない。
今見ると、書き方がひどすぎる。。。
「cognitoの認証をパスしたら、targetgroupに向けてforwardして」を1行で書いて通るわけがない。

通る書き方

(中略)
  hogeALBLISTENER:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties: 
      Certificates: 
        - CertificateArn: "arn:aws:acm:ap-northeast-1:xxxxxxxx:certificate/hogehoge"
      DefaultActions: 
        - AuthenticateCognitoConfig: 
              UserPoolArn: "arn:aws:cognito-idp:ap-northeast-1:xxxxxxx:userpool/hogehoge"
              UserPoolClientId: "hogehoge"
              UserPoolDomain: "hogehoge.auth.com"
          Order: 1
          Type: "authenticate-cognito"
        - TargetGroupArn: !Ref 'hogeALBTG'
          Order: 2
          Type: "forward"

      LoadBalancerArn: !Ref 'hogeALB'
      Port: 443
      Protocol: "HTTPS"

ちゃんと段階踏ませる書き方をすれば通る。

  1. Cognitoで認証させる → Order :1
  2. 通ったらtargetgroupへforwardさせる → Order :2

リファレンス読んで書いてたけど、あっちこっち飛ばされたらよくわからなくなる…

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Cognitoのトークンと有効期限について

Cognitoから発行されるトークン

Cognitoからは以下3つのトークンが発行されます。

IDトークン(IDToken)

Cognito User Poolsのユーザー属性(例えばメールアドレスなど)を含めたトークンです。
ユーザーに関する情報をすべて取得したい場合に使用します。
APIGatewayではこのトークンを使用します。

有効期限
ユーザーが認証した3600秒後(1時間後)に有効期限切れになります。

アクセストークン(AccessToken)

Cognito User Poolsの最低限のユーザー情報を含めたトークンです。

有効期限
ユーザーが認証した3600秒後(1時間後)に有効期限切れになります。

更新トークン(RefreshToken)

IDトークン、アクセストークンを更新するために利用します。
Cognito User PoolsのクライアントSDKを利用している場合は自動で更新されるようです。

有効期限
デフォルトではアプリのユーザーがユーザープールにサインインしてから30日後に有効期限が切れます。
有効期限は1日~3650日の任意の値に設定できます。

有効期限について

ユーザ認証には基本的にIDトークンを使用します。
IDトークンは1時間後に有効期限切れとなり、有効期限が切れたら更新トークンを使用して新しいIDトークンを発行します。

※クライアントSDKを使用している場合は更新トークンによって自動的にIDトークンが更新されるようです。

更新トークンはデフォルトで30日後に有効期限切れとなり、有効期限が切れたらサインインが必要となります。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS GuarDutyでS3バケットへのログ保存について

覚書です。
1.AWS GuarDutyを有効にする
2.S3バケットへのログ保存のためGuarDuty画面から
  [設定]-[結果のエクスポートオプション]でS3バケットを新規に作成し保存をするが
  KMSが無いので失敗

3.KMSキーをKMS Console画面から作成する
4.GuarDuty画面に戻って再度KMSキー(エイリアスが選択できる)を選択してほぞんするが失敗
5.KMS Console画面に戻って[カスタマー管理型のキー]で対象のエイリアスを選択し
  キーポリシーエディタを編集で開く※これを実施しないとずーっとエラー

  {
"Sid": "Allow GuardDuty to use the key",
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "kms:GenerateDataKey",
"Resource": "*"
  }

  上記内容を適当な場所に追加して保存

6.再度GuardDuty画面からS3バケット作成、キー選択、保存することで成功

7.6時間おきに収集していたので翌日確認したところ年>月>日 のフォルダにgzファイルとして
  保存されていた。

以上

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS学習 〜EC2(Elastic Compute Cloud)学習メモ〜

EC2(Elastic Compute Cloud)とは?

AWS上に仮想サーバを作るサービス。AWSに建てるサーバーのOSはWindowsやLinux、機能面ではCPUやメモリ、プロセッサなど要件に合わせて構築できる。(種類が多すぎるので要件をどれだけ搾りこめるのかなど経験や知識が必要になりそう・・・)

EC2はサービス名で自分たちで立てたサーバことを「インスタンス」と呼ぶ。

EBS(Elastic Block Store)

EC2とセットで使うのが基本らしい・・・。理由がコンソールからEC2の停止ボタンを押下するとデータが消えてしまうため停止させても消去されないようにEBSにデータを保存する

インスタンスタイプについて

・インスタンスファミリーの数字は世代を表し数字が大きいほど新しい → 用途
・インスタンスサイズ → CPUのスペック

凡庸タイプ(A、T、M)
凡庸インスタンスは、バランスの取れたコンピューティング、メモリ、
ネットワークのリソースを提供し、多様なワークロードに使用できる。

コンピューティング最適化タイプ( C )
バッチ処理、メディアトランスコード、高性能ウェブサーバー、専用ゲームサーバー、
広告サーバーエンジン、

メモリ最適化タイプ(R、X、z)
メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンス
を実現するように設計されている。

高速コンピューティングタイプ(P、inf、G、F)
ハードウェアアクセラレーター(プロセッサ)を使用して、浮動小数点計算、
グラフィックス処理、データパターン照合などの機能、CPUで実行中のソフトウェアよりも
効率的に実行する。

ストレージ最適化タイプ(I3、I3en、D、H)
ローカルストレージの大規模データセットに対する高いシーケンシャル読み取りおよび
書き込みアクセスを必要とするワークロード用に設計されている。
ストレージ最適化インスタンスは、数万IOPSもの低レイテンシーなランダムI/Oオペレーションを
アプリケーションに提供するように最適化されている。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SageMaker Studioに含まれる個別機能を一通り触ってみた

概要

以下を一通り触ってみた。クラスメソッドさんの解説サイトを読みながら、AWS labsのサンプルを写経しました。
* Autopilot
* Experiments
* Model Monitoring
* SageMaker Debugger

※Studioからの見え方ではありません。

Autopilot

  • XGBoostなどのアルゴリズムやハイパーパラメータを様々試してくれる
    • 実行するとSageMakerのジョブが250個走りました
      • なんだかんだでXGBoostが選ばれることが多い
    • データサイエンティストが要らなくなる、とまでは言えないまでもかなりの作業が楽になると思います
  • 電話によるマーケティングで定期預金を契約するユースケース

Experiments

  • 機械学習は言うまでもなく、様々な学習を試行錯誤します   * 学習結果をタンキングし、後々比較検証できるようにします   * Autopilotは比較検証まで自動でやってくれるものだとすると、比較検証の部分を目検するイメージ
  • MNISTの手書き文字を判別するユースケース

Model Monitoring

  • 高精度が得られた学習モデルも時間変化などにより劣化する場合があります
    • 推論時に学習モデルの精度の劣化をモニタリングしてくれます
    • システム開発でもCI/CDにより品質デグレードを日々確認しますが、機械学習でも同様のことが必要なイメージ
  • 学習済みモデルに対して推論をかけてモニタリングするユースケース

Debugger

  • 化学の実験のように機械学習の学習時間は非常に長く、結果が出ないこともしばしば
    • 途中経過がどのような状態かは確認したいものです
    • 勾配やロスなどの状態を取得し、その内容に応じた分析が可能になります
  • MNISTのデータセットに対する学習中に勾配消失やロスが減らない状態を監視するケース

まとめ

今回紹介した機能を統合したSageMaker Studioを使えばさらに簡単に使えるようになること間違いなしです。AutopilotをSageMaker Studioで使ってみたりもしましたが、より簡易に使えるようになるなという印象でした。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

S3 で SPA をホスティングするとき、アクセスする URL が 404 のときに index.html を返す方法

概要

S3 で SPA をホスティングするときに、404のときにindex.htmlを返してくれないと正常にSPAを動かせません。
Cloud Front であればエラーコード時の返すページを設定できますが、S3のみでホスティングしたときのやり方で少しはまったので共有です。

やり方

エラードキュメントに index.html を設定すればよいだけです。

スクリーンショット 2020-01-19 23.39.53.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む