/var/log/messages

Sep 18, 2018 - 4 minute read - Comments - aws

Aws Sam Cli

自分メモを控え。

API Gateway + Lambda

aws-sam-cli というツールにより

  • プロジェクト雛形の作成
  • ローカルでの動作確認
  • パッケージング、AWS へのデプロイ

などが可能です。

インストール

以下に依存しているとのこと。

  • Python3
  • Docker
  • Python Virtual Environment

aws-sam-cli の導入は pip で行ないます。

$ pip install aws-sam-cli

npm 製の aws-sam-local を導入している場合はアンインストールしておく必要があります。

$ npm uninstall -g aws-sam-local

プロジェクト雛形の作成

以下のコマンドで sam-app というディレクトリが作成されます。

sam init --runtime python3.6

runtime は python 以外にもありますが、ここでは Python3.6 限定とします。sam-app ディレクトリ配下は以下な形になっています。

.
├── README.md                   <-- This instructions file
├── hello_world                 <-- Source code for a lambda function
│   ├── __init__.py
│   └── app.py                  <-- Lambda function code
├── requirements.txt            <-- Python dependencies
├── template.yaml               <-- SAM template
└── tests                       <-- Unit tests
    └── unit
        ├── __init__.py
        └── test_handler.py

また、ライブラリをローカルで管理するために venv を使います。

$ python -m venv .
$ . bin/activate
(sam-app)$

この状態で requirements.txt を以下な状態にします。

atomicwrites==1.2.1
attrs==18.2.0
certifi==2018.8.24
chardet==3.0.4
idna==2.6
more-itertools==4.3.0
pluggy==0.7.1
py==1.6.0
pytest==3.7.4
pytest-mock==1.10.0
requests==2.18.4
six==1.11.0
urllib3==1.22

で、仮想環境にライブラリを導入します。

(sam-app)$ pip install -f requirements.txt

また、ライブラリを追加したときには以下の方法で requirements.txt に反映してリポジトリに反映する必要があります。

(sam-app)$ pip install boto3
(sam-app)$ pip freeze > requirements.txt

この状態でリポジトリを作ります。venv が bin を作るので、以下を .gitignore に反映しておく必要があります。

# venv

bin/

リポジトリ作成します。

(sam-app)$ git init
(sam-app)$ git add .
(sam-app)$ git commit -m 'create repository'

これで動作確認を行なう用意ができているはずなので、初期状態で動作の確認を行なってみます。

ローカルでの動作確認

初期状態で単体テストはパスしている状態のはずです (出力は略)。

(sam-app)$ python -m pytest tests/ -v

また、api gateway であれば Docker の助けなしに単体で動作確認が可能なようです。

(sam-app)$ sam local start-api

これで何らかの形で http://localhost:3000/hello にアクセスすると以下な JSON が戻されることが確認できるはずです。

{"message": "hello world", "location": "xxx.xxx.xxx.xxx"}

また、LocalStack を起動しているのであれば Lambda 単体での実行確認も可能です。まず、LocalStack を起動します。別端末にてリポジトリを取得して

$ cd Documents
$ git clone https://github.com/atlassian/localstack.git

docker-compose します。

$ cd localstack
$ TMPDIR=/private$TMPDIR docker-compose up

以下で Lambda に渡す疑似イベントファイルを作成し

(sam-app)$ sam local generate-event apigateway aws-proxy  > event_file.json

Lambda を invoke します。

sam local invoke HelloWorldFunction --event event_file.json

上記と同様の JSON 文字列が出力されているはずです。

start-lambda

以下で Lambda Function に直接アクセスできるようです。ひとまず start-lambda を行ないます。

(sam-app)$ sam local start-lambda

別端末から以下の aws コマンドを発行します。

$ aws lambda invoke  --function-name HelloWorldFunction --endpoint-url http://127.0.0.1:3001/ --payload file://event_file.json output.txt
{
    "StatusCode": 200
}

output.txt にレスポンス文字列が格納されているはずです。また、これも LocalStack が起動している必要があるようです。

Neptune 接続

Lambda から Neptune インスタンスに対して Gremlin クエリを発行する実装である場合、LocalStack では Neptune は動作しませんので試験は不可能ですが、上述の ssh トンネリングを使うことで localhost に対してクエリの発行が可能となるため、ローカルでの動作確認が行なえるものという認識です (start-api での動作確認となります)。

環境変数

環境変数ですが CloudFormation のテンプレートに定義できるようです。雛形での定義例が以下。

            Environment: # More info about Env Vars: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#environment-object
                Variables:
                    PARAM1: VALUE

Neptune のエンドポイント修正時、ここを変更して、という事も可能と思われますが、自動化というあたりを鑑みるとどういった手法を採用するか、は判断が難しいかもしれません。

ただし、試験にあたっては接続先を localhost にしておいて、という方法は使えるものと思われます。

パッケージング、AWS へのデプロイ

ここは動作確認を行なっておりませんので記載は略します。以下ドキュメントにて必要となる権限が列挙されています。

おわりに

ここで紹介した二点以外に Neptune を公開できる代理サービスがあるか、については別途引き続き確認します。アクセスを限定できる、という意味では API 化した方が良いかもしれない、という認識です。

参考ドキュメント

以下にポインタを列挙します。

Ltspice 囲碁とはどういうゲームなのか

comments powered by Disqus