Configuration Reference¶
This section enumerates all the options that can be provided in the slam.yaml configuration file.
Core Options¶
name
The name of the project.
description
A description for the project.
function
Options that describe the function that is being deployed.
module
The Python module or package that contains the application callable.
app
The name of the function or callable to invoke.
requirements
The project’s requirements filename.
devstage
The name of the stage designated as the development stage.
environment
A collection of variables, specified as key-value pairs, that are made available to the Lambda function as environment variables.
Example:
environment: IN_LAMBDA: "1" ADMIN_URL: "1.2.3.4"
stage_environments
A collection of stages. Each stage contains a collection of variables, given as key-value pairs. These variables are exposed as environment variables to the Lambda function when running on the stage.
Example:
stage_environments: dev: DEBUG: "1" prod: DEBUG: "0"
Note: When using multiple stages, it is important to that any stage variables defined in this section are given values for all stages. This is necessary because sometimes AWS reuses Lambda containers, so environment variables from a previous invocation on a different stage may still exist.
aws
A collection of settings specific to AWS.
s3_bucket
The bucket on S3 where Lambda packages are to be stored. If this bucket does not exist, it is created during the deployment.
lambda_timeout
The timeout, in seconds, for the Lambda function.
lambda_memory
The memory size, in megabytes, for the Lambda function.
lambda_security_groups
If the Lambda function needs to access resources inside a VPC, this entry must contain the list of security groups for the function to use. When VPC access is not desired, this entry must be left blank.
lambda_subnet_ids
If the Lambda function needs to access resources inside a VPC, this entry must contain the list of subnet IDs in that VPC that have to be connected to the function. When VPC access is not desired, this entry must be left blank.
lambda_managed_policies
This entry can define additional managed policies to be assigned to the Lambda function execution role. These can be AWS managed policies (you can provide just the policy name, such as
AWSLambdaDynamoDBExecutionRole
), or custom managed policies, for which you must provide the fully qualified ARN.lambda_inline_policies
This entry can define additonal inline policies to be assigned to the Lambda function execution role.
cfn_resources
A list of additional Cloudformation resources to add to the deployment.
cfn_outputs
A list of additional Cloudformation outputs to add to the deployment.
WSGI Plugin¶
wsgi
If this configuration option exists, the project is assumed to be a web application compliant with the WSGI protocol. The values under the
function
option (described above) are assumed to be of the WSGI callable.The following options provide more details on how the WSGI deployment should be configured:
deploy_api_gateway
If set to
true
(the default), an API Gateway resource is created to map to the Lambda function, so that HTTP requests can be made transparently. If set tofalse
, no API Gateway resources are deployed.log_stages
A list of stages that are configured to include API Gateway logging. For included stages, API Gateway will produce detailed logging. For stages not included, logging will only be produced for errors. This option is only meaningful when
deploy_api_gateway
is set totrue
.
DynamoDB Plugin¶
dynamodb_tables
A collection of DynamoDB tables to create for each stage. Each table entry is defined by the table name, and contains a sub-collection of settings that define the table schema.
Tables created by this plugin have a name with the format stage.name, so for example, for a project that defines
dev
andprod
stages, a table namedmytable
in the configuration will result in DynamoDB tablesdev.mytable
andprod.mytable
created.attributes
A collection of attributes, as key-value pairs where the key is the attribute name, and the value is the attribute type. Attribute types are defined by DynamoDB and can be
"S"
for string,"N"
for number,"B"
for binary, and"BOOL"
for boolean.key
The name of the attribute that is the table’s hash key, or a list of two elements with the attributes that are the table’s hash and range keys.
read_throughput
The read throughput units for the table.
write_throughput
The write throughput units for the table.
local_secondary_indexes
A collection of local secondary indexes to define for the table. The indexes are defined by their name, and contain a sub-collection that specifies their structure.
key
Same as the table-level
key
attribute. For a local secondary index, the hash key must match the key selected for the table-level index.project
The attributes to project on this index. If set to
"all"
all table attributes are projected. Else it can be set to a list of attribute names to project, or to an empty list to only project the key attributes.
global_secondary_indexes
A collection of global secondary indexes to define for the table. The indexes are defined by their name, and contain a sub-collection that specifies their structure.
key
Same as the table-level
key
attribute.project
The attributes to project on this index. If set to
"all"
all table attributes are projected. Else it can be set to a list of attribute names to project, or to an empty list to only project the key attributes.read_throughput
The read throughput units for the index.
write_throughput
The write throughput units for the index.
Example:
dynamodb_tables: # a simple table with "id" as hash key mytable: attributes: id: "S" key: "id" read_throughput: 1 write_throughput: 1 # a more complex table with hash/sort keys and secondary indexes mytable2: attributes: id: "S" name: "S" age: "N" key: ["id", "name"] read_throughput: 1 write_throughput: 1 local_secondary_indexes: myindex: key: ["id", "age"] project: ["name"] global_secondary_indexes: myindex2: key: ["age", "name"] project: "all" read_throughput: 1 write_throughput: 1