- 1. AWSを利用した会員サイトをサーバーレスで実装しました
- 2. SwaggerでLambdaのデバッグ環境を作る(7):AWS S3トリガをデバッグする
- 3. Slack から KING OF TIME に打刻する社内ツールで Rust 入門しました
- 4. AWSハンズオン実践メモ 〜AWS Lambda と AWS AI Services を組み合わせて作る音声文字起こし & 感情分析パイプライン〜
- 5. 基本的なREST-APIをAWSのAPI GatewayとLambdaとDynamoDBで作るための参考サイトまとめ
- 6. Lambda+SAMテンプレートのBlue/Greenデプロイメントで「デプロイの再試行」した際の動作を検証する
- 7. Python + Selenium Chromedirverとserverless-chromeの相性問題
- 8. [Next.js/Vercel]LambdaとDynamoDBでJamstackなアプリを作ってみた
- 9. serverlessを使ってLambdaにmultipart/form-dataでバイナリデータをアップロードする
- 10. Golangはじめて物語(第3話: CodePipeline+SAM+LambdaでCI/CD編)
- 11. Jamstack構成メディアのプレビュー機能を、サーバレスAPIを使って実装した
- 12. LambdaとDjangoの相性ってどうなの??
- 13. Gitのサブモジュール機能とTerraformのモジュール機能で実現するCI/CDパイプラインの量産(Lambda編)
- 14. PythonではじめるAWS CDK
- 15. API GatewayでLambdaのエラーハンドリング
- 16. ESP32をAlexa Gadgets Toolkitデバイスにしよう: Alexa Gadgetデバイス→カスタムスキルへの通知
- 17. AWS SESとLambdaで個人ドメインメールをGmailに転送
- 18. Slack APIとAWS (API Gateway + Lambda) でBotを作成してみた
- 19. ESP32をAlexa Gadgets Toolkitデバイスにしよう:カスタムスキル→Alexa Gadgetデバイスへの通知
- 20. serverless framework (AWS) のプラグインについて
AWSを利用した会員サイトをサーバーレスで実装しました
AWSを利用した会員サイトをサーバーレスで実装しました。
始めはCognitoとS3でなんとかなるだろうと思っていましたが、
いざやってみるとどうにも思い通りにならず、四苦八苦しました。調べてみると、どうやらCognitoとS3だけでは、S3に対して**ユーザー単位のコンテンツ**にしかアクセスできず、**ユーザー共有のコンテンツ**にはアクセスできないみたいです。(私の調査不足/理解不足かもしれませんが…)
というわけで、以下のAWSの機能を利用して実装してみました。
* S3
* CloudFront
* Cognito
* API Gateway
* Lambda## 処理手順
1. S3に公開フォルダと会員限定フォルダを作成する。
1. S3に対してはCloudFrontを通してアクセスする。
1. S3の会員限定フォルダへは、**CloudFrontの閲覧者のアクセスを制限する機能**のCookieを使用する。
1. Cognitoで認証が成功した場合、認証情報のJWTトークンをAPI Gatewayのオーソライザーで検証する。
1. API Gatewayの
SwaggerでLambdaのデバッグ環境を作る(7):AWS S3トリガをデバッグする
久しぶりの、SwaggerでLambdaのデバッグ環境を作る の拡張です。
第一回の投稿はこちらから:[SwaggerでLambdaのデバッグ環境を作る(1)](https://qiita.com/poruruba/items/e3a46787c79517a815f9)AWS S3にファイルがアップロードされたときにLambdaを起動するスクリプトを書こうと思っても、Lambda上でのデバッグは大変なので、ローカルでデバッグ(実行中のブレイクを入れたり、変数を参照したり)できるようにします。
S3は、本物ではなく、S3互換のMinIOを使います。
今回のローカルデバッグ環境は以下のGitHubに反映済みです。
poruruba/swagger_template
https://github.com/poruruba/swagger_template#MinIOのセットアップ
ほぼこちらに書いてある通りに進めます。
MinIO Quickstart Guide
https://docs.min.io/今回は、Distributed MinIO Quicksta
Slack から KING OF TIME に打刻する社内ツールで Rust 入門しました
とりあえず [The Book](https://doc.rust-lang.org/book/) やってたんですが、座学続けられないタイプなもので 12 章あたりで疲れてしまったので、
もう書いてみるかということで、もともと TypeScript で書いて AWS Lambda で動かしている Slack [Slash Commands](https://api.slack.com/interactivity/slash-commands) で会社の勤怠管理システム [KING OF TIME](https://www.kingtime.jp/) に打刻するプログラムをリプレースしてみました。## インストールしておくもの
– [Rust](https://www.rust-lang.org/)
– [musl-cross](https://github.com/FiloSottile/homebrew-musl-cross)
– [AWS CLI](https://aws.amazon.com/jp/cli/)## とりあえず AWS のドキュメントを参考に Lambda
AWSハンズオン実践メモ 〜AWS Lambda と AWS AI Services を組み合わせて作る音声文字起こし & 感情分析パイプライン〜
# はじめに
AWS公式の[ハンズオンシリーズ](https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/?trk=aws_blog)の中から、AWS Lambda と AWS の各種 AI サービスを組み合わせて、**“音声ファイルがアップロードされると文字起こしと感情分析を自動的に行う”** パイプラインを構築する[ハンズオン](https://pages.awscloud.com/event_JAPAN_Ondemand_Hands-on-for-Beginners-Serverless-3_LP.html?trk=aws_introduction_page)を実施しました。
本記事は自身のハンズオン学習メモとして投稿します。
# 目次
– [ハンズオンの目的](#ハンズオンの目的)
– [本編](#本編)
– [おわりに](#おわりに)# ハンズオンの目的
– 音声の文字起こし、およびその感情分析を行うパイプラインをサーバーレスアーキテクチャで構築する
– S3トリガーでLambdaを
基本的なREST-APIをAWSのAPI GatewayとLambdaとDynamoDBで作るための参考サイトまとめ
ゼロからAWSでREST-APIを一気通貫で実装してみましたが、それなりの苦労があったため、次はもっと効率よく作りたいので、参考サイトをまとめておきたいと思います。
# やってみたこと
超シンプルなREST-APIを作ってみました。シンプルですがいろいろ知る必要がありました。+ 一覧は、GETでパスパラメータがあり、パーテーションキーだけ渡す、レスポンスはJSONでBODYが配列
+ 追加は、POSTでパスパラメータがあり、パーテーションキーだけ渡す、リクエスト本文はJSON、レスポンスもJSONでBODYが1件、ソートキーが採番される
+ 更新は、PATCHでパスパラメータがある、パーテーションキー、ソートキーを渡す、リクエスト本文はJSON、レスポンスもJSONでBODYが1件
+ 検索は、GETでパスパラメータがある、パーテーションキー、ソートキーを渡す、リクエスト本文はなし、レスポンスはJSONでBODYが1件
+ 削除は、DELETEでパスパラメータがある、パーテーションキー、ソートキーを渡す、リクエスト本文はなし、レスポンスはJSONでBODYが0件# 参考サイ
Lambda+SAMテンプレートのBlue/Greenデプロイメントで「デプロイの再試行」した際の動作を検証する
# はじめに
デプロイ運用は、Blue/Greenでシームレスにサービス移行できるのも重要だが、デプロイに失敗した際のロールバックと再デプロイをスムースに行えることも重要だ。Canaryなデプロイにおける自動ロールバックについては、[過去の記事](https://qiita.com/neruneruo/items/2e7bf289f375ccc91356)で調査を行ったので、今回は手動ロールバックと再デプロイについての動作検証を行う。
なお、最初に断っておくと、この方法は結果的に期待した動作になっているが、途中でエラーが出たりして怪しさ満点である。もう少しちゃんとした検証が必要かもしれない。
# 前提条件
– Lambda+SAMテンプレートでの基本的な動作の仕様を理解している([過去の記事](https://qiita.com/neruneruo/items/73906cdc3c2aa699644f)で紹介済み)
– デプロイは以下の仕様とする
– Prodのエイリアスを使用してCanaryの向き先を制御する(SAMテンプレートで“`AutoPublishAlias: P
Python + Selenium Chromedirverとserverless-chromeの相性問題
# 環境
AWS SAM + Python 3.7
AWS LambdaのAmazon Linuxコンテナ上で動作。# 動作を確認できた組み合わせ
“`
serverless-chrome 1.0.0.37 + Chromedriver 2.37 + Selenium 3.141.0
“``chrome_options` ではなく `oputions` にセット。
“`python:
from selenium import webdriver
from datetime import datetimeCHROME_DRIVER_PATH = “/opt/python/bin/chromedriver”
HEADLESS_CHROMIUM_PATH = “/opt/python/bin/headless-chromium”def lambda_handler(event, context):
options = webdriver.ChromeOptions()
options.binary_location = HEADLESS_CHROMIU
[Next.js/Vercel]LambdaとDynamoDBでJamstackなアプリを作ってみた
## 概要
– 以前にQiitaの前日のいいね数を通知してくれるLINE Botを作りました
– [Qiitaのいいね数を通知してくれるLINE Botを作ってみた](https://qiita.com/ozaki25/items/03b834de8c0c175d955d)
– この延長でいいね数の推移をグラフで表示するWebページを作ってみたというのが今回の内容です
– せっかくなので技術検証も兼ねてJamstackな構成で作ってみました
– 前述の記事の通りデータはDynamoDBにデータを蓄積しているのでHeadlessCMSなどは使わずにチャレンジしてみます## 作ったもの
– 直近1週間のいいね数をグラフで表示するWebアプリをLIFFアプリとして表示しています
![Screenshot_20200726-014511.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/175213/a656b608-38c1-afa4-52ac-1428c92e63a8.png)
serverlessを使ってLambdaにmultipart/form-dataでバイナリデータをアップロードする
serverlessを使ってLambdaをデプロイする際、Lambda統合の時にバイナリデータをどうやって送るのか地味にハマったのでメモとして残しておきます。
(たぶんうちの若い子達がココ見るはず..)serverless便利ですね。コマンド一発でデプロイから各種AWSリソースをいい感じにセットアップしてくれます。いらなくなったら同じくコマンド一発でまるっと削除してくれます。これを使わない手はないですね。
## TL;DR
– serverless.ymlのcustomキー配下にapiBinaryでバイナリメディアタイプを指定する
– serverless.ymlのpluginsキー配下にserverless-apigw-binaryを追加する
– Lambdaに送られてくるリクエストはbase64エンコードされたmultipart/form-dataなのでデコードしてaws-lambda-multipart-parserでマルチパートデータをバイナリにする“`serverless.yml
custom:
…省略
apigwBinary:
types:
Golangはじめて物語(第3話: CodePipeline+SAM+LambdaでCI/CD編)
# はじめに
[前回](https://qiita.com/neruneruo/items/fe292262836ac068e2ea)というか[第一話](https://qiita.com/neruneruo/items/1ef52f908e4497103a59)の続編。
第一話ではServerless Frameworkを使ったが、今回はCodePipelineを使って自動起動するパイプラインを使ってみようと思う。となると、セオリー(だと思ってるの)はSAMをCloudFormationで起動するパターンだろう。golangのアプリケーションそのものの話は薄めというか、ほぼ入っていないのであしからず。
# 前提条件
・golangのアプリケーションは[第一話](https://qiita.com/neruneruo/items/1ef52f908e4497103a59)のものをほぼ流用するので、読んでいる前提
・[別の記事](https://qiita.com/neruneruo/items/e2e4fd70c90e2dbdc67f)で書いたTerraformのサブモジュールを
Jamstack構成メディアのプレビュー機能を、サーバレスAPIを使って実装した
社内で運用するオウンドメディア開発にあたり、Jamstack構成でのプレビュー機能の開発で得た知見などをまとめておきます。構成はNext.js + Contentfulで、ホスティングサービスはAmplify Consoleを使っていますが、上記スタックに特有の機能を使ったとかではないので、他の構成でも使えるかと思います。
## 最初にざっくりまとめ
– プレビューデータを取得するためのAPIをサーバレス構成で作成した
– APIはAPI Gateway + Lambdaで作成し、リソース構築にはServerless Frameworkを利用した
– APIの認可処理にはCognitoを利用した## Jamstackでのプレビュー機能の設計検討
ブログやオウンドメディアをJamstack構成で構築する際、基本的に各ページは事前ビルドしておき静的ページとして配信するSSGをベースに開発することになると思います。
ただ、執筆中の記事を確認する機能であるプレビュー機能については、SSGでは不可能ではないもののいまいち使い勝手が悪いものになりがちです。プレビューを確認するたびにアプ
LambdaとDjangoの相性ってどうなの??
# 忙しい人へ
結論とまとめを最初にのせときます## 結論
Djangoのようなフルスタックフレームワークではあまり良いとは言えない
フルスタックフレームワーク使うならECSを使った方が良いらしい## まとめ
> Lambdaのコールドスタートで時間かかるのでは?結構かかります
> DjangoのプロジェクトをLambdaにアップロードしたら、Lambdaのアップロードサイズ制限に引っかかるのでは?
かかる可能性はあります
ただよほど入れなければ大丈夫なはず> REST APIを作る時に、DjangoのルーティングとAPI Gatewayの組み合わせって相性悪くね?
実害はないと思うけど悪いと思います
> Django使うってことはサーバーレスなのにサーバー立ち上げるってこと?
その通りです
# 前置き
この記事はあくまでも私見です
これが絶対正しいということではないのでご了承ください# 前提
zappaというデプロイツールを用いての検証# 本題
LambdaとDjangoの組み合わせにした時の疑問点がいくつかあった
その疑問点をひとつづ
Gitのサブモジュール機能とTerraformのモジュール機能で実現するCI/CDパイプラインの量産(Lambda編)
# はじめに
Terraformのモジュール機能は最初はありがたみを感じられなかったので使わなかったものの、CI/CDパイプラインをいろいろと量産するようになってくると、いちいち過去のtfファイルを流用しようとして「どれが最新だったっけ……」と悩むようになったので、そろそろリポジトリ管理をするべきなのでは、と考えていた。そんな折、Gitのサブモジュール機能を知って「これってもしかして組み合わせれば「おれの考えた最強量産型CI/CDパイプラインができるのでは?」と思い、作ってみた。
# 全体構成
今回は以下のような構成だ。“`メインモジュール
terraform-mainmodule-lambdapipeline
├── .gitmodules
├── main.tf
└── modules
├── 01_variables.tf
├── 02_iam.tf
├── 03_s3.tf
├── 04_cloudwatchlogs.tf
├── 05_codepipeline.tf
└── 06_cloudformation_par
PythonではじめるAWS CDK
# Pythonで始めるAWS CDK
最近までいろいろと触る機会があったのと、AWS CDK+Pythonの記事が少なかったので書いてみた。
内容はAWS CDKのインストール〜デプロイまで。ついでにLambda関係でよく使いそうなところをいくつか。## 実行環境
* Python 3.7.4
* OSX Catalina 10.15.5Python、Pipが実行可能な環境であることが前提で書いています。
## はじめに
### AWS CDKってなに?
[AWS クラウド開発キット](https://aws.amazon.com/jp/cdk/)より
> AWS クラウド開発キット (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。
かなり大雑把にまとめると、使い慣れたプログラミング言語でAWSのリソースを定義、作成できるIaC(Infrastructure as Code)ツールですよっと。
### なんでAWS CDK
API GatewayでLambdaのエラーハンドリング
題材とするアーキテクチャ
Lambda (2) → API Gateway → Lambda (1)
# API Gatewayの返り値を整形する。
エラー時に400/500台のステータスコードを付してDescriptionをつけて返したい。
__1 Exceptionクラスを継承して拡張した例外クラスを作る。__
__2 エラー時にraiseする。__“`python:Lambda1
import json
import boto3
import logging
import tracebacklogger = logging.getLogger()
logger.setLevel(logging.INFO)dynamodb = boto3.resource(‘dynamodb’)
# 例外クラスを拡張
class ExtendException(Exception):
def __init__(self, statusCode, description):
self.statusCode = statusCode
se
ESP32をAlexa Gadgets Toolkitデバイスにしよう: Alexa Gadgetデバイス→カスタムスキルへの通知
今回は、[ESP32をAlexa Gadgets Toolkitデバイスにしよう](https://qiita.com/poruruba/items/e4559e18cb90cd0a3b81) の続きで、カスタムインタフェースのうちのAlexa Gadgetデバイスからカスタムスキルに通知をしてみます。(一応シリーズ最後の投稿です)
以下の図のイベントのところです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/261826/1de77295-cb43-e836-6f7f-42f8ecbf0bce.png)
#プロトコルバッファの定義
Alexa Gadgetデバイスからのイベントは、プロトコルバッファにエンコードして送信する必要があるため、protoファイルで宣言して、エンコーダを作成する必要があります。
以前、protoファイルからエンコーダを作った環境(compile_nanos.batなど)を流用しましょう。
“`C:\XXXXX\Alexa-Gadgets-Embe
AWS SESとLambdaで個人ドメインメールをGmailに転送
> 英語版はMediumで作成しました:[Forwarding Personal Domain Emails to Gmail with AWS Lambda and CloudFormation](https://medium.com/@yjzhang.me/forwarding-personal-domain-emails-to-gmail-with-aws-lambda-and-cloudformation-4a7208af4eb8)。日本語に自信がないので、ほぼGoogle Translateで作成しています。
**サマリー**:個人DomainのEmailを無料で信頼性の高いソリューションを構築するために、AWS無料利用枠サービス(SES、Lambda、S3)を使用してMIMEメールをアーカイブし、Gmailに転送します。他のソリューション:
* AWSブログ:[受信メールを外部の宛先に転送する](https://aws.amazon.com/blogs/messaging-and-targeting/forward-incoming-email-to-an-extern
Slack APIとAWS (API Gateway + Lambda) でBotを作成してみた
# はじめに
Slack-botを本格的に作りたい!ということで触ってみた。
作成するBotは、メンションに付与する単語に応じて3パターンの応答を返す、とても簡単なBotです。> ※これくらいの機能ならSlack標準のBotで充分実装できますが、
> 今後の拡張に向けた「穴通し」の位置づけとして、作成しています。以下の記事を大変参考にさせて頂きました。図が豊富で分かりやすい。
# できたもの
![slackbot.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384185/b875cffd-de63-c2dc-5a46-e67d90c41da4.gif)3パターンのBotです。
1. 基本は、このbotを読んだユーザ名を返してくる。
2. trelloと打つと、自分のTrelloダッシュボードのリンクが返す
3. :+1:(いいねスタンプ)を打つと、花京院さん大好きな「
ESP32をAlexa Gadgets Toolkitデバイスにしよう:カスタムスキル→Alexa Gadgetデバイスへの通知
今回は、[ESP32をAlexa Gadgets Toolkitデバイスにしよう]( https://qiita.com/poruruba/items/e4559e18cb90cd0a3b81) に続いて、カスタムインタフェースに対応させます。
カスタムインタフェースは、AlexaのスキルからAlexa Gadgetsデバイスに指示を出したり、Alexa Gadgetsからスキルにイベントを伝達できたりするためのものです。
今回は、Echoデバイスへの発話を契機に、Alexa Gadgetデバイスに文字列付きで通知します。また、Alexa GadgetデバイスのM5StickCについているボタンの押下を契機に、メッセージ付きでAlexaスキルに通知します。
と言いながら、体力が尽きたので、とりあえず、前者です。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/261826/afa7d1c1-b553-6324-7c5a-e279139de42f.png)
以下に記載されている通りに
serverless framework (AWS) のプラグインについて
最近 AWS Lambda を開発・デプロイするにあたり、serverless framework を使っているのですが、多くのnpmプラグインがあります。
今回は今まで利用したプラグインを備忘録としてまとめておきます。
## serverless-domain-manager
API Gatewayのカスタムドメインを作ることができます
[amplify-education/serverless-domain-manager: Serverless plugin for managing custom domains with API Gateways.](https://github.com/amplify-education/serverless-domain-manager)
### 設定例
下記で、ACMによる証明書の発行、Route53へのレコード登録、カスタムドメイン設定の追加を行えます。
“`yaml:serverless.yml
custom:
defaultStage: dev
customDomain:
domainName: ho