そうだ、教祖になろう。出エジプト記 第3章7節 Cloud9のLambdaで共通処理を持つ
持てるものは与へられて益々豊かならむ
第3章5節 LambdaのログをCloudWatch Logsに出力するでトレースログを実装しました。
第3章6節 CloudWatch LogsをSNSで通知するで作成したSNS通知用のLambda関数にもこれを適用したいのですが…
1つ問題があります。
通常、LambdaはLayersという領域にZIP化した共通処理をアップロードすると、各関数でその共通処理を使えるようになります。
が、Cloud9はLayersに対応していません。
ということで、AWSから推奨されるのかわかりませんが、非常に泥臭いやり方で処理を共通化したいと思います。
されど持たざるものは,その持てるものをも取らるべし
Lambdaアプリケーション配下に共通処理用のフォルダを作成します。
Lambda関数は、Cloud9で見えているこのフォルダでではなく、/var/task/
配下にデプロイされてから実行されるため、Lambdaアプリケーション配下以外に配置してしまうと、実行時に参照できません。
作成したフォルダに第3章5節 LambdaのログをCloudWatch Logsに出力するで作ったトレースログ処理を移動します。
一方、それを読み込む側である通知用のLambda関数のlambda_function.py
ではsys.path.append()
で共通処理用のフォルダをインポート対象フォルダに追加します。
import os import sys sys.path.append(os.path.join(os.path.dirname(__file__), '../lib')) # 共通処理用のフォルダ sys.path.append(os.path.join(os.path.dirname(__file__), '.')) # 中略 from tracelogger import trace # 中略 @trace # 共通処理用のデコレータ def lambda_handler(event, context): # 処理
では、Lambda(local)
で実行してみます。
SNS通知用のLambda関数でもトレースログが出力できました。
元々トレースログを呼んでいたLambda関数でも同じように、パスへ共通フォルダを追加しておきます。
ちなみに、途中で削除や移動したはずのファイルが何度デプロイしてもLambdaから消えない現象が発生したのですが、Lambdaアプリケーションフォルダ配下にある.debug
という隠しフォルダに過去ファイルが残っているからでした。
.debug
配下のファイルを削除すると、Lambdaにも反映されました。
今回、本当はLayersを使ってかっこよく共通化しようとしたのですが、Layersを使えないCloud9内で共通処理を認識する方法が見つからず、いたって普通のフォルダ構成になりました。
いつの日かCloud9でLayersが読めるともっときれいに共通化できそうです。