- 投稿日:2020-02-14T23:54:27+09:00
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.js
が1
でしたが、現在は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ダッシュボードでも確認することができるものです。
c.
アプリケーションのヘルス状態を詳細に確認するには、
eb healthを実行します。
こちらはAWSコンソールでは、Elastic Beanstalkダッシュボードからアプリケーションの詳細を開き、ヘルスメニューで見ることができます。
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 コンテナのデプロイ」に進む予定です
- 投稿日:2020-02-14T23:27:48+09:00
Terraformでmoduleを使ってみる。
Terraformにはモジュールで処理を使いまわせる機能がありますが
IaC初心者には理解が難しかったので備忘録がてらメモです。https://www.terraform.io/docs/configuration/modules.html
ディレクトリ構造
work/ ├── module │ └── ec2_module.tf └── test.tfec2_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してあげれば作成できます。
あまりコードを書いた経験のないエンジニアだと最初理解に苦しむかもしれませんが(実体験)、
結構簡単なことしかしていないです。
- 投稿日:2020-02-14T22:05:52+09:00
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
- 投稿日:2020-02-14T21:38:50+09:00
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.26Node.jsのインストール
Serverless FrameworkはNode.jsで作られているため、Node.jsのインストールをする。
本家のダウンロードサイトから最新版のWindows用インストーラー(執筆時点では12.15.0)をダウンロードし、実行する。
オプションは特に変更しないでデフォルトのままインストールする。>node --version v12.15.0Serverless 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でローカル開発する環境が完成。
- 投稿日:2020-02-14T21:15:31+09:00
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
- 投稿日:2020-02-14T19:48:48+09:00
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
- 投稿日:2020-02-14T18:19:59+09:00
CognitoにSDKやAWSCLI無しでアクセスする(curlなど)
はじめに
AWSのAPIGatewyの認証としてLambdaAuthorizerは使用したことがありますが、Congnito認証は使用したことが無かったため試してみました。
またクライアントがCognitoにアクセスする際、ググるとほとんどがSDKやAWSCLIを使用していました。AWSのサポートに「curlなどで普通にアクセスできないのか?」と質問をしたところ、以下の情報を教えて貰えました。
Cognito UserPool へのサインイン時には、以下の InitiateAuth API が呼ばれているため、Cognito UserPool のエンドポイントに対して InitiateAuth を curl コマンドで呼び出すことで、実現すること自体は可能です。
これらの情報をもとに、Cognito認証に最低限必要と思われるcurlでも叩けるようなAPIリクエストのサンプルをまとめておきます。
共通で必要な情報
Endpoint(東京リージョンの場合)
https://cognito-idp.ap-northeast-1.amazonaws.com/Method
POSTHeader
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" }
- 投稿日:2020-02-14T17:35:56+09:00
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名を記述する
- 投稿日:2020-02-14T15:13:01+09:00
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コマンドを打つのも面倒なので、シェルを作成します。
このファイルはクレデンシャル情報を直接、記述しているので間違っても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公式はこちら
- 投稿日:2020-02-14T14:38:19+09:00
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 SecurityGroupCDKで既存の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-optionsCDKのドキュメントはTypeScriptのが一番読みやすいのでTSの方でざっくり確認してからPythonのドキュメント読むんですが、Pythonのドキュメントどうして読みづらいんですかね。慣れですかね。
boto3のドキュメントもだいぶ読みづらい。おわり
CDK面白いのでもっと流行ってほしいですね!!私はPythonが好きですよ!!
- 投稿日:2020-02-14T11:35:43+09:00
Cloudformationでcognitoを作ったときにハマったメモ
またくだらないことでハマったのでメモ。
今思えば、普通に頭悪い。やりたいこと
- Cloudformation使いたい
- ALBにCognito組み合わせたい
具体的には
1. ALBを叩きに来たアクセスをCognitoに飛ばしたい
2. Cognitoの認証をパスしたら、ALBの後ろにいるEC2へforwardさせたいとりあえずyaml書く。
ALBとCognitoの連携は、
ElasticLoadBalancingV2
のListener
で指定。(中略) 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"ちゃんと段階踏ませる書き方をすれば通る。
- Cognitoで認証させる →
Order :1
- 通ったらtargetgroupへforwardさせる →
Order :2
リファレンス読んで書いてたけど、あっちこっち飛ばされたらよくわからなくなる…
- 投稿日:2020-02-14T11:08:00+09:00
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日後に有効期限切れとなり、有効期限が切れたらサインイン
が必要となります。
- 投稿日:2020-02-14T10:51:23+09:00
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ファイルとして
保存されていた。以上
- 投稿日:2020-02-14T06:59:13+09:00
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オペレーションを
アプリケーションに提供するように最適化されている。
- 投稿日:2020-02-14T02:20:09+09:00
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で使ってみたりもしましたが、より簡易に使えるようになるなという印象でした。