--Scenario: I want to treat a simple configuration file (YAML, JSON, etc.) as a file to be read in a Lambda function.
--Problem: I put ʻenv.yml in the same directory as ʻapp.py, but chalice deploy did not upload the file
--Solution: Create a directory called chalicelib under the chalice project and put the files there. See the tree results below.
--When using it, read it as filepath = os.path.join (os.path.dirname (__ file__),'chalicelib','env.yml') and solve it.
-The official manual shows the same thing
$ tree -a .
.
├── .chalice
│ └── config.json
├── .gitignore
├── app.py
├── chalicelib
│ └── env.yml
└── requirements.txt
When deploying with chalice, in case of Linux / Mac etc., the file permissions are inherited as they are. Therefore, note that if you deploy a file such as 750, you will get Permission Denied at runtime when you try to read that file.
-Similar case. Probably because the permissions at the time of saving are expanded when extracting the zip file created at the time of upload.
--Scenario: One of Chalice's useful features is the automatic generation of IAM Policies. This is a function that automatically determines when accessing AWS resources using the boto3 library in Lambda and dynamically automatically generates an IAM Policy. --Problem: For some reason, my program did not automatically generate and grant this.
When I looked it up, it was because ** only programs using boto3.client were automatically generated **. There is also a way to use resource in boto3, but even if you use it, it will not be subject to automatic IAM generation. All my programs used boto3.resource.
Therefore, since IAM Policy is automatically generated, ** Always use boto3.client ** when using boto3 with Chalice can be a guideline.
Conversely, if you want to use the existing IAM Role or manage the Policy description yourself, disable ʻautogen_policy in .chalice / config.json`. For example:
json:.chalice/config.Excerpt from json
"stages": {
"dev": {
"api_gateway_stage": "api",
"autogen_policy": false
}
}
If this is disabled, the default is to read policy- <stage name> .json (in this case policy-dev.json) in .chalice. If you want to specify an alias, specify the file name with ʻiam_policy_file`. Click here for more detailed explanation
json:.chalice/policy-dev.Just write the access authority in Role in json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*"
],
"Resource": [
"*"
],
"Sid": "xxxx-xxxx-xxxx-xxxx-1234"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*",
"Sid": "xxxx-xxxx-xxxx-xxxx-1235"
}
]
}
If you want to use an external library etc., you will adopt this if you use boto3.resource. Due to the IAM authority, if you do not have the IAM operation authority in the first place, you can specify the IAM Role ARN and grant it (ʻiam_role_arn`).
The description that only client can automatically generate IAM Policy is, for example, Explanation in AWS BlackBelt series Much more detailed than the article](https://michimani.net/post/aws-about-auto-generate-iam-policy-in-chalice/) I could find it, but in the official documentation this I couldn't find the description. It should be okay, but ...
--Scenario: I want to call API Gateway with ajax from a browser --Lambda and get the response
--Problem: When I access it with ajax from a browser, it is repelled due to CORS. The same applies when running on chalice local.
You will have to set CORS according to your use case, but this is it is faster to read the formula -cors-support) The explanation is substantial.
As a general rule, after setting the appropriate settings for the instance of chalice.CORSConfig, pass the settings to cors in the decorator like @ app.route (path, cors = config). It makes me happy.
Recommended Posts