概要

• AWS Fargate で起動したコンテナからあるサーバへの接続をIPアドレスで制限をかけたいが、普通にFargateを設定したコンテナでは、割り当てられるグローバルIPアドレスはコロコロ変わり固定ではない。
• AWS Fargate で VPC 内に作成されたコンテナからインターネットへ出るときに AWS NATゲートウェイを経由させることで、NATゲートウェイに割り当てたEIPがコンテナの接続元IPアドレスとして固定することができる。接続先のサーバではそのEIPを設定することでアクセス制限を行うことができるようになる。

構成概要

構成内容

• Amazon ECR
  • Dockerイメージレジストリ
  • ECR リポジトリの作成は、AWS CLI で行う
• Amazon Fargate
  • コンテナ実行環境
  • ECR からイメージを pull する
• VPC
  • Internetゲートウェイをアタッチする
  • Subnet-A と SubnetB を作成する
• Subnet-A
  • コンテナ用サブネット
  • ルートテーブルで、インターネットへの接続(0.0.0.0/0)を NATゲートウェイに向ける
• Subnet-B
  • NATゲートウェイ用サブネット
  • ルートテーブルで、インターネットへの接続(0.0.0.0/0)を Internetゲートウェイに向ける
• コンテナ
  • AWS ECR にある Docker イメージを AWS Fargate が PULL して、Subnet-A にコンテナ化する
• NAT ゲートウェイ
  • Elastic IP を割り当てる

VPC環境設定概要

1. VPC作成
   Internetゲートウェイをアタッチする

2. NATゲートウェイ用サブネット (Subnet-B) 作成
   ルートテーブル設定
   ・インターネットへの接続(0.0.0.0/0)を Internetゲートウェイに向ける

3. Subnet-B 内に NATゲートウェイを作成
   Elastic IP を割り当てる（今回は 3.113.58.14 ）

4. コンテナ用サブネット (Subnet-A) 作成
   ルートテーブル設定
   ・インターネットへの接続(0.0.0.0/0)を NATゲートウェイに向ける

動作確認用コンテナのDockerイメージを作成

接続元IPアドレスを確認するために、コンテナ内から https://ifconfig.me にアクセスして接続元（コンテナ）のIPアドレスを確認する

1. Dockerfile 作成

   FROM alpine:latest
   RUN apk --no-cache add curl
   CMD curl -s https://ifconfig.me
   

2. ビルド

   $ docker build -t demo .
   

3. イメージ確認

   $ docker images
   REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
   demo                latest              204b606e4331        33 minutes ago      6.92MB
   alpine              latest              4d90542f0623        2 days ago          5.58MB
   

4. 実行テスト

   $ docker run demo
   xxx.xxx.xxx.xxx （接続元IPアドレス）
   

AWS ECR 設定概要

参考：Dockerイメージを AWS ECR に登録して AWS ECS の Fargate でコンテナ化してサービス提供

1. AWS CLI で AWS ECR を設定するための IAM ユーザを作成
   AmazonEC2ContainerRegistryFullAccessポリシーをアタッチする

2. 1.のIAMユーザをターミナルに登録する （今回は "ecr" というプロファイル名）
   

   $ aws configure --profile ecr
   AWS Access Key ID [None]: **********
   AWS Secret Access Key [None]: **********
   Default region name [None]: ap-northeast-1
   Default output format [None]:
   

3. ECR のリポジトリを作成する （今回は "demo-repository" というリポジトリ名）
   

   $ aws ecr create-repository --repository-name demo-repository --profile dev-netnative-nishimura-toru
   

4. AWS ECR レジストリ用の docker login 認証コマンド文字列(12時間有効な認証トークン)を取得する
   

   $ aws ecr get-login --no-include-email --profile dev-netnative-nishimura-toru
   docker login -u AWS -p eyJwYXlsb2FkI〜

5. 上記で発行されたコマンドをそのまますべてをコピーして、ターミナルにペーストして実行する
   

   $ docker login -u AWS -p eyJwYXlsb2FkI〜
   〜
   WARNING! Using --password via the CLI is insecure. Use --password-stdin.
   Login Succeeded
   

Dockerイメージを AWS ECR へ PUSH する

1. Docker イメージにタグを付ける

   $ docker tag demo ＜AWSアカウントID＞.dkr.ecr.ap-northeast-1.amazonaws.com/demo-repository:demo
   

2. 確認

   $ docker images
   REPOSITORY                                                          TAG                 IMAGE ID            CREATED             SIZE
   ＜AWSアカウントID＞.dkr.ecr.ap-northeast-1.amazonaws.com/demo-repository   demo                204b606e4331        38 minutes ago      6.92MB
   demo                                                                latest              204b606e4331        38 minutes ago      6.92MB
   alpine                                                              latest              4d90542f0623        2 days ago          5.58MB
   

3. Dockerイメージを AWS ECR に PUSH する

   $ docker push ＜AWSアカウントID＞.dkr.ecr.ap-northeast-1.amazonaws.com/demo-repository:demo
   The push refers to repository [777813037810.dkr.ecr.ap-northeast-1.amazonaws.com/demo-repository]
   39f660b1173d: Pushed
   256a7af3acb1: Pushed
   demo: digest: sha256:e903f0093f0d376a607c95279a204b36a15335dbda9fd0d73722f7593494aeff size: 738
   

AWS Fargate の設定とタスク実行

参考：Dockerイメージを AWS ECR に登録して AWS ECS の Fargate でコンテナ化してサービス提供

1. タスク定義を作成する

(1) 新しいタスク定義の作成

(2) 起動タイプで FARGATE を選択

(3) タスクとコンテナの定義の設定

①タスク定義名を ここでは demo-demo とする
　他はデフォルト

②タスクの実行IAMロールはデフォルト

③タスクサイズは最小サイズで

④コンテナの定義

コンテナの追加

コンテナ名： demo-container
イメージ： ＜AWSアカウントID＞.dkr.ecr.ap-northeast-1.amazonaws.com/demo-repository:demo
他はデフォルト

⑤作成

2. クラスターを作成する

(1) クラスターの作成

(2) クラスターテンプレートの選択

「AWS Fargate を使用」 を選択

(3) クラスターの設定

クラスター名： demo-cluster
他はデフォルト

(4) 作成

3. タスク実行を作成する

① 新しいタスクの実行

② タスクの実行

起動タイプ： FARGATE
タスク定義： demo-task:1
クラスター： demo-cluster
クラスターVPC
サブネット：コンテナ用に作成したサブネット
パブリックIPの自動割り当て： DISABLED

③ タスクの実行
タスクを実行すると、コンテナのプロビジョニングが始まり、実行後に消滅する

4. タスクの実行結果の確認

タスクの実行結果は、CloudWatch ログ に送られる。
CloudWatchロググループは、タスク定義を作成した時に作られている。

CloudWatchロググループ: /ecs/demo-task
メッセージに Elastic IP の IPアドレスが表示されていれば成功。

やること

CodeBuildプロジェクトの実装途中でのデバッグをローカルマシンで行う。
マネージドイメージを使っているものとする。

手順

まず、イメージを手に入れる必要がある。
ビルド済みイメージは公開されていないので、自分でビルドする。

aws/aws-codebuild-docker-images: Official AWS CodeBuild repository for managed Docker images

git clone https://github.com/aws/aws-codebuild-docker-images.git
cd aws-codebuild-docker-images/ubuntu/standard/2.0
docker build -t aws/codebuild/standard:2.0 .

イメージが手に入ったら、作業したいディレクトリ（リポジトリ）に
codebuild_build.sh を設置する（上記リポジトリ内にあるのでコピーしてくる）。

実行コマンド例

./codebuild_build.sh \
-i aws/codebuild/standard:2.0 \
-b codebuild/buildspec.yml \
-e codebuild/env \
-a codebuild/artifact/ \
-c

引数	用途
i	イメージの指定
b	buildspecファイルの指定
e	環境変数ファイルの指定 1行ずつVAR=VALUE形式で記述
a	アーティファクト設置先ディレクトリの指定
c	AWS CLIのクレデンシャルを利用
p	AWS CLI プロファイルを指定

AWSリソースに干渉するような作業を行うプロジェクトの場合、

• ローカル実行時に使っているクレデンシャルの権限
• 本物のプロジェクトが扱える権限

の差異に注意する。

あるいはちゃんとCLIにロールを引き受けさせられるようにしておいて、pオプションでプロファイル指定をする。

AWS CLI で IAM ロールを引き受ける - AWS Command Line Interface

AWS Training の動画を早送りしたい

この記事に必要な範囲で自己紹介すると、

• 最近 AWS の勉強をはじめた
• とりあえず AWS Training を進めている
• リアルの会話はゆっくりのほうが嬉しいし、自分自身の喋りはとろい
  • （何でもかんでも早送りにしたい人ではない、ということです）

という感じです。

AWS Training とは

AWS が公式に提供してくれている学習用リソースです。まだ始めたばかりでよく分かっていませんが、ブラウザでアクセスして、動画を見ながら勉強できます。様々なコンテンツが準備されていて、興味のあるものを選ぶことができます。

しかし、動画に早送り機能がありません。速く進めたいけど途中に重要な情報があるかもしれないから飛ばしたくはない、という場合に困ってしまいます。

ページの要素を調べる

AWS Training のページ構成はコンテンツによって異なりますが、いくつか見た感じでは、<video> 要素として動画が配置されているという点は共通しているようです。<video> 要素の interface は HTMLVideoElement で、これは HTMLMediaElement を継承しています。そして、HTMLMediaElement の playbackRate プロパティで再生速度を制御することができます。

開発ツールを開き、コンソールで下記を実行すれば、再生速度が 1.25 倍になります。

const videos = document.body.getElementsByTagName("video");
videos[0].playbackRate = 1.25;

注意点

• 自分が確認に使ったブラウザは Firefox です。
• コンテンツによっては、<video> 要素が複数存在する場合があります。メインの動画が一番前にある可能性が高そうですが、確認した訳ではないので断言できません。videos のインデックスを 0 から変更する必要が生じるかもしれません。
• コンテンツによっては、動画のスピードを変えても seek bar の速度が変わりません。その結果、実際の動画と seek bar にずれが生じてしまいます。このずれの解消にはソースのスクリプトを変更する必要がありそうなので、あきらめました。

おわりに

ブラウザの開発ツールは、アプリケーションをつくるときだけでなく、日々の生活をちょっと便利にするためにも使えるんだと改めて感じました。

RDSのスナップショットを別リージョンにコピーするラムダ関数の備忘録です。
Python 3.7で、環境変数に以下をセットしています。Javascriptでやろうとしましたが、PythonがシンプルだったのでPython素人ですが採用しました。

Key	説明
DESTINATION_REGION	コピー先のリージョン名(ex:us-east-1) AWS のリージョンとエンドポイント

AWSの公式でも公開してました。2017/8/28の記事ですが、現在(2019/6/22)でも有効です。
Cross-Region Automatic Disaster Recovery on Amazon RDS for Oracle Database Using DB Snapshots and AWS Lambda

import botocore
import json
import boto3
import os

destinationRegion = os.environ['DESTINATION_REGION']

def lambda_handler(event, context):

     sourceRegion = event['region']

     rds = boto3.client('rds', region_name = destinationRegion)

     #Build the Snapshot ARN - Always use the ARN when copying snapshots across region.
     sourceSnapshotARN = event['detail']['SourceArn']
     sourceSnapshotARN = sourceSnapshotARN.replace(":db:", ":snapshot:")

     #build a new snapshot name
     sourceSnapshotIdentifer = event['detail']['SourceIdentifier']
     targetSnapshotIdentifer = "{0}-ManualCopy".format(sourceSnapshotIdentifer)
     targetSnapshotIdentifer = targetSnapshotIdentifer.replace(":","-")

     #Execute copy
     try:
         copy = rds.copy_db_snapshot(
             SourceDBSnapshotIdentifier = sourceSnapshotARN,
             TargetDBSnapshotIdentifier = targetSnapshotIdentifer,
             SourceRegion = sourceRegion)
         print("Started Copy of Snapshot {0} in {2} to {1} in {3} ".format(
             sourceSnapshotIdentifer,
             targetSnapshotIdentifer,
             sourceRegion,destinationRegion)
         )
     except botocore.exceptions.ClientError as ex:
         if ex.response['Error']['Code'] == 'DBSnapshotAlreadyExists':
             print("Snapshot {0} already exist".format(targetSnapshotIdentifer))
         else:
             print("ERROR: {0}".format(ex.response['Error']['Code']))

     return {
         'statusCode': 200,
         'body': json.dumps('Opearation Complete')
     }

ウェブサイトをAMSで運用したいと思い、下記のサイトを見て試したんですが

https://note.mu/mossmuss/n/ne846c1b1f0da

ステップ６．CloudfrontでSSLを設定

ここで完全に詰まり、先に進めなくなりました。

このようなエラーがでます。

com.amazonaws.services.cloudfront.model.InvalidViewerCertificateException: To add an alternate domain name (CNAME) to a CloudFront distribution, you must attach a trusted certificate that validates your authorization to use the domain name. For more details, see: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/... (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidViewerCertificate; Request ID: 33c1a60a-94d3-11e9-9e59-414ad5adae14)

調べても訳が分かりません。

わかる方いらっしゃいましたら、お教えください。

terraform使ってますか、便利ですね。
業務だとAWSが多いですが、Cfnよりterraformの方が好きです。

hashicorp/terraformのイメージを使います。

$ docker --version
Docker version 18.09.2

これをプロジェクトにコピペして使います。
outputの時、下の方で${TEE_FILE}に指定したファイルにterraform outputの結果を書き込むようになっているので、CIでバケット名欲しいとかあるあるな状況でよく使ってます。

#!/bin/bash

TF_VER=0.11.14

function usage() {
    usage_doc=$(cat <<EOF
Usage: /bin/bash provisioning.sh -e [env] [cmd]

Options:
  -e Select target e.g. [dev|stg|prd].
  -m Execute terraform original commands.

Environments:
  AWS_PROFILE (Attach volume ~/.aws)

Commands:
  cmd: [init|wnew|wls|fmt|plan|apply|output]

Example:
  /bin/bash provisioning.sh init
  /bin/bash provisioning.sh -e dev wnew
  /bin/bash provisioning.sh -e dev plan
  /bin/bash provisioning.sh -e dev apply
  /bin/bash provisioning.sh -e dev output
EOF
)
    echo "${usage_doc}"
    exit 2
}

function exe_terraform(){
    docker run  -it --rm \
        -e AWS_PROFILE=${AWS_PROFILE} \
        -v $(pwd):/work \
        -v ${HOME}/.aws:/root/.aws \
        -w /work \
        hashicorp/terraform:${TF_VER} ${TF_CMD}
}

function workspace_select(){
    echo "workspale: ${ENV}"
    TF_CMD="workspace select ${ENV}"
    exe_terraform || exit 1
}

# Check options.
while getopts e:m OPT; do
    case "${OPT}" in
        e)  ENV=${OPTARG};;
        m)  M=true;;
        \?) usage;;
    esac
done
shift $((OPTIND - 1))

# Check environment or manual command.
if [ "${M}" = "true" ]; then
    TF_CMD="${@}"
    exe_terraform
    exit ${?}
else
    CMD="${1}"
    TEE_FILE=/dev/null
fi

# Execute terraform command.
case "${CMD}" in
    init) TF_CMD="init";;
    fmt)  TF_CMD="fmt";;
    wls)  TF_CMD="workspace list";;
    *)
        [ "${ENV}" == "" ] && usage
        case "${CMD}" in
            wnew) TF_CMD="workspace new ${ENV}";;
            plan)
                workspace_select
                TF_CMD="plan -var env=${ENV}"
                # TF_CMD="plan -var env=${ENV} -var-file=envs/${ENV}.tfvars"
                ;;
            apply)
                workspace_select
                TF_CMD="apply -var env=${ENV}"
                # TF_CMD="apply -var env=${ENV} -var-file=envs/${ENV}.tfvars"
                ;;
            output)
                workspace_select
                TF_CMD="output -json"
                TEE_FILE=outputs/${ENV}.json
                ;;
        esac
esac

echo "Your command: terraform ${TF_CMD}"
exe_terraform | tee ${TEE_FILE}

概要

vue.jsのサーバサイドレンダリングで行うNuxt.jsをAWS Lambda上で動かしてみます．あくまでも試験的に試すことが目的の記事です．もし，本番サービスでの導入する場合には慎重な議論をお願いします．

構成

• AWS Lambdaでnuxt.jsを可動させる
• API Gateway経由でWebブラウザ等からアクセスする．

前提

• yarn, npx, nodeといったnuxt.jsを開発する環境がある．
• AWSアカウントを取得しaws-cliがインストール済みで実行できる状態である．
• node.jsとexpressでWebサーバを作ったことがある．
• AWS LambdaやAPI Gateway, CloudFormation, S3などAWSのサービスを使ったことがある.

手順

1. nuxtプロジェクト作成

1.1 初期化

npxコマンドを使ってnuxtプロジェクトを立ち上げます．

• カスタムサーバフレームワークにはexpressを選択してください．後ほどexpressを使ったLambdaサーバにするため．
• UIフレームワークにVuetifyを指定していますが必須ではありません．
• パッケージマネージャはyarnを選択していますがnpmでも動くと思います(未検証)

$ npx create-nuxt-app nuxt_lambda_sample
? Project name nuxt_lambda_sample
? Project description My remarkable Nuxt.js project
? Use a custom server framework express
? Choose features to install
? Use a custom UI framework vuetify
? Use a custom test framework none
? Choose rendering mode Universal
? Author name Hirokazu Yokoyama
? Choose a package manager yarn

1.2 nuxt.js 起動

初期化後,下記コマンドでローカル環境にnuxt.jsが起動します．

$ cd ./nuxt_lambda_sample
$ yarn install
$ yarn run dev

....
 READY  Server listening on http://localhost:3000

2. lambdaサービスに変更する

2.1 expressを確認

server/index.js にexpressを使ったnode.jsのプログラムがあることを確認しましょう．
package.jsonのscriptsにも定義されている通り，このファイルがプログラムのエントリポイントになっています．　app.useでnuxtを登録していることがわかります．

server/index.js

const express = require('express')
const consola = require('consola')
const { Nuxt, Builder } = require('nuxt')
const app = express()

// Import and Set Nuxt.js options
const config = require('../nuxt.config.js')
config.dev = !(process.env.NODE_ENV === 'production')

async function start() {
  // Init Nuxt.js
  const nuxt = new Nuxt(config)

  const { host, port } = nuxt.options.server

  // Build only in dev mode
  if (config.dev) {
    const builder = new Builder(nuxt)
    await builder.build()
  } else {
    await nuxt.ready()
  }

  // Give nuxt middleware to express
  app.use(nuxt.render)

  // Listen the server
  app.listen(port, host)
  consola.ready({
    message: `Server listening on http://${host}:${port}`,
    badge: true
  })
}
start()

2.2 lambdaで動くようにする

このままでは通常のnode.jsで動くための状態であるので， AWS Lambda上で動くように改修します．
expressをAWS Lambdaで可動させるaws-serverless-expressを導入します．

$yarn add aws-lambda aws-serverless-express

server/index.jsを下記のように改修します． また，ミドルウェアを新規作成します(server/middleware.js). ポイントは２つです．

• Lambdaのエントリポイントであるhandler関数を作成し， awsServerlessExpresを動かしている．
• ミドルウェアとしてURLを置き換える処理(customDomainAdaptorMiddleware)を追加している．

なお， binaryMimeTypesでバイナリデータとして処理させるMimeTypeを追加しています．バイナリタイプとして処理させないとAPI Gatewayを経由したときにgzip圧縮等の関係でブラウザが正常に処理できない事象が発生するので指定しています．(ERR_CONTENT_DECODING_FAILEDというエラーになりました．)

server/index.js

const awsServerlessExpress = require('aws-serverless-express')
const express = require('express')
const { Nuxt, Builder } = require('nuxt')
const { customDomainAdaptorMiddleware } = require('./middleware');
const app = express()

// Import and Set Nuxt.js options
let config = require('../nuxt.config.js')
config.dev = false

async function initApp() {
  // Init Nuxt.js
  const nuxt = new Nuxt(config)

  const { host, port } = nuxt.options.server

  // Build only in dev mode
  if (config.dev) {
    const builder = new Builder(nuxt)
    await builder.build()
  } else {
    await nuxt.ready()
  }

  // Give nuxt middleware to express
  app.use(customDomainAdaptorMiddleware)
  app.use(nuxt.render)

  return app
}

var server = undefined;
const binaryMimeTypes = [
  'application/javascript',
  'application/json',
  'application/octet-stream',
  'application/xml',
  'font/eot',
  'font/opentype',
  'font/otf',
  'image/jpeg',
  'image/png',
  'image/svg+xml',
  'text/comma-separated-values',
  'text/css',
  'text/html',
  'text/javascript',
  'text/plain',
  'text/text',
  'text/xml'
]

exports.handler = (event, context) => {
  initApp().then((app) => {
    if (server === undefined) {
      server = awsServerlessExpress.createServer(app, null, binaryMimeTypes)
    }
    awsServerlessExpress.proxy(server, event, context)
  })
}

下記のミドルウェアを新規に作成します． API Gatewayでは/dev/といったステージ名を示すパスが入るのでそれに対応させるためにURLを置き換えています．

server/middleware.js

let config = require('../nuxt.config.js')

const customDomainAdaptorMiddleware = (req, res, next) => {
    const apigatewayHeader = req.headers['x-apigateway-event'];

    if (apigatewayHeader === undefined) {
      next()
      return
    }

    req.url = req.originalUrl = `${config.router.base}${req.url}`.replace('//', '/')

    next()
};

module.exports = {customDomainAdaptorMiddleware};

API Gatewayのステージ名となる既定パスをnuxt.config.jsに追記して設定します．今回は/dev/が既定パスとして設定します．　（URLのhttps://xxxx.amazonaws.com/devのこと）

nuxt.config.js

  router: {
    base: '/dev/',
  },

3. デプロイ

3.1 デプロイ定義を作成

CloudFormationのデプロイ定義を作成します．　LambdaとAPI Gateway及びそれらに付随する権限設定を書いています．

cloudformation.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'

Resources:
  NuxtServerLambda:
    Type: AWS::Lambda::Function
    Properties:
      Code: .
      Timeout: 5
      MemorySize: 512
      FunctionName: nuxt_sample_server
      Role: !GetAtt [ "NuxtServerLambdaRole", "Arn" ]
      Runtime: nodejs8.10
      Handler: server/index.handler  

  NuxtServerLambdaRole:
    Type: AWS::IAM::Role
    Properties:
      ManagedPolicyArns:
        - !Ref NuxtServerLambdaPolicy
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: "sts:AssumeRole"

  NuxtServerLambdaPolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement: 
          - Effect: Allow
            Action:
              - "logs:CreateLogStream"
              - "logs:PutLogEvents"
              - "logs:CreateLogGroup"
            Resource: "arn:aws:logs:*:*:*"

  LogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/lambda/${NuxtServerLambda}
      RetentionInDays: 3

  ApiGateway:
    Type: AWS::Serverless::Api
    Properties:
      StageName: dev
      DefinitionBody:
        swagger: "2.0"
        info:
          version: "1.0.0"
          title: "nuxt_lambda_sample"
        basePath: dev
        x-amazon-apigateway-binary-media-types:
          - '*/*'
        paths:
          /:
            get: 
              produces:
                - "application/json"
              responses:
                "200":
                  description: "200 response"
                  schema:
                    $ref: "#/definitions/Empty"
              x-amazon-apigateway-integration:
                uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${NuxtServerLambda.Arn}/invocations"
                responses:
                  default:
                    statusCode: "200"
                passthroughBehavior: "when_no_match"
                httpMethod: "POST"
                contentHandling: "CONVERT_TO_TEXT"
                type: "aws_proxy"            
          /{proxy+}:
            get: 
              produces:
                - "application/json"
              responses:
                "200":
                  description: "200 response"
                  schema:
                    $ref: "#/definitions/Empty"
              x-amazon-apigateway-integration:
                uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${NuxtServerLambda.Arn}/invocations"
                responses:
                  default:
                    statusCode: "200"
                passthroughBehavior: "when_no_match"
                httpMethod: "POST"
                contentHandling: "CONVERT_TO_TEXT"
                type: "aws_proxy"

  ApiPermission:
    Type: "AWS::Lambda::Permission"
    DependsOn:
      - ApiGateway
      - NuxtServerLambda
    Properties:
      Action: "lambda:InvokeFunction"
      FunctionName: !Ref NuxtServerLambda
      Principal: apigateway.amazonaws.com

3.2 ビルド & デプロイ

yarnでビルド後, awsコマンドでデプロイしています．
STACK_NAME, S3_BUCKETは適切に変更してください．

$ STACK_NAME=nuxt-lambda-sampl
$ S3_BUCKET=<デプロイするパッケージを置くS3バケット名>

$ yarn run build
$ aws cloudformation package --template-file cloudformation.yaml --s3-bucket $S3_BUCKET --output-template-file cloudformation_dist.yaml
$ aws cloudformation deploy --template-file cloudformation_dist.yaml --stack-name STACK_NAME --capabilities CAPABILITY_IAM

4. 動いた

まとめ

Nuxt.jsのWebページをAWS Lambdaで動くようにしました．

参考にした文献

• https://qiita.com/kai_kou/items/5b1ebb9abc5d62545e04
• https://github.com/awslabs/aws-serverless-express/tree/master/examples/basic-starter

サービス

タスク

コンテナインスタンス

Fargate

Game Day の備忘録

感想を一言で言うと「思い切って参加して良かったー?！」です。
でも、参加する前はこんな気持ちでした。

• 楽しそう！と応募してしまったもののイベント開催日が近づくにつれ、不安になってきました
  • ゲーム（演習）についていけるのかしら？
  • 保有スキル(IaaS)が役に立たないかも、イベントのタイトルに「Microservices」と書いてあるし?
  • キャンセルしようかな・・・

いやちょっと待てよ、自分に足りないスキルを早めに知るいい機会かも?と考え直し、思い切って参加してみたところ・・・

• 社外のエンジニアの方から刺激を受けました！
  • 更にレベルあげるぞ！という前向きな気持ちになる
  • みんな凄いぞ、自分はまだまだAWSのスキル未熟だな?
  • 使ったことのあるサービスのスキルは深くは理解できてないな
  • 日常業務はシステム(環境)の構成・設計・運用を予め把握しているからできる気になっているけど、社外に出たら通用しないね
  • AWSさんのスキル凄いぞ(ほぼマンツーでのヘルプで垣間見た感想)

ちなみに私のAWS経験値はこんな程度です。

• AWS歴1年
• AWS認定資格なし
• Technical Essential 1,2受講済
• 代表的なサービスを実験的に幾つか実験したことある
• 仕事でVPC、EC2などのインフラ関連、最近WorkSpacesをちょっと

ゲームの内容は守秘義務がありますのでお話できませんが、ぜひ参加されてみては如何でしょうか。
プライベートや職場の都合など色々あるかと思いますので、あくまでも個人の感想と捉えていただければと思います。

いただいたクッキーです↓ 調整者の証！

RDS AutoScaling

いつにもまして唐突にリリースされた感のあるRDSにおけるAutoScaling。先日発表された新機能により、これまでの手動で行っていたストレージの拡張作業から開放されるかもしれません。細かな説明に関しては参照元のクラスメソッドさんの記事を読む事をお勧めします。

■参照
【DBのディスクサイズ管理が簡単に】RDSのストレージがストレージの自動スケーリングをサポートしました！

RDSストレージ拡張時のAWS仕様

通常RDSのストレージ容量を拡張した場合、公式ガイドのように以下の仕様により[Storage-optimization]のステータスが解除されるか、6時間の長い方の何れかが経つまで次の変更を加える事が出来ません。この仕様はRDS AutoScalingにおいても適用されるものなのかが気になるところ…。

DB インスタンスのストレージサイズを変更すると、DB インスタンスのステータスは [Storage-optimization] になります。ストレージ変更後、DB インスタンスは完全に動作します。ただし、6 時間 あるいは DB インスタンスステータスが [Storage-optimization] の間のいずれか長い方の間は、ストレージに変更を加えることはできません。

[Storage-optimization] とは画像だとこのようなステータス状態です。

私自身、業務で手動によるストレージ拡張を実施することがあり、その際にもこの仕様には度々意識させられてきたのでこれは検証せねばということでやってみました。

1回目のAutoScaling

※検証方法は参照の記事をそのまま使わせて頂きました。

結果

無事、成功ですね！
イベントログ出力とAutoScalingの流れを時系列に載せておきます。

イベントログ

AutoScalingの流れ

時間	概要
00:27	①容量枯渇
00:32	②AutoScaling開始
00:35	③AutoScaling完了

今回のケースですと、20GBから25GBへの増加に対しては容量が枯渇してからおよそ8分でAutoScaleが完了していますね。

ステータス確認

気になるストレージステータスと変更可否ですが、AutoScaling直後ですと以下の様になっておりました。

ストレージステータス

想定通りのステータスが表示されています。

※そしておよそ１０分後に利用可能ステータスに切り替わっていました。

ストレージ変更の可否

対象のRDSを選択して画面右上の[変更]を押下して確認してみましょう。

やはり、ストレージ容量の設定項目がグレーアウトされて注意書きが表示されていますね。１回目のAutoScalingが実行された状態でもう一度容量を枯渇させてみたらどうなるか検証してみましょう。

２回目のAutoScaling

結果

1回目と同様の方法でストレージを枯渇させて１時間ほど暫く様子を見てみたところ、AutoScalingは実行されませんでした。

ステータス確認

ステータスはStorage-fullと、その名の通り容量が一杯ですよと表示されておりました。暫く放置して2回目のAutoScalingが実行されるのを見届けましょう。

約6時間後

6時間経過してAutoScalingが実行されました〜。公式ガイドの記載の通りの動きとなりましたね。これらで得たい結果を見ることが出来ました！

結論

RDS AutoScalingにおいても、これまで通りストレージ拡張時には変更制限の仕様に沿った挙動となることが分かりました。余程の事がない限り６時間以内という短期期間の間に連続して容量の拡張が必要なシチュエーションは訪れないでしょうけれども、AutoScale設定を有効にする際には念頭においた方がいいかもしれませんね。

また、AutoScaling専用のイベントサブスクリプションも作成できるようになれれば尚良いですね。今後のリリースに期待しましょう。

以上、さっくりとRDSのAutoScaleを検証してみました。
非常に便利な機能なのでAWSでシステムを作る際には積極的に使っていきたいですね！

RDS AutoScaling

いつにもまして唐突にリリースされた感のあるRDSにおけるAutoScaling。先日発表された新機能により、これまでの手動で行っていたストレージの拡張作業から開放されるかもしれません。細かな説明に関しては参照元のクラスメソッドさんの記事を読む事をお勧めします。

■参照
【DBのディスクサイズ管理が簡単に】RDSのストレージがストレージの自動スケーリングをサポートしました！

RDSストレージ拡張時のAWS仕様

通常RDSのストレージ容量を拡張した場合、公式ガイドのように以下の仕様により[Storage-optimization]のステータスが解除されるか、6時間の長い方の何れかが経つまで次の変更を加える事が出来ません。この仕様はRDS AutoScalingにおいても適用されるものなのかが気になるところ…。

DB インスタンスのストレージサイズを変更すると、DB インスタンスのステータスは [Storage-optimization] になります。ストレージ変更後、DB インスタンスは完全に動作します。ただし、6 時間 あるいは DB インスタンスステータスが [Storage-optimization] の間のいずれか長い方の間は、ストレージに変更を加えることはできません。

[Storage-optimization] とは画像だとこのようなステータス状態です。

私自身、業務で手動によるストレージ拡張を実施することがあり、その際にもこの仕様には度々意識させられてきたのでこれは検証せねばということでやってみました。

1回目のAutoScaling

※検証方法は参照の記事をそのまま使わせて頂きました。

結果

無事、成功ですね！
イベントログ出力とAutoScalingの流れを時系列に載せておきます。

イベントログ

AutoScalingの流れ

時間	概要
00:27	①容量枯渇
00:32	②AutoScaling開始
00:35	③AutoScaling完了

今回のケースですと、20GBから25GBへの増加に対しては容量が枯渇してからおよそ8分でAutoScaleが完了していますね。

ステータス確認

気になるストレージステータスと変更可否ですが、AutoScaling直後ですと以下の様になっておりました。

ストレージステータス

想定通りのステータスが表示されています。

※そしておよそ１０分後に利用可能ステータスに切り替わっていました。

ストレージ変更の可否

対象のRDSを選択して画面右上の[変更]を押下して確認してみましょう。

やはり、ストレージ容量の設定項目がグレーアウトされて注意書きが表示されていますね。１回目のAutoScalingが実行された状態でもう一度容量を枯渇させてみたらどうなるか検証してみましょう。

２回目のAutoScaling

結果

1回目と同様の方法でストレージを枯渇させて１時間ほど暫く様子を見てみたところ、AutoScalingは実行されませんでした。

ステータス確認

ステータスはStorage-fullと、その名の通り容量が一杯ですよと表示されておりました。暫く放置して2回目のAutoScalingが実行されるのを見届けましょう。

約6時間後

6時間経過してAutoScalingが実行されました〜。公式ガイドの記載の通りの動きとなりましたね。これらで得たい結果を見ることが出来ました！

結論

RDS AutoScalingにおいても、これまで通りストレージ拡張時には変更制限の仕様に沿った挙動となることが分かりました。余程の事がない限り６時間以内という短期期間の間に連続して容量の拡張が必要なシチュエーションは訪れないでしょうけれども、AutoScale設定を有効にする際には念頭においた方がいいかもしれませんね。

また、AutoScaling専用のイベントサブスクリプションも作成できるようになれれば尚良いですね。今後のリリースに期待しましょう。

以上、さっくりとRDSのAutoScaleを検証してみました。
非常に便利な機能なのでAWSでシステムを作る際には積極的に使っていきたいですね！

RDS自動スケーリング

いつにもまして唐突にリリースされた感のあるRDSにおけるAutoScaling。先日発表された新機能により、これまでの手動で行っていたストレージの拡張作業から開放されるかもしれません。細かな機能説明に関しては参照元のクラスメソッドさんの記事を読む事をお勧めします！

■参照
【DBのディスクサイズ管理が簡単に】RDSのストレージがストレージの自動スケーリングをサポートしました！

RDSストレージ拡張時のAWS仕様

通常RDSのストレージ容量を拡張した場合、公式ガイドのように以下の仕様により[Storage-optimization]のステータスが解除されるか、6時間の長い方の何れかが経つまで次の変更を加える事が出来ません。この仕様はRDS 自動スケーリングにおいても適用されるものなのかが気になるところ…。

DB インスタンスのストレージサイズを変更すると、DB インスタンスのステータスは [Storage-optimization] になります。ストレージ変更後、DB インスタンスは完全に動作します。ただし、6 時間 あるいは DB インスタンスステータスが [Storage-optimization] の間のいずれか長い方の間は、ストレージに変更を加えることはできません。

[Storage-optimization] とは画像だとこのようなステータス状態です。

私自身、業務で手動によるストレージ拡張を実施することがあり、その際にもこの仕様には度々意識させられてきたのでこれは検証せねばということでやってみました。

1回目の自動スケーリング

※検証方法は参照の記事をそのまま使わせて頂きました。

結果

無事、成功ですね！
イベントログ出力と自動スケーリングの流れを時系列に載せておきます。

イベントログ

自動スケーリングの流れ

時間	概要
00:27	①容量枯渇
00:32	②AutoScaling開始
00:35	③AutoScaling完了

今回のケースですと、20GBから25GBへの増加に対しては容量が枯渇してからおよそ8分でAutoScaleが完了していますね。

ステータス確認

気になるストレージステータスと変更可否ですが、自動スケーリング直後ですと以下の様になっておりました。

ストレージステータス

想定通りのステータスが表示されています。

※そしておよそ１０分後に利用可能ステータスに切り替わっていました。

ストレージ変更の可否

対象のRDSを選択して画面右上の[変更]を押下して確認してみましょう。

やはり、ストレージ容量の設定項目がグレーアウトされて注意書きが表示されていますね。１回目が実行された状態でもう一度容量を枯渇させてみたらどうなるか検証してみましょう。

２回目のAutoScaling

結果

1回目と同様の方法でストレージを枯渇させて１時間ほど暫く様子を見てみたところ、自動スケーリングは実行されませんでした。

ステータス確認

ステータスはStorage-fullと、その名の通り容量が一杯ですよと表示されておりました。暫く放置して2回目が実行されるのを見届けましょう。

約6時間後

6時間経過してAutoScalingが実行されました〜。公式ガイドの記載の通りの動きとなりましたね。これらで得たい結果を見ることが出来ました！

結論

RDS自動スケーリングにおいても、これまで通りストレージ拡張時には変更制限の仕様に沿った挙動となることが分かりました。余程の事がない限り６時間以内という短期期間の間に連続して容量の拡張が必要なシチュエーションは訪れないでしょうけれども、AutoScale設定を有効にする際には念頭においた方がいいかもしれませんね。

また、AutoScaling専用のイベントサブスクリプションも作成できるようになれれば尚良いですね。今後のリリースに期待しましょう。

以上、さっくりと検証してみました。
非常に便利な機能なのでAWSでシステムを作る際には積極的に使っていきたいですね！

RDS自動スケーリング

いつにもまして唐突にリリースされた感のあるRDSにおけるAuto Scaling。先日発表された新機能により、これまでの手動で行っていたストレージの拡張作業から開放されるかもしれません。細かな機能説明に関しては参照元のクラスメソッドさんの記事を読む事をお勧めします！

■参照
【DBのディスクサイズ管理が簡単に】RDSのストレージがストレージの自動スケーリングをサポートしました！

RDSストレージ拡張時のAWS仕様

通常RDSのストレージ容量を拡張した場合、公式ガイドのように以下の仕様によりStorage-optimizationのステータスが解除されるか、6時間の長い方の何れかが経つまで次の変更を加える事が出来ません。この仕様はRDS 自動スケーリングにおいても適用されるものなのかが気になるところ…。

DB インスタンスのストレージサイズを変更すると、DB インスタンスのステータスは Storage-optimization になります。ストレージ変更後、DB インスタンスは完全に動作します。ただし、6 時間 あるいは DB インスタンスステータスが Storage-optimization の間のいずれか長い方の間は、ストレージに変更を加えることはできません。

Storage-optimizationとは画像だとこのようなステータス状態です。

私自身、業務で手動によるストレージ拡張を実施することがあり、その際にもこの仕様には度々意識させられてきたのでこれは検証せねばということでやってみました。

1回目の自動スケーリング

※検証方法は参照の記事をそのまま使わせて頂きました。

結果

無事、成功ですね！
イベントログ出力と自動スケーリングの流れを時系列に載せておきます。

イベントログ

自動スケーリングの流れ

時間	概要
00:27	①容量枯渇
00:32	②AutoScaling開始
00:35	③AutoScaling完了

今回のケースですと、20GBから25GBへの増加に対しては容量が枯渇してからおよそ8分で完了していますね。

ステータス確認

気になるストレージステータスと変更可否ですが、自動スケーリング直後ですと以下の様になっておりました。

ストレージステータス

想定通りのステータスが表示されています。

※そしておよそ１０分後に利用可能ステータスに切り替わっていました。

ストレージ変更の可否

対象のRDSを選択して画面右上の[変更]を押下して確認してみましょう。

やはり、ストレージ容量の設定項目がグレーアウトされて注意書きが表示されて変更が不可になっていますね。１回目が実行された状態でもう一度容量を枯渇させてみたらどうなるか検証してみましょう。

２回目の自動スケーリング

結果

1回目と同様の方法でストレージを枯渇させて１時間ほど暫く様子を見てみたところ、自動スケーリングは実行されませんでした。

ステータス確認

ステータスはStorage-fullと、その名の通り容量が一杯ですよと表示されておりました。暫く放置して2回目が実行されるのを見届けましょう。

約6時間後

6時間経過してようやく実行されました〜。公式ガイドの記載の通りの動きとなりましたね。これらで得たい結果を見ることが出来ました！

結論

RDS自動スケーリングにおいても、これまで通りストレージ拡張時には変更制限の仕様に沿った挙動となることが分かりました。余程の事がない限り６時間以内という短期期間の間に連続して容量の拡張が必要なシチュエーションは訪れないでしょうけれども、自動スケーリング設定を有効にする際には念頭においた方がいいかもしれませんね。

また、専用のイベントサブスクリプションも作成できるようになれれば尚良いですね。今後のリリースに期待しましょう。

以上、さっくりと検証してみました。
非常に便利な機能なのでAWSでシステムを作る際には積極的に使っていきたいですね！