IntelliJを使って、SAM CLIから起動したPythonのコードをリモートデバッグする
サーバーレス開発部＠大阪の岩田です。
Pythonで開発しているLambdaをデバッグするためにSAM CLIを使ったリモートデバッグを試したので、その時の手順をまとめます。
雛形作成
まずはアプリの雛形を作成します。 SAMテンプレートは下記のように記述しました。
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
python remote debug
Globals:
Function:
Timeout: 300
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
Handler: app.lambda_handler
Runtime: python3.6
Events:
HelloWorld:
Type: Api
Properties:
Path: /
Method: get
注意点として、タイムアウト時間をがっつり長くしています。 ここが短いと、ステップ実行したり、変数の中身を確認したりしている間にLambdaがタイムアウトしてしまうからです。
次にPythonのコードです。
def lambda_handler(event, context):
status_code = 200
body = 'hello'
return {
"statusCode": status_code,
"body": body
}
ここまでできたら、まずは動作確認してみます。
sam local start-api -t template.yml
でAPIをローカルで起動し、curlでテストしてみます。
curl http://127.0.0.1:3000/ hello
OKです。
リモートデバッグのための設定
ここからが本題です。 curlから発火した先ほどのコードをリモートデバッグできるように設定していきます。
pydevdのインストール
まずリモートデバッグで使用するために、pydevdをインストールします。
pip install pydevd -t lib
注意点として、Lambdaを実行するDockerコンテナにpydevdをデプロイしてやる必要があるので、アプリケーションのルートディレクトリ配下にlibというディレクトリを指定してインストールしています。 今回のSAMテンプレートではcodeUriを特に指定していないので、Dockerコンテナにはtemplate.ymlが置いてあるディレクトリの中身が丸々マウントされます。 結果、Dockerコンテナ内の/var/task/libというディレクトリにpydevdが配置されます。
Dockerコンテナの環境変数を設定
SAMテンプレートに下記の記述を追加します。
Environment:
Variables:
PYTHONPATH: "/var/runtime:/var/task/lib"
Lambda(Python)用Dockerコンテナのデフォルトでは環境変数PYTHONPATHに/var/runtimeが設定されているのですが、追加で/var/task/libを設定することで、Dockerコンテナ内で起動するLambdaが先ほどインストールしたpydevdを読み込むことが可能になります。
※このやり方は中山に教えてもらいました。
InteliJの設定
Run → Edit Configurations
からPythonをリモートデバッグするための設定を追加します。
適当にホスト名とポート番号を設定した後、ローカルの開発環境とDockerコンテナ間のパスのマッピングを追加します。
ローカル側はアプリケーションのルートディレクトリをフルパスを指定、Dockerコンテナ側は/var/taskにコードがデプロイされるので、決め打ちで/var/taskを指定します。
Lambdaの修正
次にpythonのコードにリモートデバッグ用のロジックを埋め込みます。
将来的に色々なLambda関数をデバッグすることを考え、decorator.pyというファイルを新しく作成し、その中にリモートデバッグ用のロジックを実装しました。
import os
def remote_debugable(func):
def remote_debug_wrapper(*args, **kwargs):
if not os.getenv("AWS_SAM_LOCAL", False):
return func(*args, **kwargs)
parameters = args[0]["queryStringParameters"]
if parameters is None:
return func(*args, **kwargs)
debug = "DEBUG" in parameters.keys()
if debug:
import pydevd
host = parameters.get("DEBUG_HOST", ["host.docker.internal"])[0]
port = int(parameters.get("DEBUG_PORT", [54321])[0])
pydevd.settrace(host, port=port, stdoutToServer=True, stderrToServer=True)
return func(*args, **kwargs)
return remote_debug_wrapper
SAM CLIからLambdaが起動された場合は、環境変数AWS_SAM_LOCALが入っているので、まずは７行目で環境変数のチェックを行っています。
次に、SAM CLIから起動した場合でもリモートデバッグしたくない場合もあるので、クエリストリングにDEBUGが設定された場合だけリモートデバッグを実行するようにしています。ソースコードの１3,14行目の部分になります。
また、pydevdの接続先ホストとして、デフォルトでhost.docker.internalを指定しています。
Dockerのドキュメントに記載されているのですが、Docker for Macではブリッジインターフェースのdocker0が作成されないため、ホストのIPをそのまま指定しても通信できないためです。
次にLambda本体にリモートデバッグ用のコードを注入します。
from decorator import remote_debugable
@remote_debugable
def lambda_handler(event, context):
status_code = 200
body = 'hello'
return {
"statusCode": status_code,
"body": body
}
リモートデバッグを開始！
これで準備OKです。実際にリモートデバッグを試してみます。 まずIntelliJ側で、先ほど作成した構成でデバッグを開始します。
IntelliJ側で待ち受けの準備ができたら、ターミナルからcurlでAPIを呼び出します。
curl http://127.0.0.1:3000/?DEBUG=1
無事にpydevd.settraceした直後で止まりました！
ここからステップ実行したり、変数の中身をみたりもバッチリです！
まとめ
いかがだったでしょうか？ ユニットテストのライブラリを活用することで、ある程度効率的にLambdaのコードをデバッグすることは可能ですが、やはりローカルでcurlやpostman等のツールで実際にAPIを叩きながらデバッグしたい状況もあると思います。 今回紹介したような方法でリモートデバッグを行うことで、より効率的に開発が進められるのではないでしょうか？
