- 1. Golangはじめて物語(第3話: CodePipeline+SAM+LambdaでCI/CD編)
- 2. Jamstack構成メディアのプレビュー機能を、サーバレスAPIを使って実装した
- 3. LambdaとDjangoの相性ってどうなの??
- 4. Gitのサブモジュール機能とTerraformのモジュール機能で実現するCI/CDパイプラインの量産(Lambda編)
- 5. PythonではじめるAWS CDK
- 6. API GatewayでLambdaのエラーハンドリング
- 7. ESP32をAlexa Gadgets Toolkitデバイスにしよう: Alexa Gadgetデバイス→カスタムスキルへの通知
- 8. AWS SESとLambdaで個人ドメインメールをGmailに転送
- 9. Slack APIとAWS (API Gateway + Lambda) でBotを作成してみた
- 10. ESP32をAlexa Gadgets Toolkitデバイスにしよう:カスタムスキル→Alexa Gadgetデバイスへの通知
- 11. serverless framework (AWS) のプラグインについて
- 12. AWS Lambdaで、CloudWatchのイベントログを取得する
- 13. CodePiplineでLambda関数デプロイ自動化
- 14. Schemeのnamed-letのサンプル
- 15. API gateway + lambda + S3でDDoS攻撃を受けて1日あたりで$3000溶かした話
- 16. ローカル環境でLambda開発を進める際の私的ベストプラクティス
- 17. node_modulesをLambdaレイヤーにアップロードしてライブラリを使用する
- 18. AWSハンズオン実践メモ 〜AWS SAM を使ってテンプレートからサーバーレスな環境を構築する〜
- 19. Slack AppHomeでAWS環境構築モーダル作ってみた
- 20. QuarkusでAWS Lambdaを作る
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
AWS Lambdaで、CloudWatchのイベントログを取得する
#イベントログを取得する方法
①AWS SDK
②AWS CLI#AWS SDKの使い方
###pythonのSDK
「AWS SDK for Python (Boto3)」です。
https://aws.amazon.com/jp/sdk-for-python/###どんな関数があるか
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/index.html###何を使えばイベントログが取れるか
####①filter_log_events
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/logs.html#CloudWatchLogs.Client.filter_log_events
・startTime/endTimeで日時の範囲を指定してデータ抽出が可能。ただし、指定する値がUNIXタイムの”””ミリ秒”””
→私は、UNIXタイムでしょ?秒でしょ?と思いこんでいて長
CodePiplineでLambda関数デプロイ自動化
##1.Lambda関数と設定ファイルをCodeCommitへpush
###①lambda_function.py“`python
import jsondef lambda_handler(event, context):
# TODO implement
return {
‘body’: json.dumps(‘Hello World!’)
}
“`
###②buildspec.yml
“`python
version: 0.2phases:
pre_build:
commands:
– echo Nothing to do in the pre_build phase…
build:
commands:
– export BUCKET=cloudform1
– aws cloudformation package –template-file template.yml –s3-bucket $BUCKET –output-template-file o
Schemeのnamed-letのサンプル
Schemeのnamed-letの記述例.いつものように[Gauche](https://www.jdoodle.com/execute-scheme-online/)で実行確認.
“`scheme:named-let.scm
gosh> (define (sum x y l) ; named-letを使用しない.
(cond ((> x y) (reverse l))
(else
(sum (+ x 1) y (cons x l)))))
sum
gosh> (sum 3 11 ‘())
(3 4 5 6 7 8 9 10 11)
gosh> (define (sum x y l)
(let loop ((x x) (l l)) ; named-letを使用する.
(cond ((> x y) (reverse l))
(else
(loop (+ x 1) (cons x l))))))
sum
go
API gateway + lambda + S3でDDoS攻撃を受けて1日あたりで$3000溶かした話
qiita夏祭りに乗り遅れてしまったので一人後夜祭
~2019年某日~
パイセン「それじゃあ、ワイ君は明日からフロントのログデータを飛ばすのにAPI gatewayとlambdaでS3に保存するようにしてな。木曜までな。その間に自分はサービンのドメイン取ったりRoute53周りの構築するから」
![sls.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/614012/4205ec23-503f-4d39-d1ac-9c5693fade21.png)ワイ「これもcloud formationに書くんです?」
パイセン「serverless frameworkっていう基本的な設定はデフォルトで構築してくれる便利なものがあるんやで。これ使い」
ワイ「めっちゃ素敵やん。わかったやで」パイセン「週初めのMTGは終わりや飯食いに行こう。上野に新しい醤油ラーメン屋ができたんや」
ワイ「いいですね〜」
パイセン「それじゃ自分は新しいロードバイク持ってきたからワイ君も付いてきてな!」
ワイ「ワイ無手なんやが?え
ローカル環境でLambda開発を進める際の私的ベストプラクティス
# TL;DR
– AWSマネジメントコンソール上ではLambdaのコードを編集しない
– コードは全てバージョン管理が有効になったローカルIDE上で開発し、docker-lambdaを利用して迅速にテストできるようにする# ローカルでLambdaを開発するフローを考える
## 最も単純なLambdaの開発プロセス
– AWSマネジメントコンソールを利用した最も単純なLambda開発のフローを整理すると、以下のフローになります1. ローカルでコードを書く
1. AWSマネジメントコンソールにログイン
1. 関数を新規作成、ローカルで編集したコードをブラウザ上のエディタにコピー&ペースト
1. 関数の実行テスト
1. 失敗した場合は原因を特定してローカルのコードを再編集(ここで直接ブラウザ上のエディタを編集したくなるが、ローカルのコードと同期が取れなくなってしまう)
1. 修正したコードををブラウザ上のエディタにコピー&ペースト
1. 成功するまで4〜6を繰り返す必要がある(!)。手作業でコピペするのは辛く、イケてない。– Lambda上で動作することが保証されているコードを
node_modulesをLambdaレイヤーにアップロードしてライブラリを使用する
# 経緯
– 同じライブラリを使用しているLambda関数が増えた
– コンソール画面からコードを編集できるようにしたい
– 上記の理由から、layerに共通ライブラリを登録し、それを読み込ませることでLambda関数を軽量化する# 環境
– ローカルOSはWindows10(Macでもで順は同様)
– LambdaはNode.jsを使用# node_modules準備
– 『nodejs』という名前のフォルダを作成する
※名前がめちゃくちゃ大事です。layerはnodejs/node_modulesのフォルダ構成じゃないと読み込んでくれません(正確に言えばopt直下に生成されるのでopyt/nodejs/node_modulesとなりますが気にしなくて良いです)
① 新規で準備する場合
→作ったフォルダ直下にnode_modulesを作成
“`
npm install 必要なライブラリ名
“`② すでにnode_modulesフォルダが有る場合
→node_modulesフォルダを先程作ったnodejsフ
AWSハンズオン実践メモ 〜AWS SAM を使ってテンプレートからサーバーレスな環境を構築する〜
# はじめに
前回、AWS公式の[ハンズオンシリーズ](https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/?trk=aws_blog)の中から、翻訳 Web API の構築を通して、サーバーレスアーキテクチャの基本を学ぶ[ハンズオン](https://pages.awscloud.com/event_JAPAN_Hands-on-for-Beginners-Serverless-2019_LP.html?trk=aws_introduction_page)を実施しました。
**参考**:[AWSハンズオン実践メモ 〜サーバーレスアーキテクチャで翻訳 Web API を構築する〜](https://qiita.com/kuwadev/items/52133e5a6cec9358ca3c)今回は、前回のハンズオンで構築した翻訳 Web API を**AWS Serverless Application Model (AWS SAM)を用いてテンプレートから構築**します。
AWS Serverl
Slack AppHomeでAWS環境構築モーダル作ってみた
[Slack AppHome](https://api.slack.com/lang/ja-jp/app-home-with-modal)は、アプリホーム画面を作れて便利ですね。
今回はAWS環境を構築する機能を作ってみました。
実装時のポイントなど書いていきます!これからAppHome使う方の参考になれば幸いです!## なぜ作ったのか
私の現場ではEC2を使って複数のプロジェクト環境を作ることがあります。ただ、今まではAWSコンソールからEC2/CloudWatchなどを設定する運用になってました。
環境構築手順は、CloudFormationでテンプレート化できますが、それでもAWSコンソールログインなど手間ですね。そこで、みんな慣れているSlackから環境作れるようにしました。## 完成イメージ
![aws-bot(CreateEC2).gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/174816/4972a33e-c860-5875-60a2-2881d1b7f3ee.gif)AppH
QuarkusでAWS Lambdaを作る
Quarkus(https://quarkus.io/) とは`SUPERSONIC SUBATOMIC JAVA`で、
> A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.
だそうです。
何言ってるかわかりませんがすごそうです。GraalVMの機能でJavaのプログラムをネイティブに変換することが可能なので、AWS Lambdaのカスタムランタイムと組み合わせることで AWS Lambda上で動作するJavaアプリケーションの特性である **コールドスタートが遅い問題** の解決に期待ができます。
公式サイトの手順に従い試してみましたので、手順を残します。
QUARKUS – BUILDING A NATIVE EXECUTABLE
https://quarkus.io/guides/building-native-imageQUARKUS – AMAZ