Invokes deployed function. It allows to send event data to the function, read logs and display other important information of the function invocation.
serverless invoke [local] --function functionName
Note: Please refer to this guide for event data passing when your function uses the http
event with a Lambda Proxy integration.
--function
or-f
The name of the function in your service that you want to invoke. Required.--stage
or-s
The stage in your service you want to invoke your function in.--region
or-r
The region in your stage that you want to invoke your function in.--data
or-d
String data to be passed as an event to your function. By default data is read from standard input.--raw
Pass data as a raw string even if it is JSON. If not set, JSON data are parsed and passed as an object.--path
or-p
The path to a json file with input data to be passed to the invoked function. This path is relative to the root directory of the service.--type
or-t
The type of invocation. EitherRequestResponse
,Event
orDryRun
. Default isRequestResponse
.--log
or-l
If set totrue
and invocation type isRequestResponse
, it will output logging data of the invocation. Default isfalse
.
invoke:invoke
Invokes a function locally for testing and logs the output. Keep in mind that we mock the context
with simple mock data.
serverless invoke local --function functionName
--function
or-f
The name of the function in your service that you want to invoke locally. Required.--path
or-p
The path to a json file holding input data to be passed to the invoked function as theevent
. This path is relative to the root directory of the service.--data
or-d
String data to be passed as an event to your function. Keep in mind that if you pass both--path
and--data
, the data included in the--path
file will overwrite the data you passed with the--data
flag.--raw
Pass data as a raw string even if it is JSON. If not set, JSON data are parsed and passed as an object.--contextPath
or-x
, The path to a json file holding input context to be passed to the invoked function. This path is relative to the root directory of the service.--context
or-c
, String data to be passed as a context to your function. Same like with--data
, context included in--contextPath
will overwrite the context you passed with--context
flag.
serverless invoke --function functionName --stage dev --region us-east-1
This example will invoke your deployed function named functionName
in region us-east-1
in stage dev
. This will
output the result of the invocation in your terminal.
serverless invoke --function functionName --stage dev --region us-east-1 --data "hello world"
node dataGenerator.js | serverless invoke --function functionName --stage dev --region us-east-1
serverless invoke --function functionName --stage dev --region us-east-1 --log
Just like the first example, but will also outputs logging information about your invocation.
serverless invoke --function functionName --stage dev --region us-east-1 --path lib/data.json
This example will pass the json data in the lib/data.json
file (relative to the root of the service) while invoking
the specified/deployed function.
{
"resource": "/",
"path": "/",
"httpMethod": "GET",
// etc. //
}
serverless invoke local --function functionName --context "hello world"
serverless invoke local --function functionName --contextPath lib/context.json
This example will pass the json context in the lib/context.json
file (relative to the root of the service) while invoking the specified/deployed function.
Currently, invoke local
only supports the NodeJs and Python runtimes.
Lambda functions assume an IAM role during execution: the framework creates this role, and set all the permission provided in the iamRoleStatements
section of serverless.yml
.
Unless you explicitly state otherwise, every call to the AWS SDK inside the lambda function is made using this role (a temporary pair of key / secret is generated and set by AWS as environment variables, AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
).
When you use serverless invoke local
, the situation is quite different: the role isn't available (the function is executed on your local machine), so unless you set a different user directly in the code (or via a key pair of environment variables), the AWS SDK will use the default profile specified inside you AWS credential configuration file.
Take a look to the official AWS documentation (in this particular instance, for the javascript SDK, but should be similar for all SDKs):
- http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-node-credentials-shared.html
- http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-node-credentials-lambda.html
Whatever approach you decide to implement, be aware: the set of permissions might be (and probably is) different, so you won't have an exact simulation of the real IAM policy in place.