20190318のAWSに関する記事は11件です。

投稿日：2019-03-18T23:11:42+09:00

aws-amplify-vueで作成した認証画面でSignUpをさせないようにする

背景

AWS Amplify + AppSync + Vue で爆速でモダンなフロントエンドが開発できるという噂を聞きつけ、実際に試してみたところ、とてもみみっちいところで躓いてしまったのでその対処法を記述します。
なお、本来の趣旨である「爆速でモダンなフロントエンド開発」という点については、確かに革命的な効果を感じましたので、今後も引き続き深堀りしていきたいと思います。特にAppSyncにはかなり将来性を感じました。
Amplify + AppSync + Vue での具体的なフロントエンド構築方法が知りたい方は、以下の記事を読むことをお勧め致します。私も参考にさせて頂きました。
https://qiita.com/nakayama_cw/items/6d3514b51c5fbf9ba450
https://qiita.com/shunp/items/d491adfadd570f66f990

サインアップできないようにしたい…！

上記の記事を参考にAmplifyから環境構築し、認証をCognito、APIをAppSyncで作成しました。（ここまで本当にあっという間にできます。）
バックエンド部分はAmplify Consoleのおかげもあり、ほとんどが自動でできます。さすがにフロントエンド部分は自分で書かないといけませんが、それでもaws-amplify-vueというパッケージが用意されており、これを使うことで面倒なログイン画面などの作成をスキップすることができます。

ということで、早速このパッケージを使って、ログイン機能を実装しました。具体的な方法は以下の記事が参考になります。
https://qiita.com/maniju/items/d33d64f0b729630d0c3d

おお、簡単にできました！ログインだけでなく、パスワードリセットの機能やアカウント作成の機能までコンポーネントを読み込んで配置するだけであっという間にできます。

サインアップ画面もこの通り。（ログイン画面のCreate accountより遷移）
必要な項目の追加や削除もパラメータ設定によって変更することができます。（具体的な設定内容は以下ドキュメントを参考のこと。）
https://aws-amplify.github.io/docs/js/vue#authentication-components

さて、自分が作っているサイトは実に細々としたものなので、一般ユーザに勝手に登録されるのも困ります。Cognitoの方は「管理者のみがユーザ登録可能」な設定になっているので、サイトからもサインアップができないようにする必要があります。

が…上述のドキュメントをいくら読んでも、サインアップをさせないようにする設定が書かれていません…orz
サインアップ画面から項目全部消したり、signUpConfig: nullとかやってみたものの全然ダメでした。

結論

GitHubのIssueに書いてありました。
https://github.com/aws-amplify/amplify-js/issues/1993
export default {
  ...
  data: function(){
    return {
      authConfig: {
        signInConfig: {
          isSignUpDisplayed : false  // ← コレ！！
        }
      }
    }
  }
}
消えた！
（「No account? Create account」のリンクが。）

このパラメータ、需要は多いと思うんですが、なぜか上述のドキュメントにはまだ載っていません。
この記事が私と同じように悩んでいる方の参考になれば幸いです。

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T21:17:34+09:00

AWS Lambdaのスケジュール実行をローカルでテストしてみる

はじめに

AWSが公式で提供しているサーバーレスアプリケーションを構築するためのフレームワークである、AWS SAMを使うことにより、コードを書いてテストを行い、デプロイするまでを全てローカルで行うことができるようになります。
今回は、AWS SAMを用いてAWS Lambda Functionのスケジュール実行をローカル環境でテストする手順をメモとして残します。

環境

OS: macOS Mojave10.14
言語: Node.js 8.10
Docker: 18.09.2
SAM CLI: 0.11.0

環境構築

Dockerのインストール

AWS SAMはDocker上で動くのでDockerが必要。
以下の公式サイトからインストール。
https://docs.docker.com/docker-for-mac/install/

AWS SAM CLIのインストール

Homebrewでインストール。
$ brew tap aws/tap
$ brew install aws-sam-cli
プロジェクト作成

適当なディレクトリで、以下のコマンドを入力。
※samコマンドについては以下の記事が参考に。
https://qiita.com/gnk263/items/7f8796c26b9b61d33d96
$ sam init -r nodejs8.10 -n sample-app
すると以下のようなプロジェクトが作成される。
sample-app/
├── README.md
├── hello-world
│   ├── app.js
│   ├── package.json
│   └── tests
│       └── unit
│           └── test-handler.js
└── template.yaml
template.yamlの修正

Resources配下のHelloWorldFunctionを以下のように修正。スケジュールの実行間隔は任意に修正。
※Lambdaのスケジュール実行に関しては以下を参照。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/tutorial-scheduled-events-schedule-expressions.html
HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
        CodeUri: hello-world/
        Handler: app.lambdaHandler
        Runtime: nodejs8.10
        Events:
            Timer:
                Type: Schedule
                Properties:
                    Schedule: rate(1 minute)
ローカル実行環境構築用の設定ファイルを作成

sample-app配下で以下のコマンドを入力。
$ sam local generate-event cloudwatch scheduled-event > event_file.json
テスト

sample-app配下で以下のコマンドを入力。
$ sam local invoke "HelloWorldFunction" -e event_file.json
以下のような反応が返って来れば成功。
START RequestId: e832090d-203c-19f4-c6ae-580e00b3905f Version: $LATEST
END RequestId: e832090d-203c-19f4-c6ae-580e00b3905f
REPORT RequestId: e832090d-203c-19f4-c6ae-580e00b3905f  Duration: 13.40 ms  Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 30 MB  

{"statusCode":200,"body":"{\"message\":\"hello world\"}"}
終わりに

色々試したところ、template.yamlのScheduleの所にタイポがあっても成功レスポンスが返ってくるし、実際にCloudWatchに正しいスケジュール間隔で登録されるかどうかはデプロイしてみるまでは分からない模様。うーん。。。
指摘等ありましたらコメントお願いします。

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T20:22:11+09:00

aws DevOps Proに合格して5冠になったのでこれまでも含めて書いてみる

先日、
DevOps Professional対策 Opsworks編
なんてのを書きましたが、ポイントとしては悪くなかったかなとおもってます。
今日受けてきたDevOps Proの事を忘れないうちに書こうと思っておりますが、一つの区切りなのでこれまでについてをまず記しますよ。

Me

基本、何でも屋

インフラについては実務で必要な技術をその都度使っているだけ

なぜかインフラの人間と思われがちでそっちが良く降ってくる

aws経験は1年半くらい

受講のきっかけとしては、社内のリソースをawsに移行するプロジェクトをやる事になったためです。
最初は外注云々って話だったんだけど、社内のリソースがややこしすぎて、これなら自分でやる方が楽だよね、ってやり始めました。
で、aws認定を受けはじめたのは社内の人に納得してもらうという理由だったりします。
受かっても別に手当とかないですし、実はあんまメリットない。
とりあえずアソシエトは全部とっとけ。プロは1年くらいかけて取ろうっていうスケジュール感です。

受講履歴

試験受験日

ソリューションアーキテクトアソシエイト 2017/12/1

SysOps Administrator アソシエイト 2017/12/25

デベロッパーアソシエイト 2018/1/9

ソリューションアーキテクト　プロフェッショナル 2018/9/28

DevOpsエンジニアプロフェッショナル 2019/3/18

ソリューションアーキテクトアソシエイト

一発目。勉強期間は1カ月くらいだったでしょうか。
基本、合格対策 AWS認定ソリューションアーキテクト－アソシエイトって本で勉強しました。
今はいくつか本あるみたいだけど、当時はこれしかなかった。
何すりゃいいかあんまりよくわかなくて勉強はこれだけ。模試すら受けてない。
この本を2度ほど解いたのですが、まあ比較的似通った問題が多くてなんとなく解けた・・という程度です。
なんとなくなのでギリギリですね。。点数は忘れたけど70%に届かないぐらいだったような気がします。
まあ、運が良かったですね。
ちなみに、時間的な意味だと一番勉強したのがこの回。トータル10時間以上やったんじゃなかろうか。おそらく。

SysOps Administrator アソシエイト

さて。教材がなくなりました。正直、自分の中で一番インパクトが薄い試験であまり覚えてません。。
ただ、一つ受かるとプラクティスのタダ券が貰えます。それ使って模試受けました。
で、模試の時に問題をキャプチャしておいて、後で見直したりしましたっけ。
模試の結果はギリギリ合格ぐらいだったように思います。
というか正直、ソリューションアーキテクト受かる人ならだいたい受かるんじゃないかな、って試験でした。もちろんバックグラウンドにもよるんでしょうけど。

デベロッパーアソシエイトアソシエイト

DevOpsの要素が入っていて、これまでとは少し違う感じに。
ElasticBeanstalkとかCloudFormationとかあまり馴染みのないものも出てくる。
ただ、試験の内容としては所詮はアソシエイトレベルでして、S3とかDynamoDbですとかそのあたりを把握できてればおおよそいける気がする。
試験はいつも午後に受けるようにしていて、午前に半日漬けをするようにしています。
馴染みのない部分については半日漬けでなんとかしました。
あとBlakBeltの資料(Pdf)を通勤中にスマホで眺めたりしていました。
これもギリギリ合格。これが一番ギリギリで、あと一問間違ったらアウトでした。運が良かった。

ソリューションアーキテクト　プロフェッショナル

さてプロフェッショナル。
デベロッパーアソシエイト受けた直後ぐらいにプラクティスを受けたのですが・・確か40%ぐらい。いや、それ以下だったかも。
これは無理かも・・と思いしばらく放置します。
そして業務の方ではaws移行プロジェクトが佳境。いや、修羅場。
まあ、でもいい経験になったのでしょうか。aws歴1年未満だったけど、精神と時の部屋に籠った気分。
で、プロジェクトが無事完了した後勉強開始。
BlackBeltの資料みたりします。
で、本試験の4日前に模試受けてみるも・・また40%台。。こりゃアカンやろ。
そこで見つけたのがAWS Web問題集で勉強しようってサイト。
SAPの問題もけっこうあったので、サンプル問題をチェックしてみてから入会し、一通り解いてみました。問題的にはかなり本番に近いものが多くてちょっとズルい感じはしたものの、おかげ様で少し余裕をもって合格できました。これと半日漬けがなかったら確実に落ちてましたね。

DevOps Professinal

では本題です。
勉強方法としては・・日本語で学習する方法がうまく見つかりませんでした。
なので、

わかんないやつ触ってみる

ホワイトペーパー眺める（どれ見たらいいかわかんなくて適当に2つぐらい流し見)

といったのが基本でした。
が、模試やってみるとまた40%ぐらいしか取れない。。
追加でやってみたのが、

サンプル問題の日本語訳が公開されてるブログを見る

Udemy(https://www.udemy.com/)

の2点。
主に後者のUdemyに時間を使いました。
英語ではあったものの、な～んとなくはわからなくもないので通勤時にスマホで解いてみる。
使い始めたのが試験の2週間くらい前だったのですが、一日20問ぐらいやってました。
なんかDevOps Proの講座は二つあって、どっちも90%オフ(←期間限定商法？）だったのでそれに釣られて。。2400円ぐらいだったっけ？二つで。
一つが40問x2で80問、もう一つが80問x5で400問。後者は3割ぐらいしかやれてない。問題としては被ってたから後者の方だけで良かったすね。

んでまあ、アーキテクトのproの時みたいに似通った問題がいっぱい出るんじゃないかなーと淡い期待をして臨んだのですが・・結果、ぜんぜん違う。。
思わず「こりゃアカン」・・と声が出そうになりました。絶望しかない。
時間もけっこうギリギリで終了1分前まで粘って終了のボタンを押す。
・・で、結果が表示された瞬間、我が目を疑う。

　おめでとうございます。合格しました。

（↑正確な文章は覚えてない）
は？なんでやねん。
90%不合格やと思てたのに。
一生懸命考えて答えたのがそれなりに合ってたという事でしょうか。
これはもう実力でしょう。きっと。たぶん。

試験内容

さて、この堕記事をごらんになっている方が知りたいのはこちらではないでしょうか。
ざっと言って重要なのはこのあたりかと思いました。

Systems Manager

CloudWatch / CloudWatchLogs

CloudFormation

Code3兄弟

AWS Inspector

ElasticBeanstalk

OpsWorks

ECS

Trusted Advisor

aws Config

10選するとこんな感じでしょうか。上から順に印象強し。
Systems Managerとか、パラメーターストアぐらいしか知らなかったのでマジわかんなかったです。でもいっぱい出た。
あとECSが問題に乗ってきたのはちょっと意外。けっこうマニアックなものかと思ってた。EFSなんかもちょろっと出ましたよ。
あとInspectorもなんとなくしかわかってなかったから苦戦。
Code3兄弟はちゃんと触って覚えておくのが良いと思います。
それから、比較的、ログ飛ばします。それからどうするの？みたいな問題が多かったっけ。

ご参考になると幸いです！
ちなみに2019/3/18の最新情報でございます。
今後もどんどんアップデートされていくのでしょうね。
2年以内に更新必要とかカンベンしてほしいっすわ。。

追記

そういえば、問題の一つでポートフォリオがどうこうって問題があったけど、これかなぁ。
https://docs.aws.amazon.com/servicecatalog/latest/adminguide/getstarted-portfolio.html
AWS Service Catalog Portfolioってやつ。これは日本語（というかカタカナ）に訳さんでええんやなかろうか。ぜんぜん頭に入ってこなかった。
なんかすんなり入ってこない問題があると一瞬、思考放棄したくなっちゃいますよね。3時間の試験で糖分足りなくなってるのでなおさら。

さらに追記

Udemyとかで似通った問題少なかったって書いたけど、この試験、2/18に改訂されてたんですね。そりゃ似てるの少いはずだわ。
なんとか受かって良かったー。メールでの合格通知とか正答率がまだ来てないのもそのせいなのかな。
いや、合格自体が間違いとかやないかと少し不安になってきた。。

結果を受信

受験から2日後の3/20に結果通知メールが届きました。スコアレポートがDLできるようになっています。

The AWS Certified DevOps Engineer - Professional (DOP-C01) の試験結果は、100 から 1000 の間の値で示されます。合格に必要な最低スコアは750です。

となっています。
これまでは70%とかのパーセンテージでスコアが示されてたと思うけど今回から変わったみたいです。
100-1000の100って何だろう。名前書いたら100点か？

そして気になるスコアは・・

　760

ちょーギリギリやん。
だいたいいつもギリギリな低空飛行。本番に強ええな。

ちなみに結果の詳細でのスコア(%)の表記はあんまりよくわからない。

分野１：22%
分野２：19%
分野３：15%
分野４：10%
分野５：18%
分野６：16%

ってなってて、分野２の構成管理およびInfrastructure as Codeだけが十分な知識を有する と評価されてた。
100%で満点やないのか？ようわからん。けどまあ良かった。

あとなんか今回から有効期限が３年になったとかいう噂。これは助かる。

試験	受験日
ソリューションアーキテクトアソシエイト	2017/12/1
SysOps Administrator アソシエイト	2017/12/25
デベロッパーアソシエイト	2018/1/9
ソリューションアーキテクト　プロフェッショナル	2018/9/28
DevOpsエンジニアプロフェッショナル	2019/3/18

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T13:41:53+09:00

俺でもわかるterraform resource aws_rds_clusterのengine早見表2019.03版

俺です。寺フォーム原人です。

寺でAuroraガンガン立ててガンガンしたいときがあります。
Aurora MySQL 5.6.10aだけがサポートされていた時代から既に数世紀経過しているようなものでございまして
今ではMySQL5.6, MySQL5.7, PostgreSQLエンジンがサポートされています。
俺みたいな猿人がどのEngineでエンジョイしたいんだっけっていう俺のために早見表をメモしておきます。

ドキュメントから抜粋するとこーゆーことらしく
engine - (Optional) The name of the database engine to be used for this DB cluster. Defaults to aurora. Valid Values: aurora, aurora-mysql, aurora-postgresql
エンジンバージョン早見表にするとこーなります

parameter value engine

engine aurora MySQL 5.6

engine aurora-mysql MySQL 5.7

engine aurora-postgresql PostgreSQL

enjoi.

parameter	value	engine
engine	aurora	MySQL 5.6
engine	aurora-mysql	MySQL 5.7
engine	aurora-postgresql	PostgreSQL

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T10:37:23+09:00

AWS CloudFormationでデプロイしたAPI Gatewayが更新されない

はじめに

ある特定のケースでデプロイの結果がAPI Gatewayに反映されない場合があり、原因はわからないが解決はできたので覚書

解決策

AWSコンソールから何も変更を加えず手動でデプロイのアクションをする

状況

CloudFormationのテンプレートにAPI GatewayのSwaggerファイルを読み込んでいる
API Gatewayのmethod.response.header.Access-Control-Allow-Origin:のみ変更しデプロイする
デプロイ完了後、確認するも設定が反映されていない

使用したテンプレートの抜粋

template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: ...
Resources:
  Api:
    Type: AWS::Serverless::Api
    Properties:
      StageName: dev
      DefinitionBody:
        Fn::Transform:
          Name: AWS::Include
          Parameters:
            Location: !Sub s3://${CfnBucketName}/${AWS::StackName}/src/api/swagger.yaml

swagger.yaml

swagger: "2.0"
info:
  version: "2018-09-04T22:25:14Z"
  title: "title"
basePath: "/dev"
schemes:
- "https"

paths:
  /token:
    options:
      consumes:
      - "application/json"
      produces:
      - "application/json"
      responses:
        200:
          description: "200 response"
          schema:
            $ref: "#/definitions/Empty"
          headers:
            Access-Control-Allow-Origin:
              type: "string"
            Access-Control-Allow-Methods:
              type: "string"
            Access-Control-Allow-Headers:
              type: "string"
      x-amazon-apigateway-integration:
        responses:
          default:
            statusCode: "200"
            responseParameters:
              method.response.header.Access-Control-Allow-Methods: "'DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT'"
              method.response.header.Access-Control-Allow-Headers: "'Content-Type,Authorization,X-Amz-Date,X-Api-Key,X-Amz-Security-Token'"
              method.response.header.Access-Control-Allow-Origin:
                Fn::Sub: "'${AllowOrigins}'"
        requestTemplates:
          application/json: "{\"statusCode\": 200}"
        passthroughBehavior: "when_no_match"
        type: "mock"

おわりに

今のところ2回同じ操作をして2回とも同じ現象になっている
リソースやメソッドの追加・削除では起きたことがないので、メソッドのプロパティの変更の場合に起きるんだろうか
気が向いたら調査するかも

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T10:37:23+09:00

CloudFormationでデプロイしたAPI Gatewayが更新されない

はじめに

ある特定のケースでデプロイの結果がAPI Gatewayに反映されない場合があり、原因はわからないが解決はできたので覚書

解決策

AWSコンソールから何も変更を加えず手動でデプロイのアクションをする

状況

CloudFormationのテンプレートにAPI GatewayのSwaggerファイルを読み込んでいる
API Gatewayの"method.response.header.Access-Control-Allow-Origin:"のみ変更しデプロイする
デプロイ完了後、確認するも設定が反映されていない

使用したテンプレートの抜粋

template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: ...
Resources:
  Api:
    Type: AWS::Serverless::Api
    Properties:
      StageName: dev
      DefinitionBody:
        Fn::Transform:
          Name: AWS::Include
          Parameters:
            Location: !Sub s3://${CfnBucketName}/${AWS::StackName}/src/api/swagger.yaml

swagger.yaml

swagger: "2.0"
info:
  version: "2018-09-04T22:25:14Z"
  title: "title"
basePath: "/dev"
schemes:
- "https"

paths:
  /token:
    options:
      consumes:
      - "application/json"
      produces:
      - "application/json"
      responses:
        200:
          description: "200 response"
          schema:
            $ref: "#/definitions/Empty"
          headers:
            Access-Control-Allow-Origin:
              type: "string"
            Access-Control-Allow-Methods:
              type: "string"
            Access-Control-Allow-Headers:
              type: "string"
      x-amazon-apigateway-integration:
        responses:
          default:
            statusCode: "200"
            responseParameters:
              method.response.header.Access-Control-Allow-Methods: "'DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT'"
              method.response.header.Access-Control-Allow-Headers: "'Content-Type,Authorization,X-Amz-Date,X-Api-Key,X-Amz-Security-Token'"
              method.response.header.Access-Control-Allow-Origin:
                Fn::Sub: "'${AllowOrigins}'"
        requestTemplates:
          application/json: "{\"statusCode\": 200}"
        passthroughBehavior: "when_no_match"
        type: "mock"

おわりに

今のところ2回同じ操作をして2回とも同じ現象になっている
APIの追加や削除では起きたことがないので、APIのサブプロパティの変更の場合に起きるんだろうか
気が向いたら調査するかも。。

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T08:04:47+09:00

AWS API Gateway + Lambda (Python�) でモックを作ってみよう

前回記事での失敗

前回記事のAWS API Gatewayでモックを作ってみようで、API Gatewayの統合タイプ：MockでAPIのモックを作ってみました。
が、統合タイプ：MockではPOSTのリクエストデータが取得できないようでした。
（参考：teratail　AWS API GatewayでHTTPリクエストのjsonを取得したい）
そのため今回は統合タイプ：Mockを使わず、統合タイプ：LAMBDAで作っていくことにします。

PythonでLambda関数を作る

Amazon Lambdaコンソールで関数の作成ボタンから関数の作成画面に遷移する

基本的な情報の関数名に任意の関数名を入力する

基本的な情報のランタイムで使用する言語を選択する（この記事ではPython 3.7を選んでいます）

基本的な情報のアクセス権限でロールを選択する（ロールの説明は省略説明できるほど詳しくないので）

画面右下の関数の作成ボタンをクリックする

関数を作成する画面に遷移するので、関数コード欄にPythonコードを打ち込んでいく

Lambdaプロキシ統合を使用しない場合

API Gatewayでの設定

統合タイプ：Lambda関数

Lambdaプロキシ統合の使用：チェックOff

Lambda関数コード
import json
def lambda_handler(event, context):
    return {
        'test_data': 123456,
        'test_message': 'Hello, World!'
    }
上記のように記述すると、ステータス 200としてreturnの内容がレスポンス本文として返されます。
ステータス 400等で返す場合は
import json

def lambda_handler(event, context):
    raise Exception('400')
というような形で例外を発生させます。
例外を発生させた場合のレスポンス本文は、API Gatewayの統合レスポンスで設定します。
API Gatewayでメソッドレスポンスに該当ステータス（この場合は400）を追加し、統合レスポンスの該当ステータスのマッピングテンプレートにレスポンス本文を入力します。

Lambdaプロキシ統合を使用する場合

API Gatewayでの設定

統合タイプ：Lambda関数

Lambdaプロキシ統合の使用：チェックOn

Lambda関数コード
import json
def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': json.dumps(
            {
                'test': 123456,
                'test_message': 'Hello, World!'
            }
        )
    }
ステータス 400等で返す場合は、statusCodeとbodyを書き換えます。
Lambdaプロキシ統合を使用している場合はAPI Gatewayの統合レスポンスでレスポンス本文を設定する必要はありません。（というかLambdaプロキシ統合を使用している場合は統合レスポンスは触れない）
Lambdaプロキシ統合を使用する場合の出力の基本は以下になります。（公式ドキュメントより）
{
  "isBase64Encoded" : "boolean",
  "statusCode": "number",
  "headers": { ... },
  "body": "JSON string"
}
複数のリソースからのリクエストを振り分ける

Lambdaプロキシ統合を使用するとAPI GatewayのリソースパスをLambda関数で受け取ることができるので、リソース毎にLambda関数を作るのではなくLambda関数を一つにまとめてみましょう。
API Gatewayのリソースパスはevent['path']で取得できます。
import json

def lambda_handler(event, context):
    path = event['path']

    if path == '/proxy200':
        return {
            'statusCode': 200,
            'body': json.dumps('Good Request!') 
        }
    elif path == '/proxy400':
        return {
            'statusCode': 400,
            'body': json.dumps('Bad Request..')
        }
（API Gatewayで/proxy200と/proxy400というというリソースを作成した場合）
このようにevent['path']の値で処理内容を分ければ、一つのLambda関数で複数のリソースに対応できます。

次回

前回と今回の内容で、API Gatewayでのモック作りがある程度出来るようになりました。
次回はSlackからAPI Gatewayモック作りを行えるようにしてみます。

プチ連載

1回目　AWS API Gatewayでモックを作ってみよう
2回目　AWS API Gateway + Lambda (Python) でモックを作ってみよう（本記事）

We're hiring!

AIチャットボットを開発しています。
ご興味ある方は Wantedlyページからお気軽にご連絡ください！

参考記事

Qiita 【API Gateway】AWS Lambda統合のPythonでHello, world
AWSドキュメント API Gateway で Lambda エラーを処理する

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T01:45:44+09:00

AWSでこれ使いますよねな用語まとめ

勤めている会社でAWSをいじって覚えるための枠が設けられる模様でちょっと用語をまとめておきます

EC2

仮想サーバを調達できるサービス
利用したいサーバのスペックに応じてインスタンスタイプを決める

AMI（Amazon Machine Image）

仮想サーバに必要な情報が入っていて、２種類ある
大きな違いは生存期間
1. インスタンスストア - インスタンスを停止or削除するとなくなる（リブートはできる）
2. EBS - 作成して削除するまで生存する（インスタンスに依存しない）

、、、こいつか！いつまで経っても自分のアカウントで料金が発生しているのは！
インスタンス停止してから２,3ヵ月くらい経つけど今月も$0.50請求が！
デタッチしてDeleteしてやっと削除しといた

インスタンスストアはインスタンスの停止でも復元できなくなるので、なくなって困るものは置けないのでキャッシュなどに向いていて、基本的にはEBSを指定します

EIP(Elastic IP Address)

固定のグローバルIPを取得してインスタンスに付与できるサービス

またしても曲者です
EIPはインスタンスでEIPを１つだけ関連づけるとか通常は基本的には料金は発生しません

しかしEIPが関連づけているインスタンスが停止していると料金がかかります
あとインスタンスに関連づいてないEIPも料金がかかります
EIPを別のインスタンスに付け替えまくっても料金がかかります

使わないときはアドレスは解放しましょうということです

Route 53

DNSサービス
DNSサーバへの問い合わせ結果をキャッシュしておくキャッシュDNSサーバの機能はないです

SLA（Service Level Agreement）１００％で、応答しない時間が発生したりすると払い戻しを受けられるそうです
まあでもその払い戻しもRoute 53にしか使えないですがね
詳しくは↓
Route 53 SLA

VPC

仮想ネットワークを作成できるサービス
まあ仮想ルータです

AWSアカウントを作成するとデフォルトのVPCが作成されます

S3

ストレージ

バケット

S3に格納されるオブジェクトのコンテナ
バケットの名前はユニークでないとダメです（ほかのユーザががすでに作成している名前はダメ）

S3にはフォルダのようなものがありますが、フォルダではない？

S3はKey-Value型データストアなので最後が/(スラッシュ)で終わるものはValueのないKeyということでサイズが0のファイル扱いとなっています
# 以下のような場合はhoge配下にfuga.txtがあるわけではなく、hoge/fuga.txtがKey名
hoge/
hoge/fuga.txt
CloudFront

CDNサービス
EC2やS3などにあるコンテンツをエッジロケーションにコピーし、そこから配信することで高速にコンテンツを提供できる

RDS

リレーショナルデータベースサービス
OSの管理やパッチ当てなどをAWS側でやってくれます

ELB

自動で拡張と縮小を行うロードバランサーサービス

CloudWatch

AWSサービスの監視やモニタリング

IAM

ユーザーとユーザー権限を管理する

端折ったのは今度かいつか深掘りします
（EBSの時点で個人的な問題が解決してしまった(-_- ;)

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T00:54:55+09:00

CodestarでLayerを作ろうとして粘ったがだめだった話

AWS CloudformationでLayerを作る際の障害

AWS Cloudformationは非常に便利なサービスである反面、痒いところに手が届かないサービスでもある。
lambda Layerは最たるもので、コードのアップロードの方法は今の所S3へのファイルアップロードしかサポートされていない。
AWS Lambda LayerVersion Content
ただ、Layerの素晴らしいところは、複数のlambdaで利用している機能の一部をモジュール化できるところだ。
これは非常に魅力的だが、予めS3にデータをアップロードしておかなければならない。

以下は、どうにかしてlayerをCloudformationで楽にできないかと悪戦苦闘してだめだった失敗談である。

悪あがき

状況

Codestarでプロジェクトを作成し、編集していた。途中でLayerが使いたくなった

所見

まず、一連のサービスについて当時は以下のように認識していた。

ymlに構造を記載する

CodeBuildで、buildspecに記載したunixコマンドを実行しているっぽい

$がついているのは変数っぽい？→変数であることを確認

ならば、他のUnixコマンドも動くかも？

echoを試してみる

変数っぽかった
逆説的に、ディレクトリの構造さえわかればS3のバケット名とキーを特定できるのでは？と考えた。
buildspec.yml
phases:
  install:
    commands:

      # Upgrade AWS CLI to the latest version
      - pip install --upgrade awscli
      - echo $S3_BUCKET
codebuild
aws-codestar-ap-northeast-1-<AccountID>-<ProjectName>-pipe
buildspecには、unixコマンドが記載されており、変数も実行できることが確認できた。また、CodeBuildのlog画面の上の方に、次のような変数を確認した。
log
CODEBUILD_SRC_DIR=codebuild/output/src780260603/src
こちらもechoで試してみると、ディレクトリが得られた。
buildspec.yml
- echo $CODEBUILD_SRC_DIR 
codebuild
codebuild/output/src780260603/src
lsコマンドを使ってみると、たしかにお目当てのファイルがあった。
-ls $S3_BUCKET
```

text: log python1_dir python2_dir module_dir

では、これをどうにかしてtemplate.yml内に反映させられればできるのではないか？と考えて１時間ほど調べた。

sedの発見（笑）

そんな中、ふとbuildspec.ymlを見ると、次のような箇所があった。
buildspec.yml
sed -i.bak 's/\$PARTITION\$/'${PARTITION}'/g;s/\$AWS_REGION\$/'${AWS_REGION}'/g;s/\$ACCOUNT_ID\$/'${ACCOUNT_ID}'/g;s/\$PROJECT_ID\$/'${PROJECT_ID}'/g' template-configuration.json
なんとなーく「文字列を置き換えているのかな？」と考えたらビンゴ。
sed コマンド
~~常識的なコマンドじゃないかって？こちとら去年Raspberry Piで初めてWidows以外のOSに触った筋金入りの初心者なんだよ。~~

早速使ってみたい。

sedを使って置換

どうもこうすれば置換できるらしい。
command
ed -i 's/<置換対象の文字列>/<置換したい文字列>/g;'
また、このままでは、$S3_BUCKETはテンプレート内でそのまま$S3_BUCKETとして置換されてしまう。そのため、シングルクオートではなく、ダブルクオートで囲む。
まくまくsed/awkノート
sed の置換パターンの中でシェルの変数を参照する
これでいけるはずだッ！！
と思うもエラーログ
text:log No such key
どうも、S3にはそんなファイルがないようだ
ここからは何度試してもだめだった。

そもそも前提条件が違った

というかそもそも、さっきから見ていたのは、決してS3のディレクトリ(キー)構造ではなく、CodeBuild内に構築されているビルド環境内のディレクトリ構造であるという視点が抜けていた。
CodeBuild の概念

実質的にLayerのようなものは作れる

色々試したがだめだった。
それでも、共通(または類似)した処理のコード変更が発生した際、いちいち全てのファイルをチェックするのは面倒くさい。

そこで、落ち着いて今考えると次のようなコマンドをbuildspecのcommに記載すれば実質Layerみたいに使えることに気がついた。
directory
cloudformation ---- python1 -- first.py
                |
                |-- python2 -- second.py
                |
                --- common_modules -- common_module.py
buildspec
#略
　- cp ./common_modules/common_module.py ./python1/
　- cp ./common_modules/common_module.py ./python2/
#略
~~要するに手段と目的が逆転していたんですね~~

感想その他

結局やりたかたことはできなかったが、目的は達成できた。
また、なんだかんだCodeBuildやCloudformationの仕様にもなれることができたので良しとする。
~~なお進捗~~

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T00:02:55+09:00

AWS FargateでBlue/Greenデプロイを行う

概要

CodeDeployを利用したFargateでのBlue/Greenデプロイメントをコンソールから実装します。

基本的な内容は下記の記事を参考にしています。記事には書かれていないECRリポジトリのイメージの更新も含めて記載し、デプロイの流れを説明しています。
AWS CodeDeploy による AWS Fargate と Amazon ECS でのBlue/Greenデプロイメントの実装 | Amazon Web Services

全体の流れ

FargateでBlue/Greenデプロイメントを実装するための前提条件と、全体の流れを把握します。

前提条件

ECRにリポジトリが作成されていること

ECRにリポジトリにlatestタグがついたDockerメージがpushされていること

ECSクラスターが作成されていること

ECRにリポジトリを作成しDockerイメージをpushする方法については、下記の記事で手順を書いていますので、よろしければご覧ください。
LaravelアプリケーションをAWS上のDockerで動かす

Blue/Greenデプロイに必要なリソースを作成

IAMロールの作成

ALBの作成

タスクの定義の作成

ECSサービスの作成

詳細は後述しますが、ECSサービスの作成の中で、Deployment typeにBlue/Green deploymentを選択することで、CodeDeployアプリケーションとデプロイメントグループが自動的に作成されます。CodeDeployを手動で作る必要がなく、とても便利です。

Blue/Greenデプロイをする

ECRのリポジトリに新しいDockerイメージをpushする

タスク定義のリビジョンを作成

新しいリビジョンのタスクの定義を使用し、ECSサービスを更新する

ECSサービスを更新した時点で、CodeDeployによるBlue/Greenデプロイが実行されます。

これより先は、具体的な手順を解説していきます。

Blue/Greenデプロイに必要なリソースを作成

IAMロールの作成

ECSサービスが更新されると、CodeDeployによってECSへのデプロイが行われます。
そのため、CodeDeployがECSへのデプロイに関する操作を行えるようにIAMロールの作成を行います。

CodeDeploy用のIAMロールを作成し、AWSCodeDeployRoleForECSLimited管理ポリシーをアタッチ

タスク実行ロールまたはタスクロール上書きに対する iam:PassRole アクセス許可を、CodeDeploy用のIAMロールにインラインポリシーとして追加

Fargateの場合、タスク実行ロールが追加されていると思いますので、2つめの手順も忘れずに実行してください。

詳細な手順については、「Amazon ECS 開発者ガイド」のAmazon ECS CodeDeploy IAM Role を参照して下さい。

ALBの作成

443/tcp、8080/tcpを受け付けるALBを作成します。
この手順ではアプリケーションの都合上443/tcpとしていますが、80/tcpでも問題ありません。

ALBの作成の中で、セキュリティグループも新規作成します。
8080/tcpを任意の場所 (0.0.0.0/0) でも使用できるように、ルールを追加します。

ルーティングの設定で、新しいターゲットグループを作成します。
名前は、Blue/Greenデプロイのためのターゲットグループであることがわかるように、stg-fargate-blueとしてます。Blue/Greenデプロイにおいて、ターゲットを切り替えるためのもう１つのターゲットグループは、ECSサービスの作成において作成するため、現時点ではターゲットグループは１つで大丈夫です。

「ステップ 5: ターゲットの登録」は、特に設定は必要ありません。確認画面で設定を確認し、ALBを作成してください。
また、必要に応じてRoute53のレコードセットの追加を行います。

タスクの定義の作成

Fargateのタスクの定義の作成方法については省略させていただきます。

ECSサービスの作成

サービスの設定

項目値

起動タイプ FARGATE

タスク定義上記で作成したタスクの定義を選択

プラットフォームのバージョン LATEST

クラスタ作成済みのクラスタを選択

サービス名任意のサービス名

タスクの数 1

サービスの設定

項目値

Deployment type Blue/green deployment (powered by AWS CodeDeploy)

Service role for CodeDeploy 上記で作成したCodeDeploy用のIAMロール選択

VPC とセキュリティグループ
VPCは、ALB作成で指定したVPC指定。
セキュリティグループは、作成済みのECSサービスのセキュリティグループを指定。

Elastic Load Balancing（オプション）

項目値

ELB タイプ Application Load Balancer

ELB 名上記で作成したALBを選択

「負荷分散用のコンテナ」をクリックして、負荷分散用のコンテナを登録します。

項目値

リスナーポート 443:HTTPS をドロップダウンリストから選択

リスナープロトコル HTTPS

Test listener チェックあり

Test listener port 8080

Test listener protocol HTTP

Additional configuration
ここでは、Blue/Greenデプロイで使用する2つのターゲットグループに関する設定を行います。
このターゲットグループをCodeDeployが切り替えることによって、Blue/Greenデプロイが可能になります。

ターゲットグループ1は、ALB作成時に作成したstg-fargate-blueを選択します。

ターゲットグループ2は、新規で作成します。名前は、stg-fargate-greenとしておきます。なお、ターゲットグループ名、ヘルスチェックパスについては環境に合わせて変更してください。

上記の設定が完了したら、ECSサービスを作成します。
この時点で、ALBを確認するとターゲットグループが作成されていることが確認できます。

CodeDeployについても確認してみると、アプリケーションとデプロイグループが作成されています。(この例だと名前が微妙ですね。)

デプロイグループのデプロイ設定を変更

デプロイグループのデフォルトの設定では、デプロイされた際に、新しくデプロイが行われた側のターゲットグループに、トラフィックが自動で流れ始めてしまいます。
今回は、動作確認をしてからターゲットグループの変更を行いたいため、トラフィックの再ルーティングするタイミングを指定します。今回は15分後に、再ルーティングされるように変更します。この設定をすることで、15分間待たなくても手動で再ルーティングすることも可能です。詳細は後述。

また、デフォルトの設定では、タスクの正常な展開後(再ルーティング後)1時間待ってから元のタスクが終了します。今回は30分後にタスクが終了するように設定を変更します。

デプロイグループを選択し、「編集」ボタンを押下することで、デプロイ設定画面が表示されます。

Blue/Greenデプロイをする

ECRのリポジトリに新しいDockerイメージをPushする

ECRのリポジトリは下記の通りとなっています。

タグ1.0.2,latestをつけたDockerイメージをECRのリポジトリにpushします。
latestが最新のイメージのみについています。古いイメージについていたlatestは自動的に剥がされています。

タスク定義のリビジョンを作成し、ECSサービスを更新する

タスクの定義の新しいリビジョンを作成し、ECSサービスを更新します。
このサービスを更新した時点で、CodeDeployによるデプロイが開始されます。

CodeDeployからデプロイのステータス、トラフィック移行の進行状況を確認できます。

タスクを確認すると、新旧のタスクのリビジョンが起動していることを確認できます。

ALBのエンドポイントの8080番ポートにアクセスし、正常に動作していることを確認します。
問題がなければ、デプロイしたターゲットグループにトラフィックを向け、リリースを実施します。

CodeDeployの「トラフィックの再ルーティング」ボタンを押下することで、デプロイしたターゲットグループにトラフィックが流れ始めます。

ALBのリスナーを確認すると、ターゲットグループが変更されていることを確認できます。
HTTPSの転送先のターゲットグループがstg-fargate-blueからstg-fargate-greenに変更されています。

旧タスクの待機時間が終了すると、旧タスクが停止されデプロイが完了します。

ロールバック機能

デプロイに問題が発生した場合は、展開を停止してロールバックすることができます。
サービスのデプロイタブに表示されている「Stop and rollback deployment」ボタンを押下することで、展開が停止されます。

まとめ

ECSでCodeDeployを使用したBlue/Greenデプロイメントを利用することで、簡単にBlue/Greenデプロイができました。CodePipelineを利用したデプロイもサポートされているので、さらにデプロイが簡単になりますね！

参考記事

参考にさせていただきました。ありがとうございます。
AWS CodeDeploy による AWS Fargate と Amazon ECS でのBlue/Greenデプロイメントの実装
 ECSでCodeDeployを使用したBlue/Green Deploymentがサポートされたので早速試してみた #reinvent ｜ DevelopersIO

項目	値
起動タイプ	FARGATE
タスク定義	上記で作成したタスクの定義を選択
プラットフォームのバージョン	LATEST
クラスタ	作成済みのクラスタを選択
サービス名	任意のサービス名
タスクの数	1

項目	値
Deployment type	Blue/green deployment (powered by AWS CodeDeploy)
Service role for CodeDeploy	上記で作成したCodeDeploy用のIAMロール選択

項目	値
ELB タイプ	Application Load Balancer
ELB 名	上記で作成したALBを選択

項目	値
リスナーポート	443:HTTPS をドロップダウンリストから選択
リスナープロトコル	HTTPS
Test listener	チェックあり
Test listener port	8080
Test listener protocol	HTTP

　 Tweet
Qiitaで続きを読む

投稿日：2019-03-18T00:00:41+09:00

AWS Direct Connectの設定ミスで$424請求された失敗談と、1つの接続を複数VPCに分ける方法（読了時間:5分）

この記事は5分で以下のことが理解できる。

　・$424請求されたミス設定。DXで絶対にやってはいけない設定とは
　・DXの経路を分割し、別のVPCへ接続する方法
　・別のVPCの契約アカウントが違う場合の対応方法、および承諾方法

この記事は以下の方に読んでもらいたい
　・Direct Connectでクラウドとオンプレを接続することとなった新AWS担当者
　・新規VPCを作成後、既存のDXの経路を有効活用し安価にセキュアな通信を実現したい方

■これを回線を分けて別のVPCに設定します

■契約アカウントA　で作業する

VPC画面の「仮想プライベートゲートウェイ」を選択

任意の名前をつけて作成

できました。IDを控えておく。

「仮想インターフェイスの作成」を選択する

仮想インターフェースを作成する

仮想インターフェースが作成できました。が、

別アカウントB （接続するVPCアカウント番号の管理者）に承諾されるまで使用できない。

別アカウントBで作業する

接続するアカウント（別アカウントB）番号にログインし、Direct Connectの画面を開く。

「仮想インターフェースの承諾」を選択する。

承諾する

作成した仮想インターフェースをVPCにアタッチする



しかし、このままではオンプレのルーター設定に必要な「BGP認証キー」番号が閲覧できない。

契約アカウントA　のDirect Connect契約管理者のみ
BGP認証キーを閲覧できます。

インターフェースdownはオンプレ側のルータを設定することでavailableになります。

■手順化しませんが、オンプレのルーター、接続先VPCのルートテーブル、セキュリティグループ、ネットワークACLを設定すること

　オンプレのルーター設定はちょっとしたコツで実現可能なので、
　リクエストが多ければ記事化しようと思います。
　「いいね」30くらいを目安としたいです…

■AWS Direct Connectで設定ミスって$424請求された失敗談

なお、Direct Connectの料金体系は
大きく2つに別れています。
　・接続の時間課金
　・転送量の従量課金

請求ページの「転送量の従量課金」表記　（通常）
　\$0.041 per GB - AWS Direct Connect to AWS Private Cloud data transfer Outbound per GB Asia Pacific (Tokyo)100.00 GB $4.10

請求ページの「接続の時間課金」表記　（通常）
　\$0.285 per connected 1G port-hour (or partial hour) (Asia Pacific, Tokyo in Equinix TY2)744 hours$212.04

■間違って「接続」をVPC分作成し、無駄な$424の料金が発生した例

請求ページの「接続の時間課金」表記　（なにかおかしい）
　\$0.285 per connected 1G port-hour (or partial hour) (Asia Pacific, Tokyo in Equinix TY2)2,232 hours$636.12

…1ヶ月が31日だとして、744時間しかないのに、
なぜ2232時間も課金されているのだろうか…

もし1つの契約にも関わらず744時間以上の課金をされていたなら、
接続が謝って複数作成されていないか確認した方が良いだろう。

■謝って不要な「接続」を作成した場合のイメージ図

Direct Connectの画面の「接続」を確認し、
不要に接続を作成していないか確認することをお勧めする。

ベストプラクティスにもあるが、サブ回線には安価なVPNを使用するというのは有名な話だ。
次回はVPNについても設定手順を記載していこうと思う。

ありがとうございました。
少しでもお役にたちましたら「いいね」をよろしくお願いします。