Lambda関連のことを調べてみた2020年01月22日

ElixirでAWS LambdaでGithubActionsで継続デプロイ

# はじめに

「Elixirで簡単にAWS Lambdaの開発ができるようになれば、もっとElixirが流行るのでは？」

そんな想いから、Elixirで実装されたAWS Lambdaの関数をGithubにプッシュすると、Github Actionsが自動でビルドしAWSにデプロイしてくれる仕組みを試してみました。

# ElixirでAWS Lambda

AWSの公式としてElixir用のAWS Lambdaランタイムは用意されていないので、ElixirでAWS Lambdaを動かすためには、Elixirで実装したコードを動かすためのカスタムのAWS Lambdaランタイムを用意する必要があります。

また、Elixirでは`mix release`でElixirやErlang不要で実行可能なパッケージを作成することができるのですが、このパッケージを実行するためには、パッケージを実行する環境で作成する必要があり、AWS Lambdaの場合は、Amazon Linuxの環境でビルドする必要があります。

つまり、ElixirでAWS Lambdaを動かす場合、Amazon Linu

【AWS】API GateWay + LambdaでSlakcアプリケーションの認証を行う方法

SlackのEventをAPI GateWayで処理し、Lambdaを起動しています。
APIのアドレスが漏れた場合、攻撃を受ける可能性が有る為、API GateWayで何かしらの対策ができないかと思い記事を書こうと思いました。

# Slackの認証方法について
以下の2種類があります。

– リクエストのBody内の文字列を利用した認証
– Signing Secretを用いた認証

# リクエストのBody内の文字列を利用した認証

## SlackのEvent APIについて
Eventが発生すると、下記のようなJSONが発行されます。

“`json:Slackのイベント
{
“token”: “XXYYZZ”,
“team_id”: “TXXXXXXXX”,
“api_app_id”: “AXXXXXXXXX”,
“event”: {
“type”: “name_of_event”,
“event_ts”: “1234567890.123456”

AuroraServerlessを操作するAPI(GET、PUT、POST)+lambdaを作る。

# 作るもの


今回、DBに入れるデータは以下のものとして進める。

|id|name|age|
|:—:|:—:|:—:|
|1|Apigateway|12|
|2|lambda|34|
|3|Dynamodb|56|

_contents_

* Aurora serverless、シークレットマネージャとは
* Aurora serverlessのDBの作り方。
* lambdaからAurora serverlessへアクセスする方法。
* APIでGET、PUT、POSTする方法

## Aurora serverlessとは？

DBのインスタンス部分とストレージ部分が分離した構造を取っており、アクセスがない時にはインスタンス部分は起動しておらず、ストレージ部分のみが存在する。アクセスを受けると、負荷に応じてインスタンスが

codecommitのPullRequestをredmineのチケットに連携する

概要
—
[これのシリーズもの](https://qiita.com/turbo5522mame/items/d5a7e126f993eb185d29)
codecommitでpullrequestしたときに、関連するredmineのチケットのコメントに通知を出したくてごにょごにょした記録。
手順にはなってませんが、ヒントにはなるかな、と。
こんな感じで。

やりたい構成図
—
ざっくりこんなかんじ

やったこと概要
—
### 前提
codecommitでブランチを切るときに必ずred

Elastic Beanstalkのインスタンスやボリュームのタグをデプロイ時に更新

#なぜ
* .ebextensionsで環境プロパティからインスタンスやボリュームにカスタムタグを追加している。管理ルールが変わりタグ更新が必要になったため、何気なく更新したらデプロイに失敗した。目的の環境プロパティをタグ以外の処で参照していた。
* シンプルに.ebextensionsを修正する何のことでもないことだが、保守担当に説明すると承認が必要のこと。これは時間がかかりそうだ。

#遠回り
改善策でサーバ構成もプログラムも遠回りしてはいけない。根本原因をつぶすのがベストだ。しかし、
承認とリリースまで1~2ヵ月はかかりそうなことと、以前からLambdaのイベントトリガーを試してみたかったことがあり今回は遠回りをする。


## Lambda
* LambdaのRoleは事前登録しておく

“`python:Python3.8
imp

codecommitとredmineを連携させる

概要
—
世の中的にgit→redmineはやり方整ってるけど、codecommit→redmineは無いのでごにょごにょした記録。
手順にはなってませんが、ヒントにはなるかな、と。

[※こっちはPullRequestの連携](https://qiita.com/turbo5522mame/items/48f1fdcd95a7fd4409f4)

やりたい構成図
—
ざっくりこんなかんじ

やったこと概要
—
### redmine側の設定
– redmineにgit連携のプラグイン[github_hook](https://github.com/koppen/redmine_github_hook)を入れる
– redmineのサーバにcodecommit上のリポジトリのbareリポジトリを作る

参考にしたサイトは[こちら](

APIGateway+Lambda+ServerlessFramework（言語：Python&Golang）の色々。offlineモードとかバイナリアップロードとか

##はじめに
APIGateway＋Lambdaを使って、RESTfullなAPIによるPDF生成APIをデプロイメントする時に色々とハマったので、その時の備忘録を記事にしました。

基本はServerlessFrameworkを使ったデプロイメントの自動化を目指して作業をしていった内容をまとめています。

##APIGatewayでメディアタイプの追加
まず、APIGatewayのバイナリレスポンス対応がどういうフローになるかを説明しておきます。

– 【リクエスト】
ブラウザ → (jsonリクエスト） → APIGateway → Lambda

– 【レスポンス】
Lambda → （ファイルを文字列：Base64変換） → APIGateway → （文字列をデコード:Base64変換） → ブラウザ

上記のようにLambdaからはBase64変換されたバイナリデータの文字列が返却される事が期待されています。Lambdaで返却する時の処理として、ここがまずポイントになります。

###APIGatewayのバイナリサポート周辺
APIGatewayでPDFファイルを直接返す

LambdaでPHPを実行する手順

なるべく、簡潔にできるようにまとめてみました。

##前提
Mac
AWSアカウント作成済
Dockerインストール済

##手順
1. Docker内で、PHPの実行環境を作り、それをzip化
2. そのzipファイルをLambdaにアップロード
3. API GatewayでAPI作成

##1. Docker内で、PHPの実行環境を作り、それをzip化
[`stackery/phplambdalayer`](https://github.com/stackery/php-lambda-layer)というツールを使うと、**makeコマンド一つ**で簡単にできました。

このツールには、PHPの実行環境をzip化するために必要なスクリプトや、Lambdaでカスタムランタイム自体を動作させるboostrapファイル等がまとめて入っている

“`
$ git clone https://github.com/stackery/php-lambda-layer.git
$ cd php-lambda-layer
$ make php71.zip
“`

`php71.zip`と

Amazon API GatewayのHTTP API使ってみた

# はじめに
lambdaをさわっててAPIGatewayのコンソールを覗いてみたら見覚えのない選択肢がありました。
この`HTTP API`なるもの、新機能らしいです。
しかも出たばかり。
ホットなので使ってみました。

※検証時点ではプレビュー版となります。

# HTTP API
クラスメソッドさんが解説してくれてます。
いつも助かります。

Amazon API Gatewayは「HTTP API」と「REST API」のどちらを選択すれば良いのか？ #reinvent

なにやら従来のREST APIよりも簡単に使えそうな雰囲気ですね。

# やりたい事
curlでapi叩いてlambda動かしたい。
認証も噛ませたい。

# やってみた
## lambda作る
* ウィザードに従い、ぽちぽち作る。
* 言語はpython3.7を指定。
* ソースはこんな感じ。

“`
import json

def lambda_handler(event, context):

return {
‘isBase64Encoded’: False,

スロークエリをSlackに通知してみた

最近スロークエリをSlackに通知するようにしたので、そのやり方をまとめておきます。Slackに通知したいと思った背景などは以下の記事をご参照ください。
https://qiita.com/yuzoiwasaki/items/d8b56a98822e2b2bb6e7

上の記事で全く技術的なことを書けなかったので、この記事では主に技術の話をします。

## スロークエリをSlackに通知する方法

こちらの記事を参考にさせていただきました。ありがとうございます。

基本的には上記の記事の内容で事足りたのですが、運用していくうちにいくつか無視したいクエリが出てきました。アプリケーション側でキャッシュしているためそれほど気にする必要がないクエリや、管理画面のLIKE検索などすぐには解決が難しいが優先度は低いものなどです。

Slack通知が無視して良い項目で埋まってしまうと本当に重要なクエリを見落とす危険性があったため、無視して良いものは通知から除外するようにしました。

#

node.js製のlambdaアプリをコマンド一発でアップロードする方法

node.jsでlambdaのアプリを作っているのですが、コードやパッケージが増えてくるとインライン編集出来なくなったり、zipでアップロードする必要が出てきます。ちょっとした変更でもわざわざawsのサイトに行ってアップロードするのは面倒ですし、複数のlambdaアプリを作っていたら間違えて別の関数にアップロードしてしまった、といった事故も起きるかもしれません。そこで、コンソールからコマンドでアップロードできるようにする方法を書きます。

※動作確認環境: macOS 10.14.6

# aws CLIの設定

まずawsのCLIをインストールします。バージョンが出ればOKです。

“`
$ brew install python3
$ pip3 install aws
$ aws –version
“`

次にawsのユーザー情報を設定する必要がありますが、アクセスキーが必要になります。IAMでAdministratorAccessポリシーを持ったユーザーを作成しておきます。

[AWS]はじめてのIAMユーザ作成

アクセスキー、シーク

Github Actionsを使ってRuby製のAWS Lambda関数を更新する

# モチベーション
AWSコンソールを開いたり、AWS CLIを使わずに、gitの操作だけでAWS Lambda関数のデプロイを完了します。

近年、[Github Acitons](https://github.com/features/actions)というGithub純正のCI/CDツールがリリースされました。
これを使って、Githubで管理しているAWS Lambda関数の変更を、AWSに反映します。

# 前提条件

今回はRubyで作成されたAWS Lambda関数を更新します。
Lambda関数とデプロイスクリプトが同じ言語だとメンテナンスが楽なので、デプロイにもRubyを使います。

## 先駆者

検索すると、AWS Lambda関数をデプロイするGithub Acitonsがいくつか公開されているのが見つかります。[^1]

[^1]: https://github.com/marketplace?utf8=%E2%9C%93&type=actions&query=lambda

例えば [Deploy AWS Lambda function](https://

[Python3]datetimeにタイムゾーンを指定するawareな方法

PCでコーディングしたプログラムをAWSのLambda関数で実行したら、`datetime.now()`で取得される時刻が異なることに気づきました。PCはJST時間、AWSはUTC時間のため9時間の差があることが原因です。
プログラムを変えずにPCでもAWSのLambda関数でも同じ結果を得るために、datetimeにタイムゾーンを指定する方法を調べました。

#環境
– Python 3.7.4

#問題の事象
例えば次のプログラムを実行すると、PCで取得される現在時刻と、AWSのLambda関数で取得される現在時刻に9時間の差異が発生します。9時間の差異なので、Lambda関数で実行するときには` + timedelta(hours=+9)`として9時間足せばいいのだけれど、それではPCからLambda関数に持っていくときにプログラムの修正が発生するので望ましくないため、プログラムを変更せずに同じ結果が得られるようにしたいと考えました。

“`python:lambda_function.py
from datetime import datetime, timezone, ti

AWS Support との思い出をいつまでもとっておけるようにしました。

## AWS Support みなさん使っていますか？
わたしの好きなサービスのひとつが AWS Support なのは皆さんご存知だとは思います。
試験に出ますよ。

さて。
この AWS Support を使って問い合わせたもの(起票したもの)は、起票後12か月間は使えるとのこと。
https://aws.amazon.com/jp/premiumsupport/faqs/
>**Q: ケース履歴の保存期間はどれほどですか?**
>
>サポートケースの履歴は、作成後12ヵ月間ご利用いただけます。

ということは、起票から12か月経過すると、 AWS Support との思い出がなくなってしまう！？
軽微な質問や超重要な障害への問い合わせも全部なくなってしまうの！？

それは、なんだか嫌だな、って。
と、弊社の複数のつよつよエンジニアーズから同じタイミングで話をもらったので、
ものは試しと、AWS Support との思い出を取っておけるようにしてみました。

## レシピ
### 登場人物
– AWS Support
– ~~AWS Support との思い出~~ サポートケース

LambdaからRedisのデータを取得したい

# 使用するもの
– Lambda
– Redis

## 私の環境
Node 12系

DockerでLamdaを用意しています。方法については、以下の記事を参考にしてください。
https://qiita.com/gdtypk/items/78b6a76dc9f212296c89

Redisも同様にDockerで起動しています。
redis:4.0

## 困ったこと
Node.jsは非同期で動作するので、そのあたりが苦労した。

## コード

“`javascript
const redis = require(“redis”);
const Promise = require(‘bluebird’);

// 接続情報
const config = {
host: ‘redis’,
port: 6379
};

let client = null;
let value = “”;
const key = “key”;

exports.handler = async (event, context) => {
try {
/

Go AWS Lambda の init, main, handler のライフサイクルについて

# はじめに
Go AWS lambdaでRDSに接続する処理を書く必要が出てきた際
connectionを作るのは `init()` で良いのですが果たして `close` をいつどこで行えば良いのか悩み、[公式のリファレンス](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/go-programming-model-handler-types.html
)を参照しましたが肝心のライフサイクルについて具体的な記載が見当たらないため、実際に各func内の実行回数のcountを取って調査しました。

# 検証

`init()` `main()` `Handler()` それぞれの実行countをグローバルに保持しその値を出力する検証コードを作成して実行してみます。

“`Go
package main

import (
“fmt”
“github.com/aws/aws-lambda-go/lambda”
“log”
)

var invokeCount = 0
var initCount = 0
var mainCoun

DockerでローカルのLambda実行環境を用意する。

# はじめに
ファイルの中身のみ記載します。

## ディレクトリ構造
“`
.
├── docker-compose.yml
├── lambda
├── sample
└── index.js

“`

## docker-compose.ymlの内容

“`yml
version: ‘3’

services:
addData:
container_name: sample-lambda
image: lambci/lambda:nodejs12.x
volumes:
– ./lambda/sample:/var/task
ports:
– 9001:9001
environment:
AWS_DEFAULT_REGION: XXXXXXXX
AWS_ACCOUNT_ID: YYYYYYYY
DOCKER_LAMBDA_WATCH: 1
DOCKER_LAMBDA_STAY_OPEN: 1
command: index.hand

YouTubeで指定したチャンネルに投稿された動画の情報を自動で集める

# やったこと（概要）

1. 指定したチャンネルに投稿された動画リストを取得し、API経由で動画情報を取得してS3に保存するスクリプトの作成
1. 上記を毎日0時(UTC)に定期実行するようにlambdaを設定

# やったこと(詳細)

## 1. 動画情報を取得するスクリプトの作成

大まかに、下記の流れで動画情報を取得します
1. チャンネルIDから、そのチャンネルに投稿された動画が全て入っているプレイリスト（「アップロード動画」）のIDを取得
2. プレイリストIDから、そのプレイリストに含まれる動画のIDを取得
3. 2.で得られた動画IDのリストについて、順次APIから動画情報を取得して保存

なお、今回利用するYouTube Data API v3について、最初の登録に当たっては下記を参考にしました
（一年前にやったので状況が変わっている可能性もあります）
https://qiita.com/moshisora/items/4ea23d5abd7b4d852955

### 1.1 「アップロード動画」のIDを取得

YouTube Data API v3を使う際は、基

AWS APIGateway/LambdaとJavascriptで簡易問い合わせサイトをつくる

#概要
問い合わせフォーム(javascript)　⇒　APIGateway　⇒　Lambda(Node.js)　⇒　Lambda(Node.js)　の流れで簡単な問い合わせサイトを作ります。

一応レスポンシブにします。

バリデーションもあります。
無駄なEBSスナップショットをLambdaで定期削除する

「不要になったAMIを登録解除したけど、EBSスナップショットは消し忘れちゃって無駄なスナップショットがたくさん残っちゃってる…」ってこと結構あると思います。
こういう明らかに不要なスナップショットは、Lambdaの定期実行などを利用して自動的に削除されるようにしちゃいましょう。

無駄なスナップショットを残しておくと、スナップショットの管理が煩雑になるし、そのスナップショットにも費用がかかるので、消しちゃうに越したことはありません。

まずAMI登録解除時に消し忘れたスナップショットを一括削除するLambdaは以下のようになります。

“`python

import boto3

ec2 = boto3.client(“ec2”)

def lambda_handler(event, context):
#AMIと共に作られたsnapshotを抽出
response = ec2.describe_snapshots(
Filters=[
{
‘Name’: ‘des