2024-06-11 17:11:50 +02:00

175 lines
6.2 KiB
Markdown

<!--
title: Serverless Framework - Variables
menuText: Variables
menuOrder: 1
description: How to use Serverless Variables to insert dynamic configuration info into your serverless.yml
layout: Doc
-->
<!-- DOCS-SITE-LINK:START automatically generated -->
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/guides/variables)
<!-- DOCS-SITE-LINK:END -->
# Variables
Variables allow users to dynamically replace config values in `serverless.yml` config.
They are especially useful when providing secrets for your service to use and when you are working with multiple stages.
## Syntax
To use variables, you will need to reference values enclosed in `${}` brackets.
```yml
# serverless.yml file
yamlKeyXYZ: ${variableSource} # see list of current variable sources below
# this is an example of providing a default value as the second parameter
otherYamlKey: ${variableSource, defaultValue}
```
You can define your own variable syntax (regex) if it conflicts with CloudFormation's syntax.
**Note:** You can only use variables in `serverless.yml` property **values**, not property keys. So you can't use variables to generate dynamic logical IDs in the custom resources section for example.
## Current variable sources:
- [Self-References Properties Defined in `serverless.yml`](/framework/docs/guides/variables/self)
- [Serverless Core Variables](/framework/docs/guides/variables/core)
- [Environment Variables](/framework/docs/guides/variables/env)
- [CLI Options](/framework/docs/guides/variables/cli-options)
- [External YAML/JSON Files](/framework/docs/guides/variables/file)
- [Dynamic Values from Javascript](/framework/docs/guides/variables/javascript)
- [Git](/framework/docs/guides/variables/git)
- [AWS-specific](/framework/docs/guides/variables/aws)
- [AWS S3](/framework/docs/guides/variables/s3)
- [AWS SSM Parameter Store & Secrets Manager](/framework/docs/guides/variables/ssm)
- [AWS CloudFormation Outputs](/framework/docs/guides/variables/cf-stack)
- [HashiCorp Terraform State Outputs](/framework/docs/guides/variables/teraform)
- [HashiCorp Vault Secrets](/framework/docs/guides/variables/vault)
## Recursively reference properties
You can also **recursively reference properties** with the variable system. This means you can combine multiple values and variable sources for a lot of flexibility.
For example:
```yml
provider:
name: aws
environment:
MY_SECRET: ${file(./config.${sls:stage}.json):CREDS}
```
If `sls deploy --stage qa` is run, the stage will be set to `qa`, which is used inside the `${file(./config.${sls:stage}.json):CREDS}` variable and it will resolve the `config.qa.json` file and use the `CREDS` key defined.
**How that works:**
1. `stage` is set to `qa` from the option supplied to the `sls deploy --stage qa` command. If no option is defined, then `${sls:stage}` will use the value in `provider.stage` or default to `dev` if not set.
2. `${sls:stage}` resolves to `qa` and is used in `${file(./config.${sls:stage}.json):CREDS}`
3. `${file(./config.qa.json):CREDS}` is found & the `CREDS` value is read
4. `MY_SECRET` value is set
Likewise, if `sls deploy --stage prod` is run the `config.prod.json` file would be found and used.
## Setting Variables using Parameters
Occasionally you may want to set a variable directly in the `serverless.yml` that you can use throughout the file. In such a case you can use Parameters to set new variables or use them to set stage-specific variables.
Here is an example of setting a domain variable based on the stage:
```yaml
stages:
default:
domain: ${sls:stage}.example-dev.com
prod:
domain: example.com
provider:
environment:
APP_DOMAIN: ${param:domain}
```
Read all about parameters in the [Parameters documentation](/framework/docs/providers/aws/guide/parameters).
## Multiple Configuration Files
Adding many custom resources to your `serverless.yml` file could bloat the whole file, so you can use the Serverless Variable syntax to split this up.
```yml
resources:
Resources: ${file(cloudformation-resources.json)}
```
The corresponding resources which are defined inside the `cloudformation-resources.json` file will be resolved and loaded into the `Resources` section.
In order to use multiple resource files combined with resources inside the `serverless.yml` you can use an array.
```yml
resources:
- Resources:
ApiGatewayRestApi:
Type: AWS::ApiGateway::RestApi
- ${file(resources/first-cf-resources.yml)}
- ${file(resources/second-cf-resources.yml)}
- Outputs:
CognitoUserPoolId:
Value:
Ref: CognitoUserPool
```
Each of your cloudformation files has to start with a `Resources` entity
```yml
Resources:
Type: 'AWS::S3::Bucket'
Properties:
BucketName: some-bucket-name
```
## Default values
The Serverless framework gives you an intuitive way to reference multiple variables as a fallback strategy in case one of the variables is missing. This way you'll be able to use a default value from a certain source, if the variable from another source is missing.
For example, you can use the `opt` variable to get the `memory` CLI option when running `serverless deploy --memory 2048`. If the `memory` option is not provided, the default value of `1024` will be used.
```yml
functions:
hello:
handler: handler.hello
memorySize: ${opt:memory, 1024}
```
The default value can also reference another variable.
## Read String Variable Values as Boolean Values
In some cases, a parameter expect a `true` or `false` boolean value. If you are using a variable to define the value, it may return as a string (e.g. when using SSM variables) and thus return a `"true"` or `"false"` string value.
To ensure a boolean value is returned, read the string variable value as a boolean value. For example:
```yml
provider:
tracing:
apiGateway: ${strToBool(${ssm:API_GW_DEBUG_ENABLED})}
```
These are examples that explain how the conversion works after first lowercasing the passed string value:
```plaintext
${strToBool(true)} => true
${strToBool(false)} => false
${strToBool(True)} => true
${strToBool(False)} => false
${strToBool(TRUE)} => true
${strToBool(FALSE)} => false
${strToBool(0)} => false
${strToBool(1)} => true
${strToBool(2)} => Error
${strToBool(null)} => Error
${strToBool(anything)} => Error
```