chaliceの記事は日々増えてきており、情報を集めるには苦労しなくなってきた。
ただ、どれも1APIを作る部分の説明のみで、プロジェクトを続けていく中で複数APIを作る時にどんな構成を組んでるか記載されているものが少なかった。
少しハマったので、書いて残しておく。
基本の流れ
プロジェクト作成
chalice new-project api_1
これでAPIのプロジェクトを作成し、app.pyにコーディングしていく。
しかしこのプロジェクトに全部詰め込むのも管理し辛いので、API毎にファイルを分けたい。
デプロイ
chalice deploy
作成したプロジェクト内でデプロイのコマンドを叩くと、.chalice/config.json
及び.chalice/policy-prod.json
の設定に沿ってデプロイが実行される。
実行すると、deployed
、deployments
が作成される
gitプロジェクトの構成
├── README.md
├── api_1
│ ├── app.py
│ ├── requirements.txt
│ ├── chalicelib -> ../lib
│ ├── vendor
│ ├── .chalice
├── api_2
│ ├── app.py
│ ├── requirements.txt
│ ├── vendor
│ ├── .chalice
・・・
・・・
こんな感じにしたい。
api_1だけデプロイしたいとか当然あるし。
必要なこと
1. .chalice/config.json
の"app_name"をそれぞれ独自のものにする
よくよく考えれば当たり前だが、app_nameはそれぞれのプロジェクト毎に独自に設定する
(api_1なら"api_1"、api_2なら"api_2"等)
{
"version": "2.0",
"app_name": "api_1",
"stages": {
"prod": {
"api_gateway_stage": "prod",
"manage_iam_role":false,
"iam_role_arn":"arn:aws:iam::prod",
"environment_variables": {
"DEVELOP": "false"
}
},
"dev": {
"api_gateway_stage": "dev",
"manage_iam_role":false,
"iam_role_arn":"arn:aws:iam::dev",
"environment_variables": {
"DEVELOP": "true"
}
}
}
}
2. 初回デプロイ時はdeployed
、deployments
は削除する
これも当たり前の話なんだけど、デプロイ実行で作成されるファイルはそのプロジェクト用なので、他のプロジェクトにコピーしちゃダメ。気付かずに時間だけ食ってしまった。
3. lambdaとAPIGatewayの関係を一対一にする
実装・デプロイを繰り返していると、lambdaとAPIGatewayの関係が歪になることをあるかもしれない。
作業中、何故か一つのAPIGatewayに複数のlambdaが乗っていた時があって、api_1をデプロイするとapi_2が502
のエラーを返すようになった。
"ChaliceError": Execution failed due to configuration error: Malformed Lambda proxy response
その時は一度lambdaを削除してデプロイし直して、APIGatewayとの関連付けを一対一にする。
まとめ
chaliceはデプロイ周りが本当に楽で、ロジック作成に集中出来るので便利だが、いくつものAPIを作成するような大きなプロジェクトでは向いているのか正直まだ分からない。
が、気軽にサーバレスでAPIを作るにはもってこいなフレームワークであることは間違いない
余談
自作ライブラリを追加する場合は、同プロジェクト内のchalicelibに格納するのがセオリー。
docsにも記載されてる
├── api_1
│ ├── app.py
│ ├── chalicelib
│ │ └── utils.py
でもこれだとapi毎に用意しなければならないので、共通処理とか用意する時に不便。
[シンボリックリンクでもいける]
├── api_1
│ ├── app.py
│ ├── chalicelib -> ../lib
├── api_2
│ ├── app.py
│ ├── chalicelib -> ../lib
├── lib
│ └── utils.py