mirror of
https://github.com/serverless/serverless.git
synced 2026-01-25 15:07:39 +00:00
commit
0428373f4e
@ -1,24 +0,0 @@
|
||||
environment:
|
||||
global:
|
||||
SLS_IGNORE_WARNING: "*"
|
||||
matrix:
|
||||
- NODEJS_VERSION: "4"
|
||||
- NODEJS_VERSION: "6"
|
||||
- NODEJS_VERSION: "8"
|
||||
|
||||
install:
|
||||
# For Ruby invoke local testing
|
||||
- set PATH=C:\Ruby25\bin;%PATH%
|
||||
# Get the version of Node.js
|
||||
- ps: Install-Product node $Env:NODEJS_VERSION
|
||||
# install modules
|
||||
- rm -rf node_modules
|
||||
- npm install
|
||||
- node --version
|
||||
- npm --version
|
||||
|
||||
test_script:
|
||||
- npm test
|
||||
|
||||
# Don't actually build.
|
||||
build: off
|
||||
@ -8,3 +8,6 @@ indent_size = 2
|
||||
indent_style = space
|
||||
insert_final_newline = true
|
||||
trim_trailing_whitespace = true
|
||||
|
||||
[*.md]
|
||||
trim_trailing_whitespace = false
|
||||
|
||||
@ -1,5 +0,0 @@
|
||||
coverage
|
||||
node_modules
|
||||
tmp
|
||||
tmpdirs-serverless
|
||||
lib/plugins/create/templates/**
|
||||
18
.eslintrc.js
18
.eslintrc.js
@ -1,18 +0,0 @@
|
||||
module.exports = {
|
||||
"root": true,
|
||||
"extends": "airbnb",
|
||||
"plugins": [],
|
||||
"rules": {
|
||||
"func-names": "off",
|
||||
|
||||
// doesn't work in node v4 :(
|
||||
"strict": "off",
|
||||
"prefer-rest-params": "off",
|
||||
"react/require-extension": "off",
|
||||
"import/no-extraneous-dependencies": "off"
|
||||
},
|
||||
"env": {
|
||||
"mocha": true,
|
||||
"jest": true
|
||||
}
|
||||
};
|
||||
19
.github/ISSUE_TEMPLATE/bug_report.md
vendored
19
.github/ISSUE_TEMPLATE/bug_report.md
vendored
@ -16,17 +16,18 @@ about: Create a report to help us improve
|
||||
|
||||
## Description
|
||||
|
||||
* What went wrong?
|
||||
* What did you expect should have happened?
|
||||
* What was the config you used?
|
||||
* What stacktrace or error message from your provider did you see?
|
||||
- What went wrong?
|
||||
- What did you expect should have happened?
|
||||
- What was the config you used?
|
||||
- What stacktrace or error message from your provider did you see?
|
||||
|
||||
Similar or dependent issues:
|
||||
* #12345
|
||||
|
||||
- #12345
|
||||
|
||||
## Additional Data
|
||||
|
||||
* ***Serverless Framework Version you're using***:
|
||||
* ***Operating System***:
|
||||
* ***Stack Trace***:
|
||||
* ***Provider Error messages***:
|
||||
- **_Serverless Framework Version you're using_**:
|
||||
- **_Operating System_**:
|
||||
- **_Stack Trace_**:
|
||||
- **_Provider Error messages_**:
|
||||
|
||||
7
.github/ISSUE_TEMPLATE/feature_request.md
vendored
7
.github/ISSUE_TEMPLATE/feature_request.md
vendored
@ -16,8 +16,9 @@ about: Suggest an idea for serverless framework
|
||||
|
||||
## Description
|
||||
|
||||
* What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
|
||||
* If there is additional config how would it look
|
||||
- What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
|
||||
- If there is additional config how would it look
|
||||
|
||||
Similar or dependent issues:
|
||||
* #12345
|
||||
|
||||
- #12345
|
||||
|
||||
16
.github/PULL_REQUEST_TEMPLATE.md
vendored
16
.github/PULL_REQUEST_TEMPLATE.md
vendored
@ -34,13 +34,21 @@ Examples:
|
||||
|
||||
## Todos:
|
||||
|
||||
- [ ] Write tests
|
||||
_**Note: Run `npm run test-ci` to run all validation checks on proposed changes**_
|
||||
|
||||
- [ ] Write tests and confirm existing functionality is not broken.
|
||||
**Validate via `npm test`**
|
||||
- [ ] Write documentation
|
||||
- [ ] Fix linting errors
|
||||
- [ ] Ensure there are no lint errors.
|
||||
**Validate via `npm run lint-updated`**
|
||||
_Note: Some reported issues can be automatically fixed by running `npm run lint:fix`_
|
||||
- [ ] Ensure introduced changes match Prettier formatting.
|
||||
**Validate via `npm run prettier-check-updated`**
|
||||
_Note: All reported issues can be automatically fixed by running `npm run prettify-updated`_
|
||||
- [ ] Make sure code coverage hasn't dropped
|
||||
- [ ] Provide verification config / commands / resources
|
||||
- [ ] Enable "Allow edits from maintainers" for this PR
|
||||
- [ ] Update the messages below
|
||||
|
||||
***Is this ready for review?:*** NO
|
||||
***Is it a breaking change?:*** NO
|
||||
**_Is this ready for review?:_** NO
|
||||
**_Is it a breaking change?:_** NO
|
||||
|
||||
8
.gitignore
vendored
8
.gitignore
vendored
@ -2,6 +2,7 @@
|
||||
*.log
|
||||
npm-debug.log
|
||||
npm-shrinkwrap.json
|
||||
/package-lock.json
|
||||
|
||||
# Runtime data
|
||||
pids
|
||||
@ -12,8 +13,9 @@ dist
|
||||
# Directory for instrumented libs generated by jscoverage/JSCover
|
||||
lib-cov
|
||||
|
||||
# Coverage directory used by tools like istanbul
|
||||
# Coverage directory used by tools like nyc
|
||||
coverage
|
||||
/.nyc_output
|
||||
|
||||
# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
|
||||
.grunt
|
||||
@ -57,5 +59,7 @@ jest
|
||||
|
||||
# DotNet
|
||||
obj/
|
||||
[Bb]in/
|
||||
[Oo]bj/
|
||||
|
||||
# Tests
|
||||
!tests/**/*.zip
|
||||
|
||||
@ -1,48 +0,0 @@
|
||||
{
|
||||
"html": {
|
||||
"allowed_file_extensions": ["htm", "html", "xhtml", "shtml", "xml", "svg"],
|
||||
"brace_style": "collapse",
|
||||
"end_with_newline": false,
|
||||
"indent_char": " ",
|
||||
"indent_handlebars": false,
|
||||
"indent_inner_html": false,
|
||||
"indent_scripts": "keep",
|
||||
"indent_size": 2,
|
||||
"max_preserve_newlines": 4,
|
||||
"preserve_newlines": true,
|
||||
"unformatted": ["a", "span", "img", "code", "pre", "sub", "sup", "em", "strong", "b", "i", "u", "strike", "big", "small", "pre", "h1", "h2", "h3", "h4", "h5", "h6"],
|
||||
"wrap_line_length": 0
|
||||
},
|
||||
"css": {
|
||||
"allowed_file_extensions": ["css", "scss", "sass", "less"],
|
||||
"end_with_newline": true,
|
||||
"indent_char": " ",
|
||||
"indent_size": 2,
|
||||
"max_preserve_newlines": 4,
|
||||
"newline_between_rules": true,
|
||||
"selector_separator": " ",
|
||||
"selector_separator_newline": true
|
||||
},
|
||||
"js": {
|
||||
"allowed_file_extensions": ["jshintrc", "jsbeautifyrc"],
|
||||
"brace_style": "collapse",
|
||||
"break_chained_methods": false,
|
||||
"e4x": false,
|
||||
"end_with_newline": false,
|
||||
"indent_char": " ",
|
||||
"indent_level": 0,
|
||||
"indent_size": 2,
|
||||
"indent_with_tabs": false,
|
||||
"jslint_happy": false,
|
||||
"keep_array_indentation": false,
|
||||
"keep_function_indentation": false,
|
||||
"max_preserve_newlines": 0,
|
||||
"preserve_newlines": true,
|
||||
"space_after_anon_function": false,
|
||||
"space_before_conditional": true,
|
||||
"space_in_empty_paren": false,
|
||||
"space_in_paren": false,
|
||||
"unescape_strings": false,
|
||||
"wrap_line_length": 0
|
||||
}
|
||||
}
|
||||
186
.travis.yml
186
.travis.yml
@ -1,62 +1,128 @@
|
||||
language: node_js
|
||||
matrix:
|
||||
exclude:
|
||||
- node_js: '6.2'
|
||||
env:
|
||||
- secure: ruPmxtjLY9jX/TQQe1d8vxwL0KsjsTzJK/EL6rZM954JJc+3c5gshxB1Ca9+WRwIGdMjCZgKo4dQcn2DrAap7KoDz+GRCi40kc5AOr2ZLmjxJeCJls+sQ713QJ01GgIA1X2zmz/bDSw5lan8ODR3eYI0fIn37ZV4yxNJ5PObBLCMQW6nnOdMXxcLLi2iJRqu3k0gb85wsUNOB0AF2cBrbxoYmGsrGjGuPjIXPeEdnVJ0jzBY+jDrBraIHEBN9tecIyG77ZgEhlPopqTrj39dEPMwAow+derEVWugPRF3Wps6z+Yx0qtxETptWuOgn0V9GpfZF9vJlHifQUuuJEGtttVCYjZCUOIoIRwWnX+/SygjlgLJ9PpVa6XyZfnqygJXnv7wouGGkiyZEDbayu65qP3Ls/Dj+N2nEtamOPf3dGBeaX8KKF61h80bH7o9JL/t6yxyvm+yDRTkYd9SNk3U7dFXoBcCcjMNNUkKBKtY9G3EZlE0ZV0D7jD33Na4yX8mKBHkYLKXCAn+rh6DIwLNkV8IOtAYD77qan6v4qH9fpPMX4UkLu9SRM1r5RfsZU0gX7sCP9OKFKkAx5BWUqjg+D6Xa0EACtO8bPDHA548hWU2vYx7ghuVJfVNOUlAl97OXclx2SZwXJ46rHaHgrH2I3gi3qyHMib3iUV7SLdRQnY=
|
||||
- secure: p9ka7mRzo/ecjnDh/dz19g0iVfQdvsGRAtg/4ONeiq75I2+oqHzu+VxUBA1Z2IQbpCEAMo21CarR3fg2I6MFUeazL0nEpqr1PoOAI8nPFeQlg/h+jLXsrPAkDcu2/b8ij7J5MXeLdZXUVqiPcGkr68x/tCMk/rwxftljQhvXPQfc7Lxm/m61ELnC7rLJulhxWZLNIq1hwQ9nh0GMKb4hm0KmPn8ksccVL+wyDikkgXCuvIujhTBjhNivAe4mG8mqnNsW1Ugh++SUe1ld27TtbH7wQj02SSG4Bxfwc3Gz0GFdAL1GyOkWI2WvrqP4a0KYTRUo+pUr9E+HZ1SNlxU5t6QWtmDiy5MKkxzgeTXmkKiJ98vMlF0ja5bpp46NjYarzDafqE8FozHzLtr+uAtqr6gRAgU1rWaG9BE3gKeW/f4B/2MfPI26b7SxuU1MwGVy0I76hb0Ujbgb3X8G4TYTGb6Nhoewc+RZExPwVhfrN8cJjo45masndv5tQAZMSRX/JUFjs4h/QMXNsn0A53GXgf6eIzUu15m+W8TJYFiKQeq9nMejzEE4sWMO3BFnkxueBGVCEurOc1GgdEnKxeqlp+psxHcJRlNCxC1HkUVOzfpkCr/Jy42vM8jQomAMv41Z9zWjOagVphWT25xNeSILfRt4yPku5wfW4CAxp+fl4KQ=
|
||||
include:
|
||||
- node_js: '4.4'
|
||||
env: SLS_IGNORE_WARNING=*
|
||||
- node_js: '5.11'
|
||||
env: SLS_IGNORE_WARNING=*
|
||||
- node_js: '6.2'
|
||||
env: SLS_IGNORE_WARNING=*
|
||||
- node_js: '6.2'
|
||||
env:
|
||||
- INTEGRATION_TEST=true
|
||||
- INTEGRATION_TEST_SUITE=simple
|
||||
- SLS_IGNORE_WARNING=*
|
||||
- secure: Ia2nYzOeYvTE6qOP7DBKX3BO7s/U7TXdsvB2nlc3kOPFi//IbTVD0/cLKCAE5XqTzrrliHINSVsFcJNSfjCwmDSRmgoIGrHj5CJkWpkI6FEPageo3mdqFQYEc8CZeAjsPBNaHe6Ewzg0Ev/sjTByLSJYVqokzDCF1QostSxx1Ss6SGt1zjxeP/Hp4yOJn52VAm9IHAKYn7Y62nMAFTaaTPUQHvW0mJj6m2Z8TWyPU+2Bx6mliO65gTPFGs+PdHGwHtmSF/4IcUO504x+HjDuwzW2itomLXZmIOFfGDcFYadKWzVMAfJzoRWOcVKF4jXdMoSCOviWpHGtK35E7K956MTXkroVoWCS7V0knQDovbRZj8c8td8mS4tdprUA+TzgZoHet2atWNtMuTh79rdmwoAO+IAWJegYj62Tdfy3ycESzY+KxSaV8kysG9sR3PRFoWjZerA7MhLZEzQMORXDGjJlgwLaZfYVqjlsGe5p5etFBUTd0WbFgSwOKLoA2U/fm7WzqItkjs3UWaHuvFVvwYixGxjEVmVczS6wa2cdGpHtVD9H7km4fPEzljHqQ26v0P5e8eylgqLF2IB6mL7UqGFrAtrMvAgN/M3gnq4dTs/wq1AJIOxEP7YW7kc0NAldk8vUz6t5GzCPNcuukxAku91Awnh0twxgUywatgJLZPY=
|
||||
- secure: Dgaa5XIsA5Vbw/CYQLUAuVVsDX26C8+f1XYGwsbNmFQKbKvM8iy9lGrHlfrT3jftJkJH6re8tP1RjyZjjzLe25KPk4Tps7grNteCyiIIEDsC2aHhiXHD6zNHsItpxYusaFfyQinFWnK4CAYKWb9ZNIwHIDUIB4vq807QGAhYsnoj1Lg/ajWvtEKBwYjEzDz9OjB91lw7lpCnHtmKKw5A+TNIVGpDDZ/jRBqETsPaePtiXC9UTHZQyM3gFoeVXiJw9KSU/gjIx9REihCaWWPbnuQSeIONGGlVWY9V4DTZIsJr9/uwDcbioeXDD3G1ezGtNPPRSNTtq08QlUtE4mEtKea/+ObpllKZCeZGn6AJhMn+uqMIP95FFlqBB55YzRcLZY+Igi/qm/9LJ9RinAhxRVXiwzeQ+BdVA6jshAAzr+7wklux6lZAa0xGw9pgTv7MI4RP2LJ/LMP1ppFsnv9n/qt93Ax1VEwEu3xHZe3VTYL9tbXOPTZutf6fKjUrW7wSSuy637queESjYnnPKSb1vZcPxjSFlyh+GJvxu/3PurF9aqfiBdiorIBre+pQS4lakLtoft5nsbA+4iYUwrXR58qUPVUqQ7a0A0hedOWlp6g9ixLa6nugUP5aobJzR71T8l/IjqpnY2EEd/iINEb0XfUiZtB5zHaqFWejBtmWwCI=
|
||||
- node_js: '8.9'
|
||||
env: SLS_IGNORE_WARNING=*
|
||||
- node_js: '8.9'
|
||||
env:
|
||||
- INTEGRATION_TEST=true
|
||||
- INTEGRATION_TEST_SUITE=simple
|
||||
- SLS_IGNORE_WARNING=*
|
||||
- secure: Ia2nYzOeYvTE6qOP7DBKX3BO7s/U7TXdsvB2nlc3kOPFi//IbTVD0/cLKCAE5XqTzrrliHINSVsFcJNSfjCwmDSRmgoIGrHj5CJkWpkI6FEPageo3mdqFQYEc8CZeAjsPBNaHe6Ewzg0Ev/sjTByLSJYVqokzDCF1QostSxx1Ss6SGt1zjxeP/Hp4yOJn52VAm9IHAKYn7Y62nMAFTaaTPUQHvW0mJj6m2Z8TWyPU+2Bx6mliO65gTPFGs+PdHGwHtmSF/4IcUO504x+HjDuwzW2itomLXZmIOFfGDcFYadKWzVMAfJzoRWOcVKF4jXdMoSCOviWpHGtK35E7K956MTXkroVoWCS7V0knQDovbRZj8c8td8mS4tdprUA+TzgZoHet2atWNtMuTh79rdmwoAO+IAWJegYj62Tdfy3ycESzY+KxSaV8kysG9sR3PRFoWjZerA7MhLZEzQMORXDGjJlgwLaZfYVqjlsGe5p5etFBUTd0WbFgSwOKLoA2U/fm7WzqItkjs3UWaHuvFVvwYixGxjEVmVczS6wa2cdGpHtVD9H7km4fPEzljHqQ26v0P5e8eylgqLF2IB6mL7UqGFrAtrMvAgN/M3gnq4dTs/wq1AJIOxEP7YW7kc0NAldk8vUz6t5GzCPNcuukxAku91Awnh0twxgUywatgJLZPY=
|
||||
- secure: Dgaa5XIsA5Vbw/CYQLUAuVVsDX26C8+f1XYGwsbNmFQKbKvM8iy9lGrHlfrT3jftJkJH6re8tP1RjyZjjzLe25KPk4Tps7grNteCyiIIEDsC2aHhiXHD6zNHsItpxYusaFfyQinFWnK4CAYKWb9ZNIwHIDUIB4vq807QGAhYsnoj1Lg/ajWvtEKBwYjEzDz9OjB91lw7lpCnHtmKKw5A+TNIVGpDDZ/jRBqETsPaePtiXC9UTHZQyM3gFoeVXiJw9KSU/gjIx9REihCaWWPbnuQSeIONGGlVWY9V4DTZIsJr9/uwDcbioeXDD3G1ezGtNPPRSNTtq08QlUtE4mEtKea/+ObpllKZCeZGn6AJhMn+uqMIP95FFlqBB55YzRcLZY+Igi/qm/9LJ9RinAhxRVXiwzeQ+BdVA6jshAAzr+7wklux6lZAa0xGw9pgTv7MI4RP2LJ/LMP1ppFsnv9n/qt93Ax1VEwEu3xHZe3VTYL9tbXOPTZutf6fKjUrW7wSSuy637queESjYnnPKSb1vZcPxjSFlyh+GJvxu/3PurF9aqfiBdiorIBre+pQS4lakLtoft5nsbA+4iYUwrXR58qUPVUqQ7a0A0hedOWlp6g9ixLa6nugUP5aobJzR71T8l/IjqpnY2EEd/iINEb0XfUiZtB5zHaqFWejBtmWwCI=
|
||||
- node_js: '8.9'
|
||||
env:
|
||||
- DISABLE_TESTS=true
|
||||
- LINTING=true
|
||||
- node_js: '10.6'
|
||||
env:
|
||||
- DISABLE_TESTS=true
|
||||
- LINTING=true
|
||||
- node_js: '10.7'
|
||||
env:
|
||||
- DISABLE_TESTS=true
|
||||
- LINTING=true
|
||||
sudo: false
|
||||
|
||||
git:
|
||||
# Minimize git history, but ensure to not break things:
|
||||
# - Merging multiple PR's around same time may introduce a case where it's not
|
||||
# the last merge commit that is to be tested
|
||||
depth: 10
|
||||
|
||||
cache:
|
||||
# Not relying on 'npm' shortcut, as per Travis docs it's the only 'node_modules' that it'll cache
|
||||
directories:
|
||||
- $HOME/.npm
|
||||
- node_modules
|
||||
|
||||
# Ensure to install dependencies at their latest versions
|
||||
install:
|
||||
- travis_retry npm install
|
||||
script:
|
||||
- if [[ -z "$INTEGRATION_TEST" && -z "$DISABLE_TESTS" ]]; then npm test; fi
|
||||
- if [[ ! -z "$DISABLE_TESTS" && ! -z "$LINTING" && -z "$INTEGRATION_TEST" ]]; then
|
||||
npm run lint; fi
|
||||
- if [[ ! -z "$INTEGRATION_TEST" && ! -z ${AWS_ACCESS_KEY_ID+x} && "$INTEGRATION_TEST_SUITE"
|
||||
== "simple" ]]; then npm run simple-integration-test; fi
|
||||
after_success:
|
||||
- cat ./coverage/lcov.info | ./node_modules/coveralls/bin/coveralls.js && rm -rf ./coverage
|
||||
deploy:
|
||||
provider: npm
|
||||
email: services@serverless.com
|
||||
skip_cleanup: true
|
||||
on:
|
||||
tags: true
|
||||
node: 10.7
|
||||
api_key:
|
||||
secure: EgoetjrRlGfvGnmVp8A0btr1CzB0hl7owVIpbfk4zXJzhGEbHoVu0CG0IdmyLN+JlaZa7EDJTjkDCd6g3fVAh9TT7ZCeaq8YwbZDrql7mAJj7xYQAyM4eSkc95BRzcFJBx7Mxr6H90IDLxKr6ZtB+HEdiHN+59XbepKYYJeb1jHfnKn5xzOqk4BdnZo6pKfudfeO+7/BwJJ0FwlFA40bY2HS/Lp+NG/2IedNR7k3m/5W83/XH5qlWP8jhBKlxrAzks27aNo+42xHkRCVyPViJKq0mfz1hl2bfswChWHgaCuajp+0amNL39pgIX9eXxFc3bNX9Iftox5t31elEhsw06vvuAaVkKEd+VEMaDySbQ9M+irKZeREg+NFYZLnc2WiEE3Sexo6hm9eM2q2KEZ7bleN9B0CQAut1XXLRQEts80rzss4Z2Q7AZb9cOYBQlj9Wf1X0Y74UqvnDn83a4Y38a+lhx7J2q691ZeM1UFSCdO0QfeJRkB55bSyHqUqrLAqUN7eNsKGdBH0kvYIGFREgGgReEpBRAuNqWuJ/5qexp63Kbf+09raG5IvfxSIM5fJ5KE5VxSduBdRnSH0GNKfjuq296/Rg4fmm/bygZ3Yk5L6Wd41SUU8uHzlZFBwtcvxAKDTQe6s+5JU24ilqxOx6J4Ut34X3dIbLLAmoB1ogdM=
|
||||
# Note: with `npm update` there seems no way to update all project dependency groups in one run
|
||||
- npm update --no-save # Updates just dependencies
|
||||
# Note: npm documents --dev option for dev dependencies update, but it's only --save-dev that works
|
||||
- npm update --save-dev --no-save # Updates just devDependencies
|
||||
|
||||
branches:
|
||||
only:
|
||||
- master # Do not build PR branches
|
||||
- /^v\d+\.\d+\.\d+$/ # Ensure to build release tags
|
||||
|
||||
env:
|
||||
global:
|
||||
- SLS_IGNORE_WARNING=*
|
||||
- FORCE_COLOR=1 # Ensure colored output (color support is not detected in some cases)
|
||||
|
||||
stages:
|
||||
- name: Test
|
||||
- name: Integration Test
|
||||
if: branch = master AND type = push
|
||||
- name: Deploy
|
||||
if: tag =~ ^v\d+\.\d+\.\d+$
|
||||
|
||||
before_script:
|
||||
# Fail build right after first script fails. Travis doesn't ensure that: https://github.com/travis-ci/travis-ci/issues/1066
|
||||
# More info on below line: https://www.davidpashley.com/articles/writing-robust-shell-scripts/#idm5413512
|
||||
- set -e
|
||||
|
||||
# Ensure to fail build if deploy fails, Travis doesn't ensure that: https://github.com/travis-ci/travis-ci/issues/921
|
||||
before_deploy:
|
||||
# Remove eventual old npm logs
|
||||
- rm -rf ~/.npm/_logs
|
||||
after_deploy:
|
||||
- |
|
||||
# npm creates log only on failure
|
||||
if [ -d ~/.npm/_logs ]; then
|
||||
# Undocumented way to force Travis build to fail
|
||||
travis_terminate 1
|
||||
fi
|
||||
|
||||
jobs:
|
||||
include:
|
||||
# In most cases it's best to configure one job per Platform & Node.js version combination
|
||||
# (job boot & setup takes ca 1 minute, one task run usually lasts seconds)
|
||||
|
||||
# PR's
|
||||
- name: 'Prettier check updated, Lint updated, Unit Tests - Linux - Node.js v12'
|
||||
if: type = pull_request
|
||||
node_js: 12
|
||||
script:
|
||||
- npm run prettier-check-updated
|
||||
- npm run lint-updated
|
||||
- npm test
|
||||
|
||||
# master branch and version tags
|
||||
- name: 'Lint, Unit Tests - Linux - Node.js v12'
|
||||
if: type != pull_request
|
||||
node_js: 12
|
||||
script:
|
||||
- npm run lint
|
||||
- npm test
|
||||
|
||||
- name: 'Unit Tests - Windows - Node.js v12'
|
||||
os: windows
|
||||
node_js: 12
|
||||
before_install:
|
||||
# Ensure Python 2 in Windows enviroment (Ruby is already preinstalled)
|
||||
- |
|
||||
if [ $TRAVIS_OS_NAME = windows ]
|
||||
then
|
||||
choco install python2 &&
|
||||
export PATH="/c/Python27:/c/Python27/Scripts:$PATH"
|
||||
fi
|
||||
|
||||
- name: 'Isolated Unit Tests, Package Integration Tests - Linux - Node.js v10'
|
||||
node_js: 10
|
||||
script:
|
||||
- npm run test-isolated
|
||||
- npm run integration-test-run-package
|
||||
|
||||
- name: 'Unit Tests, Coverage - Linux - Node.js v8'
|
||||
node_js: 8
|
||||
script: npm run coverage
|
||||
after_success:
|
||||
- cat ./coverage/lcov.info | ./node_modules/coveralls/bin/coveralls.js
|
||||
- rm -rf ./coverage
|
||||
|
||||
- name: 'Unit Tests - Linux - Node.js v6'
|
||||
node_js: 6
|
||||
|
||||
- stage: Integration Test
|
||||
name: 'Integration Tests - Linux - Node.js v12'
|
||||
node_js: 12
|
||||
env:
|
||||
# AWS_ACCESS_KEY_ID
|
||||
- secure: Ia2nYzOeYvTE6qOP7DBKX3BO7s/U7TXdsvB2nlc3kOPFi//IbTVD0/cLKCAE5XqTzrrliHINSVsFcJNSfjCwmDSRmgoIGrHj5CJkWpkI6FEPageo3mdqFQYEc8CZeAjsPBNaHe6Ewzg0Ev/sjTByLSJYVqokzDCF1QostSxx1Ss6SGt1zjxeP/Hp4yOJn52VAm9IHAKYn7Y62nMAFTaaTPUQHvW0mJj6m2Z8TWyPU+2Bx6mliO65gTPFGs+PdHGwHtmSF/4IcUO504x+HjDuwzW2itomLXZmIOFfGDcFYadKWzVMAfJzoRWOcVKF4jXdMoSCOviWpHGtK35E7K956MTXkroVoWCS7V0knQDovbRZj8c8td8mS4tdprUA+TzgZoHet2atWNtMuTh79rdmwoAO+IAWJegYj62Tdfy3ycESzY+KxSaV8kysG9sR3PRFoWjZerA7MhLZEzQMORXDGjJlgwLaZfYVqjlsGe5p5etFBUTd0WbFgSwOKLoA2U/fm7WzqItkjs3UWaHuvFVvwYixGxjEVmVczS6wa2cdGpHtVD9H7km4fPEzljHqQ26v0P5e8eylgqLF2IB6mL7UqGFrAtrMvAgN/M3gnq4dTs/wq1AJIOxEP7YW7kc0NAldk8vUz6t5GzCPNcuukxAku91Awnh0twxgUywatgJLZPY=
|
||||
# AWS_SECRET_ACCESS_KEY
|
||||
- secure: Dgaa5XIsA5Vbw/CYQLUAuVVsDX26C8+f1XYGwsbNmFQKbKvM8iy9lGrHlfrT3jftJkJH6re8tP1RjyZjjzLe25KPk4Tps7grNteCyiIIEDsC2aHhiXHD6zNHsItpxYusaFfyQinFWnK4CAYKWb9ZNIwHIDUIB4vq807QGAhYsnoj1Lg/ajWvtEKBwYjEzDz9OjB91lw7lpCnHtmKKw5A+TNIVGpDDZ/jRBqETsPaePtiXC9UTHZQyM3gFoeVXiJw9KSU/gjIx9REihCaWWPbnuQSeIONGGlVWY9V4DTZIsJr9/uwDcbioeXDD3G1ezGtNPPRSNTtq08QlUtE4mEtKea/+ObpllKZCeZGn6AJhMn+uqMIP95FFlqBB55YzRcLZY+Igi/qm/9LJ9RinAhxRVXiwzeQ+BdVA6jshAAzr+7wklux6lZAa0xGw9pgTv7MI4RP2LJ/LMP1ppFsnv9n/qt93Ax1VEwEu3xHZe3VTYL9tbXOPTZutf6fKjUrW7wSSuy637queESjYnnPKSb1vZcPxjSFlyh+GJvxu/3PurF9aqfiBdiorIBre+pQS4lakLtoft5nsbA+4iYUwrXR58qUPVUqQ7a0A0hedOWlp6g9ixLa6nugUP5aobJzR71T8l/IjqpnY2EEd/iINEb0XfUiZtB5zHaqFWejBtmWwCI=
|
||||
script:
|
||||
- npm run integration-test-run-basic || { npm run integration-test-cleanup; exit 1; }
|
||||
- npm run integration-test-run-all || { npm run integration-test-cleanup; exit 1; }
|
||||
- npm run integration-test-cleanup
|
||||
|
||||
- stage: Deploy
|
||||
node_js: 12
|
||||
script: skip
|
||||
deploy:
|
||||
provider: npm
|
||||
email: services@serverless.com
|
||||
on:
|
||||
tags: true
|
||||
api_key:
|
||||
secure: EgoetjrRlGfvGnmVp8A0btr1CzB0hl7owVIpbfk4zXJzhGEbHoVu0CG0IdmyLN+JlaZa7EDJTjkDCd6g3fVAh9TT7ZCeaq8YwbZDrql7mAJj7xYQAyM4eSkc95BRzcFJBx7Mxr6H90IDLxKr6ZtB+HEdiHN+59XbepKYYJeb1jHfnKn5xzOqk4BdnZo6pKfudfeO+7/BwJJ0FwlFA40bY2HS/Lp+NG/2IedNR7k3m/5W83/XH5qlWP8jhBKlxrAzks27aNo+42xHkRCVyPViJKq0mfz1hl2bfswChWHgaCuajp+0amNL39pgIX9eXxFc3bNX9Iftox5t31elEhsw06vvuAaVkKEd+VEMaDySbQ9M+irKZeREg+NFYZLnc2WiEE3Sexo6hm9eM2q2KEZ7bleN9B0CQAut1XXLRQEts80rzss4Z2Q7AZb9cOYBQlj9Wf1X0Y74UqvnDn83a4Y38a+lhx7J2q691ZeM1UFSCdO0QfeJRkB55bSyHqUqrLAqUN7eNsKGdBH0kvYIGFREgGgReEpBRAuNqWuJ/5qexp63Kbf+09raG5IvfxSIM5fJ5KE5VxSduBdRnSH0GNKfjuq296/Rg4fmm/bygZ3Yk5L6Wd41SUU8uHzlZFBwtcvxAKDTQe6s+5JU24ilqxOx6J4Ut34X3dIbLLAmoB1ogdM=
|
||||
|
||||
@ -5,37 +5,41 @@ Below are projects and plugins relating to version 0.5 and below. Note that thes
|
||||
You can read the v0.5.x documentation at [readme.io](https://serverless.readme.io/v0.5.0/docs).
|
||||
|
||||
## Projects (v0.5.x)
|
||||
Serverless Projects are shareable and installable. You can publish them to npm and install them via the Serverless Framework CLI by using `$ serverless project install <project-name>`
|
||||
* [serverless-graphql](https://github.com/serverless/serverless-graphql) - Official Serverless boilerplate to kick start your project
|
||||
* [serverless-starter](https://github.com/serverless/serverless-starter) - A simple boilerplate for new projects (JavaScript) with a few architectural options
|
||||
* [serverless-starter-python](https://github.com/alexcasalboni/serverless-starter-python) - A simple boilerplate for new projects (Python) with a few architectural options
|
||||
* [serverless-graphql-blog](https://github.com/serverless/serverless-graphql-blog) - A blog boilerplate that leverages GraphQL in front of DynamoDB to offer a minimal REST API featuring only 1 endpoint
|
||||
* [serverless-authentication-boilerplate](https://github.com/laardee/serverless-authentication-boilerplate) - A generic authentication boilerplate for Serverless framework
|
||||
* [sc5-serverless-boilerplate](https://github.com/SC5/sc5-serverless-boilerplate) - A boilerplate for test driven development of REST endpoints
|
||||
* [MoonMail] (https://github.com/microapps/MoonMail) - Build your own email marketing infrastructure using Lambda + SES
|
||||
|
||||
Serverless Projects are shareable and installable. You can publish them to npm and install them via the Serverless Framework CLI by using `$ serverless project install <project-name>`
|
||||
|
||||
- [serverless-graphql](https://github.com/serverless/serverless-graphql) - Official Serverless boilerplate to kick start your project
|
||||
- [serverless-starter](https://github.com/serverless/serverless-starter) - A simple boilerplate for new projects (JavaScript) with a few architectural options
|
||||
- [serverless-starter-python](https://github.com/alexcasalboni/serverless-starter-python) - A simple boilerplate for new projects (Python) with a few architectural options
|
||||
- [serverless-graphql-blog](https://github.com/serverless/serverless-graphql-blog) - A blog boilerplate that leverages GraphQL in front of DynamoDB to offer a minimal REST API featuring only 1 endpoint
|
||||
- [serverless-authentication-boilerplate](https://github.com/laardee/serverless-authentication-boilerplate) - A generic authentication boilerplate for Serverless framework
|
||||
- [sc5-serverless-boilerplate](https://github.com/SC5/sc5-serverless-boilerplate) - A boilerplate for test driven development of REST endpoints
|
||||
- [MoonMail](https://github.com/microapps/MoonMail) - Build your own email marketing infrastructure using Lambda + SES
|
||||
|
||||
## Plugins (v0.5.x)
|
||||
Serverless is composed of Plugins. A group of default Plugins ship with the Framework, and here are some others you can add to improve/help your workflow:
|
||||
* [Meta Sync](https://github.com/serverless/serverless-meta-sync) - Securely sync your the variables in your project's `_meta/variables` across your team.
|
||||
* [Hook Scripts](https://github.com/kennu/serverless-plugin-hookscripts) - Easily create shell script hooks that are run whenever Serverless actions are executed.
|
||||
* [CORS](https://github.com/joostfarla/serverless-cors-plugin) - Adds support for CORS (Cross-origin resource sharing).
|
||||
* [Serve](https://github.com/Nopik/serverless-serve) - Simulate API Gateway locally, so all function calls can be run via localhost.
|
||||
* [Webpack](https://github.com/asprouse/serverless-webpack-plugin) - Use Webpack to optimize your Serverless Node.js Functions.
|
||||
* [Serverless Client](https://github.com/serverless/serverless-client-s3) - Deploy and config a web client for your Serverless project to S3.
|
||||
* [Alerting](https://github.com/martinlindenberg/serverless-plugin-alerting) - This Plugin adds Cloudwatch Alarms with SNS notifications for your Lambda functions.
|
||||
* [Optimizer](https://github.com/serverless/serverless-optimizer-plugin) - Optimizes your code for performance in Lambda. Supports coffeeify, babelify and other transforms
|
||||
* [CloudFormation Validator](https://github.com/tmilewski/serverless-resources-validation-plugin) - Adds support for validating your CloudFormation template.
|
||||
* [Prune](https://github.com/Nopik/serverless-lambda-prune-plugin) - Delete old versions of AWS lambdas from your account so that you don't exceed the code storage limit.
|
||||
* [Base-Path](https://github.com/daffinity/serverless-base-path-plugin) - Sets a base path for all API Gateway endpoints in a Component.
|
||||
* [Test](https://github.com/arabold/serverless-test-plugin) - A Simple Integration Test Framework for Serverless.
|
||||
* [SNS Subscribe](https://github.com/martinlindenberg/serverless-plugin-sns) - This plugin easily subscribes your lambda functions to SNS notifications.
|
||||
* [JSHint](https://github.com/joostfarla/serverless-jshint-plugin) - Detect errors and potential problems in your Lambda functions.
|
||||
* [ESLint](https://github.com/nishantjain91/serverless-eslint-plugin) - Detect errors and potential problems in your Lambda functions using eslint.
|
||||
* [Mocha](https://github.com/SC5/serverless-mocha-plugin) - Enable test driven development by creating test cases when creating new functions
|
||||
* [Function-Package](https://github.com/HyperBrain/serverless-package-plugin) - Package your lambdas without deploying to AWS.
|
||||
* [Sentry](https://github.com/arabold/serverless-sentry-plugin) - Automatically send errors and exceptions to [Sentry](https://getsentry.com).
|
||||
* [Auto-Prune](https://github.com/arabold/serverless-autoprune-plugin) - Delete old AWS Lambda versions.
|
||||
* [Serverless Secrets](https://github.com/trek10inc/serverless-secrets) - Easily encrypt and decrypt secrets in your Serverless projects
|
||||
* [Serverless DynamoDB Local](https://github.com/99xt/serverless-dynamodb-local) - Simulate DynamoDB instance locally.
|
||||
* [Serverless Dependency Install](https://github.com/99xt/serverless-dependency-install) - Manage node, serverless dependencies easily within the project.
|
||||
* [Serverless Header Function](https://github.com/blackevil245/serverless-header-function) - Automatically run a javascript script on every Serverless action hooks.
|
||||
|
||||
Serverless is composed of Plugins. A group of default Plugins ship with the Framework, and here are some others you can add to improve/help your workflow:
|
||||
|
||||
- [Meta Sync](https://github.com/serverless/serverless-meta-sync) - Securely sync your the variables in your project's `_meta/variables` across your team.
|
||||
- [Hook Scripts](https://github.com/kennu/serverless-plugin-hookscripts) - Easily create shell script hooks that are run whenever Serverless actions are executed.
|
||||
- [CORS](https://github.com/joostfarla/serverless-cors-plugin) - Adds support for CORS (Cross-origin resource sharing).
|
||||
- [Serve](https://github.com/Nopik/serverless-serve) - Simulate API Gateway locally, so all function calls can be run via localhost.
|
||||
- [Webpack](https://github.com/asprouse/serverless-webpack-plugin) - Use Webpack to optimize your Serverless Node.js Functions.
|
||||
- [Serverless Client](https://github.com/serverless/serverless-client-s3) - Deploy and config a web client for your Serverless project to S3.
|
||||
- [Alerting](https://github.com/martinlindenberg/serverless-plugin-alerting) - This Plugin adds Cloudwatch Alarms with SNS notifications for your Lambda functions.
|
||||
- [Optimizer](https://github.com/serverless/serverless-optimizer-plugin) - Optimizes your code for performance in Lambda. Supports coffeeify, babelify and other transforms
|
||||
- [CloudFormation Validator](https://github.com/tmilewski/serverless-resources-validation-plugin) - Adds support for validating your CloudFormation template.
|
||||
- [Prune](https://github.com/Nopik/serverless-lambda-prune-plugin) - Delete old versions of AWS lambdas from your account so that you don't exceed the code storage limit.
|
||||
- [Base-Path](https://github.com/daffinity/serverless-base-path-plugin) - Sets a base path for all API Gateway endpoints in a Component.
|
||||
- [Test](https://github.com/arabold/serverless-test-plugin) - A Simple Integration Test Framework for Serverless.
|
||||
- [SNS Subscribe](https://github.com/martinlindenberg/serverless-plugin-sns) - This plugin easily subscribes your lambda functions to SNS notifications.
|
||||
- [JSHint](https://github.com/joostfarla/serverless-jshint-plugin) - Detect errors and potential problems in your Lambda functions.
|
||||
- [ESLint](https://github.com/nishantjain91/serverless-eslint-plugin) - Detect errors and potential problems in your Lambda functions using eslint.
|
||||
- [Mocha](https://github.com/SC5/serverless-mocha-plugin) - Enable test driven development by creating test cases when creating new functions
|
||||
- [Function-Package](https://github.com/HyperBrain/serverless-package-plugin) - Package your lambdas without deploying to AWS.
|
||||
- [Sentry](https://github.com/arabold/serverless-sentry-plugin) - Automatically send errors and exceptions to [Sentry](https://getsentry.com).
|
||||
- [Auto-Prune](https://github.com/arabold/serverless-autoprune-plugin) - Delete old AWS Lambda versions.
|
||||
- [Serverless Secrets](https://github.com/trek10inc/serverless-secrets) - Easily encrypt and decrypt secrets in your Serverless projects
|
||||
- [Serverless DynamoDB Local](https://github.com/99xt/serverless-dynamodb-local) - Simulate DynamoDB instance locally.
|
||||
- [Serverless Dependency Install](https://github.com/99xt/serverless-dependency-install) - Manage node, serverless dependencies easily within the project.
|
||||
- [Serverless Header Function](https://github.com/blackevil245/serverless-header-function) - Automatically run a javascript script on every Serverless action hooks.
|
||||
|
||||
140
CHANGELOG.md
140
CHANGELOG.md
@ -1,3 +1,140 @@
|
||||
# 1.47.0 (2019-07-10)
|
||||
|
||||
- [Add Onica as a Consultant](https://github.com/serverless/serverless/pull/6300)
|
||||
- [Correct typo](https://github.com/serverless/serverless/pull/6301)
|
||||
- [Adapt new ESLint and Prettier configuration](https://github.com/serverless/serverless/pull/6284)
|
||||
- [Ensure deploy is triggered in CI](https://github.com/serverless/serverless/pull/6306)
|
||||
- [Remove jsbeautify configuration](https://github.com/serverless/serverless/pull/6309)
|
||||
- [Improve PR template](https://github.com/serverless/serverless/pull/6308)
|
||||
- [Allow users to specify API Gateway Access Log format](https://github.com/serverless/serverless/pull/6299)
|
||||
- [Fix service.provider.region resolution](https://github.com/serverless/serverless/pull/6317)
|
||||
- [Add null as a consultant](https://github.com/serverless/serverless/pull/6323)
|
||||
- [Update very minor typo in credentials.md](https://github.com/serverless/serverless/pull/6321)
|
||||
- [Expose non-errors in informative way](https://github.com/serverless/serverless/pull/6318)
|
||||
- [Fix async leaks detection conditional](https://github.com/serverless/serverless/pull/6319)
|
||||
- [Typo fix in AWS ALB event documentation](https://github.com/serverless/serverless/pull/6325)
|
||||
- [Websockets: fix passing log group ARN](https://github.com/serverless/serverless/pull/6310)
|
||||
- [Specify invoke local option in the guide](https://github.com/serverless/serverless/pull/6327)
|
||||
- [Update Webpack version and usage of aws-nodejs-ecma-script template](https://github.com/serverless/serverless/pull/6324)
|
||||
- [Make ALB event target group names unique](https://github.com/serverless/serverless/pull/6322)
|
||||
- [Improve Travis CI conf](https://github.com/serverless/serverless/pull/6330)
|
||||
- [Support for Github Entreprise in sls create](https://github.com/serverless/serverless/pull/6332)
|
||||
- [Merge patch 1.46.1 release artifacts back into master](https://github.com/serverless/serverless/pull/6343)
|
||||
- [Add support for existing S3 buckets](https://github.com/serverless/serverless/pull/6290)
|
||||
- [PLAT-1202 - Interactive `serverless` create](https://github.com/serverless/serverless/pull/6294)
|
||||
- [PLAT-1091 - message in `npm i` output about the `serverless` quickstart command](https://github.com/serverless/serverless/pull/6238)
|
||||
|
||||
## Meta
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.46.1...v1.47.0)
|
||||
|
||||
# 1.46.1 (2019-06-28)
|
||||
|
||||
- [Fix service.provider.region resolution](https://github.com/serverless/serverless/pull/6317)
|
||||
- [Ensure deploy is triggered in CI](https://github.com/serverless/serverless/pull/6306)
|
||||
|
||||
## Meta
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.46.0...v1.46.1)
|
||||
|
||||
# 1.46.0 (2019-06-26)
|
||||
|
||||
- [Fix formatting issue with Markdown link](https://github.com/serverless/serverless/pull/6228)
|
||||
- [Update docs | dont use provider.tags with shared API Gateway](https://github.com/serverless/serverless/pull/6225)
|
||||
- [Fix: Update azure template](https://github.com/serverless/serverless/pull/6258)
|
||||
- [Improve user message](https://github.com/serverless/serverless/pull/6254)
|
||||
- [Reference custom ApiGateway for models and request validators if conf…](https://github.com/serverless/serverless/pull/6231)
|
||||
- [Ensure integration tests do not fail when run concurrently](https://github.com/serverless/serverless/pull/6256)
|
||||
- [Improve integration test experience](https://github.com/serverless/serverless/pull/6253)
|
||||
- [Fix lambda integration timeout response template](https://github.com/serverless/serverless/pull/6255)
|
||||
- [Fix duplicate packaging issue](https://github.com/serverless/serverless/pull/6244)
|
||||
- [Fix Travis configuration for branch/tag runs](https://github.com/serverless/serverless/pull/6265)
|
||||
- [fixed a typo 🖊](https://github.com/serverless/serverless/pull/6275)
|
||||
- [Fix #6267](https://github.com/serverless/serverless/pull/6268)
|
||||
- [#6017 Allow to load plugin from path](https://github.com/serverless/serverless/pull/6261)
|
||||
- [Added correction based on community feedback](https://github.com/serverless/serverless/pull/6286)
|
||||
- [Remove package-lock.json and shrinkwrap scripts](https://github.com/serverless/serverless/pull/6280)
|
||||
- [Remove README redundant link](https://github.com/serverless/serverless/pull/6288)
|
||||
- [Remove default stage value in provider object](https://github.com/serverless/serverless/pull/6200)
|
||||
- [Use naming to get stackName](https://github.com/serverless/serverless/pull/6285)
|
||||
- [Fix typo in link to ALB docs](https://github.com/serverless/serverless/pull/6292)
|
||||
- [Add ip, method, header and query conditions to ALB events](https://github.com/serverless/serverless/pull/6293)
|
||||
- [Feature/support external websocket api](https://github.com/serverless/serverless/pull/6272)
|
||||
|
||||
## Meta
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.45.1...v1.46.0)
|
||||
|
||||
# 1.45.1 (2019-06-12)
|
||||
|
||||
- [Fix IAM policies setup for functions with custom name](https://github.com/serverless/serverless/pull/6240)
|
||||
- [Fix Travis CI deploy config](https://github.com/serverless/serverless/pull/6234)
|
||||
|
||||
## Meta
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.45.0...v1.45.1)
|
||||
|
||||
# 1.45.0 (2019-06-12)
|
||||
|
||||
- [Add `--config` option](https://github.com/serverless/serverless/pull/6216)
|
||||
- [Fix and improve ESlint config](https://github.com/serverless/serverless/pull/6188)
|
||||
- [Tests: Fix mocha config](https://github.com/serverless/serverless/pull/6187)
|
||||
- [Thorough integration testing](https://github.com/serverless/serverless/pull/6148)
|
||||
- [Tests: Isolation improvements](https://github.com/serverless/serverless/pull/6186)
|
||||
- [Add support for Websocket Logs](https://github.com/serverless/serverless/pull/6088)
|
||||
- [Cleanup and improve Travis CI configuration](https://github.com/serverless/serverless/pull/6178)
|
||||
- [Tests: Fix stub configuration](https://github.com/serverless/serverless/pull/6205)
|
||||
- [Tests: Upgrade Sinon](https://github.com/serverless/serverless/pull/6206)
|
||||
- [Add Application Load Balancer event source](https://github.com/serverless/serverless/pull/6073)
|
||||
- [Do not run integration tests for PR's](https://github.com/serverless/serverless/pull/6207)
|
||||
- [Adding a validation to validation.js script](https://github.com/serverless/serverless/pull/6192)
|
||||
- [Tests: Upgrade dependencies, improve isolation and experience on Windows](https://github.com/serverless/serverless/pull/6208)
|
||||
- [Add support for S3 hosted package artifacts](https://github.com/serverless/serverless/pull/6196)
|
||||
- [Remove root README generator](https://github.com/serverless/serverless/pull/6215)
|
||||
- [Myho/npm lint fix](https://github.com/serverless/serverless/pull/6217)
|
||||
- [Use common prefix for log groups permissions at Lambdas' execution roles](https://github.com/serverless/serverless/pull/6212)
|
||||
- [Update Scala version to 2.13.0 for aws-scala-sbt template](https://github.com/serverless/serverless/pull/6222)
|
||||
|
||||
## Meta
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.44.1...v1.45.0)
|
||||
|
||||
# 1.44.1 (2019-05-28)
|
||||
|
||||
- [Fix enterprise plugin lookup in global yarn installs](https://github.com/serverless/serverless/pull/6183)
|
||||
|
||||
## Meta
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.44.0...v1.44.1)
|
||||
|
||||
# 1.44.0 (2019-05-28)
|
||||
|
||||
- [Built in integration of Serverless Enterprise](https://github.com/serverless/serverless/pull/6074)
|
||||
- [Setup Travis Windows support / Remove AppVeyor](https://github.com/serverless/serverless/pull/6132)
|
||||
- [Update required Node.js version / Add version check](https://github.com/serverless/serverless/pull/6077)
|
||||
- [Add scopes for cognito type APIGW referenced authorizer ](https://github.com/serverless/serverless/pull/6150)
|
||||
- [Do not throw error if authorizer has empty claims](https://github.com/serverless/serverless/pull/6121)
|
||||
- [Tests: Patch mocha bugs and fix broken async flow cases](https://github.com/serverless/serverless/pull/6157)
|
||||
- [Fix tagging API Gateway stage fails if tag contains special characters like space](https://github.com/serverless/serverless/pull/6139)
|
||||
- [Solve the problem of principal format in China region](https://github.com/serverless/serverless/pull/6127)
|
||||
- [Upgrade mocha, switch from istanbul to nyc, improve tests configuration](https://github.com/serverless/serverless/pull/6169)
|
||||
|
||||
## Meta
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.43.0...v1.44.0)
|
||||
|
||||
# 1.43.0 (2019-05-20)
|
||||
|
||||
- [Update services.md](https://github.com/serverless/serverless/pull/6138)
|
||||
- [Azure: exclude development dependency files when packaging functions](https://github.com/serverless/serverless/pull/6137)
|
||||
- [Update release process docs and toolings](https://github.com/serverless/serverless/pull/6113)
|
||||
- [Update AWS Node.js runtime to version 10](https://github.com/serverless/serverless/pull/6142)
|
||||
- [Fix tests setup issues](https://github.com/serverless/serverless/pull/6147)
|
||||
|
||||
## Meta
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.42.3...v1.43.0)
|
||||
|
||||
# 1.42.3 (2019-05-14)
|
||||
|
||||
- [Update deploy.md](https://github.com/serverless/serverless/pull/6110)
|
||||
@ -11,7 +148,8 @@
|
||||
- [Improve handling of custom API Gateway options](https://github.com/serverless/serverless/pull/6129)
|
||||
|
||||
## Meta
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.42.2...v1.42.3)
|
||||
|
||||
- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.42.2...v1.42.3)
|
||||
|
||||
# 1.42.2 (2019-05-10)
|
||||
|
||||
|
||||
@ -14,21 +14,21 @@ orientation.
|
||||
Examples of behavior that contributes to creating a positive environment
|
||||
include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
- Using welcoming and inclusive language
|
||||
- Being respectful of differing viewpoints and experiences
|
||||
- Gracefully accepting constructive criticism
|
||||
- Focusing on what is best for the community
|
||||
- Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery and unwelcome sexual attention or
|
||||
advances
|
||||
* Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or electronic
|
||||
- The use of sexualized language or imagery and unwelcome sexual attention or
|
||||
advances
|
||||
- Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
- Public or private harassment
|
||||
- Publishing others' private information, such as a physical or electronic
|
||||
address, without explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a
|
||||
- Other conduct which could reasonably be considered inappropriate in a
|
||||
professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
@ -38,7 +38,19 @@ You can do that by replying to [issues on Github](https://github.com/serverless/
|
||||
|
||||
# Code Style
|
||||
|
||||
We aim for clean, consistent code style. We're using ESlint to check for codestyle issues using the Airbnb preset (you can run `npm run lint` to lint your code).
|
||||
We aim for clean, consistent code style. We're using ESlint to check for codestyle issues using the Airbnb preset.
|
||||
|
||||
## Verifying linting style
|
||||
|
||||
```
|
||||
npm run lint
|
||||
```
|
||||
|
||||
## Fixing lint issues
|
||||
|
||||
```
|
||||
npm run lint:fix
|
||||
```
|
||||
|
||||
To help reduce the effort of creating contributions with this style, an [.editorconfig file](http://editorconfig.org/) is provided that your editor may use to override any conflicting global defaults and automate a subset of the style settings.
|
||||
|
||||
@ -52,11 +64,11 @@ During development, you can easily check coverage by running `npm test`, then op
|
||||
|
||||
Please follow these Testing guidelines when writing your unit tests:
|
||||
|
||||
- Include a top-level `describe('ClassName')` block, with the name of the class you are testing
|
||||
- Inside that top-level `describe()` block, create another `describe('#methodOne()')` block for each class method you might create or modify
|
||||
- For each method, include an `it('should do something')` test case for each logical edge case in your changes
|
||||
- As you write tests, check the code coverage and make sure all lines of code are covered. If not, just add more test cases until everything is covered
|
||||
- For reference and inspiration, please check our `tests` directory
|
||||
- Include a top-level `describe('ClassName')` block, with the name of the class you are testing
|
||||
- Inside that top-level `describe()` block, create another `describe('#methodOne()')` block for each class method you might create or modify
|
||||
- For each method, include an `it('should do something')` test case for each logical edge case in your changes
|
||||
- As you write tests, check the code coverage and make sure all lines of code are covered. If not, just add more test cases until everything is covered
|
||||
- For reference and inspiration, please check our `tests` directory
|
||||
|
||||
## Testing templates
|
||||
|
||||
@ -65,7 +77,7 @@ If you add a new template or want to test a template after changing it you can r
|
||||
To run all integration tests run:
|
||||
|
||||
```
|
||||
./tests/templates/test_all_templates
|
||||
./tests/templates/test-all-templates
|
||||
```
|
||||
|
||||
To run only a specific integration test run:
|
||||
@ -80,7 +92,7 @@ so for example:
|
||||
tests/templates/integration-test-template aws-java-maven mvn package
|
||||
```
|
||||
|
||||
If you add a new template make sure to add it to the `test_all_templates` file and configure the `docker-compose.yml` file for your template.
|
||||
If you add a new template make sure to add it to the `test-all-templates` file and configure the `docker-compose.yml` file for your template.
|
||||
|
||||
# Our Code of Conduct
|
||||
|
||||
|
||||
523
README.md
523
README.md
@ -10,9 +10,9 @@
|
||||
|
||||
[Website](http://www.serverless.com) • [Docs](https://serverless.com/framework/docs/) • [Newsletter](https://serverless.com/subscribe/) • [Gitter](https://gitter.im/serverless/serverless) • [Forum](http://forum.serverless.com) • [Meetups](https://github.com/serverless/meetups) • [Twitter](https://twitter.com/goserverless) • [We're Hiring](https://serverless.com/company/jobs/) • [Enterprise](https://serverless.com/enterprise/)
|
||||
|
||||
**The Serverless Framework** – Build applications comprised of microservices that run in response to events, auto-scale for you, and only charge you when they run. This lowers the total cost of maintaining your apps, enabling you to build more logic, faster.
|
||||
**The Serverless Framework** – Build applications comprised of microservices that run in response to events, auto-scale for you, and only charge you when they run. This lowers the total cost of maintaining your apps, enabling you to build more logic, faster.
|
||||
|
||||
The Framework uses new event-driven compute services, like AWS Lambda, Google Cloud Functions, and more. It's a command-line tool, providing scaffolding, workflow automation and best practices for developing and deploying your serverless architecture. It's also completely extensible via plugins.
|
||||
The Framework uses new event-driven compute services, like AWS Lambda, Google Cloud Functions, and more. It's a command-line tool, providing scaffolding, workflow automation and best practices for developing and deploying your serverless architecture. It's also completely extensible via plugins.
|
||||
|
||||
Serverless is an MIT open-source project, actively maintained by a full-time, venture-backed team.
|
||||
|
||||
@ -24,77 +24,91 @@ Serverless is an MIT open-source project, actively maintained by a full-time, ve
|
||||
|
||||
<img align="right" width="400" src="https://s3-us-west-2.amazonaws.com/assets.site.serverless.com/email/sls-getting-started.gif" />
|
||||
|
||||
* [Quick Start](#quick-start)
|
||||
* [Examples](https://github.com/serverless/examples)
|
||||
* [Services](#services)
|
||||
* [Features](#features)
|
||||
* [Plugins](#v1-plugins)
|
||||
* [Example Projects](#v1-projects)
|
||||
* [Contributing](#contributing)
|
||||
* [Community](#community)
|
||||
* [Consultants](#consultants)
|
||||
* [Licensing](#licensing)
|
||||
* [Previous Version 0.5.x](#v.5)
|
||||
- [Quick Start](#quick-start)
|
||||
- [Examples](https://github.com/serverless/examples)
|
||||
- [Services](#services)
|
||||
- [Features](#features)
|
||||
- [Plugins](https://github.com/serverless/plugins)
|
||||
- [Contributing](#contributing)
|
||||
- [Community](#community)
|
||||
- [Consultants](#consultants)
|
||||
- [Licensing](#licensing)
|
||||
- [Previous Version 0.5.x](#v.5)
|
||||
|
||||
## <a name="quick-start"></a>Quick Start
|
||||
|
||||
[Watch the video guide here](https://serverless.com/framework/) or follow the steps below to create and deploy your first serverless microservice in minutes.
|
||||
|
||||
1. **Install via npm:**
|
||||
```bash
|
||||
npm install -g serverless
|
||||
```
|
||||
|
||||
```bash
|
||||
npm install -g serverless
|
||||
```
|
||||
|
||||
2. **Set-up your [Provider Credentials](./docs/providers/aws/guide/credentials.md)**. [Watch the video on setting up credentials](https://www.youtube.com/watch?v=HSd9uYj2LJA)
|
||||
|
||||
3. **Create a Service:**
|
||||
|
||||
You can create a new service or [install existing services](#how-to-install-a-service).
|
||||
```bash
|
||||
# Create a new Serverless Service/Project
|
||||
serverless create --template aws-nodejs --path my-service
|
||||
# Change into the newly created directory
|
||||
cd my-service
|
||||
```
|
||||
You can create a new service or [install existing services](#how-to-install-a-service).
|
||||
|
||||
```bash
|
||||
# Create a new Serverless Service/Project
|
||||
serverless create --template aws-nodejs --path my-service
|
||||
# Change into the newly created directory
|
||||
cd my-service
|
||||
```
|
||||
|
||||
4. **Deploy a Service:**
|
||||
|
||||
Use this when you have made changes to your Functions, Events or Resources in `serverless.yml` or you simply want to deploy all changes within your Service at the same time.
|
||||
```bash
|
||||
serverless deploy -v
|
||||
```
|
||||
Use this when you have made changes to your Functions, Events or Resources in `serverless.yml` or you simply want to deploy all changes within your Service at the same time.
|
||||
|
||||
```bash
|
||||
serverless deploy -v
|
||||
```
|
||||
|
||||
5. **Deploy the Function:**
|
||||
|
||||
Use this to quickly upload and overwrite your AWS Lambda code on AWS, allowing you to develop faster.
|
||||
```bash
|
||||
serverless deploy function -f hello
|
||||
```
|
||||
Use this to quickly upload and overwrite your AWS Lambda code on AWS, allowing you to develop faster.
|
||||
|
||||
6. **Invoke the Function:**
|
||||
```bash
|
||||
serverless deploy function -f hello
|
||||
```
|
||||
|
||||
Invokes an AWS Lambda Function on AWS and returns logs.
|
||||
```bash
|
||||
serverless invoke -f hello -l
|
||||
```
|
||||
6. **Invoke the Function on AWS:**
|
||||
|
||||
7. **Fetch the Function Logs:**
|
||||
Invokes an AWS Lambda Function on AWS and returns logs.
|
||||
|
||||
Open up a separate tab in your console and stream all logs for a specific Function using this command.
|
||||
```bash
|
||||
serverless logs -f hello -t
|
||||
```
|
||||
```bash
|
||||
serverless invoke -f hello -l
|
||||
```
|
||||
|
||||
8. **Remove the Service:**
|
||||
7. **Invoke the Function on your machine:**
|
||||
|
||||
Removes all Functions, Events and Resources from your AWS account.
|
||||
```bash
|
||||
serverless remove
|
||||
```
|
||||
Invokes an AWS Lambda Function on your local machine and returns logs.
|
||||
|
||||
```bash
|
||||
serverless invoke local -f hello -l
|
||||
```
|
||||
|
||||
8. **Fetch the Function Logs:**
|
||||
|
||||
Open up a separate tab in your console and stream all logs for a specific Function using this command.
|
||||
|
||||
```bash
|
||||
serverless logs -f hello -t
|
||||
```
|
||||
|
||||
9. **Remove the Service:**
|
||||
|
||||
Removes all Functions, Events and Resources from your AWS account.
|
||||
|
||||
```bash
|
||||
serverless remove
|
||||
```
|
||||
|
||||
### How to Install a Service:
|
||||
|
||||
This is a convenience method to install a pre-made Serverless Service locally by downloading the Github repo and unzipping it. Services are listed below.
|
||||
This is a convenience method to install a pre-made Serverless Service locally by downloading the Github repo and unzipping it. Services are listed below.
|
||||
|
||||
```bash
|
||||
serverless install -u https://github.com/your-url-to-the-serverless-service
|
||||
@ -106,365 +120,94 @@ Check out the [Serverless Framework Guide](./docs/providers/aws/guide/README.md)
|
||||
|
||||
The following are services you can instantly install and use by running `serverless install --url <service-github-url>`
|
||||
|
||||
* [serverless-examples](https://github.com/serverless/examples)
|
||||
* [CRUD](https://github.com/pmuens/serverless-crud) - CRUD service, [Scala Port](https://github.com/jahangirmohammed/serverless-crud-scala)
|
||||
* [CRUD with FaunaDB](https://github.com/faunadb/serverless-crud) - CRUD service using FaunaDB
|
||||
* [CRUD with S3](https://github.com/tscanlin/serverless-s3-crud) - CRUD service using S3
|
||||
* [GraphQL Boilerplate](https://github.com/serverless/serverless-graphql) - GraphQL application Boilerplate service
|
||||
* [Authentication](https://github.com/laardee/serverless-authentication-boilerplate) - Authentication boilerplate service
|
||||
* [Mailer](https://github.com/eahefnawy/serverless-mailer) - Service for sending emails
|
||||
* [Kinesis streams](https://github.com/pmuens/serverless-kinesis-streams) - Service to showcase Kinesis stream support
|
||||
* [DynamoDB streams](https://github.com/pmuens/serverless-dynamodb-streams) - Service to showcase DynamoDB stream support
|
||||
* [Landingpage backend](https://github.com/pmuens/serverless-landingpage-backend) - Landingpage backend service to store E-Mail addresses
|
||||
* [Facebook Messenger Chatbot](https://github.com/pmuens/serverless-facebook-messenger-bot) - Chatbot for the Facebook Messenger platform
|
||||
* [Lambda chaining](https://github.com/pmuens/serverless-lambda-chaining) - Service which chains Lambdas through SNS
|
||||
* [Secured API](https://github.com/pmuens/serverless-secured-api) - Service which exposes an API key accessible API
|
||||
* [Authorizer](https://github.com/eahefnawy/serverless-authorizer) - Service that uses API Gateway custom authorizers
|
||||
* [Thumbnails](https://github.com/eahefnawy/serverless-thumbnails) - Service that takes an image url and returns a 100x100 thumbnail
|
||||
* [Boilerplate](https://github.com/eahefnawy/serverless-boilerplate) - Opinionated boilerplate
|
||||
* [ES6 + Jest](https://github.com/americansystems/serverless-es6-jest) - ES6 + Jest Boilerplate
|
||||
* [PHP](https://github.com/ZeroSharp/serverless-php) - Call a PHP function from your lambda
|
||||
* [Ruby](https://github.com/stewartlord/serverless-ruby) - Call a Ruby function from your lambda
|
||||
* [Slack App](https://github.com/johnagan/serverless-slack-app) - Slack App Boilerplate with OAuth and Bot actions
|
||||
* [Swift](https://github.com/choefele/swift-lambda-app) - Full-featured project template to develop Lambda functions in Swift
|
||||
* [Cloudwatch Alerts on Slack](https://github.com/dav009/serverless-aws-alarms-notifier) - Get AWS Cloudwatch alerts notifications on Slack
|
||||
- [serverless-examples](https://github.com/serverless/examples)
|
||||
- [CRUD](https://github.com/pmuens/serverless-crud) - CRUD service, [Scala Port](https://github.com/jahangirmohammed/serverless-crud-scala)
|
||||
- [CRUD with FaunaDB](https://github.com/faunadb/serverless-crud) - CRUD service using FaunaDB
|
||||
- [CRUD with S3](https://github.com/tscanlin/serverless-s3-crud) - CRUD service using S3
|
||||
- [GraphQL Boilerplate](https://github.com/serverless/serverless-graphql) - GraphQL application Boilerplate service
|
||||
- [Authentication](https://github.com/laardee/serverless-authentication-boilerplate) - Authentication boilerplate service
|
||||
- [Mailer](https://github.com/eahefnawy/serverless-mailer) - Service for sending emails
|
||||
- [Kinesis streams](https://github.com/pmuens/serverless-kinesis-streams) - Service to showcase Kinesis stream support
|
||||
- [DynamoDB streams](https://github.com/pmuens/serverless-dynamodb-streams) - Service to showcase DynamoDB stream support
|
||||
- [Landingpage backend](https://github.com/pmuens/serverless-landingpage-backend) - Landingpage backend service to store E-Mail addresses
|
||||
- [Facebook Messenger Chatbot](https://github.com/pmuens/serverless-facebook-messenger-bot) - Chatbot for the Facebook Messenger platform
|
||||
- [Lambda chaining](https://github.com/pmuens/serverless-lambda-chaining) - Service which chains Lambdas through SNS
|
||||
- [Secured API](https://github.com/pmuens/serverless-secured-api) - Service which exposes an API key accessible API
|
||||
- [Authorizer](https://github.com/eahefnawy/serverless-authorizer) - Service that uses API Gateway custom authorizers
|
||||
- [Thumbnails](https://github.com/eahefnawy/serverless-thumbnails) - Service that takes an image url and returns a 100x100 thumbnail
|
||||
- [Boilerplate](https://github.com/eahefnawy/serverless-boilerplate) - Opinionated boilerplate
|
||||
- [ES6 + Jest](https://github.com/americansystems/serverless-es6-jest) - ES6 + Jest Boilerplate
|
||||
- [PHP](https://github.com/ZeroSharp/serverless-php) - Call a PHP function from your lambda
|
||||
- [Ruby](https://github.com/stewartlord/serverless-ruby) - Call a Ruby function from your lambda
|
||||
- [Slack App](https://github.com/johnagan/serverless-slack-app) - Slack App Boilerplate with OAuth and Bot actions
|
||||
- [Swift](https://github.com/choefele/swift-lambda-app) - Full-featured project template to develop Lambda functions in Swift
|
||||
- [Cloudwatch Alerts on Slack](https://github.com/dav009/serverless-aws-alarms-notifier) - Get AWS Cloudwatch alerts notifications on Slack
|
||||
|
||||
**Note**: the `serverless install` command will only work on V1.0 or later.
|
||||
|
||||
## <a name="features"></a>Features
|
||||
|
||||
* Supports Node.js, Python, Java, Go, C#, Ruby, Swift, Kotlin, PHP, Scala, & F#
|
||||
* Manages the lifecycle of your serverless architecture (build, deploy, update, delete).
|
||||
* Safely deploy functions, events and their required resources together via provider resource managers (e.g., AWS CloudFormation).
|
||||
* Functions can be grouped ("serverless services") for easy management of code, resources & processes, across large projects & teams.
|
||||
* Minimal configuration and scaffolding.
|
||||
* Built-in support for multiple stages.
|
||||
* Optimized for CI/CD workflows.
|
||||
* Loaded with automation, optimization and best practices.
|
||||
* 100% Extensible: Extend or modify the Framework and its operations via Plugins.
|
||||
* An ecosystem of serverless services and plugins.
|
||||
* A passionate and welcoming community!
|
||||
|
||||
## <a name="v1-plugins"></a>Plugins (V1.0)
|
||||
|
||||
Use these plugins to extend or overwrite the Framework's functionality.
|
||||
|
||||
[Add a plugin to this list](https://github.com/serverless/community-plugins/blob/master/plugins.json)
|
||||
|
||||
<!-- AUTO-GENERATED-CONTENT:START (GENERATE_SERVERLESS_PLUGIN_TABLE)
|
||||
This table is generated from https://github.com/serverless/plugins/blob/master/plugins.json please make additions there
|
||||
-->
|
||||
| Plugin | Author |
|
||||
| :----- | :----: |
|
||||
| **[Fullstack Serverless](https://github.com/MadSkills-io/fullstack-serverless)** <br/> A Serverless plugin to create an AWS CloudFront distribution that serves static web content from S3 and routes API traffic to API Gateway. | [MadSkills-io](http://github.com/MadSkills-io) |
|
||||
| **[Go Serverless](https://github.com/thepauleh/goserverless)** <br/> GoFormation for Serverless. Create serverless configs with Go Structs. | [thepauleh](http://github.com/thepauleh) |
|
||||
| **[Raml Serverless](https://github.com/andrewcurioso/raml-serverless)** <br/> Serverless plugin to work with RAML API spec documents | [andrewcurioso](http://github.com/andrewcurioso) |
|
||||
| **[Serverless Alexa Plugin](https://github.com/rajington/serverless-alexa-plugin)** <br/> Serverless plugin to support Alexa Lambda events | [rajington](http://github.com/rajington) |
|
||||
| **[Serverless Alexa Skills](https://github.com/marcy-terui/serverless-alexa-skills)** <br/> Manage your Alexa Skills with Serverless Framework. | [marcy-terui](http://github.com/marcy-terui) |
|
||||
| **[Serverless Aliyun Function Compute](https://github.com/aliyun/serverless-aliyun-function-compute)** <br/> Serverless Alibaba Cloud Function Compute Plugin | [aliyun](http://github.com/aliyun) |
|
||||
| **[Serverless Api Cloudfront](https://github.com/Droplr/serverless-api-cloudfront)** <br/> Plugin that adds CloudFront distribution in front of your API Gateway for custom domain, CDN caching and access log. | [Droplr](http://github.com/Droplr) |
|
||||
| **[Serverless Api Stage](https://github.com/leftclickben/serverless-api-stage)** <br/> Serverless API Stage plugin, enables stage variables and logging for AWS API Gateway. | [leftclickben](http://github.com/leftclickben) |
|
||||
| **[Serverless Apib Validator](https://github.com/onlicar/serverless-apib-validator)** <br/> Validate that an API Blueprint has full coverage over a Serverless config | [onlicar](http://github.com/onlicar) |
|
||||
| **[Serverless Apig S 3](https://github.com/sdd/serverless-apig-s3)** <br/> Serve static front-end content from S3 via the API Gateway and deploy client bundle to S3. | [sdd](http://github.com/sdd) |
|
||||
| **[Serverless Apigateway Plugin](https://github.com/GFG/serverless-apigateway-plugin)** <br/> Configure the AWS api gateway: Binary support, Headers and Body template mappings | [GFG](http://github.com/GFG) |
|
||||
| **[Serverless Apigw Binary](https://github.com/maciejtreder/serverless-apigw-binary)** <br/> Plugin to enable binary support in AWS API Gateway. | [maciejtreder](http://github.com/maciejtreder) |
|
||||
| **[Serverless Apigwy Binary](https://github.com/ryanmurakami/serverless-apigwy-binary)** <br/> Serverless plugin for configuring API Gateway to return binary responses | [ryanmurakami](http://github.com/ryanmurakami) |
|
||||
| **[Serverless Appsync Plugin](https://github.com/sid88in/serverless-appsync-plugin)** <br/> Serverless Plugin to deploy AppSync GraphQL API | [sid88in](http://github.com/sid88in) |
|
||||
| **[Serverless Attach Managed Policy](https://github.com/Nordstrom/serverless-attach-managed-policy)** <br/> A Serverless plugin to automatically attach an AWS Managed IAM Policy (or Policies) to all IAM Roles created by the Service. | [Nordstrom](http://github.com/Nordstrom) |
|
||||
| **[Serverless Aws Alias](https://github.com/HyperBrain/serverless-aws-alias)** <br/> This plugin enables use of AWS aliases on Lambda functions. | [HyperBrain](http://github.com/HyperBrain) |
|
||||
| **[Serverless Aws Documentation](https://github.com/9cookies/serverless-aws-documentation)** <br/> Serverless plugin to add documentation and models to the serverless generated API Gateway | [9cookies](http://github.com/9cookies) |
|
||||
| **[Serverless Aws Nested Stacks](https://github.com/concon121/serverless-plugin-nested-stacks)** <br/> Yet another AWS nested stack plugin! | [concon121](http://github.com/concon121) |
|
||||
| **[Serverless Aws Resource Names](https://github.com/concon121/serverless-plugin-aws-resource-names)** <br/> Serverless plugin to alter the default naming conventions for sls resources via a simple mapping file. | [concon121](http://github.com/concon121) |
|
||||
| **[Serverless Basic Authentication](https://github.com/svdgraaf/serverless-basic-authentication)** <br/> Serverless Plugin for adding Basic Authentication to your api | [svdgraaf](http://github.com/svdgraaf) |
|
||||
| **[Serverless Build Client](https://github.com/tgfischer/serverless-build-client)** <br/> Build your static website with environment variables defined in serverless.yml | [tgfischer](http://github.com/tgfischer) |
|
||||
| **[Serverless Build Plugin](https://github.com/nfour/serverless-build-plugin)** <br/> A Node.js focused build plugin for serverless. | [nfour](http://github.com/nfour) |
|
||||
| **[Serverless Cf Vars](https://gitlab.com/kabo/serverless-cf-vars)** <br/> Enables use of AWS pseudo functions and Fn::Sub string substitution | [kabo](http://github.com/kabo) |
|
||||
| **[Serverless Cljs Plugin](https://github.com/nervous-systems/serverless-cljs-plugin)** <br/> Enables Clojurescript as an implementation language for Lambda handlers | [nervous-systems](http://github.com/nervous-systems) |
|
||||
| **[Serverless Cloudformation Changesets](https://github.com/trek10inc/serverless-cloudformation-changesets)** <br/> Natively deploy to CloudFormation via Change sets, instead of directly. Allowing you to queue changes, and safely require escalated roles for final deployment. | [trek10inc](http://github.com/trek10inc) |
|
||||
| **[Serverless Cloudformation Parameter Setter](https://github.com/trek10inc/serverless-cloudformation-parameter-setter)** <br/> Set CloudFormation parameters when deploying. | [trek10inc](http://github.com/trek10inc) |
|
||||
| **[Serverless Cloudformation Resource Counter](https://github.com/drexler/serverless-cloudformation-resource-counter)** <br/> A plugin to count the resources generated in the AWS CloudFormation stack after deployment. | [drexler](http://github.com/drexler) |
|
||||
| **[Serverless Cloudformation Sub Variables](https://github.com/santiagocardenas/serverless-cloudformation-sub-variables)** <br/> Serverless framework plugin for easily supporting AWS CloudFormation Sub function variables | [santiagocardenas](http://github.com/santiagocardenas) |
|
||||
| **[Serverless Coffeescript](https://github.com/duanefields/serverless-coffeescript)** <br/> A Serverless plugin to compile your CoffeeScript into JavaScript at deployment | [duanefields](http://github.com/duanefields) |
|
||||
| **[Serverless Cognito Add Custom Attributes](https://github.com/GetWala/serverless-cognito-add-custom-attributes)** <br/> Serverless Plugin for adding custom attributes to an existing CloudFormation-managed CognitoUserPool and CognitoUserPoolClient without losing all your users | [GetWala](http://github.com/GetWala) |
|
||||
| **[Serverless Command Line Event Args](https://github.com/horike37/serverless-command-line-event-args)** <br/> This module is Serverless Framework plugin. Event JSON passes to your Lambda function in commandline. | [horike37](http://github.com/horike37) |
|
||||
| **[Serverless Content Encoding](https://github.com/dong-dohai/serverless-content-encoding)** <br/> Enable Content Encoding in AWS API Gateway during deployment | [dong-dohai](http://github.com/dong-dohai) |
|
||||
| **[Serverless Create Global Dynamodb Table](https://github.com/rrahul963/serverless-create-global-dynamodb-table)** <br/> Serverless plugin to create dynamodb global tables | [rrahul963](http://github.com/rrahul963) |
|
||||
| **[Serverless Crypt](https://github.com/marcy-terui/serverless-crypt)** <br/> Securing the secrets on Serverless Framework by AWS KMS encryption. | [marcy-terui](http://github.com/marcy-terui) |
|
||||
| **[Serverless Custom Packaging Plugin](https://github.com/hypoport/serverless-custom-packaging-plugin)** <br/> Plugin to package your sourcecode using a custom target path inside the zip. | [hypoport](http://github.com/hypoport) |
|
||||
| **[Serverless Dependson Plugin](https://github.com/bwinant/serverless-dependson-plugin)** <br/> Serverless plugin that automatically generates DependsOn references for AWS Lambdas to prevent AWS RequestLimitExceeded errors. | [bwinant](http://github.com/bwinant) |
|
||||
| **[Serverless Ding](https://github.com/sidgonuts/serverless-ding)** <br/> Serverless plugin to audibly alert user after deployment | [sidgonuts](http://github.com/sidgonuts) |
|
||||
| **[Serverless Dir Config Plugin](https://github.com/economysizegeek/serverless-dir-config-plugin)** <br/> EXPERIMENTAL - Serverless plugin to load function and resource definitions from a directory. | [economysizegeek](http://github.com/economysizegeek) |
|
||||
| **[Serverless Domain Manager](https://github.com/amplify-education/serverless-domain-manager)** <br/> Serverless plugin for managing custom domains with API Gateways. | [amplify-education](http://github.com/amplify-education) |
|
||||
| **[Serverless Dotenv](https://github.com/Jimdo/serverless-dotenv)** <br/> Fetch environment variables and write it to a .env file | [Jimdo](http://github.com/Jimdo) |
|
||||
| **[Serverless Dotnet](https://github.com/fruffin/serverless-dotnet)** <br/> A serverless plugin to run 'dotnet' commands as part of the deploy process | [fruffin](http://github.com/fruffin) |
|
||||
| **[Serverless Dynalite](https://github.com/sdd/serverless-dynalite)** <br/> Run dynalite locally (no JVM, all JS) to simulate DynamoDB. Watch serverless.yml for table config updates. | [sdd](http://github.com/sdd) |
|
||||
| **[Serverless Dynamodb Autoscaling](https://github.com/sbstjn/serverless-dynamodb-autoscaling)** <br/> Configure Amazon DynamoDB's native Auto Scaling for your table capacities. | [sbstjn](http://github.com/sbstjn) |
|
||||
| **[Serverless Dynamodb Fixtures](https://github.com/chechu/serverless-dynamodb-fixtures)** <br/> Serverless Dynamodb Fixtures - Allows to load data on DynamoDB tables | [chechu](http://github.com/chechu) |
|
||||
| **[Serverless Dynamodb Local](https://github.com/99xt/serverless-dynamodb-local)** <br/> Serverless Dynamodb Local Plugin - Allows to run dynamodb locally for serverless | [99xt](http://github.com/99xt) |
|
||||
| **[Serverless Dynamodb Ttl](https://github.com/Jimdo/serverless-dynamodb-ttl)** <br/> Configure DynamoDB TTL in serverless.yml (until CloudFormation supports this). | [Jimdo](http://github.com/Jimdo) |
|
||||
| **[Serverless Enable Api Logs](https://github.com/paulSambolin/serverless-enable-api-logs)** <br/> Enables Coudwatch logging for API Gateway events | [paulSambolin](http://github.com/paulSambolin) |
|
||||
| **[Serverless Env Generator](https://github.com/DieProduktMacher/serverless-env-generator)** <br/> Manage environment variables with YAML and load them with dotenv. Supports variable encryption with KMS, multiple stages and custom profiles. | [DieProduktMacher](http://github.com/DieProduktMacher) |
|
||||
| **[Serverless Ephemeral](https://github.com/Accenture/serverless-ephemeral)** <br/> Build and include custom stateless libraries for any language | [Accenture](http://github.com/Accenture) |
|
||||
| **[Serverless Event Constant Inputs](https://github.com/dittto/serverless-event-constant-inputs)** <br/> Allows you to add constant inputs to events in Serverless 1.0. For more info see [constant values in Cloudwatch](https://aws.amazon.com/blogs/compute/simply-serverless-use-constant-values-in-cloudwatch-event-triggered-lambda-functions/) | [dittto](http://github.com/dittto) |
|
||||
| **[Serverless Export Env](https://github.com/arabold/serverless-export-env)** <br/> Export environment variables into a .env file with automatic AWS CloudFormation reference resolution. | [arabold](http://github.com/arabold) |
|
||||
| **[Serverless Express](https://github.com/mikestaub/serverless-express)** <br/> Making express app development compatible with serverless framework. | [mikestaub](http://github.com/mikestaub) |
|
||||
| **[Serverless Finch](https://github.com/fernando-mc/serverless-finch)** <br/> A Serverless plugin to deploy static website assets to AWS S3. | [fernando-mc](http://github.com/fernando-mc) |
|
||||
| **[Serverless Functions Base Path](https://github.com/kevinrambaud/serverless-functions-base-path)** <br/> Easily define a base path where your serverless functions are located. | [kevinrambaud](http://github.com/kevinrambaud) |
|
||||
| **[Serverless Go Build](https://github.com/sean9keenan/serverless-go-build)** <br/> Build go source files (or public functions) using yml definition file | [sean9keenan](http://github.com/sean9keenan) |
|
||||
| **[Serverless Gulp](https://github.com/rhythminme/serverless-gulp)** <br/> A thin task wrapper around @goserverless that allows you to automate build, test and deploy tasks using gulp | [rhythminme](http://github.com/rhythminme) |
|
||||
| **[Serverless Haskell](https://github.com/seek-oss/serverless-haskell)** <br/> Deploying Haskell applications to AWS Lambda with Serverless | [seek-oss](http://github.com/seek-oss) |
|
||||
| **[Serverless Hooks Plugin](https://github.com/uswitch/serverless-hooks-plugin)** <br/> Run arbitrary commands on any lifecycle event in serverless | [uswitch](http://github.com/uswitch) |
|
||||
| **[Serverless Iam Roles Per Function](https://github.com/functionalone/serverless-iam-roles-per-function)** <br/> Serverless Plugin for easily defining IAM roles per function via the use of iamRoleStatements at the function level. | [functionalone](http://github.com/functionalone) |
|
||||
| **[Serverless Ignore](https://github.com/nya1/serverless-ignore)** <br/> Serverless plugin to ignore files (.slsignore) | [nya1](http://github.com/nya1) |
|
||||
| **[Serverless Iot Local](https://github.com/tradle/serverless-iot-local)** <br/> AWS Iot events with serverless-offline | [tradle](http://github.com/tradle) |
|
||||
| **[Serverless Jest Plugin](https://github.com/SC5/serverless-jest-plugin)** <br/> A Serverless Plugin for the Serverless Framework which adds support for test-driven development using Jest | [SC5](http://github.com/SC5) |
|
||||
| **[Serverless Kms Secrets](https://github.com/SC5/serverless-kms-secrets)** <br/> Allows to easily encrypt and decrypt secrets using KMS from the serverless CLI | [SC5](http://github.com/SC5) |
|
||||
| **[Serverless Kubeless](https://github.com/serverless/serverless-kubeless)** <br/> Serverless plugin for deploying functions to Kubeless. | [serverless](http://github.com/serverless) |
|
||||
| **[Serverless Local Dev Server](https://github.com/DieProduktMacher/serverless-local-dev-server)** <br/> Speeds up development of Alexa Skills, Chatbots and APIs by exposing your functions as local HTTP endpoints and mapping received events. | [DieProduktMacher](http://github.com/DieProduktMacher) |
|
||||
| **[Serverless Local Environment](https://github.com/piercus/serverless-local-environment)** <br/> Serverless plugin to set local environment variables and remote environment variable to different values | [piercus](http://github.com/piercus) |
|
||||
| **[Serverless Local Schedule](https://github.com/UnitedIncome/serverless-local-schedule)** <br/> Schedule AWS CloudWatch Event based invocations in local time(with DST support!) | [UnitedIncome](http://github.com/UnitedIncome) |
|
||||
| **[Serverless Log Forwarding](https://github.com/amplify-education/serverless-log-forwarding)** <br/> Serverless plugin for forwarding CloudWatch logs to another Lambda function. | [amplify-education](http://github.com/amplify-education) |
|
||||
| **[Serverless Micro](https://github.com/barstoolsports/serverless-micro)** <br/> Plugin to help manage multiple micro services under one main service. | [barstoolsports](http://github.com/barstoolsports) |
|
||||
| **[Serverless Mocha Plugin](https://github.com/SC5/serverless-mocha-plugin)** <br/> A Serverless Plugin for the Serverless Framework which adds support for test-driven development using Mocha | [SC5](http://github.com/SC5) |
|
||||
| **[Serverless Multi Dotnet](https://github.com/tsibelman/serverless-multi-dotnet)** <br/> A serverless plugin to pack C# lambdas functions that are spread to multiple CS projects. | [tsibelman](http://github.com/tsibelman) |
|
||||
| **[Serverless Nested Stack](https://github.com/jagdish-176/serverless-nested-stack)** <br/> A plugin to Workaround for Cloudformation 200 resource limit | [jagdish-176](http://github.com/jagdish-176) |
|
||||
| **[Serverless Offline](https://github.com/dherault/serverless-offline)** <br/> Emulate AWS λ and API Gateway locally when developing your Serverless project | [dherault](http://github.com/dherault) |
|
||||
| **[Serverless Offline Direct Lambda](https://github.com/civicteam/serverless-offline-direct-lambda)** <br/> Allow offline direct lambda-to-lambda interactions by exposing lambdas with no API Gateway event via HTTP. | [civicteam](http://github.com/civicteam) |
|
||||
| **[Serverless Offline Scheduler](https://github.com/ajmath/serverless-offline-scheduler)** <br/> Runs scheduled functions offline while integrating with serverless-offline | [ajmath](http://github.com/ajmath) |
|
||||
| **[Serverless Offline Sns](https://github.com/mj1618/serverless-offline-sns)** <br/> Serverless plugin to run a local SNS server and call serverless SNS handlers with events notifications. | [mj1618](http://github.com/mj1618) |
|
||||
| **[Serverless Offline Ssm](https://github.com/janders223/serverless-offline-ssm)** <br/> Read SSM parameters from a .env file instead of AWS | [janders223](http://github.com/janders223) |
|
||||
| **[Serverless Package Common](https://github.com/onlicar/serverless-package-common)** <br/> Deploy microservice Python Serverless services with common code | [onlicar](http://github.com/onlicar) |
|
||||
| **[Serverless Package Python Functions](https://github.com/ubaniabalogun/serverless-package-python-functions)** <br/> Packaging Python Lambda functions with only the dependencies/requirements they need. | [ubaniabalogun](http://github.com/ubaniabalogun) |
|
||||
| **[Serverless Parameters](https://github.com/svdgraaf/serverless-parameters)** <br/> Add parameters to the generated cloudformation templates | [svdgraaf](http://github.com/svdgraaf) |
|
||||
| **[Serverless Plugin Aws Alerts](https://github.com/ACloudGuru/serverless-plugin-aws-alerts)** <br/> A Serverless plugin to easily add CloudWatch alarms to functions | [ACloudGuru](http://github.com/ACloudGuru) |
|
||||
| **[Serverless Plugin Aws Resolvers](https://github.com/DopplerLabs/serverless-plugin-aws-resolvers)** <br/> Resolves variables from ESS, RDS, or Kinesis for serverless services | [DopplerLabs](http://github.com/DopplerLabs) |
|
||||
| **[Serverless Plugin Bespoken](https://github.com/bespoken/serverless-plugin-bespoken)** <br/> Creates a local server and a proxy so you don't have to deploy anytime you want to test your code | [bespoken](http://github.com/bespoken) |
|
||||
| **[Serverless Plugin Bind Deployment Id](https://github.com/jacob-meacham/serverless-plugin-bind-deployment-id)** <br/> A Serverless plugin to bind the randomly generated deployment resource to your custom resources | [jacob-meacham](http://github.com/jacob-meacham) |
|
||||
| **[Serverless Plugin Browserifier](https://github.com/digitalmaas/serverless-plugin-browserifier)** <br/> Reduce the size and speed up your Node.js based lambda's using browserify. | [digitalmaas](http://github.com/digitalmaas) |
|
||||
| **[Serverless Plugin Browserify](https://github.com/doapp-ryanp/serverless-plugin-browserify)** <br/> Speed up your node based lambda's | [doapp-ryanp](http://github.com/doapp-ryanp) |
|
||||
| **[Serverless Plugin Canary Deployments](https://github.com/davidgf/serverless-plugin-canary-deployments)** <br/> A Serverless plugin to implement canary deployments of Lambda functions | [davidgf](http://github.com/davidgf) |
|
||||
| **[Serverless Plugin Cfauthorizer](https://github.com/SC5/serverless-plugin-cfauthorizer)** <br/> This plugin allows you to define your own API Gateway Authorizers as the Serverless CloudFormation resources and apply them to HTTP endpoints. | [SC5](http://github.com/SC5) |
|
||||
| **[Serverless Plugin Chrome](https://github.com/adieuadieu/serverless-chrome/tree/master/packages/serverless-plugin)** <br/> Plugin which bundles and ensures that Headless Chrome/Chromium is running when your AWS Lambda function handler is invoked. | [adieuadieu](http://github.com/adieuadieu) |
|
||||
| **[Serverless Plugin Cloudwatch Sumologic](https://github.com/ACloudGuru/serverless-plugin-cloudwatch-sumologic)** <br/> Plugin which auto-subscribes a log delivery lambda function to lambda log groups created by serverless | [ACloudGuru](http://github.com/ACloudGuru) |
|
||||
| **[Serverless Plugin Colocate](https://github.com/aronim/serverless-plugin-colocate)** <br/> Serverless Plugin to keep your configuration next to your code. | [aronim](http://github.com/aronim) |
|
||||
| **[Serverless Plugin Common Excludes](https://github.com/dougmoscrop/serverless-plugin-common-excludes)** <br/> Adds commonly excluded files to package.excludes | [dougmoscrop](http://github.com/dougmoscrop) |
|
||||
| **[Serverless Plugin Custom Domain](https://github.com/dougmoscrop/serverless-plugin-custom-domain)** <br/> Reliably sets a BasePathMapping to an API Gateway Custom Domain | [dougmoscrop](http://github.com/dougmoscrop) |
|
||||
| **[Serverless Plugin Deploy Environment](https://github.com/DopplerLabs/serverless-plugin-deploy-environment)** <br/> Plugin to manage deployment environment across stages | [DopplerLabs](http://github.com/DopplerLabs) |
|
||||
| **[Serverless Plugin Diff](https://github.com/nicka/serverless-plugin-diff)** <br/> Compares your local AWS CloudFormation templates against deployed ones. | [nicka](http://github.com/nicka) |
|
||||
| **[Serverless Plugin Dynamodb Autoscaling](https://github.com/medikoo/serverless-plugin-dynamodb-autoscaling)** <br/> Auto generate auto scaling configuration for configured DynamoDB tables | [medikoo](http://github.com/medikoo) |
|
||||
| **[Serverless Plugin Elastic Beanstalk](https://github.com/rawphp/serverless-plugin-elastic-beanstalk)** <br/> A serverless plugin to deploy applications to AWS ElasticBeanstalk. | [rawphp](http://github.com/rawphp) |
|
||||
| **[Serverless Plugin Embedded Env In Code](https://github.com/zaru/serverless-plugin-embedded-env-in-code)** <br/> Replace environment variables with static strings before deployment. It’s for Lambda@Edge. | [zaru](http://github.com/zaru) |
|
||||
| **[Serverless Plugin Encode Env Var Objects](https://github.com/yonomi/serverless-plugin-encode-env-var-objects)** <br/> Serverless plugin to encode any environment variable objects. | [yonomi](http://github.com/yonomi) |
|
||||
| **[Serverless Plugin External Sns Events](https://github.com/silvermine/serverless-plugin-external-sns-events)** <br/> Add ability for functions to use existing or external SNS topics as an event source | [silvermine](http://github.com/silvermine) |
|
||||
| **[Serverless Plugin Fastdeploy](https://github.com/aronim/serverless-plugin-fastdeploy)** <br/> Serverless Plugin to perform fast deployments for large service packages. | [aronim](http://github.com/aronim) |
|
||||
| **[Serverless Plugin Git Variables](https://github.com/jacob-meacham/serverless-plugin-git-variables)** <br/> A Serverless plugin to expose git variables (branch name, HEAD description, full commit hash) to your serverless services | [jacob-meacham](http://github.com/jacob-meacham) |
|
||||
| **[Serverless Plugin Graphiql](https://github.com/bencooling/serverless-plugin-graphiql)** <br/> A Serverless plugin to run a local http server for graphiql and your graphql handler | [bencooling](http://github.com/bencooling) |
|
||||
| **[Serverless Plugin Ifelse](https://github.com/anantab/serverless-plugin-ifelse)** <br/> A Serverless Plugin to write If Else conditions in serverless YAML file | [anantab](http://github.com/anantab) |
|
||||
| **[Serverless Plugin Include Dependencies](https://github.com/dougmoscrop/serverless-plugin-include-dependencies)** <br/> This is a Serverless plugin that should make your deployed functions smaller. | [dougmoscrop](http://github.com/dougmoscrop) |
|
||||
| **[Serverless Plugin Inject Dependencies](https://github.com/loanmarket/serverless-plugin-inject-dependencies)** <br/> Painlessly deploy serverless projects with only the required dependencies. | [loanmarket](http://github.com/loanmarket) |
|
||||
| **[Serverless Plugin Iopipe](https://github.com/iopipe/serverless-plugin-iopipe)** <br/> See inside your Lambda functions with high fidelity metrics and monitoring. | [iopipe](http://github.com/iopipe) |
|
||||
| **[Serverless Plugin Lambda Dead Letter](https://github.com/gmetzker/serverless-plugin-lambda-dead-letter)** <br/> A Serverless plugin that can configure a lambda with a dead letter queue or topic | [gmetzker](http://github.com/gmetzker) |
|
||||
| **[Serverless Plugin Log Subscription](https://github.com/dougmoscrop/serverless-plugin-log-subscription)** <br/> Adds a CloudWatch LogSubscription for functions | [dougmoscrop](http://github.com/dougmoscrop) |
|
||||
| **[Serverless Plugin Metric](https://github.com/alex20465/serverless-plugin-metric)** <br/> Creates dynamically AWS metric-filter resources with custom patterns | [alex20465](http://github.com/alex20465) |
|
||||
| **[Serverless Plugin Multiple Responses](https://github.com/silvermine/serverless-plugin-multiple-responses)** <br/> Enable multiple content-types for Response template | [silvermine](http://github.com/silvermine) |
|
||||
| **[Serverless Plugin Node Shim](https://github.com/jzimmek/serverless-plugin-node-shim)** <br/> Serverless plugin to run your functions in nodejs version (8 LTS, 9+) on aws lambda | [jzimmek](http://github.com/jzimmek) |
|
||||
| **[Serverless Plugin Offline Dynamodb Stream](https://github.com/orchestrated-io/serverless-plugin-offline-dynamodb-stream)** <br/> Serverless Plugin for emulating dynamodb stream triggering lambda functions offline | [orchestrated-io](http://github.com/orchestrated-io) |
|
||||
| **[Serverless Plugin Offline Kinesis Events](https://github.com/DopplerLabs/serverless-plugin-offline-kinesis-events)** <br/> Plugin that works with serverless-offline to allow offline testing of serverless functions that are triggered by Kinesis events. | [DopplerLabs](http://github.com/DopplerLabs) |
|
||||
| **[Serverless Plugin Offline Kinesis](https://github.com/godu/serverless/tree/master/packages/serverless-offline-kinesis)** <br/> ServerlessOffline's plugin which listens Kinesis stream and invokes locally your handlers | [godu](http://github.com/godu) |
|
||||
| **[Serverless Plugin Offline DynamoDBStreams](https://github.com/godu/serverless/tree/master/packages/serverless-offline-dynamodb-streams)** <br/> ServerlessOffline's plugin which listens DynamoDBStreams stream and invokes locally your handlers | [godu](http://github.com/godu) |
|
||||
| **[Serverless Plugin Offline SQS](https://github.com/godu/serverless/tree/master/packages/serverless-offline-sqs)** <br/> ServerlessOffline's plugin which listens SQS queue and invokes locally your handlers | [godu](http://github.com/godu) |
|
||||
| **[Serverless Plugin Optimize](https://github.com/FidelLimited/serverless-plugin-optimize)** <br/> Bundle with Browserify, transpile with Babel to ES5 and minify with Uglify your Serverless functions. | [FidelLimited](http://github.com/FidelLimited) |
|
||||
| **[Serverless Plugin Package Dotenv File](https://github.com/ACloudGuru/serverless-plugin-package-dotenv-file)** <br/> A Serverless plugin to copy a .env file into the serverless package | [ACloudGuru](http://github.com/ACloudGuru) |
|
||||
| **[Serverless Plugin Parent](https://github.com/aronim/serverless-plugin-parent)** <br/> Serverless Plugin that allows you to keep common configuration in a parent serverless.yml | [aronim](http://github.com/aronim) |
|
||||
| **[Serverless Plugin Provider Groups](https://github.com/loanmarket/serverless-plugin-provider-groups)** <br/> A plugin to allow management of grouped settings within large serverless projects. | [loanmarket](http://github.com/loanmarket) |
|
||||
| **[Serverless Plugin Reducer](https://github.com/medikoo/serverless-plugin-reducer)** <br/> Reduce Node.js lambda package so it contains only lambda dependencies | [medikoo](http://github.com/medikoo) |
|
||||
| **[Serverless Plugin Registry](https://github.com/aronim/serverless-plugin-registry)** <br/> Serverless plugin to register function names with AWS SSM Parameter Store. | [aronim](http://github.com/aronim) |
|
||||
| **[Serverless Plugin Scripts](https://github.com/mvila/serverless-plugin-scripts)** <br/> Add scripting capabilities to the Serverless Framework | [mvila](http://github.com/mvila) |
|
||||
| **[Serverless Plugin Select](https://github.com/FidelLimited/serverless-plugin-select)** <br/> Select which functions are to be deployed based on region and stage. | [FidelLimited](http://github.com/FidelLimited) |
|
||||
| **[Serverless Plugin Simulate](https://github.com/gertjvr/serverless-plugin-simulate)** <br/> Simulate AWS Lambda and API Gateway locally using Docker | [gertjvr](http://github.com/gertjvr) |
|
||||
| **[Serverless Plugin Split Stacks](https://github.com/dougmoscrop/serverless-plugin-split-stacks)** <br/> Migrate certain resources to nested stacks | [dougmoscrop](http://github.com/dougmoscrop) |
|
||||
| **[Serverless Plugin Stack Config](https://github.com/rawphp/serverless-plugin-stack-config)** <br/> A serverless plugin to manage configurations for a stack across micro-services. | [rawphp](http://github.com/rawphp) |
|
||||
| **[Serverless Plugin Stack Outputs](https://github.com/svdgraaf/serverless-plugin-stack-outputs)** <br/> Displays stack outputs for your serverless stacks when `sls info` is ran | [svdgraaf](http://github.com/svdgraaf) |
|
||||
| **[Serverless Plugin Stackstorm](https://github.com/StackStorm/serverless-plugin-stackstorm)** <br/> Reusable Functions from StackStorm Exchange | [StackStorm](http://github.com/StackStorm) |
|
||||
| **[Serverless Plugin Stage Variables](https://github.com/svdgraaf/serverless-plugin-stage-variables)** <br/> Add stage variables for Serverless 1.x to ApiGateway, so you can use variables in your Lambda's | [svdgraaf](http://github.com/svdgraaf) |
|
||||
| **[Serverless Plugin Subscription Filter](https://github.com/tsub/serverless-plugin-subscription-filter)** <br/> A serverless plugin to register AWS CloudWatchLogs subscription filter | [tsub](http://github.com/tsub) |
|
||||
| **[Serverless Plugin Tracer](https://github.com/enykeev/serverless-plugin-tracer/)** <br/> Trace serverless hooks as they execute | [enykeev](http://github.com/enykeev) |
|
||||
| **[Serverless Plugin Transpiler](https://github.com/medikoo/serverless-plugin-transpiler)** <br/> Transpile lambda files during packaging step | [medikoo](http://github.com/medikoo) |
|
||||
| **[Serverless Plugin Typescript](https://github.com/graphcool/serverless-plugin-typescript)** <br/> Serverless plugin for zero-config Typescript support. | [graphcool](http://github.com/graphcool) |
|
||||
| **[Serverless Plugin Vpc Eni Cleanup](https://github.com/medikoo/serverless-plugin-vpc-eni-cleanup)** <br/> Automatic cleanup of VPC network interfaces on stage removal | [medikoo](http://github.com/medikoo) |
|
||||
| **[Serverless Plugin Warmup](https://github.com/FidelLimited/serverless-plugin-warmup)** <br/> Keep your lambdas warm during Winter. | [FidelLimited](http://github.com/FidelLimited) |
|
||||
| **[Serverless Plugin Webpack](https://github.com/goldwasserexchange/serverless-plugin-webpack)** <br/> A serverless plugin to automatically bundle your functions individually with webpack | [goldwasserexchange](http://github.com/goldwasserexchange) |
|
||||
| **[Serverless Plugin Write Env Vars](https://github.com/silvermine/serverless-plugin-write-env-vars)** <br/> Write environment variables out to a file that is compatible with dotenv | [silvermine](http://github.com/silvermine) |
|
||||
| **[Serverless Prune Plugin](https://github.com/claygregory/serverless-prune-plugin)** <br/> Deletes old versions of functions from AWS, preserving recent and aliased versions | [claygregory](http://github.com/claygregory) |
|
||||
| **[Serverless Pseudo Parameters](https://github.com/svdgraaf/serverless-pseudo-parameters)** <br/> Use ${AWS::AccountId} and other cloudformation pseudo parameters in your serverless.yml values | [svdgraaf](http://github.com/svdgraaf) |
|
||||
| **[Serverless Puresec Cli](https://github.com/puresec/serverless-puresec-cli)** <br/> Serverless Plugin for magically creating IAM roles that are least privileged per function. | [puresec](http://github.com/puresec) |
|
||||
| **[Serverless Python Individually](https://github.com/cfchou/serverless-python-individually)** <br/> A serverless framework plugin to install multiple lambda functions written in python | [cfchou](http://github.com/cfchou) |
|
||||
| **[Serverless Python Requirements](https://github.com/UnitedIncome/serverless-python-requirements)** <br/> Serverless plugin to bundle Python packages | [UnitedIncome](http://github.com/UnitedIncome) |
|
||||
| **[Serverless Reqvalidator Plugin](https://github.com/RafPe/serverless-reqvalidator-plugin)** <br/> Serverless plugin to add request validator to API Gateway methods | [RafPe](http://github.com/RafPe) |
|
||||
| **[Serverless Resources Env](https://github.com/rurri/serverless-resources-env)** <br/> After Deploy, this plugin fetches cloudformation resource identifiers and sets them on AWS lambdas, and creates local .<state>-env file | [rurri](http://github.com/rurri) |
|
||||
| **[Serverless Run Function Plugin](https://github.com/lithin/serverless-run-function-plugin)** <br/> Run serverless function locally | [lithin](http://github.com/lithin) |
|
||||
| **[Serverless Rust](https://github.com/softprops/serverless-rust)** <br/> Deploy Rustlang applications to AWS Lambda | [softprops](http://github.com/softprops) |
|
||||
| **[Serverless S 3 Encryption](https://github.com/tradle/serverless-s3-encryption)** <br/> Set or remove the encryption settings on your s3 buckets | [tradle](http://github.com/tradle) |
|
||||
| **[Serverless S 3 Remover](https://github.com/sinofseven/serverless-s3-remover)** <br/> A serverless plugin to make s3 buckets empty before deleting cloudformation stack when ```sls remove``` | [sinofseven](http://github.com/sinofseven) |
|
||||
| **[Serverless S 3 Sync](https://github.com/k1LoW/serverless-s3-sync)** <br/> A plugin to sync local directories and S3 prefixes for Serverless Framework, | [k1LoW](http://github.com/k1LoW) |
|
||||
| **[Serverless S 3 Bucket Sync](https://github.com/sbstjn/serverless-s3bucket-sync)** <br/> Sync a local folder with a S3 bucket after sls deploy | [sbstjn](http://github.com/sbstjn) |
|
||||
| **[Serverless Sam](https://github.com/SAPessi/serverless-sam)** <br/> Exports an AWS SAM template for a service created with the Serverless Framework. | [SAPessi](http://github.com/SAPessi) |
|
||||
| **[Serverless Scriptable Plugin](https://github.com/weixu365/serverless-scriptable-plugin)** <br/> Customize Serverless behavior without writing a plugin. | [weixu365](http://github.com/weixu365) |
|
||||
| **[Serverless Sentry](https://github.com/arabold/serverless-sentry-plugin)** <br/> Automatic monitoring of memory usage, execution timeouts and forwarding of Lambda errors to Sentry (https://sentry.io). | [arabold](http://github.com/arabold) |
|
||||
| **[Serverless Shell](https://github.com/UnitedIncome/serverless-shell)** <br/> Drop to a runtime shell with all the environment variables set that you'd have in lambda. | [UnitedIncome](http://github.com/UnitedIncome) |
|
||||
| **[Serverless Sns Filter](https://github.com/MechanicalRock/serverless-sns-filter)** <br/> Serverless plugin to add SNS Subscription Filters to events | [MechanicalRock](http://github.com/MechanicalRock) |
|
||||
| **[Serverless Spa](https://github.com/gilmarsquinelato/serverless-spa)** <br/> Serverless plugin to deploy your website to AWS S3 using Webpack to bundle it. | [gilmarsquinelato](http://github.com/gilmarsquinelato) |
|
||||
| **[Serverless Sqs Alarms Plugin](https://github.com/sbstjn/serverless-sqs-alarms-plugin)** <br/> Wrapper to setup CloudWatch Alarms on SQS queue length | [sbstjn](http://github.com/sbstjn) |
|
||||
| **[Serverless Sqs Fifo](https://github.com/vortarian/serverless-sqs-fifo)** <br/> A serverless plugin to handle creation of sqs fifo queue's in aws (stop-gap) | [vortarian](http://github.com/vortarian) |
|
||||
| **[Serverless Ssm Fetch](https://github.com/gozup/serverless-ssm-fetch)** <br/> Sets "AWS Systems Manager Parameter Store (SSM)" parameters into functions' environment variables. | [gozup](http://github.com/gozup) |
|
||||
| **[Serverless Stack Output](https://github.com/sbstjn/serverless-stack-output)** <br/> Store output from your AWS CloudFormation Stack in JSON/YAML/TOML files, or to pass it to a JavaScript function for further processing. | [sbstjn](http://github.com/sbstjn) |
|
||||
| **[Serverless Stage Manager](https://github.com/jeremydaly/serverless-stage-manager)** <br/> Super simple Serverless plugin for validating stage names before deployment | [jeremydaly](http://github.com/jeremydaly) |
|
||||
| **[Serverless Static](https://github.com/iliasbhal/serverless-static)** <br/> Easily serve files from a folder while developing on localhost with the serverless-offline plugin | [iliasbhal](http://github.com/iliasbhal) |
|
||||
| **[Serverless Step Functions](https://github.com/horike37/serverless-step-functions)** <br/> AWS Step Functions with Serverless Framework. | [horike37](http://github.com/horike37) |
|
||||
| **[Serverless Sthree Env](https://github.com/StyleTributeIT/serverless-sthree-env)** <br/> Serverless plugin to get config from a json formatted file in S3 and copy them to environment variable | [StyleTributeIT](http://github.com/StyleTributeIT) |
|
||||
| **[Serverless Subscription Filter](https://github.com/blackevil245/serverless-subscription-filter)** <br/> Serverless plugin to register subscription filter for Lambda logs. Register and pipe the logs of one lambda to another to process. | [blackevil245](http://github.com/blackevil245) |
|
||||
| **[Serverless Tag Api Gateway](https://github.com/gfragoso/serverless-tag-api-gateway)** <br/> Serverless plugin to tag API Gateway | [gfragoso](http://github.com/gfragoso) |
|
||||
| **[Serverless Tag Cloud Watch Logs](https://github.com/gfragoso/serverless-tag-cloud-watch-logs)** <br/> Serverless plugin to tag CloudWatchLogs | [gfragoso](http://github.com/gfragoso) |
|
||||
| **[Serverless Tag Sqs](https://github.com/gfragoso/serverless-tag-sqs)** <br/> Serverless plugin to tag SQS - Simple Queue Service | [gfragoso](http://github.com/gfragoso) |
|
||||
| **[Serverless Vpc Discovery](https://github.com/amplify-education/serverless-vpc-discovery)** <br/> Serverless plugin for discovering VPC / Subnet / Security Group configuration by name. | [amplify-education](http://github.com/amplify-education) |
|
||||
| **[Serverless Webpack](https://github.com/serverless-heaven/serverless-webpack)** <br/> Serverless plugin to bundle your lambdas with Webpack | [serverless-heaven](http://github.com/serverless-heaven) |
|
||||
| **[Serverless Wsgi](https://github.com/logandk/serverless-wsgi)** <br/> Serverless plugin to deploy WSGI applications (Flask/Django/Pyramid etc.) and bundle Python packages | [logandk](http://github.com/logandk) |
|
||||
<!-- AUTO-GENERATED-CONTENT:END This table is generated from https://github.com/serverless/plugins/blob/master/plugins.json please make additions there -->
|
||||
|
||||
## <a name="v1-projects"></a>Example Projects (V1.0)
|
||||
|
||||
<!-- AUTO-GENERATED-CONTENT:START (GENERATE_SERVERLESS_EXAMPLES_TABLE)
|
||||
This table is generated from https://github.com/serverless/examples/blob/master/community-examples.json please make additions there
|
||||
-->
|
||||
| Project Name | Author |
|
||||
|:-------------|:------:|
|
||||
| **[Serverless Pipeline](https://github.com/msfidelis/serverless-pipeline)** <br/> Simple CI/CD Pipeline to Serverless Projects on AWS using Codepipeline, Codebuild and Terraform | [msfidelis](http://github.com/msfidelis) |
|
||||
| **[Jwtauthorizr](https://github.com/serverlessbuch/jwtAuthorizr)** <br/> Custom JWT Authorizer Lambda function for Amazon API Gateway with Bearer JWT | [serverlessbuch](http://github.com/serverlessbuch) |
|
||||
| **[AWS Demo Java Spring Cloud Function Serverless](https://github.com/mbsambangi/aws-java-spring-cloud-function-demo)** <br/> If Java is your choice of programming language-Spring Cloud Function,Serverless Framework makes a great technology stack. It boosts developer productivity by decoupling from Vendor specific FaaS API, and deployment activities. | [mbsambangi](http://github.com/mbsambangi) |
|
||||
| **[Serverless Architecture Boilerplate](https://github.com/msfidelis/serverless-architecture-boilerplate)** <br/> Boilerplate to organize and deploy big projects using Serverless and CloudFormation on AWS | [msfidelis](http://github.com/msfidelis) |
|
||||
| **[Bablebot](https://github.com/abiglobalhealth/babelbot)** <br/> Lambda + API Gateway: Zero-to-chatbot in <10 lines of JS. Built-in integrations for Messenger, Telegram, Kik, Line, Twilio, Skype, and Wechat. Or roll your own! | [abiglobalhealth](http://github.com/abiglobalhealth) |
|
||||
| **[Jwt Authorizr](https://github.com/serverlessbuch/jwtAuthorizr)** <br/> Custom JWT Authorizer Lambda function for Amazon API Gateway with Bearer JWT | [serverlessbuch](http://github.com/serverlessbuch) |
|
||||
| **[Slack Signup Serverless](https://github.com/dzimine/slack-signup-serverless)** <br/> Serverless signup to Slack and more. Lambda with Python, StepFunctions, and Web front end. Python boilerplate included. | [dzimine](http://github.com/dzimine) |
|
||||
| **[Serverless Graphql Api](https://github.com/boazdejong/serverless-graphql-api)** <br/> Serverless GraphQL API using Lambda and DynamoDB | [boazdejong](http://github.com/boazdejong) |
|
||||
| **[Serverless Screenshot](https://github.com/svdgraaf/serverless-screenshot)** <br/> Serverless Screenshot Service using PhantomJS | [svdgraaf](http://github.com/svdgraaf) |
|
||||
| **[Serverless Postgraphql](https://github.com/rentrop/serverless-postgraphql)** <br/> GraphQL endpoint for PostgreSQL using postgraphql | [rentrop](http://github.com/rentrop) |
|
||||
| **[Serverless Messenger Boilerplate](https://github.com/SC5/serverless-messenger-boilerplate)** <br/> Serverless messenger bot boilerplate | [SC5](http://github.com/SC5) |
|
||||
| **[Serverless Npm Registry](https://github.com/craftship/yith)** <br/> Serverless private npm registry, proxy and cache. | [craftship](http://github.com/craftship) |
|
||||
| **[Serverless Pokego](https://github.com/jch254/pokego-serverless)** <br/> Serverless-powered API to fetch nearby Pokemon Go data | [jch254](http://github.com/jch254) |
|
||||
| **[Serverless Weekly 2 Pocket App](https://github.com/s0enke/weekly2pocket)** <br/> Serverless-powered API for sending posts to pocket app | [s0enke](http://github.com/s0enke) |
|
||||
| **[Serverless Facebook Quotebot](https://github.com/pmuens/quotebot)** <br/> 100% Serverless Facebook messenger chatbot which will respond with inspiring quotes | [pmuens](http://github.com/pmuens) |
|
||||
| **[Serverless Slack Trevorbot](https://github.com/conveyal/trevorbot)** <br/> Slack bot for info on where in the world is Trevor Gerhardt? | [conveyal](http://github.com/conveyal) |
|
||||
| **[Serverless Garden Aid](https://github.com/garden-aid/web-bff)** <br/> IoT Garden Aid Backend | [garden-aid](http://github.com/garden-aid) |
|
||||
| **[Serverless React Boilerplate](https://github.com/99xt/serverless-react-boilerplate)** <br/> A serverless react boilerplate for offline development | [99xt](http://github.com/99xt) |
|
||||
| **[Serverless Delivery Framework](https://github.com/99xt/serverless-delivery-framework)** <br/> This is a boilerplate for version release pipeline with serverless framework | [99xt](http://github.com/99xt) |
|
||||
| **[Serverless Mailgun Slack](https://github.com/Marcus-L/serverless-mailgun-slack)** <br/> A Serverless function for posting to a Slack Webhook in response to a Mailgun route | [Marcus-L](http://github.com/Marcus-L) |
|
||||
| **[Pfs Email Serverless](https://github.com/SCPR/pfs-email-serverless)** <br/> This is a lambda function created by the serverless framework. It searches through members in our mongodb who have not been sent emails and sends them an email with their custom token to unlock the pledge free stream. It then marks those members off as already receiving the email. | [SCPR](http://github.com/SCPR) |
|
||||
| **[Plaid Cashburndown Service](https://github.com/cplee/cashburndown-service)** <br/> Service for calculating cash burndown with plaid. Frontend code can be found here: https://github.com/cplee/cashburndown-site | [cplee](http://github.com/cplee) |
|
||||
| **[Cordis Serverless](https://github.com/marzeelabs/cordis-serverless)** <br/> A serverless API for EU Cordis data | [marzeelabs](http://github.com/marzeelabs) |
|
||||
| **[Serverless Newsletter Signup](https://github.com/ivanderbu2/serverless-newsletter-signup)** <br/> Saves user details into DynamoDB table. Required values are email, first_name and last_name. | [ivanderbu2](http://github.com/ivanderbu2) |
|
||||
| **[Serverless Slack Cron](https://github.com/ivanderbu2/serverless-slack-cron)** <br/> Lambda function which sends messages to Slack channel in regular intervals via cron trigger. | [ivanderbu2](http://github.com/ivanderbu2) |
|
||||
| **[Giphy Bot](https://github.com/tywong/lambda-workshop-2016/tree/master/giphy-bot)** <br/> giphy-bot for Facebook chat | [tywong](http://github.com/tywong) |
|
||||
| **[Jwt Lambda Python](https://github.com/mikaelmork/jwt-auth.serverless)** <br/> Minimal proof-of-concept implementation of JWT with Serverless / AWS Lambda | [mikaelmork](http://github.com/mikaelmork) |
|
||||
| **[Sls Access Counter](https://github.com/takahashim/sls-access-counter)** <br/> Site visitor counter | [takahashim](http://github.com/takahashim) |
|
||||
| **[Sls Form Mail](https://github.com/takahashim/sls-form-mail)** <br/> Send SNS email from form data | [takahashim](http://github.com/takahashim) |
|
||||
| **[Serverless Python Sample](https://github.com/bennybauer/serverless-python-sample)** <br/> A simple serverless python sample with REST API endpoints and dependencies | [bennybauer](http://github.com/bennybauer) |
|
||||
| **[Serverless Msg Gateway](https://github.com/yonahforst/msg-gateway)** <br/> A messaging aggregator for kik, skype, twilio, telegram, & messenger. Send and receive messages in a standard format. | [yonahforst](http://github.com/yonahforst) |
|
||||
| **[Serverless AWS Rekognition Finpics](https://github.com/rgfindl/finpics)** <br/> Use AWS Rekognition to provide a faces search of finpics.com | [rgfindl](http://github.com/rgfindl) |
|
||||
| **[Serverless Slack Emojibot](https://github.com/markhobson/emojibot)** <br/> Serverless slack bot for emoji | [markhobson](http://github.com/markhobson) |
|
||||
| **[Keboola Developer Portal](https://github.com/keboola/developer-portal)** <br/> Keboola developer portal built with Serverless | [keboola](http://github.com/keboola) |
|
||||
| **[Serverless Cloudwatch Rds Custom Metrics](https://github.com/AndrewFarley/serverless-cloudwatch-rds-custom-metrics)** <br/> A NodeJS-based MySQL RDS Data Collection script to push Custom Metrics to Cloudwatch with Serverless | [AndrewFarley](http://github.com/AndrewFarley) |
|
||||
| **[Jrestless Examples](https://github.com/bbilger/jrestless-examples)** <br/> [JRestless](https://github.com/bbilger/jrestless) (Java / JAX-RS) examples for [API Gateway Functions](https://github.com/bbilger/jrestless-examples/tree/master/aws/gateway) ([plain JAX-RS](https://github.com/bbilger/jrestless-examples/blob/master/aws/gateway/aws-gateway-showcase), [Spring](https://github.com/bbilger/jrestless-examples/blob/master/aws/gateway/aws-gateway-spring), [binary data requests/responses](https://github.com/bbilger/jrestless-examples/blob/master/aws/gateway/aws-gateway-binary), [custom authorizers](https://github.com/bbilger/jrestless-examples/blob/master/aws/gateway/aws-gateway-security-custom-authorizer) and [Cognito User Pool authorizers](https://github.com/bbilger/jrestless-examples/blob/master/aws/gateway/aws-gateway-security-cognito-authorizer)), [SNS Functions](https://github.com/bbilger/jrestless-examples/blob/master/aws/sns/aws-sns-usage-example) (asynchronous communication between functions) and [Service Functions](https://github.com/bbilger/jrestless-examples/blob/master/aws/service/aws-service-usage-example) (synchronous HTTP-like communication between functions - transparent through Feign) | [bbilger](http://github.com/bbilger) |
|
||||
| **[Sc 5 Serverless Boilerplate](https://github.com/SC5/sc5-serverless-boilerplate)** <br/> A boilerplate that contains setup for test-driven development | [SC5](http://github.com/SC5) |
|
||||
| **[Serverless Blog To Podcast](https://github.com/SC5/serverless-blog-to-podcast)** <br/> Service that reads RSS feed and converts the entries to a podcast feed and audio files using Amazon Polly | [SC5](http://github.com/SC5) |
|
||||
| **[Offset Trump](https://github.com/FLGMwt/offset-trump)** <br/> Single page app using Serverless (C# runtime) and S3 site hosting. Pledge to do a good thing for the next four years to offset the potential negative effects of the US Presidency | [FLGMwt](http://github.com/FLGMwt) |
|
||||
| **[Serverless Url Shortener](https://github.com/aletheia/serverless-url-shortener)** <br/> A simple url-shortener, using Serverless framework | [aletheia](http://github.com/aletheia) |
|
||||
| **[Serverless Html Pdf](https://github.com/calvintychan/serverless-html-pdf)** <br/> Service that convert HTML to PDF using PhantomJS's rasterize example. | [calvintychan](http://github.com/calvintychan) |
|
||||
| **[Serverless Examples Cached Rds Ws](https://github.com/mugglmenzel/serverless-examples-cached-rds-ws)** <br/> A serverless framework example project that uses API Gateway, ElastiCache, and RDS PostgreSQL. | [mugglmenzel](http://github.com/mugglmenzel) |
|
||||
| **[Bittman](https://github.com/rhlsthrm/bittman)** <br/> A serverless project that follows a stock trading algorithm and uses scheduled functions to save data to DynamoDB and send emails through Mailgun. | [rhlsthrm](http://github.com/rhlsthrm) |
|
||||
| **[Adoptable Pet Bot](https://github.com/lynnaloo/adoptable-pet-bot)** <br/> Tweets adoptable pets using Serverless (Node.js) and AWS Lambda | [lynnaloo](http://github.com/lynnaloo) |
|
||||
| **[Owntracks Serverless](https://github.com/dschep/owntracks-serverless)** <br/> A serverless implementation of the OwnTracks HTTP backend | [dschep](http://github.com/dschep) |
|
||||
| **[Serverless Modern Koa](https://github.com/barczaG/serverless-modern-koa)** <br/> Serverless modern koa starter kit | [barczaG](http://github.com/barczaG) |
|
||||
| **[Serverless React JS Universal Rendering Boilerplate](https://github.com/TylorShin/react-universal-in-serverless)** <br/> ReactJS web app Starter kit does universal (isomorphic) rendering with Serverless | [TylorShin](http://github.com/TylorShin) |
|
||||
| **[Open Bot](https://github.com/open-bot/open-bot)** <br/> An unoptionated Github bot driven by a configuration file in the repository | [open-bot](http://github.com/open-bot) |
|
||||
| **[Aws Ses Serverless Example](https://github.com/lakshmantgld/aws-ses-serverless-example)** <br/> AWS SES example in NodeJS using lambda | [lakshmantgld](http://github.com/lakshmantgld) |
|
||||
| **[AWS API Gateway Serverless Project Written In Go](https://github.com/yunspace/serverless-golang)** <br/> A serverless project that contains an API Gateway endpoint powered by a Lambda function written in golang and built using [eawsy/aws-lambda-go-shim](https://github.com/eawsy/aws-lambda-go-shim). | [yunspace](http://github.com/yunspace) |
|
||||
| **[Video Preview And Analysis Service](https://github.com/laardee/video-preview-and-analysis-service)** <br/> An event-driven service that generates labels using Amazon Rekognition and creates preview GIF animation from a video file. | [laardee](http://github.com/laardee) |
|
||||
| **[Serverless ES 6 7 CRUD API](https://github.com/AnomalyInnovations/serverless-stack-demo-api)** <br/> [Serverless Stack](http://serverless-stack.com) examples of backend CRUD APIs (DynamoDB + Lambda + API Gateway + Cognito User Pool authorizer) for [React.js single-page app](http://demo.serverless-stack.com) | [AnomalyInnovations](http://github.com/AnomalyInnovations) |
|
||||
| **[SQS Worker With AWS Lambda And Cloud Watch Alarms](https://github.com/sbstjn/sqs-worker-serverless)** <br/> Process messages stored in SQS with an [auto-scaled AWS Lambda worker](https://sbstjn.com/serverless-sqs-worker-with-aws-lambda.html) function. | [sbstjn](http://github.com/sbstjn) |
|
||||
| **[Serverless Image Manager](https://github.com/TylorShin/lambda-image-manager)** <br/> image upload / download with resizing. Used API gateway's binary support & serverless | [TylorShin](http://github.com/TylorShin) |
|
||||
| **[AWS Lambda Power Tuning Powered By Step Functions](https://github.com/alexcasalboni/aws-lambda-power-tuning)** <br/> Build a [Step Functions](https://aws.amazon.com/step-functions/) state machine to optimize your AWS Lambda Function memory/power configuration. | [alexcasalboni](http://github.com/alexcasalboni) |
|
||||
| **[Amazon Kinesis Streams Fan Out Via Kinesis Analytics](https://github.com/alexcasalboni/kinesis-streams-fan-out-kinesis-analytics)** <br/> Use [Amazon Kinesis Analytics](https://aws.amazon.com/kinesis/analytics/) to fan-out your Kinesis Streams and avoid read throttling. | [alexcasalboni](http://github.com/alexcasalboni) |
|
||||
| **[Grants Api Serverless](https://github.com/comicrelief/grants-api-serverless)** <br/> ES6 API to consume data from an external API, ingest into Elasticsearch and return a queryable endpoint on top of Elasticsearch | [comicrelief](http://github.com/comicrelief) |
|
||||
| **[Honey Lambda](https://github.com/0x4D31/honeyLambda)** <br/> a simple, serverless application designed to create and monitor URL {honey}tokens, on top of AWS Lambda and Amazon API Gateway | [0x4D31](http://github.com/0x4D31) |
|
||||
| **[Faultline](https://github.com/faultline/faultline)** <br/> Error tracking tool on AWS managed services. | [faultline](http://github.com/faultline) |
|
||||
| **[Stack Overflow Monitor](https://github.com/picsoung/stackoverflowmonitor)** <br/> Monitor Stack Overflow questions and post them in a Slack channel | [picsoung](http://github.com/picsoung) |
|
||||
| **[Serverless Analytics](https://github.com/sbstjn/serverless-analytics)** <br/> Write your own Google Analytics clone and track website visitors serverless with API Gateway, Kinesis, Lambda, and DynamoDB. | [sbstjn](http://github.com/sbstjn) |
|
||||
| **[React Stripe Serverless Ecommerce](https://github.com/patrick-michelberger/serverless-shop)** <br/> Serverless E-Commerce App with AWS Lambda, Stripe and React | [patrick-michelberger](http://github.com/patrick-michelberger) |
|
||||
| **[Serverless Medium Text To Speech](https://github.com/RafalWilinski/serverless-medium-text-to-speech)** <br/> Serverless-based, text-to-speech service for Medium articles | [RafalWilinski](http://github.com/RafalWilinski) |
|
||||
| **[Serverless Java Dynamo DB Implementation Example](https://github.com/igorbakman/java-lambda-dynamodb)** <br/> example for java programmers that want to work with AWS-Lambda and DynamoDB | [igorbakman](http://github.com/igorbakman) |
|
||||
| **[AWS Cognito Custom User Pool Example](https://github.com/bsdkurt/aws-node-custom-user-pool)** <br/> Example CloudFormation custom resource backed by a lambda using Cognito User Pools | [bsdkurt](http://github.com/bsdkurt) |
|
||||
| **[Serverless Lambda Protobuf Responses](https://github.com/theburningmonk/lambda-protobuf-demo)** <br/> Demo using API Gateway and Lambda with Protocol Buffer | [theburningmonk](http://github.com/theburningmonk) |
|
||||
| **[Serverless Telegram Bot](https://github.com/jonatasbaldin/serverless-telegram-bot)** <br/> This example demonstrates how to setup an echo Telegram Bot using the Serverless Framework ⚡🤖 | [jonatasbaldin](http://github.com/jonatasbaldin) |
|
||||
| **[Serverless Line Bot](https://github.com/jiyeonseo/azure-line-bot-example)** <br/> Echo Line bot using Azure Function with Node.js | [jiyeonseo](http://github.com/jiyeonseo) |
|
||||
| **[Serverless Dashboard For Atom Editor](https://github.com/horike37/serverless-dashboard-for-atom)** <br/> Atom editor package which allows you to deploy and visualize your serverless services with Serverless Framework on your editor. | [horike37](http://github.com/horike37) |
|
||||
| **[Serverless Lambda Vpc Nat Redis](https://github.com/ittus/aws-lambda-vpc-nat-examples)** <br/> Demo using API Gateway and Lambda with VPC and NAT to access Internet and AWS Resource | [ittus](http://github.com/ittus) |
|
||||
| **[Serverless Gitlab CI](https://github.com/bvincent1/serverless-gitlab-ci)** <br/> Simple Gitlab CI template for automatic testing and deployments | [bvincent1](http://github.com/bvincent1) |
|
||||
| **[Serverless Ffmpeg](https://github.com/kvaggelakos/serverless-ffmpeg)** <br/> Bucket event driven FFMPEG using serverless. Input bucket => Serverless ffmpeg => Output bucket. | [kvaggelakos](http://github.com/kvaggelakos) |
|
||||
| **[Serverless SSH Command](https://github.com/upgle/serverless-openwhisk-ssh)** <br/> Example of executing ssh command with OpenWhisk | [upgle](http://github.com/upgle) |
|
||||
| **[Realtime WW 2 Alexa Skill](https://github.com/ceilfors/realtime-ww2-alexa)** <br/> An alexa skill project that's using Alexa SDK. Can also be used for a working example of serverless-webpack (with use of async/await via babel). | [ceilfors](http://github.com/ceilfors) |
|
||||
| **[Serverless Kakao Bot](https://github.com/JisuPark/serverless-kakao-bot)** <br/> Easy development for Kakaotalk Bot with Serverless | [JisuPark](http://github.com/JisuPark) |
|
||||
| **[Serverless Q A Example](https://github.com/jacksoncharles/serverless-qa-template-api)** <br/> Inspired by the AWS example forum. A multitenancy Q&A template for surveys, forums and more | [jacksoncharles](http://github.com/jacksoncharles) |
|
||||
| **[Personal Access Tokens Cron Check](https://github.com/madtrick/cfpat-audit)** <br/> Audit for leaked PAT in your Contentful organization. How to use serverless as cronjobs to keep your Personal Access Tokens secure | [madtrick](http://github.com/madtrick) |
|
||||
| **[Serverless Sns Api](https://github.com/eddielisc/serverless-sns-api)** <br/> Build a SNS service on AWS, support backend API for SNS by device, by group and by user | [eddielisc](http://github.com/eddielisc) |
|
||||
| **[Daily Instance Backups With AMI Rotation](https://github.com/AndrewFarley/AWSAutomatedDailyInstanceAMISnapshots)** <br/> A simple Python application which scans through your entire AWS account for tagged instances, makes daily AMIs of them, and rotates their backups automatically | [AndrewFarley](http://github.com/AndrewFarley) |
|
||||
| **[Serverless Instagram Crawler](https://github.com/kimcoder/serverless-instagram-crawler)** <br/> Instagram hashtag Crawler with Lambda & DynamoDB. | [kimcoder](http://github.com/kimcoder) |
|
||||
| **[Serving Binary Files](https://github.com/thomastoye/serverless-binary-files-xlsx)** <br/> Small example showing how to serve binary files using Serverless on AWS with the serverless-apigw-binary plugin, using generated Excel files as an example | [thomastoye](http://github.com/thomastoye) |
|
||||
| **[Serverless CloudWatch Proxy](https://github.com/abbasdgr8/cloudwatch-proxy)** <br/> Logging adapter that consumes log streams from AWS CloudWatch, streams them to other log destinations | [abbasdgr8](http://github.com/abbasdgr8) |
|
||||
<!-- AUTO-GENERATED-CONTENT:END This table is generated from https://github.com/serverless/examples/blob/master/community-examples.json please make additions there -->
|
||||
- Supports Node.js, Python, Java, Go, C#, Ruby, Swift, Kotlin, PHP, Scala, & F#
|
||||
- Manages the lifecycle of your serverless architecture (build, deploy, update, delete).
|
||||
- Safely deploy functions, events and their required resources together via provider resource managers (e.g., AWS CloudFormation).
|
||||
- Functions can be grouped ("serverless services") for easy management of code, resources & processes, across large projects & teams.
|
||||
- Minimal configuration and scaffolding.
|
||||
- Built-in support for multiple stages.
|
||||
- Optimized for CI/CD workflows.
|
||||
- Loaded with automation, optimization and best practices.
|
||||
- 100% Extensible: Extend or modify the Framework and its operations via Plugins.
|
||||
- An ecosystem of serverless services and plugins.
|
||||
- A passionate and welcoming community!
|
||||
|
||||
## <a name="contributing"></a>Contributing
|
||||
|
||||
We love our contributors! Please read our [Contributing Document](CONTRIBUTING.md) to learn how you can start working on the Framework yourself.
|
||||
|
||||
Check out our [help wanted](https://github.com/serverless/serverless/labels/help%20wanted) or [good first issue](https://github.com/serverless/serverless/labels/good%20first%20issue) labels to find issues we want to move forward on with your help.
|
||||
|
||||
## <a name="community"></a>Community
|
||||
|
||||
* [Email Updates](http://eepurl.com/b8dv4P)
|
||||
* [Serverless Forum](http://forum.serverless.com)
|
||||
* [Gitter Chatroom](https://gitter.im/serverless/serverless)
|
||||
* [Serverless Meetups](http://www.meetup.com/serverless/)
|
||||
* [Stackoverflow](http://stackoverflow.com/questions/tagged/serverless-framework)
|
||||
* [Facebook](https://www.facebook.com/serverless)
|
||||
* [Twitter](https://twitter.com/goserverless)
|
||||
* [Contact Us](mailto:hello@serverless.com)
|
||||
- [Email Updates](http://eepurl.com/b8dv4P)
|
||||
- [Serverless Forum](http://forum.serverless.com)
|
||||
- [Gitter Chatroom](https://gitter.im/serverless/serverless)
|
||||
- [Serverless Meetups](http://www.meetup.com/serverless/)
|
||||
- [Stackoverflow](http://stackoverflow.com/questions/tagged/serverless-framework)
|
||||
- [Facebook](https://www.facebook.com/serverless)
|
||||
- [Twitter](https://twitter.com/goserverless)
|
||||
- [Contact Us](mailto:hello@serverless.com)
|
||||
|
||||
## <a name="consultants"></a>Consultants
|
||||
|
||||
These consultants use the Serverless Framework and can help you build your serverless projects.
|
||||
* [Andrew Griffiths](https://www.andrewgriffithsonline.com/) - Independent consultant specialising in serverless technology
|
||||
* [Trek10](https://www.trek10.com/)
|
||||
* [Parallax](https://parall.ax/) – they also built the [David Guetta Campaign](https://serverlesscode.com/post/david-guetta-online-recording-with-lambda/)
|
||||
* [Geniusee](https://geniusee.com)
|
||||
* [SC5 Online](https://sc5.io)
|
||||
* [Carrot Creative](https://carrot.is)
|
||||
* [microapps](http://microapps.com)
|
||||
* [Apiwise](http://www.apiwise.nl)
|
||||
* [Useful IO](http://useful.io) - and [Hail Messaging](http://hail.io)
|
||||
* [WhaleTech](https://whaletech.co/)
|
||||
* [Hop Labs](http://www.hoplabs.com)
|
||||
* [Webscale](https://webscale.fi/briefly-in-english/)
|
||||
* [API talent](http://www.apitalent.co.nz) - who also run [Serverless-Auckland Meetup](http://www.meetup.com/Serverless-Auckland)
|
||||
* [Branded Crate](https://www.brandedcrate.com/)
|
||||
* [cloudonaut](https://cloudonaut.io/serverless-consulting/)
|
||||
* [PromptWorks](https://www.promptworks.com/serverless/)
|
||||
* [Craftship](https://craftship.io)
|
||||
* [EPX Labs](http://www.epxlabs.com/) - runs [Serverless NYC Meetup](https://www.meetup.com/Serverless-NYC/)
|
||||
* [Red Badger](https://red-badger.com)
|
||||
* [Langa](http://langa.io/?utm_source=gh-serverless&utm_medium=github) - They built [Trails.js](http://github.com/trailsjs/trails)
|
||||
* [Emerging Technology Advisors](https://www.emergingtechnologyadvisors.com)
|
||||
* [OneSpeed](https://onespeed.io/)
|
||||
* [Seraro](http://www.seraro.com/) - Who also runs Atlanta Serverless Meetup (https://www.meetup.com/Atlanta-CABI-Camp-Cloud-AI-Blockchain-IOT) and Delhi Serverless Meetup (https://www.meetup.com/Delhi-NCR-Serverless-Architecture-Meetup/)
|
||||
* [superluminar](https://superluminar.io) - runs serverlessdays Hamburg and Serverless Meetup Hamburg
|
||||
----
|
||||
|
||||
- [Andrew Griffiths](https://www.andrewgriffithsonline.com/) - Independent consultant specialising in serverless technology
|
||||
- [Trek10](https://www.trek10.com/)
|
||||
- [Parallax](https://parall.ax/) – they also built the [David Guetta Campaign](https://serverlesscode.com/post/david-guetta-online-recording-with-lambda/)
|
||||
- [Geniusee](https://geniusee.com)
|
||||
- [SC5 Online](https://sc5.io)
|
||||
- [Carrot Creative](https://carrot.is)
|
||||
- [microapps](http://microapps.com)
|
||||
- [Apiwise](http://www.apiwise.nl)
|
||||
- [Useful IO](http://useful.io) - and [Hail Messaging](http://hail.io)
|
||||
- [WhaleTech](https://whaletech.co/)
|
||||
- [Hop Labs](http://www.hoplabs.com)
|
||||
- [Webscale](https://webscale.fi/briefly-in-english/)
|
||||
- [API talent](http://www.apitalent.co.nz) - who also run [Serverless-Auckland Meetup](http://www.meetup.com/Serverless-Auckland)
|
||||
- [Branded Crate](https://www.brandedcrate.com/)
|
||||
- [cloudonaut](https://cloudonaut.io/serverless-consulting/)
|
||||
- [PromptWorks](https://www.promptworks.com/serverless/)
|
||||
- [Craftship](https://craftship.io)
|
||||
- [EPX Labs](http://www.epxlabs.com/) - runs [Serverless NYC Meetup](https://www.meetup.com/Serverless-NYC/)
|
||||
- [Red Badger](https://red-badger.com)
|
||||
- [Langa](http://langa.io/?utm_source=gh-serverless&utm_medium=github) - They built [Trails.js](http://github.com/trailsjs/trails)
|
||||
- [Emerging Technology Advisors](https://www.emergingtechnologyadvisors.com)
|
||||
- [OneSpeed](https://onespeed.io/)
|
||||
- [Seraro](http://www.seraro.com/) - Who also runs Atlanta Serverless Meetup (https://www.meetup.com/Atlanta-CABI-Camp-Cloud-AI-Blockchain-IOT) and Delhi Serverless Meetup (https://www.meetup.com/Delhi-NCR-Serverless-Architecture-Meetup/)
|
||||
- [superluminar](https://superluminar.io) - runs serverlessdays Hamburg and Serverless Meetup Hamburg
|
||||
- [Onica](https://www.onica.com/aws-cloud-native-developers/) - AWS Premier Consulting Partner for Cloud Native Development and host of [eleven regional Meetup groups](https://www.onica.com/events/).
|
||||
- [null](https://null.tc/) - maintains [Bref](https://bref.sh/) to create serverless PHP applications
|
||||
|
||||
---
|
||||
|
||||
## <a name="licensing"></a>Licensing
|
||||
|
||||
|
||||
@ -7,31 +7,27 @@ More info about our release process can be found in the [`RELEASE_PROCESS.md`](.
|
||||
## Pre-Release
|
||||
|
||||
- [ ] Look through all open issues and PRs (if any) of that milestone and close them / move them to another
|
||||
milestone if still open
|
||||
- [ ] Look through all closed issues and PRs of that milestone to see what has changed. Run `./scripts/prs-since-last-tag` or if you want to run against a specific tag `./scripts/prs-since-last-tag v1.20.0` to get a list of all merged PR's since a specific tag
|
||||
- [ ] Close milestone on GitHub
|
||||
- [ ] Create a new draft release in GitHub
|
||||
|
||||
# Testing
|
||||
|
||||
- [ ] Create a Serverless service (with some events), deploy and test it intensively
|
||||
- [ ] Look through the milestone and test all of the new major changes
|
||||
- [ ] Run `npm test`
|
||||
- [ ] Run `npm run simple-integration-test`
|
||||
- [ ] Run `npm run complex-integration-test`
|
||||
milestone if still open
|
||||
- [ ] Create a new branch for the release
|
||||
- [ ] Bump the version number in `package.json`
|
||||
- [ ] Run `./scripts/prs-since-last-tag <OLD-TAG>`
|
||||
- [ ] Save the terminal output to your clipboard
|
||||
- [ ] Close the milestone on GitHub
|
||||
- [ ] Create a new [**draft** release](https://github.com/serverless/serverless/releases/new) in GitHub
|
||||
- [ ] Use the content in your clipboard as a description (without the heading)
|
||||
- [ ] Ensure that the "Tag version" follows our naming convention
|
||||
|
||||
## Prepare Package
|
||||
|
||||
- [ ] Create a new branch to bump version in `package.json`
|
||||
- [ ] Install the latest `npm` version or Docker container with latest `node` and `npm`
|
||||
- [ ] Bump version in `package.json`, remove `node_modules` folder and run `npm install` and `npm prune --production && npm shrinkwrap`
|
||||
- [ ] Look through closed PRs and update `CHANGELOG.md`
|
||||
- [ ] Install the latest `npm` version or Docker container with latest `node` and `npm` (Ensure to work with an `npm` version which is distributed with latest `node` version)
|
||||
- [ ] Update `CHANGELOG.md` with the content from your clipboard
|
||||
- [ ] Make sure all files that need to be pushed are included in `package.json -> files`
|
||||
- [ ] Send PR and merge PR with new version to be released
|
||||
- [ ] Add the changes you made to `CHANGELOG.md` to the description of the GitHub release draft
|
||||
- [ ] Go back to branch you want to release from (e.g. `master`) and pull bumped version changes from GitHub
|
||||
- [ ] Commit your changes (make sure that `package.json` and `CHANGELOG.md` are updated)
|
||||
- [ ] Push your branch and open up a new PR
|
||||
- [ ] Await approval and merge the PR into `master`
|
||||
- [ ] Go back to the branch you want to release from (e.g. `master`) and pull the changes from GitHub
|
||||
- [ ] Make sure there are no local changes to your repository (or reset with `git reset --hard HEAD`)
|
||||
- [ ] Check `package.json`, `package-lock.json` and `npm-shrinkwrap.json` version config to make sure it fits what we want to release
|
||||
- [ ] Check `package.json` version config to make sure it fits what we want to release
|
||||
|
||||
## Releasing
|
||||
|
||||
@ -41,7 +37,3 @@ milestone if still open
|
||||
## Validate Release
|
||||
|
||||
- [ ] Validate that `npm install` works (`npm install -g serverless@<new-tag>` or `npm install -g serverless` if latest is released)
|
||||
|
||||
## Post-Release
|
||||
|
||||
- [ ] Run `./scripts/generate-release-contributors-list <old-tag> <new-tag>` and hand the generated list over to the release blog post author
|
||||
|
||||
@ -35,20 +35,24 @@ Any non-backward compatible changes leads to a major version bump. This includes
|
||||
#### What is considered a breaking change?
|
||||
|
||||
- Everything which touches the public facing API
|
||||
+ CLI commands
|
||||
+ CLI options
|
||||
+ Methods accessible through `this.serverless`
|
||||
+ ...
|
||||
- CLI commands
|
||||
- CLI options
|
||||
- Methods accessible through `this.serverless`
|
||||
- ...
|
||||
- Output Serverless produces
|
||||
+ Files and their names
|
||||
+ Transient data which is available during runtime
|
||||
+ Formatted CLI outputs (e.g. via `--json`) **NOT:** standard outputs
|
||||
+ ...
|
||||
- Files and their names
|
||||
- Transient data which is available during runtime
|
||||
- Formatted CLI outputs (e.g. via `--json`) **NOT:** standard outputs
|
||||
- ...
|
||||
|
||||
#### Example of a Breaking Change
|
||||
|
||||
If we remove a helper function from the serverless object passed down to a plugin then this is a breaking change since some people might rely on it in custom made plugins.
|
||||
|
||||
### Node.js versions
|
||||
|
||||
The Serverless Framework supports the major cloud providers Node.js runtime versions. Support for old Node.js versions will be removed once Cloud providers announce that such runtimes are not supported anymore.
|
||||
|
||||
### FAQ
|
||||
|
||||
1. Is it okay to mark a feature as deprecated in version 1.4.0 and then remove it in 1.8.0
|
||||
|
||||
@ -1,65 +1,9 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
// TODO: Remove with file with next major (breaking) release
|
||||
// Left as a fallback placeholder to not accidentally break things
|
||||
// https://github.com/search?q=%22bin%2Fserverless%22&type=Code
|
||||
|
||||
'use strict';
|
||||
|
||||
const autocomplete = require('../lib/utils/autocomplete');
|
||||
const BbPromise = require('bluebird');
|
||||
const logError = require('../lib/classes/Error').logError;
|
||||
const uuid = require('uuid');
|
||||
const initializeErrorReporter = require('../lib/utils/sentry').initializeErrorReporter;
|
||||
|
||||
Error.stackTraceLimit = Infinity;
|
||||
|
||||
if (process.env.SLS_DEBUG) {
|
||||
// For performance reasons enabled only in SLS_DEBUG mode
|
||||
BbPromise.config({
|
||||
longStackTraces: true,
|
||||
});
|
||||
}
|
||||
|
||||
process.on('unhandledRejection', (e) => {
|
||||
logError(e);
|
||||
});
|
||||
process.noDeprecation = true;
|
||||
|
||||
const invocationId = uuid.v4();
|
||||
|
||||
// boot up error reporting via sentry before anything
|
||||
(() => initializeErrorReporter(invocationId).then(() => {
|
||||
if (process.argv[2] === 'completion') {
|
||||
return autocomplete();
|
||||
}
|
||||
// requiring here so that if anything went wrong,
|
||||
// during require, it will be caught.
|
||||
const Serverless = require('../lib/Serverless'); // eslint-disable-line global-require
|
||||
|
||||
const serverless = new Serverless({
|
||||
interactive: typeof process.env.CI === 'undefined',
|
||||
});
|
||||
|
||||
serverless.invocationId = invocationId;
|
||||
|
||||
return serverless.init()
|
||||
.then(() => serverless.run())
|
||||
.then(() => process.exit(0))
|
||||
.catch((err) => {
|
||||
// If Enterprise Plugin, capture error
|
||||
let enterpriseErrorHandler = null;
|
||||
serverless.pluginManager.plugins.forEach((p) => {
|
||||
if (p.enterprise && p.enterprise.errorHandler) {
|
||||
enterpriseErrorHandler = p.enterprise.errorHandler;
|
||||
}
|
||||
});
|
||||
if (!enterpriseErrorHandler) { throw err; }
|
||||
return enterpriseErrorHandler(err, invocationId)
|
||||
.catch((error) => {
|
||||
console.log(error)
|
||||
})
|
||||
.then(() => {
|
||||
throw err
|
||||
});
|
||||
})
|
||||
}).catch(e => {
|
||||
process.exitCode = 1;
|
||||
logError(e);
|
||||
}))();
|
||||
require('./serverless.js');
|
||||
|
||||
71
bin/serverless.js
Executable file
71
bin/serverless.js
Executable file
@ -0,0 +1,71 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
'use strict';
|
||||
|
||||
const autocomplete = require('../lib/utils/autocomplete');
|
||||
const BbPromise = require('bluebird');
|
||||
const logError = require('../lib/classes/Error').logError;
|
||||
const uuid = require('uuid');
|
||||
const initializeErrorReporter = require('../lib/utils/sentry').initializeErrorReporter;
|
||||
|
||||
Error.stackTraceLimit = Infinity;
|
||||
|
||||
if (process.env.SLS_DEBUG) {
|
||||
// For performance reasons enabled only in SLS_DEBUG mode
|
||||
BbPromise.config({
|
||||
longStackTraces: true,
|
||||
});
|
||||
}
|
||||
|
||||
process.on('unhandledRejection', e => {
|
||||
logError(e);
|
||||
});
|
||||
process.noDeprecation = true;
|
||||
|
||||
const invocationId = uuid.v4();
|
||||
|
||||
// boot up error reporting via sentry before anything
|
||||
(() =>
|
||||
initializeErrorReporter(invocationId)
|
||||
.then(() => {
|
||||
if (process.argv[2] === 'completion') {
|
||||
return autocomplete();
|
||||
}
|
||||
// requiring here so that if anything went wrong,
|
||||
// during require, it will be caught.
|
||||
const Serverless = require('../lib/Serverless');
|
||||
|
||||
const serverless = new Serverless();
|
||||
|
||||
serverless.invocationId = invocationId;
|
||||
|
||||
return serverless
|
||||
.init()
|
||||
.then(() => serverless.run())
|
||||
.catch(err => {
|
||||
// If Enterprise Plugin, capture error
|
||||
let enterpriseErrorHandler = null;
|
||||
serverless.pluginManager.plugins.forEach(p => {
|
||||
if (p.enterprise && p.enterprise.errorHandler) {
|
||||
enterpriseErrorHandler = p.enterprise.errorHandler;
|
||||
}
|
||||
});
|
||||
if (!enterpriseErrorHandler) {
|
||||
throw err;
|
||||
}
|
||||
return enterpriseErrorHandler(err, invocationId)
|
||||
.catch(error => {
|
||||
process.stdout.write(`${error.stack}\n`);
|
||||
})
|
||||
.then(() => {
|
||||
throw err;
|
||||
});
|
||||
});
|
||||
})
|
||||
.then(
|
||||
() => process.exit(0),
|
||||
e => {
|
||||
process.exitCode = 1;
|
||||
logError(e);
|
||||
}
|
||||
))();
|
||||
20
bin/test
20
bin/test
@ -1,20 +0,0 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
'use strict';
|
||||
|
||||
process.on('unhandledRejection', err => {
|
||||
throw err;
|
||||
});
|
||||
|
||||
if (process.argv.length <= 2) {
|
||||
process.argv.push(
|
||||
'!(node_modules)/**/*.test.js',
|
||||
'--require=sinon-bluebird',
|
||||
'-R',
|
||||
'spec',
|
||||
'--recursive',
|
||||
'--no-exit'
|
||||
);
|
||||
}
|
||||
|
||||
require('mocha/bin/_mocha');
|
||||
@ -84,8 +84,8 @@ services:
|
||||
aws-go-mod:
|
||||
image: golang:1.11
|
||||
volumes:
|
||||
- ./tmp/serverless-integration-test-aws-go-mod:/app
|
||||
- ./tmp/serverless-integration-test-aws-go-mod:/go/src/app
|
||||
- ./tmp/serverless-integration-test-aws-go-mod:/app
|
||||
- ./tmp/serverless-integration-test-aws-go-mod:/go/src/app
|
||||
aws-nodejs-typescript:
|
||||
image: node:6.10.3
|
||||
volumes:
|
||||
|
||||
@ -17,7 +17,9 @@ menuItems:
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Documentation
|
||||
|
||||
@ -5,7 +5,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Serverless Infrastructure Providers
|
||||
|
||||
@ -5,7 +5,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS Provider Documentation
|
||||
@ -93,6 +95,7 @@ If you have any questions, [search the forums](https://forum.serverless.com?utm_
|
||||
<li><a href="./events/schedule.md">Schedule</a></li>
|
||||
<li><a href="./events/sns.md">SNS</a></li>
|
||||
<li><a href="./events/sqs.md">SQS</a></li>
|
||||
<li><a href="./events/alb.md">ALB</a></li>
|
||||
<li><a href="./events/alexa-skill.md">Alexa Skill</a></li>
|
||||
<li><a href="./events/alexa-smart-home.md">Alexa Smart Home</a></li>
|
||||
<li><a href="./events/iot.md">IoT</a></li>
|
||||
|
||||
@ -5,12 +5,14 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Serverless AWS Lambda CLI Reference
|
||||
|
||||
Welcome to the Serverless AWS Lambda CLI Reference! Please select a section on the left to get started.
|
||||
Welcome to the Serverless AWS Lambda CLI Reference! Please select a section on the left to get started.
|
||||
|
||||
**Note:** Before continuing [AWS system credentials](../guide/credentials.md) are required for using the CLI.
|
||||
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/config-credentials)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Config Credentials
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/create)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Create
|
||||
@ -33,6 +35,7 @@ serverless create --template-url https://github.com/serverless/serverless/tree/m
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--template` or `-t` The name of one of the available templates. **Required if --template-url and --template-path are not present**.
|
||||
- `--template-url` or `-u` The name of one of the available templates. **Required if --template and --template-path are not present**.
|
||||
- `--template-path` The local path of your template. **Required if --template and --template-url are not present**.
|
||||
@ -40,6 +43,7 @@ serverless create --template-url https://github.com/serverless/serverless/tree/m
|
||||
- `--name` or `-n` the name of the service in `serverless.yml`.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `create:create`
|
||||
|
||||
## Available Templates
|
||||
|
||||
@ -7,12 +7,14 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy-function)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Deploy Function
|
||||
|
||||
The `sls deploy function` command deploys an individual function without AWS CloudFormation. This command simply swaps out the zip file that your CloudFormation stack is pointing toward. This is a much faster way of deploying changes in code.
|
||||
The `sls deploy function` command deploys an individual function without AWS CloudFormation. This command simply swaps out the zip file that your CloudFormation stack is pointing toward. This is a much faster way of deploying changes in code.
|
||||
|
||||
```bash
|
||||
serverless deploy function -f functionName
|
||||
@ -24,6 +26,7 @@ is out of sync with your CloudFormation stack. Use this for faster development
|
||||
cycles and not production deployments
|
||||
|
||||
## Options
|
||||
|
||||
- `--function` or `-f` The name of the function which should be deployed
|
||||
- `--stage` or `-s` The stage in your service that you want to deploy to.
|
||||
- `--region` or `-r` The region in that stage that you want to deploy to.
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy-list)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Deploy List
|
||||
|
||||
@ -7,18 +7,22 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - deploy
|
||||
|
||||
The `sls deploy` command deploys your entire service via CloudFormation. Run this command when you have made infrastructure changes (i.e., you edited `serverless.yml`). Use `serverless deploy function -f myFunction` when you have made code changes and you want to quickly upload your updated code to AWS Lambda or just change function configuration.
|
||||
The `sls deploy` command deploys your entire service via CloudFormation. Run this command when you have made infrastructure changes (i.e., you edited `serverless.yml`). Use `serverless deploy function -f myFunction` when you have made code changes and you want to quickly upload your updated code to AWS Lambda or just change function configuration.
|
||||
|
||||
```bash
|
||||
serverless deploy
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--config` or `-c` Path to your conifguration file, if other than `serverless.yml|.yaml|.js|.json`.
|
||||
- `--stage` or `-s` The stage in your service that you want to deploy to.
|
||||
- `--region` or `-r` The region in that stage that you want to deploy to.
|
||||
- `--package` or `-p` path to a pre-packaged directory and skip packaging step.
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/info)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Info
|
||||
@ -19,11 +21,13 @@ serverless info
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--stage` or `-s` The stage in your service you want to display information about.
|
||||
- `--region` or `-r` The region in your stage that you want to display information about.
|
||||
- `--verbose` or `-v` Shows displays any Stack Output.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `info:info`
|
||||
|
||||
## Examples
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/install)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Install
|
||||
@ -19,12 +21,21 @@ serverless install --url https://github.com/some/service
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--url` or `-u` The services GitHub URL. **Required**.
|
||||
- `--name` or `-n` Name for the service.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `install:install`
|
||||
|
||||
## Supported Code Hosting Platforms
|
||||
|
||||
- GitHub
|
||||
- GitHub Enterprise
|
||||
- GitLab
|
||||
- BitBucket
|
||||
|
||||
## Examples
|
||||
|
||||
### Installing a service from a GitHub URL
|
||||
|
||||
@ -7,12 +7,14 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/invoke-local)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Invoke Local
|
||||
|
||||
This runs your code locally by emulating the AWS Lambda environment. Please keep in mind, it's not a 100% perfect emulation, there may be some differences, but it works for the vast majority of users. We mock the `context` with simple mock data.
|
||||
This runs your code locally by emulating the AWS Lambda environment. Please keep in mind, it's not a 100% perfect emulation, there may be some differences, but it works for the vast majority of users. We mock the `context` with simple mock data.
|
||||
|
||||
```bash
|
||||
serverless invoke local --function functionName
|
||||
@ -28,6 +30,7 @@ serverless invoke local --function functionName
|
||||
- `--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.
|
||||
|
||||
* `--env` or `-e` String representing an environment variable to set when invoking your function, in the form `<name>=<value>`. Can be repeated for more than one environment variable.
|
||||
* `--docker` Enable docker support for NodeJS/Python/Ruby/Java. Enabled by default for other
|
||||
runtimes.
|
||||
@ -80,7 +83,7 @@ This example will pass the json data in the `lib/data.json` file (relative to th
|
||||
{
|
||||
"resource": "/",
|
||||
"path": "/",
|
||||
"httpMethod": "GET",
|
||||
"httpMethod": "GET"
|
||||
// etc. //
|
||||
}
|
||||
```
|
||||
@ -96,6 +99,7 @@ serverless invoke local --function functionName --context "hello world"
|
||||
```bash
|
||||
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.
|
||||
|
||||
### Local function invocation, setting environment variables
|
||||
@ -120,7 +124,7 @@ Use of the `--docker` flag and runtimes other than NodeJs, Python, Java, & Ruby
|
||||
|
||||
## Resource permissions
|
||||
|
||||
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`.
|
||||
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`).
|
||||
|
||||
@ -131,4 +135,4 @@ Take a look to the official AWS documentation (in this particular instance, for
|
||||
- [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-shared.html)
|
||||
- [http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-node-credentials-lambda.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.
|
||||
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.
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/invoke)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Invoke
|
||||
@ -21,6 +23,7 @@ serverless invoke [local] --function functionName
|
||||
**Note:** Please refer to [this guide](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html#api-gateway-simple-proxy-for-lambda-input-format) for event data passing when your function uses the `http` event with a Lambda Proxy integration.
|
||||
|
||||
## Options
|
||||
|
||||
- `--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.
|
||||
@ -31,6 +34,7 @@ serverless invoke [local] --function functionName
|
||||
- `--log` or `-l` If set to `true` and invocation type is `RequestResponse`, it will output logging data of the invocation. Default is `false`.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `invoke:invoke`
|
||||
|
||||
# Invoke Local
|
||||
@ -45,7 +49,7 @@ 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 the `event`. This path is relative to the
|
||||
root directory of the service.
|
||||
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.
|
||||
@ -97,7 +101,7 @@ the specified/deployed function.
|
||||
{
|
||||
"resource": "/",
|
||||
"path": "/",
|
||||
"httpMethod": "GET",
|
||||
"httpMethod": "GET"
|
||||
// etc. //
|
||||
}
|
||||
```
|
||||
@ -109,9 +113,11 @@ serverless invoke local --function functionName --context "hello world"
|
||||
```
|
||||
|
||||
### Local function invocation with context passing
|
||||
|
||||
```bash
|
||||
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.
|
||||
|
||||
### Limitations
|
||||
@ -120,7 +126,7 @@ Currently, `invoke local` only supports the NodeJs and Python runtimes.
|
||||
|
||||
## Resource permissions
|
||||
|
||||
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`.
|
||||
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`).
|
||||
|
||||
@ -131,4 +137,4 @@ Take a look to the official AWS documentation (in this particular instance, for
|
||||
- [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-shared.html)
|
||||
- [http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-node-credentials-lambda.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.
|
||||
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.
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/login)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Login
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/logs)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Logs
|
||||
@ -65,16 +67,19 @@ This command returns as many log events as can fit in 1MB (up to 10,000 log even
|
||||
```bash
|
||||
serverless logs -f hello
|
||||
```
|
||||
|
||||
This will fetch the logs from last 10 minutes as startTime was not given.
|
||||
|
||||
```bash
|
||||
serverless logs -f hello --startTime 5h
|
||||
```
|
||||
|
||||
This will fetch the logs that happened in the past 5 hours.
|
||||
|
||||
```bash
|
||||
serverless logs -f hello --startTime 1469694264
|
||||
```
|
||||
|
||||
This will fetch the logs that happened starting at epoch `1469694264`.
|
||||
|
||||
```bash
|
||||
@ -86,4 +91,5 @@ Serverless will tail the CloudWatch log output and print new log messages coming
|
||||
```bash
|
||||
serverless logs -f hello --filter serverless
|
||||
```
|
||||
|
||||
This will fetch only the logs that contain the string `serverless`
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/metrics)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Metrics
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/package)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - package
|
||||
@ -19,6 +21,7 @@ serverless package
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--stage` or `-s` The stage in your service that you want to deploy to.
|
||||
- `--region` or `-r` The region in that stage that you want to deploy to.
|
||||
- `--package` or `-p` path to the custom packaging directory you want.
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/plugin-install)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Plugin Install
|
||||
@ -22,9 +24,11 @@ serverless plugin install --name pluginName
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--name` or `-n` The plugins name. **Required**.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `plugin:install:install`
|
||||
|
||||
## Examples
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/plugin-list)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Plugin List
|
||||
@ -19,7 +21,9 @@ serverless plugin list
|
||||
```
|
||||
|
||||
## Options
|
||||
- *None*
|
||||
|
||||
- _None_
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `plugin:list:list`
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/plugin-search)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Plugin Search
|
||||
@ -19,9 +21,11 @@ serverless plugin search --query query
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--query` or `-q` The query you want to use for your search. **Required**.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `plugin:search:search`
|
||||
|
||||
## Examples
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/plugin-uninstall)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Plugin Uninstall
|
||||
@ -19,9 +21,11 @@ serverless plugin uninstall --name pluginName
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--name` or `-n` The plugins name. **Required**.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `plugin:uninstall:uninstall`
|
||||
|
||||
## Examples
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/print)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Print
|
||||
@ -42,7 +44,7 @@ custom:
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
stage: ${opt:stage, "dev"}
|
||||
|
||||
functions:
|
||||
@ -66,7 +68,7 @@ custom:
|
||||
bucketName: test
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
stage: dev # <-- Resolved
|
||||
functions:
|
||||
hello:
|
||||
|
||||
@ -7,23 +7,27 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/remove)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Remove
|
||||
|
||||
The `sls remove` command will remove the deployed service, defined in your current working directory, from the provider.
|
||||
The `sls remove` command will remove the deployed service, defined in your current working directory, from the provider.
|
||||
|
||||
```bash
|
||||
serverless remove
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--stage` or `-s` The name of the stage in service.
|
||||
- `--region` or `-r` The name of the region in stage.
|
||||
- `--verbose` or `-v` Shows all stack events during deployment.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `remove:remove`
|
||||
|
||||
## Examples
|
||||
|
||||
@ -7,9 +7,10 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/rollback-function)
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/rollback-function)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Rollback Function
|
||||
|
||||
|
||||
@ -7,9 +7,10 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/rollback)
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/rollback)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Rollback
|
||||
|
||||
@ -22,10 +23,12 @@ serverless rollback --timestamp timestamp
|
||||
If `timestamp` is not specified, Framework will show your existing deployments.
|
||||
|
||||
## Options
|
||||
|
||||
- `--timestamp` or `-t` The deployment you want to rollback to.
|
||||
- `--verbose` or `-v` Shows any Stack Output.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `rollback:initialize`
|
||||
- `rollback:rollback`
|
||||
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/slstats)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Serverless Statistics and Usage Tracking
|
||||
@ -46,8 +48,8 @@ The following is a list of the events that we collect:
|
||||
- service_pluginUninstalled
|
||||
- service_installed
|
||||
- user_awsCredentialsConfigured
|
||||
- user_enabledTracking
|
||||
- user_disabledTracking
|
||||
- user_enabledTracking
|
||||
- user_disabledTracking
|
||||
- user_loggedIn
|
||||
- user_loggedOut
|
||||
|
||||
|
||||
@ -5,7 +5,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Serverless AWS Lambda Events
|
||||
|
||||
63
docs/providers/aws/events/alb.md
Normal file
63
docs/providers/aws/events/alb.md
Normal file
@ -0,0 +1,63 @@
|
||||
<!--
|
||||
title: Serverless Framework - AWS Lambda Events - ALB
|
||||
menuText: Application Load Balancer
|
||||
menuOrder: 8
|
||||
description: Setting up AWS Application Load Balancer events with AWS Lambda via the Serverless Framework
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/alb)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Application Load Balancer
|
||||
|
||||
[Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) can be used to re-route requests when certain traffic patterns are met. While traffic can be routed to services such as EC2 it [can also be routed to Lambda functions](https://aws.amazon.com/de/blogs/networking-and-content-delivery/lambda-functions-as-targets-for-application-load-balancers/) which can in turn be used process incoming requests.
|
||||
|
||||
The Serverless Framework makes it possible to setup the connection between Application Load Balancers and Lambda functions with the help of the `alb` event.
|
||||
|
||||
## Event definition
|
||||
|
||||
```yml
|
||||
functions:
|
||||
albEventConsumer:
|
||||
handler: handler.hello
|
||||
events:
|
||||
- alb:
|
||||
listenerArn: arn:aws:elasticloadbalancing:us-east-1:12345:listener/app/my-load-balancer/50dc6c495c0c9188/
|
||||
priority: 1
|
||||
conditions:
|
||||
path: /hello
|
||||
```
|
||||
|
||||
## Using different conditions
|
||||
|
||||
```yml
|
||||
functions:
|
||||
albEventConsumer:
|
||||
handler: handler.hello
|
||||
events:
|
||||
- alb:
|
||||
listenerArn: arn:aws:elasticloadbalancing:us-east-1:12345:listener/app/my-load-balancer/50dc6c495c0c9188/
|
||||
priority: 1
|
||||
conditions:
|
||||
host: example.com
|
||||
path: /hello
|
||||
method:
|
||||
- POST
|
||||
- PATCH
|
||||
host:
|
||||
- example.com
|
||||
- example2.com
|
||||
header:
|
||||
name: foo
|
||||
values:
|
||||
- bar
|
||||
query:
|
||||
bar: true
|
||||
ip:
|
||||
- fe80:0000:0000:0000:0204:61ff:fe9d:f156/6
|
||||
- 192.168.0.1/0
|
||||
```
|
||||
@ -1,13 +1,15 @@
|
||||
<!--
|
||||
title: Serverless Framework - AWS Lambda Events - Alexa Skill
|
||||
menuText: Alexa Skill
|
||||
menuOrder: 8
|
||||
menuOrder: 9
|
||||
description: Setting up AWS Alexa Skill Events with AWS Lambda via the Serverless Framework
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/alexa-skill)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Alexa Skill
|
||||
|
||||
@ -1,13 +1,15 @@
|
||||
<!--
|
||||
title: Serverless Framework - AWS Lambda Events - Alexa Smart Home
|
||||
menuText: Alexa Smart Home
|
||||
menuOrder: 13
|
||||
menuOrder: 10
|
||||
description: Setting up AWS Alexa Smart Home Events with AWS Lambda via the Serverless Framework
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/alexa-smart-home)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Alexa Smart Home
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/apigateway)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# API Gateway
|
||||
@ -62,15 +64,16 @@ _Are you looking for tutorials on using API Gateway? Check out the following res
|
||||
To create HTTP endpoints as Event sources for your AWS Lambda Functions, use the Serverless Framework's easy AWS API Gateway Events syntax.
|
||||
|
||||
There are five ways you can configure your HTTP endpoints to integrate with your AWS Lambda Functions:
|
||||
* `lambda-proxy` / `aws-proxy` / `aws_proxy` (Recommended)
|
||||
* `lambda` / `aws`
|
||||
* `http`
|
||||
* `http-proxy` / `http_proxy`
|
||||
* `mock`
|
||||
|
||||
- `lambda-proxy` / `aws-proxy` / `aws_proxy` (Recommended)
|
||||
- `lambda` / `aws`
|
||||
- `http`
|
||||
- `http-proxy` / `http_proxy`
|
||||
- `mock`
|
||||
|
||||
**The Framework uses the `lambda-proxy` method (i.e., everything is passed into your Lambda) by default unless another method is supplied by the user**
|
||||
|
||||
The difference between these is `lambda-proxy` (alternative writing styles are `aws-proxy` and `aws_proxy` for compatibility with the standard AWS integration type naming) automatically passes the content of the HTTP request into your AWS Lambda function (headers, body, etc.) and allows you to configure your response (headers, status code, body) in the code of your AWS Lambda Function. Whereas, the `lambda` method makes you explicitly define headers, status codes, and more in the configuration of each API Gateway Endpoint (not in code). We highly recommend using the `lambda-proxy` method if it supports your use-case, since the `lambda` method is highly tedious.
|
||||
The difference between these is `lambda-proxy` (alternative writing styles are `aws-proxy` and `aws_proxy` for compatibility with the standard AWS integration type naming) automatically passes the content of the HTTP request into your AWS Lambda function (headers, body, etc.) and allows you to configure your response (headers, status code, body) in the code of your AWS Lambda Function. Whereas, the `lambda` method makes you explicitly define headers, status codes, and more in the configuration of each API Gateway Endpoint (not in code). We highly recommend using the `lambda-proxy` method if it supports your use-case, since the `lambda` method is highly tedious.
|
||||
|
||||
Use `http` for integrating with an HTTP back end, `http-proxy` for integrating with the HTTP proxy integration or `mock` for testing without actually invoking the back end.
|
||||
|
||||
@ -99,22 +102,22 @@ functions:
|
||||
'use strict';
|
||||
|
||||
module.exports.hello = function(event, context, callback) {
|
||||
console.log(event); // Contains incoming request data (e.g., query params, headers and more)
|
||||
|
||||
console.log(event); // Contains incoming request data (e.g., query params, headers and more)
|
||||
const response = {
|
||||
statusCode: 200,
|
||||
headers: {
|
||||
'x-custom-header': 'My Header Value',
|
||||
},
|
||||
body: JSON.stringify({ message: 'Hello World!' }),
|
||||
};
|
||||
|
||||
const response = {
|
||||
statusCode: 200,
|
||||
headers: {
|
||||
"x-custom-header" : "My Header Value"
|
||||
},
|
||||
body: JSON.stringify({ "message": "Hello World!" })
|
||||
};
|
||||
|
||||
callback(null, response);
|
||||
callback(null, response);
|
||||
};
|
||||
```
|
||||
|
||||
**Note:** When the body is a JSON-Document, you must parse it yourself:
|
||||
|
||||
```
|
||||
JSON.parse(event.body);
|
||||
```
|
||||
@ -123,62 +126,62 @@ JSON.parse(event.body);
|
||||
|
||||
```json
|
||||
{
|
||||
"resource": "/",
|
||||
"path": "/",
|
||||
"resource": "/",
|
||||
"path": "/",
|
||||
"httpMethod": "POST",
|
||||
"headers": {
|
||||
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
|
||||
"Accept-Encoding": "gzip, deflate, br",
|
||||
"Accept-Language": "en-GB,en-US;q=0.8,en;q=0.6,zh-CN;q=0.4",
|
||||
"cache-control": "max-age=0",
|
||||
"CloudFront-Forwarded-Proto": "https",
|
||||
"CloudFront-Is-Desktop-Viewer": "true",
|
||||
"CloudFront-Is-Mobile-Viewer": "false",
|
||||
"CloudFront-Is-SmartTV-Viewer": "false",
|
||||
"CloudFront-Is-Tablet-Viewer": "false",
|
||||
"CloudFront-Viewer-Country": "GB",
|
||||
"content-type": "application/x-www-form-urlencoded",
|
||||
"Host": "j3ap25j034.execute-api.eu-west-2.amazonaws.com",
|
||||
"origin": "https://j3ap25j034.execute-api.eu-west-2.amazonaws.com",
|
||||
"Referer": "https://j3ap25j034.execute-api.eu-west-2.amazonaws.com/dev/",
|
||||
"upgrade-insecure-requests": "1",
|
||||
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
|
||||
"Via": "2.0 a3650115c5e21e2b5d133ce84464bea3.cloudfront.net (CloudFront)",
|
||||
"X-Amz-Cf-Id": "0nDeiXnReyHYCkv8cc150MWCFCLFPbJoTs1mexDuKe2WJwK5ANgv2A==",
|
||||
"X-Amzn-Trace-Id": "Root=1-597079de-75fec8453f6fd4812414a4cd",
|
||||
"X-Forwarded-For": "50.129.117.14, 50.112.234.94",
|
||||
"X-Forwarded-Port": "443",
|
||||
"X-Forwarded-Proto": "https"
|
||||
},
|
||||
"queryStringParameters": null,
|
||||
"pathParameters": null,
|
||||
"stageVariables": null,
|
||||
"requestContext": {
|
||||
"path": "/dev/",
|
||||
"accountId": "125002137610",
|
||||
"resourceId": "qdolsr1yhk",
|
||||
"stage": "dev",
|
||||
"requestId": "0f2431a2-6d2f-11e7-b799-5152aa497861",
|
||||
"identity": {
|
||||
"cognitoIdentityPoolId": null,
|
||||
"accountId": null,
|
||||
"cognitoIdentityId": null,
|
||||
"caller": null,
|
||||
"apiKey": "",
|
||||
"sourceIp": "50.129.117.14",
|
||||
"accessKey": null,
|
||||
"cognitoAuthenticationType": null,
|
||||
"cognitoAuthenticationProvider": null,
|
||||
"userArn": null,
|
||||
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
|
||||
"user": null
|
||||
},
|
||||
"resourcePath": "/",
|
||||
"httpMethod": "POST",
|
||||
"headers": {
|
||||
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
|
||||
"Accept-Encoding": "gzip, deflate, br",
|
||||
"Accept-Language": "en-GB,en-US;q=0.8,en;q=0.6,zh-CN;q=0.4",
|
||||
"cache-control": "max-age=0",
|
||||
"CloudFront-Forwarded-Proto": "https",
|
||||
"CloudFront-Is-Desktop-Viewer": "true",
|
||||
"CloudFront-Is-Mobile-Viewer": "false",
|
||||
"CloudFront-Is-SmartTV-Viewer": "false",
|
||||
"CloudFront-Is-Tablet-Viewer": "false",
|
||||
"CloudFront-Viewer-Country": "GB",
|
||||
"content-type": "application/x-www-form-urlencoded",
|
||||
"Host": "j3ap25j034.execute-api.eu-west-2.amazonaws.com",
|
||||
"origin": "https://j3ap25j034.execute-api.eu-west-2.amazonaws.com",
|
||||
"Referer": "https://j3ap25j034.execute-api.eu-west-2.amazonaws.com/dev/",
|
||||
"upgrade-insecure-requests": "1",
|
||||
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
|
||||
"Via": "2.0 a3650115c5e21e2b5d133ce84464bea3.cloudfront.net (CloudFront)",
|
||||
"X-Amz-Cf-Id": "0nDeiXnReyHYCkv8cc150MWCFCLFPbJoTs1mexDuKe2WJwK5ANgv2A==",
|
||||
"X-Amzn-Trace-Id": "Root=1-597079de-75fec8453f6fd4812414a4cd",
|
||||
"X-Forwarded-For": "50.129.117.14, 50.112.234.94",
|
||||
"X-Forwarded-Port": "443",
|
||||
"X-Forwarded-Proto": "https"
|
||||
},
|
||||
"queryStringParameters": null,
|
||||
"pathParameters": null,
|
||||
"stageVariables": null,
|
||||
"requestContext": {
|
||||
"path": "/dev/",
|
||||
"accountId": "125002137610",
|
||||
"resourceId": "qdolsr1yhk",
|
||||
"stage": "dev",
|
||||
"requestId": "0f2431a2-6d2f-11e7-b799-5152aa497861",
|
||||
"identity": {
|
||||
"cognitoIdentityPoolId": null,
|
||||
"accountId": null,
|
||||
"cognitoIdentityId": null,
|
||||
"caller": null,
|
||||
"apiKey": "",
|
||||
"sourceIp": "50.129.117.14",
|
||||
"accessKey": null,
|
||||
"cognitoAuthenticationType": null,
|
||||
"cognitoAuthenticationProvider": null,
|
||||
"userArn": null,
|
||||
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
|
||||
"user": null
|
||||
},
|
||||
"resourcePath": "/",
|
||||
"httpMethod": "POST",
|
||||
"apiId": "j3azlsj0c4"
|
||||
},
|
||||
"body": "postcode=LS17FR",
|
||||
"isBase64Encoded": false
|
||||
"apiId": "j3azlsj0c4"
|
||||
},
|
||||
"body": "postcode=LS17FR",
|
||||
"isBase64Encoded": false
|
||||
}
|
||||
```
|
||||
|
||||
@ -199,6 +202,7 @@ functions:
|
||||
```
|
||||
|
||||
### Enabling CORS
|
||||
|
||||
To set CORS configurations for your HTTP endpoints, simply modify your event configurations as follows:
|
||||
|
||||
```yml
|
||||
@ -263,10 +267,10 @@ functions:
|
||||
Wildcards are accepted. The following example will match all sub-domains of example.com over http:
|
||||
|
||||
```yml
|
||||
cors:
|
||||
origins:
|
||||
- http://*.example.com
|
||||
- http://example2.com
|
||||
cors:
|
||||
origins:
|
||||
- http://*.example.com
|
||||
- http://example2.com
|
||||
```
|
||||
|
||||
Please note that since you can't send multiple values for [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin), this configuration uses a response template to check if the request origin matches one of your provided `origins` and overrides the header with the following code:
|
||||
@ -276,7 +280,7 @@ Please note that since you can't send multiple values for [Access-Control-Allow-
|
||||
#if($origin == "http://example.com" || $origin == "http://*.amazonaws.com") #set($context.responseOverride.header.Access-Control-Allow-Origin = $origin) #end
|
||||
```
|
||||
|
||||
Configuring the `cors` property sets [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin), [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers), [Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods),[Access-Control-Allow-Credentials](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials) headers in the CORS preflight response.
|
||||
Configuring the `cors` property sets [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin), [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers), [Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods),[Access-Control-Allow-Credentials](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials) headers in the CORS preflight response.
|
||||
|
||||
To enable the `Access-Control-Max-Age` preflight response header, set the `maxAge` property in the `cors` object:
|
||||
|
||||
@ -326,17 +330,16 @@ If you want to use CORS with the lambda-proxy integration, remember to include t
|
||||
'use strict';
|
||||
|
||||
module.exports.hello = function(event, context, callback) {
|
||||
const response = {
|
||||
statusCode: 200,
|
||||
headers: {
|
||||
'Access-Control-Allow-Origin': '*', // Required for CORS support to work
|
||||
'Access-Control-Allow-Credentials': true, // Required for cookies, authorization headers with HTTPS
|
||||
},
|
||||
body: JSON.stringify({ message: 'Hello World!' }),
|
||||
};
|
||||
|
||||
const response = {
|
||||
statusCode: 200,
|
||||
headers: {
|
||||
"Access-Control-Allow-Origin" : "*", // Required for CORS support to work
|
||||
"Access-Control-Allow-Credentials" : true // Required for cookies, authorization headers with HTTPS
|
||||
},
|
||||
body: JSON.stringify({ "message": "Hello World!" })
|
||||
};
|
||||
|
||||
callback(null, response);
|
||||
callback(null, response);
|
||||
};
|
||||
```
|
||||
|
||||
@ -371,7 +374,7 @@ functions:
|
||||
|
||||
### HTTP Endpoints with Custom Authorizers
|
||||
|
||||
Custom Authorizers allow you to run an AWS Lambda Function before your targeted AWS Lambda Function. This is useful for Microservice Architectures or when you simply want to do some Authorization before running your business logic.
|
||||
Custom Authorizers allow you to run an AWS Lambda Function before your targeted AWS Lambda Function. This is useful for Microservice Architectures or when you simply want to do some Authorization before running your business logic.
|
||||
|
||||
You can enable Custom Authorizers for your HTTP endpoint by setting the Authorizer in your `http` event to another function
|
||||
in the same service, as shown in the following example:
|
||||
@ -388,6 +391,7 @@ functions:
|
||||
authorizerFunc:
|
||||
handler: handler.authorizerFunc
|
||||
```
|
||||
|
||||
Or, if you want to configure the Authorizer with more options, you can turn the `authorizer` property into an object as
|
||||
shown in the following example:
|
||||
|
||||
@ -499,9 +503,9 @@ functions:
|
||||
- nickname
|
||||
```
|
||||
|
||||
### Using asyncronous integration
|
||||
### Using asynchronous integration
|
||||
|
||||
Use `async: true` when integrating a lambda function using [event invocation](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#SSS-Invoke-request-InvocationType). This lets API Gateway to return immediately with a 200 status code while the lambda continues running. If not othewise speficied integration type will be `AWS`.
|
||||
Use `async: true` when integrating a lambda function using [event invocation](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#SSS-Invoke-request-InvocationType). This lets API Gateway to return immediately with a 200 status code while the lambda continues running. If not otherwise specified integration type will be `AWS`.
|
||||
|
||||
```yml
|
||||
functions:
|
||||
@ -511,7 +515,7 @@ functions:
|
||||
- http:
|
||||
path: posts/create
|
||||
method: post
|
||||
async: true # default is false
|
||||
async: true # default is false
|
||||
```
|
||||
|
||||
### Catching Exceptions In Your Lambda Function
|
||||
@ -574,11 +578,11 @@ provider:
|
||||
name: aws
|
||||
apiKeys:
|
||||
- free:
|
||||
- myFreeKey
|
||||
- ${opt:stage}-myFreeKey
|
||||
- myFreeKey
|
||||
- ${opt:stage}-myFreeKey
|
||||
- paid:
|
||||
- myPaidKey
|
||||
- ${opt:stage}-myPaidKey
|
||||
- myPaidKey
|
||||
- ${opt:stage}-myPaidKey
|
||||
usagePlan:
|
||||
- free:
|
||||
quota:
|
||||
@ -691,9 +695,7 @@ A sample schema contained in `create_request.json` might look something like thi
|
||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||
"type": "object",
|
||||
"title": "The Root Schema",
|
||||
"required": [
|
||||
"username"
|
||||
],
|
||||
"required": ["username"],
|
||||
"properties": {
|
||||
"username": {
|
||||
"type": "string",
|
||||
@ -752,51 +754,51 @@ This method is more complicated and involves a lot more configuration of the `ht
|
||||
|
||||
```json
|
||||
{
|
||||
"body": {},
|
||||
"method": "GET",
|
||||
"principalId": "",
|
||||
"stage": "dev",
|
||||
"cognitoPoolClaims": {
|
||||
"sub": ""
|
||||
},
|
||||
"enhancedAuthContext": {},
|
||||
"headers": {
|
||||
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
|
||||
"Accept-Encoding": "gzip, deflate, br",
|
||||
"Accept-Language": "en-GB,en-US;q=0.8,en;q=0.6,zh-CN;q=0.4",
|
||||
"CloudFront-Forwarded-Proto": "https",
|
||||
"CloudFront-Is-Desktop-Viewer": "true",
|
||||
"CloudFront-Is-Mobile-Viewer": "false",
|
||||
"CloudFront-Is-SmartTV-Viewer": "false",
|
||||
"CloudFront-Is-Tablet-Viewer": "false",
|
||||
"CloudFront-Viewer-Country": "GB",
|
||||
"Host": "ec5ycylws8.execute-api.us-east-1.amazonaws.com",
|
||||
"upgrade-insecure-requests": "1",
|
||||
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
|
||||
"Via": "2.0 f165ce34daf8c0da182681179e863c24.cloudfront.net (CloudFront)",
|
||||
"X-Amz-Cf-Id": "l06CAg2QsrALeQcLAUSxGXbm8lgMoMIhR2AjKa4AiKuaVnnGsOFy5g==",
|
||||
"X-Amzn-Trace-Id": "Root=1-5970ef20-3e249c0321b2eef14aa513ae",
|
||||
"X-Forwarded-For": "94.117.120.169, 116.132.62.73",
|
||||
"X-Forwarded-Port": "443",
|
||||
"X-Forwarded-Proto": "https"
|
||||
},
|
||||
"query": {},
|
||||
"path": {},
|
||||
"identity": {
|
||||
"cognitoIdentityPoolId": "",
|
||||
"accountId": "",
|
||||
"cognitoIdentityId": "",
|
||||
"caller": "",
|
||||
"apiKey": "",
|
||||
"sourceIp": "94.197.120.169",
|
||||
"accessKey": "",
|
||||
"cognitoAuthenticationType": "",
|
||||
"cognitoAuthenticationProvider": "",
|
||||
"userArn": "",
|
||||
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
|
||||
"user": ""
|
||||
},
|
||||
"stageVariables": {}
|
||||
"body": {},
|
||||
"method": "GET",
|
||||
"principalId": "",
|
||||
"stage": "dev",
|
||||
"cognitoPoolClaims": {
|
||||
"sub": ""
|
||||
},
|
||||
"enhancedAuthContext": {},
|
||||
"headers": {
|
||||
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
|
||||
"Accept-Encoding": "gzip, deflate, br",
|
||||
"Accept-Language": "en-GB,en-US;q=0.8,en;q=0.6,zh-CN;q=0.4",
|
||||
"CloudFront-Forwarded-Proto": "https",
|
||||
"CloudFront-Is-Desktop-Viewer": "true",
|
||||
"CloudFront-Is-Mobile-Viewer": "false",
|
||||
"CloudFront-Is-SmartTV-Viewer": "false",
|
||||
"CloudFront-Is-Tablet-Viewer": "false",
|
||||
"CloudFront-Viewer-Country": "GB",
|
||||
"Host": "ec5ycylws8.execute-api.us-east-1.amazonaws.com",
|
||||
"upgrade-insecure-requests": "1",
|
||||
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
|
||||
"Via": "2.0 f165ce34daf8c0da182681179e863c24.cloudfront.net (CloudFront)",
|
||||
"X-Amz-Cf-Id": "l06CAg2QsrALeQcLAUSxGXbm8lgMoMIhR2AjKa4AiKuaVnnGsOFy5g==",
|
||||
"X-Amzn-Trace-Id": "Root=1-5970ef20-3e249c0321b2eef14aa513ae",
|
||||
"X-Forwarded-For": "94.117.120.169, 116.132.62.73",
|
||||
"X-Forwarded-Port": "443",
|
||||
"X-Forwarded-Proto": "https"
|
||||
},
|
||||
"query": {},
|
||||
"path": {},
|
||||
"identity": {
|
||||
"cognitoIdentityPoolId": "",
|
||||
"accountId": "",
|
||||
"cognitoIdentityId": "",
|
||||
"caller": "",
|
||||
"apiKey": "",
|
||||
"sourceIp": "94.197.120.169",
|
||||
"accessKey": "",
|
||||
"cognitoAuthenticationType": "",
|
||||
"cognitoAuthenticationProvider": "",
|
||||
"userArn": "",
|
||||
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
|
||||
"user": ""
|
||||
},
|
||||
"stageVariables": {}
|
||||
}
|
||||
```
|
||||
|
||||
@ -866,9 +868,10 @@ You can then access the query string `https://example.com/dev/whatever?bar=123`
|
||||
If you want to spread a string into multiple lines, you can use the `>` or `|` syntax, but the following strings have to be all indented with the same amount, [read more about `>` syntax](http://stackoverflow.com/questions/3790454/in-yaml-how-do-i-break-a-string-over-multiple-lines).
|
||||
|
||||
#### Pass Through Behavior
|
||||
API Gateway provides multiple ways to handle requests where the Content-Type header does not match any of the specified mapping templates. When this happens, the request payload will either be passed through the integration request *without transformation* or rejected with a `415 - Unsupported Media Type`, depending on the configuration.
|
||||
|
||||
You can define this behavior as follows (if not specified, a value of **NEVER** will be used):
|
||||
API Gateway provides multiple ways to handle requests where the Content-Type header does not match any of the specified mapping templates. When this happens, the request payload will either be passed through the integration request _without transformation_ or rejected with a `415 - Unsupported Media Type`, depending on the configuration.
|
||||
|
||||
You can define this behaviour as follows (if not specified, a value of **NEVER** will be used):
|
||||
|
||||
```yml
|
||||
functions:
|
||||
@ -885,11 +888,11 @@ functions:
|
||||
|
||||
There are 3 available options:
|
||||
|
||||
|Value | Passed Through When | Rejected When |
|
||||
|----------------- | --------------------------------------------- | ----------------------------------------------------------------------- |
|
||||
|NEVER | Never | No templates defined or Content-Type does not match a defined template |
|
||||
|WHEN_NO_MATCH | Content-Type does not match defined template | Never |
|
||||
|WHEN_NO_TEMPLATES | No templates were defined | One or more templates defined, but Content-Type does not match |
|
||||
| Value | Passed Through When | Rejected When |
|
||||
| ----------------- | -------------------------------------------- | ---------------------------------------------------------------------- |
|
||||
| NEVER | Never | No templates defined or Content-Type does not match a defined template |
|
||||
| WHEN_NO_MATCH | Content-Type does not match defined template | Never |
|
||||
| WHEN_NO_TEMPLATES | No templates were defined | One or more templates defined, but Content-Type does not match |
|
||||
|
||||
See the [api gateway documentation](https://docs.aws.amazon.com/apigateway/latest/developerguide/integration-passthrough-behaviors.html) for detailed descriptions of these options.
|
||||
|
||||
@ -953,26 +956,26 @@ the `${file(templatefile)}` syntax.
|
||||
Serverless ships with default status codes you can use to e.g. signal that a resource could not be found (404) or that
|
||||
the user is not authorized to perform the action (401). Those status codes are regex definitions that will be added to your API Gateway configuration.
|
||||
|
||||
***Note:*** Status codes as documented in this chapter relate to `lambda` integration method (as documented at the top of this page). If using default integration method `lambda-proxy` object with status code and message should be returned as in the example below:
|
||||
**_Note:_** Status codes as documented in this chapter relate to `lambda` integration method (as documented at the top of this page). If using default integration method `lambda-proxy` object with status code and message should be returned as in the example below:
|
||||
|
||||
```javascript
|
||||
module.exports.hello = (event, context, callback) => {
|
||||
callback(null, { statusCode: 404, body: "Not found", headers: { "Content-Type": "text/plain" } });
|
||||
}
|
||||
callback(null, { statusCode: 404, body: 'Not found', headers: { 'Content-Type': 'text/plain' } });
|
||||
};
|
||||
```
|
||||
|
||||
#### Available Status Codes
|
||||
|
||||
| Status Code | Meaning |
|
||||
| --- | --- |
|
||||
| 400 | Bad Request |
|
||||
| 401 | Unauthorized |
|
||||
| 403 | Forbidden |
|
||||
| 404 | Not Found |
|
||||
| 422 | Unprocessable Entity |
|
||||
| 500 | Internal Server Error |
|
||||
| 502 | Bad Gateway |
|
||||
| 504 | Gateway Timeout |
|
||||
| Status Code | Meaning |
|
||||
| ----------- | --------------------- |
|
||||
| 400 | Bad Request |
|
||||
| 401 | Unauthorized |
|
||||
| 403 | Forbidden |
|
||||
| 404 | Not Found |
|
||||
| 422 | Unprocessable Entity |
|
||||
| 500 | Internal Server Error |
|
||||
| 502 | Bad Gateway |
|
||||
| 504 | Gateway Timeout |
|
||||
|
||||
#### Using Status Codes
|
||||
|
||||
@ -984,7 +987,7 @@ Here's an example which shows you how you can raise a 404 HTTP status from withi
|
||||
```javascript
|
||||
module.exports.hello = (event, context, callback) => {
|
||||
callback(new Error('[404] Not found'));
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
#### Custom Status Codes
|
||||
@ -1009,13 +1012,13 @@ functions:
|
||||
Content-Type: "'text/html'"
|
||||
template: $input.path('$')
|
||||
statusCodes:
|
||||
201:
|
||||
pattern: '' # Default response method
|
||||
409:
|
||||
pattern: '.*"statusCode":409,.*' # JSON response
|
||||
template: $input.path("$.errorMessage") # JSON return object
|
||||
headers:
|
||||
Content-Type: "'application/json+hal'"
|
||||
201:
|
||||
pattern: '' # Default response method
|
||||
409:
|
||||
pattern: '.*"statusCode":409,.*' # JSON response
|
||||
template: $input.path("$.errorMessage") # JSON return object
|
||||
headers:
|
||||
Content-Type: "'application/json+hal'"
|
||||
```
|
||||
|
||||
You can also create varying response templates for each code and content type by creating an object with the key as the content type
|
||||
@ -1034,15 +1037,15 @@ functions:
|
||||
Content-Type: "'text/html'"
|
||||
template: $input.path('$')
|
||||
statusCodes:
|
||||
201:
|
||||
pattern: '' # Default response method
|
||||
409:
|
||||
pattern: '.*"statusCode":409,.*' # JSON response
|
||||
template:
|
||||
application/json: $input.path("$.errorMessage") # JSON return object
|
||||
application/xml: $input.path("$.body.errorMessage") # XML return object
|
||||
headers:
|
||||
Content-Type: "'application/json+hal'"
|
||||
201:
|
||||
pattern: '' # Default response method
|
||||
409:
|
||||
pattern: '.*"statusCode":409,.*' # JSON response
|
||||
template:
|
||||
application/json: $input.path("$.errorMessage") # JSON return object
|
||||
application/xml: $input.path("$.body.errorMessage") # XML return object
|
||||
headers:
|
||||
Content-Type: "'application/json+hal'"
|
||||
```
|
||||
|
||||
## Setting an HTTP Proxy on API Gateway
|
||||
@ -1053,8 +1056,7 @@ one for method. These two templates will work together to construct your proxy.
|
||||
```yml
|
||||
service: service-name
|
||||
provider: aws
|
||||
functions:
|
||||
...
|
||||
functions: ...
|
||||
|
||||
resources:
|
||||
Resources:
|
||||
@ -1103,14 +1105,12 @@ provider:
|
||||
apiGateway:
|
||||
restApiId: xxxxxxxxxx # REST API resource ID. Default is generated by the framework
|
||||
restApiRootResourceId: xxxxxxxxxx # Root resource, represent as / path
|
||||
websocketApiId: xxxxxxxxxx # Websocket API resource ID. Default is generated by the framewok
|
||||
description: Some Description # optional - description of deployment history
|
||||
|
||||
functions:
|
||||
...
|
||||
|
||||
functions: ...
|
||||
```
|
||||
|
||||
|
||||
If your application has many nested paths, you might also want to break them out into smaller services.
|
||||
|
||||
```yml
|
||||
@ -1119,6 +1119,7 @@ provider:
|
||||
apiGateway:
|
||||
restApiId: xxxxxxxxxx
|
||||
restApiRootResourceId: xxxxxxxxxx
|
||||
websocketApiId: xxxxxxxxxx
|
||||
description: Some Description
|
||||
|
||||
functions:
|
||||
@ -1136,6 +1137,7 @@ provider:
|
||||
apiGateway:
|
||||
restApiId: xxxxxxxxxx
|
||||
restApiRootResourceId: xxxxxxxxxx
|
||||
websocketApiId: xxxxxxxxxx
|
||||
description: Some Description
|
||||
|
||||
functions:
|
||||
@ -1155,13 +1157,12 @@ provider:
|
||||
apiGateway:
|
||||
restApiId: xxxxxxxxxx
|
||||
restApiRootResourceId: xxxxxxxxxx
|
||||
websocketApiId: xxxxxxxxxx
|
||||
description: Some Description
|
||||
restApiResources:
|
||||
/posts: xxxxxxxxxx
|
||||
|
||||
functions:
|
||||
...
|
||||
posts: xxxxxxxxxx
|
||||
|
||||
functions: ...
|
||||
```
|
||||
|
||||
```yml
|
||||
@ -1170,13 +1171,12 @@ provider:
|
||||
apiGateway:
|
||||
restApiId: xxxxxxxxxx
|
||||
restApiRootResourceId: xxxxxxxxxx
|
||||
websocketApiId: xxxxxxxxxx
|
||||
description: Some Description
|
||||
restApiResources:
|
||||
/posts: xxxxxxxxxx
|
||||
|
||||
functions:
|
||||
...
|
||||
|
||||
functions: ...
|
||||
```
|
||||
|
||||
You can define more than one path resource, but by default, Serverless will generate them from the root resource.
|
||||
@ -1188,12 +1188,12 @@ provider:
|
||||
apiGateway:
|
||||
restApiId: xxxxxxxxxx
|
||||
# restApiRootResourceId: xxxxxxxxxx # Optional
|
||||
websocketApiId: xxxxxxxxxx
|
||||
description: Some Description
|
||||
restApiResources:
|
||||
/posts: xxxxxxxxxx
|
||||
/categories: xxxxxxxxx
|
||||
|
||||
|
||||
functions:
|
||||
listPosts:
|
||||
handler: posts.list
|
||||
@ -1208,19 +1208,18 @@ functions:
|
||||
- http:
|
||||
method: get
|
||||
path: /categories
|
||||
|
||||
```
|
||||
|
||||
### Easiest and CI/CD friendly example of using shared API Gateway and API Resources.
|
||||
|
||||
You can define your API Gateway resource in its own service and export the `restApiId` and `restApiRootResourceId` using cloudformation cross-stack references.
|
||||
You can define your API Gateway resource in its own service and export the `restApiId`, `restApiRootResourceId` and `websocketApiId` using cloudformation cross-stack references.
|
||||
|
||||
```yml
|
||||
service: my-api
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs8.10
|
||||
runtime: nodejs10.x
|
||||
stage: dev
|
||||
region: eu-west-2
|
||||
|
||||
@ -1231,6 +1230,13 @@ resources:
|
||||
Properties:
|
||||
Name: MyApiGW
|
||||
|
||||
MyWebsocketApi:
|
||||
Type: AWS::ApiGatewayV2::Api
|
||||
Properties:
|
||||
Name: MyWebsocketApi
|
||||
ProtocolType: WEBSOCKET
|
||||
RouteSelectionExpression: '$request.body.action'
|
||||
|
||||
Outputs:
|
||||
apiGatewayRestApiId:
|
||||
Value:
|
||||
@ -1245,9 +1251,15 @@ resources:
|
||||
- RootResourceId
|
||||
Export:
|
||||
Name: MyApiGateway-rootResourceId
|
||||
|
||||
websocketApiId:
|
||||
Value:
|
||||
Ref: MyWebsocketApi
|
||||
Export:
|
||||
Name: MyApiGateway-websocketApiId
|
||||
```
|
||||
|
||||
This creates API gateway and then exports the `restApiId` and `rootResourceId` values using cloudformation cross stack output.
|
||||
This creates API gateway and then exports the `restApiId`, `rootResourceId` and `websocketApiId` values using cloudformation cross stack output.
|
||||
We will import this and reference in future services.
|
||||
|
||||
```yml
|
||||
@ -1259,10 +1271,12 @@ provider:
|
||||
'Fn::ImportValue': MyApiGateway-restApiId
|
||||
restApiRootResourceId:
|
||||
'Fn::ImportValue': MyApiGateway-rootResourceId
|
||||
websocketApiId:
|
||||
'Fn::ImportValue': MyApiGateway-websocketApiId
|
||||
|
||||
functions:
|
||||
service-a-functions
|
||||
functions: service-a-functions
|
||||
```
|
||||
|
||||
```yml
|
||||
service: service-b
|
||||
|
||||
@ -1272,13 +1286,15 @@ provider:
|
||||
'Fn::ImportValue': MyApiGateway-restApiId
|
||||
restApiRootResourceId:
|
||||
'Fn::ImportValue': MyApiGateway-rootResourceId
|
||||
websocketApiId:
|
||||
'Fn::ImportValue': MyApiGateway-websocketApiId
|
||||
|
||||
functions:
|
||||
service-b-functions
|
||||
functions: service-b-functions
|
||||
```
|
||||
|
||||
You can use this method to share your API Gateway across services in same region. Read about this limitation [here](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-importvalue.html).
|
||||
|
||||
**Note:** We've noticed you can't use provider.tags together with `Fn::ImportValue` for `restApiId` and `restApiRootResourceId`. Doing so won't resolve the imported value, and therefore returns an error.
|
||||
|
||||
### Manually Configuring shared API Gateway
|
||||
|
||||
@ -1314,7 +1330,6 @@ functions:
|
||||
arn: xxxxxxxxxxxxxxxxx #cognito/custom authorizer arn
|
||||
```
|
||||
|
||||
|
||||
```yml
|
||||
service: service-d
|
||||
|
||||
@ -1355,6 +1370,8 @@ functions:
|
||||
type: COGNITO_USER_POOLS # TOKEN or REQUEST or COGNITO_USER_POOLS, same as AWS Cloudformation documentation
|
||||
authorizerId:
|
||||
Ref: ApiGatewayAuthorizer # or hard-code Authorizer ID
|
||||
scopes: # Optional - List of Oauth2 scopes when type is COGNITO_USER_POOLS
|
||||
- myapp/myscope
|
||||
|
||||
deleteUser:
|
||||
...
|
||||
@ -1390,19 +1407,18 @@ Resource policies are policy documents that are used to control the invocation o
|
||||
```yml
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
|
||||
resourcePolicy:
|
||||
- Effect: Allow
|
||||
Principal: "*"
|
||||
Principal: '*'
|
||||
Action: execute-api:Invoke
|
||||
Resource:
|
||||
- execute-api:/*/*/*
|
||||
Condition:
|
||||
IpAddress:
|
||||
aws:SourceIp:
|
||||
- "123.123.123.123"
|
||||
|
||||
- '123.123.123.123'
|
||||
```
|
||||
|
||||
## Compression
|
||||
@ -1472,3 +1488,20 @@ provider:
|
||||
```
|
||||
|
||||
The log streams will be generated in a dedicated log group which follows the naming schema `/aws/api-gateway/{service}-{stage}`.
|
||||
|
||||
By default, API Gateway access logs will use the following format:
|
||||
|
||||
```
|
||||
'requestId: $context.requestId, ip: $context.identity.sourceIp, caller: $context.identity.caller, user: $context.identity.user, requestTime: $context.requestTime, httpMethod: $context.httpMethod, resourcePath: $context.resourcePath, status: $context.status, protocol: $context.protocol, responseLength: $context.responseLength'
|
||||
```
|
||||
|
||||
You can specify your own [format for API Gateway Access Logs](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html#apigateway-cloudwatch-log-formats) by including your preferred string in the `format` property:
|
||||
|
||||
```yml
|
||||
# serverless.yml
|
||||
provider:
|
||||
name: aws
|
||||
logs:
|
||||
restApi:
|
||||
format: '{ "requestId":"$context.requestId", "ip": "$context.identity.sourceIp" }'
|
||||
```
|
||||
|
||||
@ -1,13 +1,15 @@
|
||||
<!--
|
||||
title: Serverless Framework - AWS Lambda Events - CloudWatch Event
|
||||
menuText: CloudWatch Event
|
||||
menuOrder: 10
|
||||
menuOrder: 12
|
||||
description: Setting up AWS CloudWatch Events with AWS Lambda via the Serverless Framework
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/cloudwatch-event)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# CloudWatch Event
|
||||
@ -25,9 +27,9 @@ functions:
|
||||
- cloudwatchEvent:
|
||||
event:
|
||||
source:
|
||||
- "aws.ec2"
|
||||
- 'aws.ec2'
|
||||
detail-type:
|
||||
- "EC2 Instance State-change Notification"
|
||||
- 'EC2 Instance State-change Notification'
|
||||
detail:
|
||||
state:
|
||||
- pending
|
||||
@ -47,9 +49,9 @@ functions:
|
||||
- cloudwatchEvent:
|
||||
event:
|
||||
source:
|
||||
- "aws.ec2"
|
||||
- 'aws.ec2'
|
||||
detail-type:
|
||||
- "EC2 Instance State-change Notification"
|
||||
- 'EC2 Instance State-change Notification'
|
||||
detail:
|
||||
state:
|
||||
- pending
|
||||
@ -68,9 +70,9 @@ functions:
|
||||
- cloudwatchEvent:
|
||||
event:
|
||||
source:
|
||||
- "aws.ec2"
|
||||
- 'aws.ec2'
|
||||
detail-type:
|
||||
- "EC2 Instance State-change Notification"
|
||||
- 'EC2 Instance State-change Notification'
|
||||
detail:
|
||||
state:
|
||||
- pending
|
||||
@ -82,9 +84,9 @@ functions:
|
||||
- cloudwatchEvent:
|
||||
event:
|
||||
source:
|
||||
- "aws.ec2"
|
||||
- 'aws.ec2'
|
||||
detail-type:
|
||||
- "EC2 Instance State-change Notification"
|
||||
- 'EC2 Instance State-change Notification'
|
||||
detail:
|
||||
state:
|
||||
- pending
|
||||
@ -92,9 +94,9 @@ functions:
|
||||
- cloudwatchEvent:
|
||||
event:
|
||||
source:
|
||||
- "aws.ec2"
|
||||
- 'aws.ec2'
|
||||
detail-type:
|
||||
- "EC2 Instance State-change Notification"
|
||||
- 'EC2 Instance State-change Notification'
|
||||
detail:
|
||||
state:
|
||||
- pending
|
||||
@ -117,9 +119,9 @@ functions:
|
||||
description: 'CloudWatch Event triggered on EC2 Instance pending state'
|
||||
event:
|
||||
source:
|
||||
- "aws.ec2"
|
||||
- 'aws.ec2'
|
||||
detail-type:
|
||||
- "EC2 Instance State-change Notification"
|
||||
- 'EC2 Instance State-change Notification'
|
||||
detail:
|
||||
state:
|
||||
- pending
|
||||
@ -138,9 +140,9 @@ functions:
|
||||
name: 'my-cloudwatch-event-name'
|
||||
event:
|
||||
source:
|
||||
- "aws.ec2"
|
||||
- 'aws.ec2'
|
||||
detail-type:
|
||||
- "EC2 Instance State-change Notification"
|
||||
- 'EC2 Instance State-change Notification'
|
||||
detail:
|
||||
state:
|
||||
- pending
|
||||
|
||||
@ -1,13 +1,15 @@
|
||||
<!--
|
||||
title: Serverless Framework - AWS Lambda Events - CloudWatch Log
|
||||
menuText: CloudWatch Log
|
||||
menuOrder: 11
|
||||
menuOrder: 13
|
||||
description: Setting up AWS CloudWatch Logs with AWS Lambda via the Serverless Framework
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/cloudwatch-log)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# CloudWatch Log
|
||||
|
||||
@ -1,13 +1,15 @@
|
||||
<!--
|
||||
title: Serverless Framework - AWS Lambda Events - Cognito User Pool
|
||||
menuText: Cognito User Pool
|
||||
menuOrder: 12
|
||||
menuOrder: 14
|
||||
description: Setting up AWS Cognito User Pool Triggers with AWS Lambda via the Serverless Framework
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/cognito-user-pool)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Cognito User Pool
|
||||
@ -114,5 +116,4 @@ resources:
|
||||
```
|
||||
|
||||
[aws-triggers-guide]: http://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools-working-with-aws-lambda-triggers.html
|
||||
[aws-triggers-list]:
|
||||
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cognito-userpool-lambdaconfig.html
|
||||
[aws-triggers-list]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cognito-userpool-lambdaconfig.html
|
||||
|
||||
@ -1,13 +1,15 @@
|
||||
<!--
|
||||
title: Serverless Framework - AWS Lambda Events - IoT
|
||||
menuText: IoT
|
||||
menuOrder: 9
|
||||
menuOrder: 11
|
||||
description: Setting up AWS IoT Events with AWS Lambda via the Serverless Framework
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/iot)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# IoT
|
||||
@ -51,9 +53,9 @@ functions:
|
||||
handler: myIoT.handler
|
||||
events:
|
||||
- iot:
|
||||
name: "myIotEvent"
|
||||
name: 'myIotEvent'
|
||||
sql: "SELECT * FROM 'some_topic'"
|
||||
description: "My IoT Event Description"
|
||||
description: 'My IoT Event Description'
|
||||
```
|
||||
|
||||
## Specify SQL Versions
|
||||
@ -67,5 +69,5 @@ functions:
|
||||
events:
|
||||
- iot:
|
||||
sql: "SELECT * FROM 'some_topic'"
|
||||
sqlVersion: "beta"
|
||||
sqlVersion: 'beta'
|
||||
```
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/s3)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# S3
|
||||
@ -78,6 +80,7 @@ functions:
|
||||
|
||||
If you need to configure the bucket itself, you'll need to create the bucket and the Lambda Permission manually in
|
||||
the Resources section while paying attention to some of the logical IDs. This relies on the Serverless naming convention. See the [Serverless Resource Reference](../guide/resources/#aws-cloudformation-resource-reference) for details. These are the logical IDs that require your attention:
|
||||
|
||||
- The logical ID of the custom bucket in the Resources section needs to match the bucket name in the S3 event after the Serverless naming convention is applied to it.
|
||||
- The Lambda Permission's logical ID needs to match the Serverless naming convention for Lambda Permissions for S3 events.
|
||||
- The `FunctionName` in the Lambda Permission configuration needs to match the logical ID generated for the target Lambda function as determined by the Serverless naming convention.
|
||||
@ -99,15 +102,35 @@ resources:
|
||||
BucketName: my-custom-bucket-name
|
||||
# add additional custom bucket configuration here
|
||||
ResizeLambdaPermissionPhotosS3:
|
||||
Type: "AWS::Lambda::Permission"
|
||||
Type: 'AWS::Lambda::Permission'
|
||||
Properties:
|
||||
FunctionName:
|
||||
"Fn::GetAtt":
|
||||
'Fn::GetAtt':
|
||||
- ResizeLambdaFunction
|
||||
- Arn
|
||||
Principal: "s3.amazonaws.com"
|
||||
Action: "lambda:InvokeFunction"
|
||||
Principal: 's3.amazonaws.com'
|
||||
Action: 'lambda:InvokeFunction'
|
||||
SourceAccount:
|
||||
Ref: AWS::AccountId
|
||||
SourceArn: "arn:aws:s3:::my-custom-bucket-name"
|
||||
SourceArn: 'arn:aws:s3:::my-custom-bucket-name'
|
||||
```
|
||||
|
||||
## Using existing buckets
|
||||
|
||||
Sometimes you might want to attach Lambda functions to existing S3 buckets. In that case you just need to set the `existing` event configuration property to `true`. All the other config parameters can also be used on existing buckets:
|
||||
|
||||
**NOTE:** Using the `existing` config will add an additional Lambda function and IAM Role to your stack. The Lambda function backs-up the Custom S3 Resource which is used to support existing S3 buckets.
|
||||
|
||||
```yaml
|
||||
functions:
|
||||
users:
|
||||
handler: users.handler
|
||||
events:
|
||||
- s3:
|
||||
bucket: legacy-photos
|
||||
event: s3:ObjectCreated:*
|
||||
rules:
|
||||
- prefix: uploads/
|
||||
- suffix: .jpg
|
||||
existing: true
|
||||
```
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/schedule)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Schedule
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/sns)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# SNS
|
||||
@ -69,11 +71,11 @@ functions:
|
||||
- sns:
|
||||
arn:
|
||||
Fn::Join:
|
||||
- ":"
|
||||
- - "arn:aws:sns"
|
||||
- Ref: "AWS::Region"
|
||||
- Ref: "AWS::AccountId"
|
||||
- "MyCustomTopic"
|
||||
- ':'
|
||||
- - 'arn:aws:sns'
|
||||
- Ref: 'AWS::Region'
|
||||
- Ref: 'AWS::AccountId'
|
||||
- 'MyCustomTopic'
|
||||
topicName: MyCustomTopic
|
||||
```
|
||||
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/sqs)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# SQS Queues
|
||||
@ -37,7 +39,7 @@ functions:
|
||||
- sqs:
|
||||
arn:
|
||||
Fn::Join:
|
||||
- ":"
|
||||
- ':'
|
||||
- - arn
|
||||
- aws
|
||||
- sqs
|
||||
|
||||
@ -7,14 +7,17 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/streams)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# DynamoDB / Kinesis Streams
|
||||
|
||||
This setup specifies that the `compute` function should be triggered whenever:
|
||||
1. the corresponding DynamoDB table is modified (e.g. a new entry is added).
|
||||
2. the Lambda checkpoint has not reached the end of the Kinesis stream (e.g. a new record is added).
|
||||
|
||||
1. the corresponding DynamoDB table is modified (e.g. a new entry is added).
|
||||
2. the Lambda checkpoint has not reached the end of the Kinesis stream (e.g. a new record is added).
|
||||
|
||||
The ARN for the stream can be specified as a string, the reference to the ARN of a resource by logical ID, or the import of an ARN that was exported by a different service or CloudFormation stack.
|
||||
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/websocket)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Websocket
|
||||
@ -46,10 +48,11 @@ functions:
|
||||
## Routes
|
||||
|
||||
The API-Gateway provides [4 types of routes](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-overview.html) which relate to the lifecycle of a ws-client:
|
||||
* `$connect` called on connect of a ws-client
|
||||
* `$disconnect` called on disconnect of a ws-client (may not be called in some situations)
|
||||
* `$default` called if there is no handler to use for the event
|
||||
* custom routes - called if the route name is specified for a handler
|
||||
|
||||
- `$connect` called on connect of a ws-client
|
||||
- `$disconnect` called on disconnect of a ws-client (may not be called in some situations)
|
||||
- `$default` called if there is no handler to use for the event
|
||||
- custom routes - called if the route name is specified for a handler
|
||||
|
||||
### Example serverless.yaml
|
||||
|
||||
@ -60,7 +63,7 @@ service: serverless-ws-test
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs8.10
|
||||
runtime: nodejs10.x
|
||||
websocketsApiName: custom-websockets-api-name
|
||||
websocketsApiRouteSelectionExpression: $request.body.action # custom routes are selected by the value of the action property in the body
|
||||
|
||||
@ -84,6 +87,7 @@ functions:
|
||||
```
|
||||
|
||||
## Using Authorizers
|
||||
|
||||
You can enable an authorizer for your connect route by specifying the `authorizer` key in the websocket event definition.
|
||||
|
||||
**Note:** AWS only supports authorizers for the `$connect` route.
|
||||
@ -114,7 +118,6 @@ functions:
|
||||
|
||||
By default, the `identitySource` property is set to `route.request.header.Auth`, meaning that your request must include the auth token in the `Auth` header of the request. You can overwrite this by specifying your own `identitySource` configuration:
|
||||
|
||||
|
||||
```yml
|
||||
functions:
|
||||
connectHandler:
|
||||
@ -127,10 +130,11 @@ functions:
|
||||
identitySource:
|
||||
- 'route.request.header.Auth'
|
||||
- 'route.request.querystring.Auth'
|
||||
|
||||
|
||||
auth:
|
||||
handler: handler.auth
|
||||
```
|
||||
|
||||
With the above configuration, you can now must pass the auth token in both the `Auth` query string as well as the `Auth` header.
|
||||
|
||||
You can also supply an ARN instead of the name when using the object syntax for the authorizer:
|
||||
@ -147,12 +151,13 @@ functions:
|
||||
identitySource:
|
||||
- 'route.request.header.Auth'
|
||||
- 'route.request.querystring.Auth'
|
||||
|
||||
|
||||
auth:
|
||||
handler: handler.auth
|
||||
```
|
||||
|
||||
## Send a message to a ws-client
|
||||
|
||||
To send a message to a ws-client the [@connection](https://docs.amazonaws.cn/en_us/apigateway/latest/developerguide/apigateway-how-to-call-websocket-api-connections.html) command is used.
|
||||
|
||||
It uses the URL of the websocket API and most importantly the `connectionId` of the ws-client's connection. If you want to send a message to a ws-client from another function, you need this `connectionId` to address the ws-client.
|
||||
@ -160,29 +165,50 @@ It uses the URL of the websocket API and most importantly the `connectionId` of
|
||||
Example on how to respond with the complete `event` to the same ws-client:
|
||||
|
||||
```js
|
||||
const sendMessageToClient = (url, connectionId, payload) => new Promise((resolve, reject) => {
|
||||
const apigatewaymanagementapi = new AWS.ApiGatewayManagementApi({apiVersion: '2018-11-29', endpoint: url});
|
||||
apigatewaymanagementapi.postToConnection({
|
||||
ConnectionId: connectionId, // connectionId of the receiving ws-client
|
||||
Data: JSON.stringify(payload),
|
||||
}, (err, data) => {
|
||||
if (err) {
|
||||
console.log('err is', err);
|
||||
reject(err);
|
||||
}
|
||||
resolve(data);
|
||||
const sendMessageToClient = (url, connectionId, payload) =>
|
||||
new Promise((resolve, reject) => {
|
||||
const apigatewaymanagementapi = new AWS.ApiGatewayManagementApi({
|
||||
apiVersion: '2018-11-29',
|
||||
endpoint: url,
|
||||
});
|
||||
apigatewaymanagementapi.postToConnection(
|
||||
{
|
||||
ConnectionId: connectionId, // connectionId of the receiving ws-client
|
||||
Data: JSON.stringify(payload),
|
||||
},
|
||||
(err, data) => {
|
||||
if (err) {
|
||||
console.log('err is', err);
|
||||
reject(err);
|
||||
}
|
||||
resolve(data);
|
||||
}
|
||||
);
|
||||
});
|
||||
});
|
||||
|
||||
module.exports.defaultHandler = async (event, context) => {
|
||||
const domain = event.requestContext.domainName;
|
||||
const stage = event.requestContext.stage;
|
||||
const connectionId = event.requestContext.connectionId;
|
||||
const connectionId = event.requestContext.connectionId;
|
||||
const callbackUrlForAWS = util.format(util.format('https://%s/%s', domain, stage)); //construct the needed url
|
||||
await sendMessageToClient(callbackUrlForAWS, connectionId, event);
|
||||
|
||||
return {
|
||||
statusCode: 200
|
||||
statusCode: 200,
|
||||
};
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
## Logs
|
||||
|
||||
Use the following configuration to enable Websocket logs:
|
||||
|
||||
```yml
|
||||
# serverless.yml
|
||||
provider:
|
||||
name: aws
|
||||
logs:
|
||||
websocket: true
|
||||
```
|
||||
|
||||
The log streams will be generated in a dedicated log group which follows the naming schema `/aws/websocket/{service}-{stage}`.
|
||||
|
||||
@ -5,26 +5,28 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Serverless AWS Lambda Examples
|
||||
|
||||
Have an example? Submit a PR or [open an issue](https://github.com/serverless/examples/issues). ⚡️
|
||||
|
||||
| Example | Runtime |
|
||||
|:--------------------------- |:-----|
|
||||
| [Aws Auth0 Api Gateway](https://serverless.com/examples/aws-node-auth0-custom-authorizers-api/) <br/> Demonstration of protecting API gateway endpoints with auth0 | nodeJS |
|
||||
| [Env Variables Encrypted In A File](https://serverless.com/examples/aws-node-env-variables-encrypted-in-a-file/) <br/> Serverless example managing secrets in an encrypted file | nodeJS |
|
||||
| [Serverless Node Env Variables](https://serverless.com/examples/aws-node-env-variables/) <br/> This example demonstrates how to use environment variables for AWS Lambdas. | nodeJS |
|
||||
| [Fetch File And Store In S3](https://serverless.com/examples/aws-node-fetch-file-and-store-in-s3/) <br/> Fetch an image from remote source (URL) and then upload the image to a S3 bucket. | nodeJS |
|
||||
| [Function Compiled With Babel](https://serverless.com/examples/aws-node-function-compiled-with-babel/) <br/> Demonstrating how to compile all your code with Babel | nodeJS |
|
||||
| [Serverless Rest With Dynamodb](https://serverless.com/examples/aws-node-rest-api-with-dynamodb/) <br/> Serverless CRUD service exposing a REST HTTP interface | nodeJS |
|
||||
| [Serverless Aws Cron Job Example](https://serverless.com/examples/aws-node-scheduled-cron/) <br/> Example of creating a function that runs as a cron job using the serverless `schedule` event | nodeJS |
|
||||
| [Aws Node Serve Dynamic Html Via Http Endpoint](https://serverless.com/examples/aws-node-serve-dynamic-html-via-http-endpoint/) <br/> Hookup an AWS API Gateway endpoint to a Lambda function to render HTML on a `GET` request | nodeJS |
|
||||
| [Aws Node Serve Dynamic Html Via Http Endpoint](https://serverless.com/examples/aws-node-simple-http-endpoint/) <br/> Example demonstrates how to setup a simple HTTP GET endpoint | nodeJS |
|
||||
| [Single Page App Via Cloudfront](https://serverless.com/examples/aws-node-single-page-app-via-cloudfront/) <br/> Demonstrating how to deploy a Single Page Application with Serverless | nodeJS |
|
||||
| [Serverless Data Pipeline](https://serverless.com/examples/aws-node-text-analysis-via-sns-post-processing/) <br/> Example demonstrates how to setup a simple data processing pipeline | nodeJS |
|
||||
| [Aws Python Simple Http Endpoint](https://serverless.com/examples/aws-python-simple-http-endpoint/) <br/> Example demonstrates how to setup a simple HTTP GET endpoint with python | python |
|
||||
| Example | Runtime |
|
||||
| :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------ |
|
||||
| [Aws Auth0 Api Gateway](https://serverless.com/examples/aws-node-auth0-custom-authorizers-api/) <br/> Demonstration of protecting API gateway endpoints with auth0 | nodeJS |
|
||||
| [Env Variables Encrypted In A File](https://serverless.com/examples/aws-node-env-variables-encrypted-in-a-file/) <br/> Serverless example managing secrets in an encrypted file | nodeJS |
|
||||
| [Serverless Node Env Variables](https://serverless.com/examples/aws-node-env-variables/) <br/> This example demonstrates how to use environment variables for AWS Lambdas. | nodeJS |
|
||||
| [Fetch File And Store In S3](https://serverless.com/examples/aws-node-fetch-file-and-store-in-s3/) <br/> Fetch an image from remote source (URL) and then upload the image to a S3 bucket. | nodeJS |
|
||||
| [Function Compiled With Babel](https://serverless.com/examples/aws-node-function-compiled-with-babel/) <br/> Demonstrating how to compile all your code with Babel | nodeJS |
|
||||
| [Serverless Rest With Dynamodb](https://serverless.com/examples/aws-node-rest-api-with-dynamodb/) <br/> Serverless CRUD service exposing a REST HTTP interface | nodeJS |
|
||||
| [Serverless Aws Cron Job Example](https://serverless.com/examples/aws-node-scheduled-cron/) <br/> Example of creating a function that runs as a cron job using the serverless `schedule` event | nodeJS |
|
||||
| [Aws Node Serve Dynamic Html Via Http Endpoint](https://serverless.com/examples/aws-node-serve-dynamic-html-via-http-endpoint/) <br/> Hookup an AWS API Gateway endpoint to a Lambda function to render HTML on a `GET` request | nodeJS |
|
||||
| [Aws Node Serve Dynamic Html Via Http Endpoint](https://serverless.com/examples/aws-node-simple-http-endpoint/) <br/> Example demonstrates how to setup a simple HTTP GET endpoint | nodeJS |
|
||||
| [Single Page App Via Cloudfront](https://serverless.com/examples/aws-node-single-page-app-via-cloudfront/) <br/> Demonstrating how to deploy a Single Page Application with Serverless | nodeJS |
|
||||
| [Serverless Data Pipeline](https://serverless.com/examples/aws-node-text-analysis-via-sns-post-processing/) <br/> Example demonstrates how to setup a simple data processing pipeline | nodeJS |
|
||||
| [Aws Python Simple Http Endpoint](https://serverless.com/examples/aws-python-simple-http-endpoint/) <br/> Example demonstrates how to setup a simple HTTP GET endpoint with python | python |
|
||||
|
||||
If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](https://forum.serverless.com/)
|
||||
|
||||
@ -6,7 +6,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Hello World Serverless Example 🌍
|
||||
@ -15,10 +17,10 @@ Welcome to the Hello World example.
|
||||
|
||||
Pick your language of choice:
|
||||
|
||||
* [JavaScript](./node)
|
||||
* [Python](./python)
|
||||
* [C#](./csharp)
|
||||
* [F#](./fsharp)
|
||||
* [Go](./go)
|
||||
- [JavaScript](./node)
|
||||
- [Python](./python)
|
||||
- [C#](./csharp)
|
||||
- [F#](./fsharp)
|
||||
- [Go](./go)
|
||||
|
||||
[View all examples](https://www.serverless.com/framework/docs/providers/aws/examples/)
|
||||
|
||||
@ -6,7 +6,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/csharp/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Hello World C# Example
|
||||
@ -57,7 +59,6 @@ sls deploy
|
||||
|
||||
This will deploy your function to AWS Lambda based on the settings in `serverless.yml`.
|
||||
|
||||
|
||||
## 4. Invoke deployed function
|
||||
|
||||
```
|
||||
|
||||
@ -1,79 +1,81 @@
|
||||
<!--
|
||||
title: Hello World F# Example
|
||||
menuText: Hello World F# Example
|
||||
description: Create a F# Hello World Lambda function
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/fsharp/)
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Hello World F# Example
|
||||
|
||||
Make sure `serverless` is installed. [See installation guide](../../../guide/installation.md).
|
||||
|
||||
Once installed the Serverless CLI can be called with `serverless` or the shorthand `sls` command.
|
||||
|
||||
```
|
||||
$ sls
|
||||
|
||||
Commands
|
||||
* You can run commands with "serverless" or the shortcut "sls"
|
||||
* Pass "--verbose" to this command to get in-depth plugin info
|
||||
* Pass "--no-color" to disable CLI colors
|
||||
* Pass "--help" after any <command> for contextual help
|
||||
```
|
||||
|
||||
## 1. Create a service
|
||||
|
||||
```
|
||||
sls create --template aws-fsharp --path myService
|
||||
```
|
||||
|
||||
Using the `create` command we can specify one of the available [templates](https://serverless.com/framework/docs/providers/aws/cli-reference/create#available-templates). For this example use aws-fsharp with the `--template` or shorthand `-t` flag.
|
||||
|
||||
The `--path` or shorthand `-p` is the location to be created with the template service files. Change directories into this new folder.
|
||||
|
||||
## 2. Build using .NET Core 2.X CLI tools and create zip package
|
||||
|
||||
```
|
||||
# Linux or Mac OS
|
||||
./build.sh
|
||||
```
|
||||
|
||||
```
|
||||
# Windows PowerShell
|
||||
./build.cmd
|
||||
```
|
||||
|
||||
## 3. Deploy
|
||||
|
||||
```
|
||||
sls deploy
|
||||
```
|
||||
|
||||
This will deploy your function to AWS Lambda based on the settings in `serverless.yml`.
|
||||
|
||||
## 4. Invoke deployed function
|
||||
|
||||
```
|
||||
sls invoke -f hello
|
||||
```
|
||||
|
||||
Invoke deployed function with command `invoke` and `--function` or shorthand `-f`.
|
||||
|
||||
In your terminal window you should see the response from AWS Lambda.
|
||||
|
||||
```bash
|
||||
{
|
||||
"Message": "Go Serverless v1.0! Your function executed successfully!",
|
||||
"Request": {
|
||||
"Key1": null,
|
||||
"Key2": null,
|
||||
"Key3": null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Congrats you have deployed and ran your Hello World function!
|
||||
<!--
|
||||
title: Hello World F# Example
|
||||
menuText: Hello World F# Example
|
||||
description: Create a F# Hello World Lambda function
|
||||
layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/fsharp/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Hello World F# Example
|
||||
|
||||
Make sure `serverless` is installed. [See installation guide](../../../guide/installation.md).
|
||||
|
||||
Once installed the Serverless CLI can be called with `serverless` or the shorthand `sls` command.
|
||||
|
||||
```
|
||||
$ sls
|
||||
|
||||
Commands
|
||||
* You can run commands with "serverless" or the shortcut "sls"
|
||||
* Pass "--verbose" to this command to get in-depth plugin info
|
||||
* Pass "--no-color" to disable CLI colors
|
||||
* Pass "--help" after any <command> for contextual help
|
||||
```
|
||||
|
||||
## 1. Create a service
|
||||
|
||||
```
|
||||
sls create --template aws-fsharp --path myService
|
||||
```
|
||||
|
||||
Using the `create` command we can specify one of the available [templates](https://serverless.com/framework/docs/providers/aws/cli-reference/create#available-templates). For this example use aws-fsharp with the `--template` or shorthand `-t` flag.
|
||||
|
||||
The `--path` or shorthand `-p` is the location to be created with the template service files. Change directories into this new folder.
|
||||
|
||||
## 2. Build using .NET Core 2.X CLI tools and create zip package
|
||||
|
||||
```
|
||||
# Linux or Mac OS
|
||||
./build.sh
|
||||
```
|
||||
|
||||
```
|
||||
# Windows PowerShell
|
||||
./build.cmd
|
||||
```
|
||||
|
||||
## 3. Deploy
|
||||
|
||||
```
|
||||
sls deploy
|
||||
```
|
||||
|
||||
This will deploy your function to AWS Lambda based on the settings in `serverless.yml`.
|
||||
|
||||
## 4. Invoke deployed function
|
||||
|
||||
```
|
||||
sls invoke -f hello
|
||||
```
|
||||
|
||||
Invoke deployed function with command `invoke` and `--function` or shorthand `-f`.
|
||||
|
||||
In your terminal window you should see the response from AWS Lambda.
|
||||
|
||||
```bash
|
||||
{
|
||||
"Message": "Go Serverless v1.0! Your function executed successfully!",
|
||||
"Request": {
|
||||
"Key1": null,
|
||||
"Key2": null,
|
||||
"Key3": null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Congrats you have deployed and ran your Hello World function!
|
||||
|
||||
@ -6,7 +6,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically geneated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/go/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Hello World Go Example
|
||||
@ -63,7 +65,7 @@ Change directories into 'myService' folder and you can see this project has 2 ha
|
||||
│ └── main.go
|
||||
```
|
||||
|
||||
This because a `main()` function is required as entry point for each handler executable.
|
||||
This because a `main()` function is required as entry point for each handler executable.
|
||||
|
||||
## 2. Build using go build to create static binaries
|
||||
|
||||
|
||||
@ -6,7 +6,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/node/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Hello World Node.js Example
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
'use strict';
|
||||
|
||||
// Your function handler
|
||||
module.exports.helloWorldHandler = function (event, context, callback) {
|
||||
module.exports.helloWorldHandler = function(event, context, callback) {
|
||||
const message = {
|
||||
message: 'Hello World',
|
||||
event,
|
||||
|
||||
@ -3,7 +3,7 @@ service: hello-world # Service Name
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
|
||||
functions:
|
||||
helloWorld:
|
||||
|
||||
@ -6,7 +6,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/python/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Hello World Python Example
|
||||
|
||||
@ -6,7 +6,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/ruby/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Hello World Ruby Example
|
||||
@ -55,8 +57,8 @@ In your terminal window you should see the response from AWS Lambda.
|
||||
|
||||
```json
|
||||
{
|
||||
"statusCode": 200,
|
||||
"body": "\"Go Serverless v1.0! Your function executed successfully!\""
|
||||
"statusCode": 200,
|
||||
"body": "\"Go Serverless v1.0! Your function executed successfully!\""
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@ -5,7 +5,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Serverless AWS Lambda Guide
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/credentials)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Credentials
|
||||
@ -26,8 +28,7 @@ Here's how to set up the Serverless Framework with your Amazon Web Services acco
|
||||
|
||||
If you're new to Amazon Web Services, make sure you put in a credit card.
|
||||
|
||||
All AWS users get access to the Free Tier for [AWS Lambda](https://aws.amazon.com/lambda/pricing/). AWS Lambda is part of the non-expiring [AWS Free Tier](https://aws.amazon.com/free/#AWS_FREE_TIER). For additional pricing information for AWS Lambda and Gateway [here](https://aws.amazon.com/lambda/pricing/). If you're using additional AWS services, they could incur additional costs. Please review pricing for you services on AWS [here](https://aws.amazon.com/pricing/).
|
||||
|
||||
All AWS users get access to the Free Tier for [AWS Lambda](https://aws.amazon.com/lambda/pricing/). AWS Lambda is part of the non-expiring [AWS Free Tier](https://aws.amazon.com/free/#AWS_FREE_TIER). For additional pricing information for AWS Lambda and AWS API Gateway [here](https://aws.amazon.com/lambda/pricing/). If you're using additional AWS services, they could incur additional costs. Please review pricing for you services on AWS [here](https://aws.amazon.com/pricing/).
|
||||
|
||||
If you don't have a credit card set up, you may not be able to deploy your resources and you may run into this error:
|
||||
|
||||
@ -35,7 +36,7 @@ If you don't have a credit card set up, you may not be able to deploy your resou
|
||||
AWS Access Key Id needs a subscription for the service
|
||||
```
|
||||
|
||||
While in the AWS Free Tier, you can build an entire application on AWS Lambda, AWS API Gateway, and more, without getting charged for 1 year... As long as you don't exceed the resources in the free tier, of course.
|
||||
While in the AWS Free Tier, you can build an entire application on AWS Lambda, AWS API Gateway, and more, without getting charged for 1 year... As long as you don't exceed the resources in the free tier, of course.
|
||||
|
||||
### Creating AWS Access Keys
|
||||
|
||||
@ -45,17 +46,17 @@ To let the Serverless Framework access your AWS account, we're going to **create
|
||||
|
||||
2. Click on **Users** and then **Add user**. Enter a name in the first field to remind you this User is the Framework, like `serverless-agent`. Enable **Programmatic access** by clicking the checkbox. Click **Next** to go through to the Permissions page. Click on **Create policy**. Select the **JSON** tab, add the following JSON file you'll find in [this gist](https://gist.github.com/ServerlessBot/7618156b8671840a539f405dea2704c8).
|
||||
|
||||
When you are finished, select **Review policy**. You can assign this policy a **Name** and **Description**, then choose **Create Policy**. Check everything looks good and click **Create user**. Later, you can create different IAM Users for different apps and different stages of those apps. That is, if you don't use separate AWS accounts for stages/apps, which is most common.
|
||||
When you are finished, select **Review policy**. You can assign this policy a **Name** and **Description**, then choose **Create Policy**. Check everything looks good and click **Create user**. Later, you can create different IAM Users for different apps and different stages of those apps. That is, if you don't use separate AWS accounts for stages/apps, which is most common.
|
||||
|
||||
3. View and copy the **API Key** & **Secret** to a temporary place. You'll need it in the next step.
|
||||
|
||||
As you add additional functions and services, your permission needs will change. Though not advised, you can **create an IAM User with Admin access**, which can configure the services in your AWS account. This IAM User will have its own set of AWS Access Keys.
|
||||
As you add additional functions and services, your permission needs will change. Though not advised, you can **create an IAM User with Admin access**, which can configure the services in your AWS account. This IAM User will have its own set of AWS Access Keys.
|
||||
|
||||
**Note:** In a production environment, we recommend reducing the permissions to the IAM User which the Framework uses. Unfortunately, the Framework's functionality is growing so fast, we can't yet offer you a finite set of permissions it needs (we're working on this). Consider using a separate AWS account in the interim, if you cannot get permission to your organization's primary AWS accounts.
|
||||
**Note:** In a production environment, we recommend reducing the permissions to the IAM User which the Framework uses. Unfortunately, the Framework's functionality is growing so fast, we can't yet offer you a finite set of permissions it needs (we're working on this). Consider using a separate AWS account in the interim, if you cannot get permission to your organization's primary AWS accounts.
|
||||
|
||||
1. Create or login to your Amazon Web Services Account and go to the Identity & Access Management (IAM) page.
|
||||
|
||||
2. Click on **Users** and then **Add user**. Enter a name in the first field to remind you this User is the Framework, like `serverless-admin`. Enable **Programmatic access** by clicking the checkbox. Click **Next** to go through to the Permissions page. Click on **Attach existing policies directly**. Search for and select **AdministratorAccess** then click **Next: Review**. Check everything looks good and click **Create user**. Later, you can create different IAM Users for different apps and different stages of those apps. That is, if you don't use separate AWS accounts for stages/apps, which is most common.
|
||||
2. Click on **Users** and then **Add user**. Enter a name in the first field to remind you this User is the Framework, like `serverless-admin`. Enable **Programmatic access** by clicking the checkbox. Click **Next** to go through to the Permissions page. Click on **Attach existing policies directly**. Search for and select **AdministratorAccess** then click **Next: Review**. Check everything looks good and click **Create user**. Later, you can create different IAM Users for different apps and different stages of those apps. That is, if you don't use separate AWS accounts for stages/apps, which is most common.
|
||||
|
||||
3. View and copy the **API Key** & **Secret** to a temporary place. You'll need it in the next step.
|
||||
|
||||
@ -76,7 +77,8 @@ serverless deploy
|
||||
# 'export' command is valid only for unix shells. In Windows - use 'set' instead of 'export'
|
||||
```
|
||||
|
||||
**Please note:** *If you are using a self-signed certificate you'll need to do one of the following:*
|
||||
**Please note:** _If you are using a self-signed certificate you'll need to do one of the following:_
|
||||
|
||||
```bash
|
||||
# String example:
|
||||
# if using the 'ca' variable, your certificate contents should replace the newline character with '\n'
|
||||
@ -94,7 +96,6 @@ export cafile="/path/to/cafile1.pem,/path/to/cafile2.pem"
|
||||
# 'export' command is valid only for unix shells. In Windows - use 'set' instead of 'export'
|
||||
```
|
||||
|
||||
|
||||
#### Using AWS Profiles
|
||||
|
||||
For a more permanent solution you can also set up credentials through AWS profiles. Here are different methods you can use to do so.
|
||||
@ -131,7 +132,7 @@ You can even set up different profiles for different accounts, which can be used
|
||||
service: new-service
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
stage: dev
|
||||
profile: devProfile
|
||||
```
|
||||
@ -176,7 +177,7 @@ This example `serverless.yml` snippet will load the profile depending upon the s
|
||||
service: new-service
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
stage: ${opt:stage, self:custom.defaultStage}
|
||||
profile: ${self:custom.profiles.${self:provider.stage}}
|
||||
custom:
|
||||
@ -191,4 +192,4 @@ custom:
|
||||
**Be aware!** Due to the way AWS IAM and the local environment works, if you invoke your lambda functions locally using the CLI command `serverless invoke local -f ...` the IAM role/profile could be (and probably is) different from the one set in the `serverless.yml` configuration file.
|
||||
Thus, most likely, a different set of permissions will be in place, altering the interaction between your lambda functions and other AWS resources.
|
||||
|
||||
*Please, refer to the [`invoke local`](https://serverless.com/framework/docs/providers/aws/cli-reference/invoke-local/#aws---invoke-local) CLI command documentation for more details.*
|
||||
_Please, refer to the [`invoke local`](https://serverless.com/framework/docs/providers/aws/cli-reference/invoke-local/#aws---invoke-local) CLI command documentation for more details._
|
||||
|
||||
@ -7,12 +7,14 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/deploying)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Deploying
|
||||
|
||||
The Serverless Framework was designed to provision your AWS Lambda Functions, Events and infrastructure Resources safely and quickly. It does this via a couple of methods designed for different types of deployments.
|
||||
The Serverless Framework was designed to provision your AWS Lambda Functions, Events and infrastructure Resources safely and quickly. It does this via a couple of methods designed for different types of deployments.
|
||||
|
||||
## Deploy All
|
||||
|
||||
@ -24,32 +26,33 @@ serverless deploy
|
||||
|
||||
Use this method when you have updated your Function, Event or Resource configuration in `serverless.yml` and you want to deploy that change (or multiple changes at the same time) to Amazon Web Services.
|
||||
|
||||
**Note:** You can always enforce a deployment using the `--force` option.
|
||||
**Note:** You can always enforce a deployment using the `--force` option, or specify a different configuration file name with the the `--config` option.
|
||||
|
||||
### How It Works
|
||||
|
||||
The Serverless Framework translates all syntax in `serverless.yml` to a single AWS CloudFormation template. By depending on CloudFormation for deployments, users of the Serverless Framework get the safety and reliability of CloudFormation.
|
||||
The Serverless Framework translates all syntax in `serverless.yml` to a single AWS CloudFormation template. By depending on CloudFormation for deployments, users of the Serverless Framework get the safety and reliability of CloudFormation.
|
||||
|
||||
* An AWS CloudFormation template is created from your `serverless.yml`.
|
||||
* If a Stack has not yet been created, then it is created with no resources except for an S3 Bucket, which will store zip files of your Function code.
|
||||
* The code of your Functions is then packaged into zip files.
|
||||
* Serverless fetches the hashes for all files of the previous deployment (if any) and compares them against the hashes of the local files.
|
||||
* Serverless terminates the deployment process if all file hashes are the same.
|
||||
* Zip files of your Functions' code are uploaded to your Code S3 Bucket.
|
||||
* Any IAM Roles, Functions, Events and Resources are added to the AWS CloudFormation template.
|
||||
* The CloudFormation Stack is updated with the new CloudFormation template.
|
||||
* Each deployment publishes a new version for each function in your service.
|
||||
- An AWS CloudFormation template is created from your `serverless.yml`.
|
||||
- If a Stack has not yet been created, then it is created with no resources except for an S3 Bucket, which will store zip files of your Function code.
|
||||
- The code of your Functions is then packaged into zip files.
|
||||
- Serverless fetches the hashes for all files of the previous deployment (if any) and compares them against the hashes of the local files.
|
||||
- Serverless terminates the deployment process if all file hashes are the same.
|
||||
- Zip files of your Functions' code are uploaded to your Code S3 Bucket.
|
||||
- Any IAM Roles, Functions, Events and Resources are added to the AWS CloudFormation template.
|
||||
- The CloudFormation Stack is updated with the new CloudFormation template.
|
||||
- Each deployment publishes a new version for each function in your service.
|
||||
|
||||
### Tips
|
||||
|
||||
* Use this in your CI/CD systems, as it is the safest method of deployment.
|
||||
* You can print the progress during the deployment if you use `verbose` mode, like this:
|
||||
- Use this in your CI/CD systems, as it is the safest method of deployment.
|
||||
- You can print the progress during the deployment if you use `verbose` mode, like this:
|
||||
```
|
||||
serverless deploy --verbose
|
||||
```
|
||||
* This method uses the AWS CloudFormation Stack Update method. CloudFormation is slow, so this method is slower. If you want to develop more quickly, use the `serverless deploy function` command (described below)
|
||||
- This method uses the AWS CloudFormation Stack Update method. CloudFormation is slow, so this method is slower. If you want to develop more quickly, use the `serverless deploy function` command (described below)
|
||||
|
||||
- This method defaults to `dev` stage and `us-east-1` region. You can change the default stage and region in your `serverless.yml` file by setting the `stage` and `region` properties inside a `provider` object as the following example shows:
|
||||
|
||||
* This method defaults to `dev` stage and `us-east-1` region. You can change the default stage and region in your `serverless.yml` file by setting the `stage` and `region` properties inside a `provider` object as the following example shows:
|
||||
```yml
|
||||
# serverless.yml
|
||||
|
||||
@ -60,47 +63,46 @@ The Serverless Framework translates all syntax in `serverless.yml` to a single A
|
||||
region: us-west-2
|
||||
```
|
||||
|
||||
* You can also deploy to different stages and regions by passing in flags to the command:
|
||||
- You can also deploy to different stages and regions by passing in flags to the command:
|
||||
|
||||
```
|
||||
serverless deploy --stage production --region eu-central-1
|
||||
```
|
||||
|
||||
* You can specify your own S3 bucket which should be used to store all the deployment artifacts.
|
||||
- You can specify your own S3 bucket which should be used to store all the deployment artifacts.
|
||||
The `deploymentBucket` config which is nested under `provider` lets you e.g. set the `name` or the `serverSideEncryption` method for this bucket. If you don't provide your own bucket, Serverless
|
||||
will create a bucket which uses default AES256 encryption.
|
||||
|
||||
* You can specify your own S3 prefix which should be used to store all the deployment artifacts.
|
||||
- You can specify your own S3 prefix which should be used to store all the deployment artifacts.
|
||||
The `deploymentPrefix` config which is nested under `provider` lets you set the prefix under which the deployment artifacts will be stored. If not specified, defaults to `serverless`.
|
||||
|
||||
* You can make uploading to S3 faster by adding `--aws-s3-accelerate`
|
||||
- You can make uploading to S3 faster by adding `--aws-s3-accelerate`
|
||||
|
||||
Check out the [deploy command docs](../cli-reference/deploy.md) for all details and options.
|
||||
|
||||
|
||||
* For information on multi-region deployments, [checkout this article](https://serverless.com/blog/build-multiregion-multimaster-application-dynamodb-global-tables).
|
||||
- For information on multi-region deployments, [checkout this article](https://serverless.com/blog/build-multiregion-multimaster-application-dynamodb-global-tables).
|
||||
|
||||
## Deploy Function
|
||||
|
||||
This deployment method does not touch your AWS CloudFormation Stack. Instead, it simply overwrites the zip file of the current function on AWS. This method is much faster, since it does not rely on CloudFormation.
|
||||
This deployment method does not touch your AWS CloudFormation Stack. Instead, it simply overwrites the zip file of the current function on AWS. This method is much faster, since it does not rely on CloudFormation.
|
||||
|
||||
```bash
|
||||
serverless deploy function --function myFunction
|
||||
```
|
||||
|
||||
-**Note:** You can always enforce a deployment using the `--force` option.
|
||||
-**Note:** You can use `--update-config` to change only Lambda configuration without deploying code.
|
||||
-**Note:** You can always enforce a deployment using the `--force` option. -**Note:** You can use `--update-config` to change only Lambda configuration without deploying code.
|
||||
|
||||
### How It Works
|
||||
|
||||
* The Framework packages up the targeted AWS Lambda Function into a zip file.
|
||||
* The Framework fetches the hash of the already uploaded function .zip file and compares it to the local .zip file hash.
|
||||
* The Framework terminates if both hashes are the same.
|
||||
* That zip file is uploaded to your S3 bucket using the same name as the previous function, which the CloudFormation stack is pointing to.
|
||||
- The Framework packages up the targeted AWS Lambda Function into a zip file.
|
||||
- The Framework fetches the hash of the already uploaded function .zip file and compares it to the local .zip file hash.
|
||||
- The Framework terminates if both hashes are the same.
|
||||
- That zip file is uploaded to your S3 bucket using the same name as the previous function, which the CloudFormation stack is pointing to.
|
||||
|
||||
### Tips
|
||||
|
||||
* Use this when you are developing and want to test on AWS because it's much faster.
|
||||
* During development, people will often run this command several times, as opposed to `serverless deploy` which is only run when larger infrastructure provisioning is required.
|
||||
- Use this when you are developing and want to test on AWS because it's much faster.
|
||||
- During development, people will often run this command several times, as opposed to `serverless deploy` which is only run when larger infrastructure provisioning is required.
|
||||
|
||||
Check out the [deploy command docs](../cli-reference/deploy.md) for all details and options.
|
||||
|
||||
@ -116,5 +118,3 @@ serverless deploy --package path-to-package
|
||||
|
||||
- The argument to the `--package` flag is a directory that has been previously packaged by Serverless (with `serverless package`).
|
||||
- The deploy process bypasses the package step and uses the existing package to deploy and update CloudFormation stacks.
|
||||
|
||||
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/events)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Events
|
||||
@ -60,7 +62,7 @@ functions:
|
||||
|
||||
## Types
|
||||
|
||||
The Serverless Framework supports all of the AWS Lambda events and more. Instead of listing them here, we've put them in a separate section, since they have a lot of configurations and functionality. [Check out the events section for more information.](../events)
|
||||
The Serverless Framework supports all of the AWS Lambda events and more. Instead of listing them here, we've put them in a separate section, since they have a lot of configurations and functionality. [Check out the events section for more information.](../events)
|
||||
|
||||
## Deploying
|
||||
|
||||
|
||||
@ -7,12 +7,14 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/functions)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Functions
|
||||
|
||||
If you are using AWS as a provider, all *functions* inside the service are AWS Lambda functions.
|
||||
If you are using AWS as a provider, all _functions_ inside the service are AWS Lambda functions.
|
||||
|
||||
## Configuration
|
||||
|
||||
@ -24,7 +26,7 @@ service: myService
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
memorySize: 512 # optional, in MB, default is 1024
|
||||
timeout: 10 # optional, in seconds, default is 6
|
||||
versionFunctions: false # optional, default is true
|
||||
@ -47,7 +49,7 @@ The `handler` property points to the file and module containing the code you wan
|
||||
|
||||
```javascript
|
||||
// handler.js
|
||||
module.exports.functionOne = function(event, context, callback) {}
|
||||
module.exports.functionOne = function(event, context, callback) {};
|
||||
```
|
||||
|
||||
You can add as many functions as you want within this property.
|
||||
@ -59,7 +61,7 @@ service: myService
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
|
||||
functions:
|
||||
functionOne:
|
||||
@ -79,7 +81,7 @@ service: myService
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
memorySize: 512 # will be inherited by all functions
|
||||
|
||||
functions:
|
||||
@ -95,7 +97,7 @@ service: myService
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
|
||||
functions:
|
||||
functionOne:
|
||||
@ -107,8 +109,7 @@ You can specify an array of functions, which is useful if you separate your func
|
||||
|
||||
```yml
|
||||
# serverless.yml
|
||||
...
|
||||
|
||||
---
|
||||
functions:
|
||||
- ${file(./foo-functions.yml)}
|
||||
- ${file(./bar-functions.yml)}
|
||||
@ -122,10 +123,9 @@ deleteFoo:
|
||||
handler: handler.foo
|
||||
```
|
||||
|
||||
|
||||
## Permissions
|
||||
|
||||
Every AWS Lambda function needs permission to interact with other AWS infrastructure resources within your account. These permissions are set via an AWS IAM Role. You can set permission policy statements within this role via the `provider.iamRoleStatements` property.
|
||||
Every AWS Lambda function needs permission to interact with other AWS infrastructure resources within your account. These permissions are set via an AWS IAM Role. You can set permission policy statements within this role via the `provider.iamRoleStatements` property.
|
||||
|
||||
```yml
|
||||
# serverless.yml
|
||||
@ -133,7 +133,7 @@ service: myService
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
iamRoleStatements: # permissions for all of your functions can be set here
|
||||
- Effect: Allow
|
||||
Action: # Gives permission to DynamoDB tables in a specific region
|
||||
@ -144,7 +144,7 @@ provider:
|
||||
- dynamodb:PutItem
|
||||
- dynamodb:UpdateItem
|
||||
- dynamodb:DeleteItem
|
||||
Resource: "arn:aws:dynamodb:us-east-1:*:*"
|
||||
Resource: 'arn:aws:dynamodb:us-east-1:*:*'
|
||||
|
||||
functions:
|
||||
functionOne:
|
||||
@ -160,21 +160,21 @@ service: myService
|
||||
provider:
|
||||
name: aws
|
||||
iamRoleStatements:
|
||||
- Effect: "Allow"
|
||||
Action:
|
||||
- "s3:ListBucket"
|
||||
# You can put CloudFormation syntax in here. No one will judge you.
|
||||
# Remember, this all gets translated to CloudFormation.
|
||||
Resource: { "Fn::Join" : ["", ["arn:aws:s3:::", { "Ref" : "ServerlessDeploymentBucket"} ] ] }
|
||||
- Effect: "Allow"
|
||||
Action:
|
||||
- "s3:PutObject"
|
||||
Resource:
|
||||
Fn::Join:
|
||||
- ""
|
||||
- - "arn:aws:s3:::"
|
||||
- "Ref" : "ServerlessDeploymentBucket"
|
||||
- "/*"
|
||||
- Effect: 'Allow'
|
||||
Action:
|
||||
- 's3:ListBucket'
|
||||
# You can put CloudFormation syntax in here. No one will judge you.
|
||||
# Remember, this all gets translated to CloudFormation.
|
||||
Resource: { 'Fn::Join': ['', ['arn:aws:s3:::', { 'Ref': 'ServerlessDeploymentBucket' }]] }
|
||||
- Effect: 'Allow'
|
||||
Action:
|
||||
- 's3:PutObject'
|
||||
Resource:
|
||||
Fn::Join:
|
||||
- ''
|
||||
- - 'arn:aws:s3:::'
|
||||
- 'Ref': 'ServerlessDeploymentBucket'
|
||||
- '/*'
|
||||
|
||||
functions:
|
||||
functionOne:
|
||||
@ -293,6 +293,7 @@ functions:
|
||||
environment:
|
||||
TABLE_NAME: tableName2
|
||||
```
|
||||
|
||||
If you want your function's environment variables to have the same values from your machine's environment variables, please read the documentation about [Referencing Environment Variables](./variables.md).
|
||||
|
||||
## Tags
|
||||
@ -359,7 +360,6 @@ To publish Lambda Layers, check out the [Layers](./layers.md) documentation.
|
||||
|
||||
By default, the framework will create LogGroups for your Lambdas. This makes it easy to clean up your log groups in the case you remove your service, and make the lambda IAM permissions much more specific and secure.
|
||||
|
||||
|
||||
## Versioning Deployed Functions
|
||||
|
||||
By default, the framework creates function versions for every deploy. This behavior is optional, and can be turned off in cases where you don't invoke past versions by their qualifier. If you would like to do this, you can invoke your functions as `arn:aws:lambda:....:function/myFunc:3` to invoke version 3 for example.
|
||||
@ -390,7 +390,7 @@ service: service
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
|
||||
functions:
|
||||
hello:
|
||||
@ -443,7 +443,7 @@ service: myService
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs8.10
|
||||
runtime: nodejs10.x
|
||||
tracing:
|
||||
lambda: true
|
||||
```
|
||||
|
||||
@ -7,18 +7,20 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/iam)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# IAM
|
||||
|
||||
Every AWS Lambda function needs permission to interact with other AWS infrastructure resources within your account. These permissions are set via an AWS IAM Role which the Serverless Framework automatically creates for each Serverless Service, and is shared by all of your Functions. The Framework allows you to modify this Role or create Function-specific Roles, easily.
|
||||
Every AWS Lambda function needs permission to interact with other AWS infrastructure resources within your account. These permissions are set via an AWS IAM Role which the Serverless Framework automatically creates for each Serverless Service, and is shared by all of your Functions. The Framework allows you to modify this Role or create Function-specific Roles, easily.
|
||||
|
||||
## The Default IAM Role
|
||||
|
||||
By default, one IAM Role is shared by all of the Lambda functions in your service. Also by default, your Lambda functions have permission to create and write to CloudWatch logs. When VPC configuration is provided the default AWS `AWSLambdaVPCAccessExecutionRole` will be associated in order to communicate with your VPC resources.
|
||||
|
||||
To add specific rights to this service-wide Role, define statements in `provider.iamRoleStatements` which will be merged into the generated policy. As those statements will be merged into the CloudFormation template, you can use `Join`, `Ref` or any other CloudFormation method or feature.
|
||||
To add specific rights to this service-wide Role, define statements in `provider.iamRoleStatements` which will be merged into the generated policy. As those statements will be merged into the CloudFormation template, you can use `Join`, `Ref` or any other CloudFormation method or feature.
|
||||
|
||||
```yml
|
||||
service: new-service
|
||||
@ -26,26 +28,27 @@ service: new-service
|
||||
provider:
|
||||
name: aws
|
||||
iamRoleStatements:
|
||||
- Effect: "Allow"
|
||||
Action:
|
||||
- "s3:ListBucket"
|
||||
Resource:
|
||||
Fn::Join:
|
||||
- ""
|
||||
- - "arn:aws:s3:::"
|
||||
- Ref: ServerlessDeploymentBucket
|
||||
- Effect: "Allow"
|
||||
Action:
|
||||
- "s3:PutObject"
|
||||
Resource:
|
||||
Fn::Join:
|
||||
- ""
|
||||
- - "arn:aws:s3:::"
|
||||
- Ref: ServerlessDeploymentBucket
|
||||
- "/*"
|
||||
|
||||
- Effect: 'Allow'
|
||||
Action:
|
||||
- 's3:ListBucket'
|
||||
Resource:
|
||||
Fn::Join:
|
||||
- ''
|
||||
- - 'arn:aws:s3:::'
|
||||
- Ref: ServerlessDeploymentBucket
|
||||
- Effect: 'Allow'
|
||||
Action:
|
||||
- 's3:PutObject'
|
||||
Resource:
|
||||
Fn::Join:
|
||||
- ''
|
||||
- - 'arn:aws:s3:::'
|
||||
- Ref: ServerlessDeploymentBucket
|
||||
- '/*'
|
||||
```
|
||||
|
||||
Alongside `provider.iamRoleStatements` managed policies can also be added to this service-wide Role, define managed policies in `provider.iamManagedPolicies`. These will also be merged into the generated IAM Role so you can use `Join`, `Ref` or any other CloudFormation method or feature here too.
|
||||
|
||||
```yml
|
||||
service: new-service
|
||||
|
||||
@ -180,7 +183,7 @@ resources:
|
||||
- logs:CreateLogGroup
|
||||
- logs:CreateLogStream
|
||||
- logs:PutLogEvents
|
||||
Resource:
|
||||
Resource:
|
||||
- 'Fn::Join':
|
||||
- ':'
|
||||
-
|
||||
@ -218,7 +221,7 @@ resources:
|
||||
- logs:CreateLogGroup
|
||||
- logs:CreateLogStream
|
||||
- logs:PutLogEvents
|
||||
Resource:
|
||||
Resource:
|
||||
- 'Fn::Join':
|
||||
- ':'
|
||||
-
|
||||
@ -277,7 +280,7 @@ resources:
|
||||
- logs:CreateLogGroup
|
||||
- logs:CreateLogStream
|
||||
- logs:PutLogEvents
|
||||
Resource:
|
||||
Resource:
|
||||
- 'Fn::Join':
|
||||
- ':'
|
||||
-
|
||||
@ -316,7 +319,7 @@ resources:
|
||||
- logs:CreateLogGroup
|
||||
- logs:CreateLogStream
|
||||
- logs:PutLogEvents
|
||||
Resource:
|
||||
Resource:
|
||||
- 'Fn::Join':
|
||||
- ':'
|
||||
-
|
||||
@ -331,5 +334,5 @@ resources:
|
||||
- ec2:DetachNetworkInterface
|
||||
- ec2:DeleteNetworkInterface
|
||||
Resource: "*"
|
||||
|
||||
|
||||
```
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/installation)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Installation
|
||||
|
||||
@ -7,16 +7,19 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/intro)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Introduction
|
||||
|
||||
The Serverless Framework helps you develop and deploy your AWS Lambda functions, along with the AWS infrastructure resources they require. It's a CLI that offers structure, automation and best practices out-of-the-box, allowing you to focus on building sophisticated, event-driven, serverless architectures, comprised of [Functions](#functions) and [Events](#events).
|
||||
The Serverless Framework helps you develop and deploy your AWS Lambda functions, along with the AWS infrastructure resources they require. It's a CLI that offers structure, automation and best practices out-of-the-box, allowing you to focus on building sophisticated, event-driven, serverless architectures, comprised of [Functions](#functions) and [Events](#events).
|
||||
|
||||
The Serverless Framework is different from other application frameworks because:
|
||||
* It manages your code as well as your infrastructure
|
||||
* It supports multiple languages (Node.js, Python, Java, and more)
|
||||
|
||||
- It manages your code as well as your infrastructure
|
||||
- It supports multiple languages (Node.js, Python, Java, and more)
|
||||
|
||||
## Core Concepts
|
||||
|
||||
@ -24,24 +27,24 @@ Here are the Framework's main concepts and how they pertain to AWS and Lambda...
|
||||
|
||||
### Functions
|
||||
|
||||
A Function is an AWS Lambda function. It's an independent unit of deployment, like a microservice. It's merely code, deployed in the cloud, that is most often written to perform a single job such as:
|
||||
A Function is an AWS Lambda function. It's an independent unit of deployment, like a microservice. It's merely code, deployed in the cloud, that is most often written to perform a single job such as:
|
||||
|
||||
* *Saving a user to the database*
|
||||
* *Processing a file in a database*
|
||||
* *Performing a scheduled task*
|
||||
- _Saving a user to the database_
|
||||
- _Processing a file in a database_
|
||||
- _Performing a scheduled task_
|
||||
|
||||
You can perform multiple jobs in your code, but we don't recommend doing that without good reason. Separation of concerns is best and the Framework is designed to help you easily develop and deploy Functions, as well as manage lots of them.
|
||||
You can perform multiple jobs in your code, but we don't recommend doing that without good reason. Separation of concerns is best and the Framework is designed to help you easily develop and deploy Functions, as well as manage lots of them.
|
||||
|
||||
### Events
|
||||
|
||||
Anything that triggers an AWS Lambda Function to execute is regarded by the Framework as an **Event**. Events are infrastructure events on AWS such as:
|
||||
Anything that triggers an AWS Lambda Function to execute is regarded by the Framework as an **Event**. Events are infrastructure events on AWS such as:
|
||||
|
||||
* *An AWS API Gateway HTTP endpoint request (e.g., for a REST API)*
|
||||
* *An AWS S3 bucket upload (e.g., for an image)*
|
||||
* *A CloudWatch timer (e.g., run every 5 minutes)*
|
||||
* *An AWS SNS topic (e.g., a message)*
|
||||
* *A CloudWatch Alert (e.g., something happened)*
|
||||
* *And more...*
|
||||
- _An AWS API Gateway HTTP endpoint request (e.g., for a REST API)_
|
||||
- _An AWS S3 bucket upload (e.g., for an image)_
|
||||
- _A CloudWatch timer (e.g., run every 5 minutes)_
|
||||
- _An AWS SNS topic (e.g., a message)_
|
||||
- _A CloudWatch Alert (e.g., something happened)_
|
||||
- _And more..._
|
||||
|
||||
When you define an event for your AWS Lambda functions in the Serverless Framework, the Framework will automatically create any infrastructure necessary for that event (e.g., an API Gateway endpoint) and configure your AWS Lambda Functions to listen to it.
|
||||
|
||||
@ -49,16 +52,16 @@ When you define an event for your AWS Lambda functions in the Serverless Framewo
|
||||
|
||||
**Resources** are AWS infrastructure components which your Functions use such as:
|
||||
|
||||
* *An AWS DynamoDB Table (e.g., for saving Users/Posts/Comments data)*
|
||||
* *An AWS S3 Bucket (e.g., for saving images or files)*
|
||||
* *An AWS SNS Topic (e.g., for sending messages asynchronously)*
|
||||
* *Anything that can be defined in CloudFormation is supported by the Serverless Framework*
|
||||
- _An AWS DynamoDB Table (e.g., for saving Users/Posts/Comments data)_
|
||||
- _An AWS S3 Bucket (e.g., for saving images or files)_
|
||||
- _An AWS SNS Topic (e.g., for sending messages asynchronously)_
|
||||
- _Anything that can be defined in CloudFormation is supported by the Serverless Framework_
|
||||
|
||||
The Serverless Framework not only deploys your Functions and the Events that trigger them, but it also deploys the AWS infrastructure components your Functions depend upon.
|
||||
|
||||
### Services
|
||||
|
||||
A **Service** is the Framework's unit of organization. You can think of it as a project file, though you can have multiple services for a single application. It's where you define your Functions, the Events that trigger them, and the Resources your Functions use, all in one file entitled `serverless.yml` (or `serverless.json` or `serverless.js`). It looks like this:
|
||||
A **Service** is the Framework's unit of organization. You can think of it as a project file, though you can have multiple services for a single application. It's where you define your Functions, the Events that trigger them, and the Resources your Functions use, all in one file entitled `serverless.yml` (or `serverless.json` or `serverless.js`). It looks like this:
|
||||
|
||||
```yml
|
||||
# serverless.yml
|
||||
@ -75,11 +78,12 @@ functions: # Your "Functions"
|
||||
|
||||
resources: # The "Resources" your "Functions" use. Raw AWS CloudFormation goes in here.
|
||||
```
|
||||
|
||||
When you deploy with the Framework by running `serverless deploy`, everything in `serverless.yml` is deployed at once.
|
||||
|
||||
### Plugins
|
||||
|
||||
You can overwrite or extend the functionality of the Framework using **Plugins**. Every `serverless.yml` can contain a `plugins:` property, which features multiple plugins.
|
||||
You can overwrite or extend the functionality of the Framework using **Plugins**. Every `serverless.yml` can contain a `plugins:` property, which features multiple plugins.
|
||||
|
||||
```yml
|
||||
# serverless.yml
|
||||
|
||||
@ -7,12 +7,14 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/layers)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Layers
|
||||
|
||||
If you are using AWS as a provider, all *layers* inside the service are [AWS Lambda
|
||||
If you are using AWS as a provider, all _layers_ inside the service are [AWS Lambda
|
||||
layers](https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-programming-language-and-share-common-components/).
|
||||
|
||||
## Configuration
|
||||
@ -109,7 +111,6 @@ layers:
|
||||
artifact: layerSource.zip
|
||||
```
|
||||
|
||||
|
||||
## Permissions
|
||||
|
||||
You can make your layers usable by other accounts by setting the `allowedAccounts` property:
|
||||
@ -170,5 +171,5 @@ functions:
|
||||
hello:
|
||||
handler: handler.hello
|
||||
layers:
|
||||
- {Ref: TestLambdaLayer}
|
||||
- { Ref: TestLambdaLayer }
|
||||
```
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/packaging)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Packaging
|
||||
@ -45,12 +47,12 @@ previously excluded files and directories.
|
||||
|
||||
By default, serverless will exclude the following patterns:
|
||||
|
||||
- .git/**
|
||||
- .git/\*\*
|
||||
- .gitignore
|
||||
- .DS_Store
|
||||
- npm-debug.log
|
||||
- .serverless/**
|
||||
- .serverless_plugins/**
|
||||
- .serverless/\*\*
|
||||
- .serverless_plugins/\*\*
|
||||
|
||||
and the serverless configuration file being used (i.e. `serverless.yml`)
|
||||
|
||||
@ -58,7 +60,7 @@ and the serverless configuration file being used (i.e. `serverless.yml`)
|
||||
|
||||
Exclude all node_modules but then re-include a specific modules (in this case node-fetch) using `exclude` exclusively
|
||||
|
||||
``` yml
|
||||
```yml
|
||||
package:
|
||||
exclude:
|
||||
- node_modules/**
|
||||
@ -67,7 +69,7 @@ package:
|
||||
|
||||
Exclude all files but `handler.js` using `exclude` and `include`
|
||||
|
||||
``` yml
|
||||
```yml
|
||||
package:
|
||||
exclude:
|
||||
- src/**
|
||||
@ -90,7 +92,7 @@ Serverless won't zip your service if this is configured and therefore `exclude`
|
||||
|
||||
The artifact option is especially useful in case your development environment allows you to generate a deployable artifact like Maven does for Java.
|
||||
|
||||
### Example
|
||||
#### Service package
|
||||
|
||||
```yml
|
||||
service: my-service
|
||||
@ -98,9 +100,10 @@ package:
|
||||
artifact: path/to/my-artifact.zip
|
||||
```
|
||||
|
||||
You can also use this to package functions individually.
|
||||
#### Individual function packages
|
||||
|
||||
You can also use this to package functions individually:
|
||||
|
||||
### Example
|
||||
```yml
|
||||
service: my-service
|
||||
|
||||
@ -118,6 +121,34 @@ functions:
|
||||
method: get
|
||||
```
|
||||
|
||||
#### Artifacts hosted on S3
|
||||
|
||||
Artifacts can also be fetched from a remote S3 bucket. In this case you just need to provide the S3 object URL as the artifact value. This applies to both, service-wide and function-level artifact setups.
|
||||
|
||||
##### Service package
|
||||
|
||||
```yml
|
||||
service: my-service
|
||||
|
||||
package:
|
||||
artifact: https://s3.amazonaws.com/some-bucket/service-artifact.zip
|
||||
```
|
||||
|
||||
##### Individual function packages
|
||||
|
||||
```yml
|
||||
service: my-service
|
||||
|
||||
package:
|
||||
individually: true
|
||||
|
||||
functions:
|
||||
hello:
|
||||
handler: com.serverless.Handler
|
||||
package:
|
||||
artifact: https://s3.amazonaws.com/some-bucket/function-artifact.zip
|
||||
```
|
||||
|
||||
### Packaging functions separately
|
||||
|
||||
If you want even more controls over your functions for deployment you can configure them to be packaged independently. This allows you more control for optimizing your deployment. To enable individual packaging set `individually` to true in the service or function wide packaging settings.
|
||||
|
||||
@ -7,19 +7,21 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/plugins)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Plugins
|
||||
|
||||
A Plugin is custom Javascript code that creates new or extends existing commands within the Serverless Framework. The Serverless Framework is merely a group of Plugins that are provided in the core. If you or your organization have a specific workflow, install a pre-written Plugin or write a plugin to customize the Framework to your needs. External Plugins are written exactly the same way as the core Plugins.
|
||||
A Plugin is custom Javascript code that creates new or extends existing commands within the Serverless Framework. The Serverless Framework is merely a group of Plugins that are provided in the core. If you or your organization have a specific workflow, install a pre-written Plugin or write a plugin to customize the Framework to your needs. External Plugins are written exactly the same way as the core Plugins.
|
||||
|
||||
- [How to create serverless plugins - Part 1](https://serverless.com/blog/writing-serverless-plugins/)
|
||||
- [How to create serverless plugins - Part 2](https://serverless.com/blog/writing-serverless-plugins-2/)
|
||||
|
||||
## Installing Plugins
|
||||
|
||||
External Plugins are added on a per service basis and are not applied globally. Make sure you are in your Service's root directory, then install the corresponding Plugin with the help of NPM:
|
||||
External Plugins are added on a per service basis and are not applied globally. Make sure you are in your Service's root directory, then install the corresponding Plugin with the help of NPM:
|
||||
|
||||
```
|
||||
npm install --save custom-serverless-plugin
|
||||
@ -33,9 +35,11 @@ We need to tell Serverless that we want to use the plugin inside our service. We
|
||||
plugins:
|
||||
- custom-serverless-plugin
|
||||
```
|
||||
|
||||
The `plugins` section supports two formats:
|
||||
|
||||
Array object:
|
||||
|
||||
```yml
|
||||
plugins:
|
||||
- plugin1
|
||||
@ -43,6 +47,7 @@ plugins:
|
||||
```
|
||||
|
||||
Enhanced plugins object:
|
||||
|
||||
```yml
|
||||
plugins:
|
||||
localPath: './custom_serverless_plugins'
|
||||
@ -63,25 +68,36 @@ custom:
|
||||
|
||||
## Service local plugin
|
||||
|
||||
If you are working on a plugin or have a plugin that is just designed for one project they can be loaded from the local folder. Local plugins can be added in the `plugins` array in `serverless.yml`.
|
||||
If you are working on a plugin or have a plugin that is just designed for one project, it can be loaded from the local `.serverless_plugins` folder at the root of your service. Local plugins can be added in the `plugins` array in `serverless.yml`.
|
||||
|
||||
By default local plugins can be added to the `.serverless_plugins` directory at the root of your service, and in the `plugins` array in `serverless.yml`.
|
||||
```yml
|
||||
plugins:
|
||||
- custom-serverless-plugin
|
||||
```
|
||||
|
||||
Local plugins folder can be changed by enhancing `plugins` object:
|
||||
|
||||
```yml
|
||||
plugins:
|
||||
localPath: './custom_serverless_plugins'
|
||||
modules:
|
||||
- custom-serverless-plugin
|
||||
```
|
||||
The `custom-serverless-plugin` will be loaded from the `custom_serverless_plugins` directory at the root of your service. If the `localPath` is not provided or empty `.serverless_plugins` directory will be taken as the `localPath`.
|
||||
|
||||
The `custom-serverless-plugin` will be loaded from the `custom_serverless_plugins` directory at the root of your service. If the `localPath` is not provided or empty, the `.serverless_plugins` directory will be used.
|
||||
|
||||
The plugin will be loaded based on being named `custom-serverless-plugin.js` or `custom-serverless-plugin\index.js` in the root of `localPath` folder (`.serverless_plugins` by default).
|
||||
|
||||
If you want to load a plugin from a specific directory without affecting other plugins, you can also specify a path relative to the root of your service:
|
||||
|
||||
```yaml
|
||||
plugins:
|
||||
# This plugin will be loaded from the `.serverless_plugins/` or `node_modules/` directories
|
||||
- custom-serverless-plugin
|
||||
# This plugin will be loaded from the `sub/directory/` directory
|
||||
- ./sub/directory/another-custom-plugin
|
||||
```
|
||||
|
||||
### Load Order
|
||||
|
||||
Keep in mind that the order you define your plugins matters. When Serverless loads all the core plugins and then the custom plugins in the order you've defined them.
|
||||
@ -102,15 +118,15 @@ In this case `plugin1` is loaded before `plugin2`.
|
||||
|
||||
#### Plugin
|
||||
|
||||
Code which defines *Commands*, any *Events* within a *Command*, and any *Hooks* assigned to a *Lifecycle Event*.
|
||||
Code which defines _Commands_, any _Events_ within a _Command_, and any _Hooks_ assigned to a _Lifecycle Event_.
|
||||
|
||||
* Command // CLI configuration, commands, subcommands, options
|
||||
* LifecycleEvent(s) // Events that happen sequentially when the command is run
|
||||
* Hook(s) // Code that runs when a Lifecycle Event happens during a Command
|
||||
- Command // CLI configuration, commands, subcommands, options
|
||||
- LifecycleEvent(s) // Events that happen sequentially when the command is run
|
||||
- Hook(s) // Code that runs when a Lifecycle Event happens during a Command
|
||||
|
||||
#### Command
|
||||
|
||||
A CLI *Command* that can be called by a user, e.g. `serverless deploy`. A Command has no logic, but simply defines the CLI configuration (e.g. command, subcommands, parameters) and the *Lifecycle Events* for the command. Every command defines its own lifecycle events.
|
||||
A CLI _Command_ that can be called by a user, e.g. `serverless deploy`. A Command has no logic, but simply defines the CLI configuration (e.g. command, subcommands, parameters) and the _Lifecycle Events_ for the command. Every command defines its own lifecycle events.
|
||||
|
||||
```javascript
|
||||
'use strict';
|
||||
@ -119,10 +135,7 @@ class MyPlugin {
|
||||
constructor() {
|
||||
this.commands = {
|
||||
deploy: {
|
||||
lifecycleEvents: [
|
||||
'resources',
|
||||
'functions'
|
||||
]
|
||||
lifecycleEvents: ['resources', 'functions'],
|
||||
},
|
||||
};
|
||||
}
|
||||
@ -133,7 +146,7 @@ module.exports = MyPlugin;
|
||||
|
||||
#### Lifecycle Events
|
||||
|
||||
Events that fire sequentially during a Command. The above example lists two Events. However, for each Event, an additional `before` and `after` event is created. Therefore, six Events exist in the above example:
|
||||
Events that fire sequentially during a Command. The above example lists two Events. However, for each Event, an additional `before` and `after` event is created. Therefore, six Events exist in the above example:
|
||||
|
||||
- `before:deploy:resources`
|
||||
- `deploy:resources`
|
||||
@ -155,17 +168,14 @@ class Deploy {
|
||||
constructor() {
|
||||
this.commands = {
|
||||
deploy: {
|
||||
lifecycleEvents: [
|
||||
'resources',
|
||||
'functions'
|
||||
]
|
||||
lifecycleEvents: ['resources', 'functions'],
|
||||
},
|
||||
};
|
||||
|
||||
this.hooks = {
|
||||
'before:deploy:resources': this.beforeDeployResources,
|
||||
'deploy:resources': this.deployResources,
|
||||
'after:deploy:functions': this.afterDeployFunctions
|
||||
'after:deploy:functions': this.afterDeployFunctions,
|
||||
};
|
||||
}
|
||||
|
||||
@ -196,20 +206,14 @@ class MyPlugin {
|
||||
constructor() {
|
||||
this.commands = {
|
||||
deploy: {
|
||||
lifecycleEvents: [
|
||||
'resources',
|
||||
'functions'
|
||||
],
|
||||
lifecycleEvents: ['resources', 'functions'],
|
||||
commands: {
|
||||
function: {
|
||||
lifecycleEvents: [
|
||||
'package',
|
||||
'deploy'
|
||||
],
|
||||
lifecycleEvents: ['package', 'deploy'],
|
||||
},
|
||||
},
|
||||
},
|
||||
}
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
@ -226,7 +230,7 @@ Option Shortcuts are passed in with a single dash (`-`) like this: `serverless f
|
||||
|
||||
The `options` object will be passed in as the second parameter to the constructor of your plugin.
|
||||
|
||||
In it, you can optionally add a `shortcut` property, as well as a `required` property. The Framework will return an error if a `required` Option is not included. You can also set a `default` property if your option is not required.
|
||||
In it, you can optionally add a `shortcut` property, as well as a `required` property. The Framework will return an error if a `required` Option is not included. You can also set a `default` property if your option is not required.
|
||||
|
||||
**Note:** At this time, the Serverless Framework does not use parameters.
|
||||
|
||||
@ -240,27 +244,25 @@ class Deploy {
|
||||
|
||||
this.commands = {
|
||||
deploy: {
|
||||
lifecycleEvents: [
|
||||
'functions'
|
||||
],
|
||||
lifecycleEvents: ['functions'],
|
||||
options: {
|
||||
function: {
|
||||
usage: 'Specify the function you want to deploy (e.g. "--function myFunction")',
|
||||
shortcut: 'f',
|
||||
required: true
|
||||
required: true,
|
||||
},
|
||||
stage: {
|
||||
usage: 'Specify the stage you want to deploy to. (e.g. "--stage prod")',
|
||||
shortcut: 's',
|
||||
default: 'dev'
|
||||
}
|
||||
}
|
||||
default: 'dev',
|
||||
},
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
this.hooks = {
|
||||
'deploy:functions': this.deployFunction.bind(this)
|
||||
}
|
||||
'deploy:functions': this.deployFunction.bind(this),
|
||||
};
|
||||
}
|
||||
|
||||
deployFunction() {
|
||||
@ -292,21 +294,19 @@ class ProviderDeploy {
|
||||
|
||||
this.commands = {
|
||||
deploy: {
|
||||
lifecycleEvents: [
|
||||
'functions'
|
||||
],
|
||||
lifecycleEvents: ['functions'],
|
||||
options: {
|
||||
function: {
|
||||
usage: 'Specify the function you want to deploy (e.g. "--function myFunction")',
|
||||
required: true
|
||||
}
|
||||
}
|
||||
required: true,
|
||||
},
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
this.hooks = {
|
||||
'deploy:functions': this.deployFunction.bind(this)
|
||||
}
|
||||
'deploy:functions': this.deployFunction.bind(this),
|
||||
};
|
||||
}
|
||||
|
||||
deployFunction() {
|
||||
@ -333,15 +333,13 @@ class MyPlugin {
|
||||
|
||||
this.commands = {
|
||||
log: {
|
||||
lifecycleEvents: [
|
||||
'serverless'
|
||||
],
|
||||
lifecycleEvents: ['serverless'],
|
||||
},
|
||||
};
|
||||
|
||||
this.hooks = {
|
||||
'log:serverless': this.logServerless.bind(this)
|
||||
}
|
||||
'log:serverless': this.logServerless.bind(this),
|
||||
};
|
||||
}
|
||||
|
||||
logServerless() {
|
||||
|
||||
@ -11,8 +11,8 @@ layout: Doc
|
||||
## Pre-requisites
|
||||
|
||||
1. Node.js `v6.5.0` or later.
|
||||
2. Serverless CLI `v1.9.0` or later. You can run
|
||||
`npm install -g serverless` to install it.
|
||||
2. Serverless CLI `v1.9.0` or later. You can run
|
||||
`npm install -g serverless` to install it.
|
||||
3. An AWS account. If you don't already have one, you can sign up for a [free trial](https://aws.amazon.com/s/dm/optimization/server-side-test/free-tier/free_np/) that includes 1 million free Lambda requests per month.
|
||||
4. **Set-up your [Provider Credentials](./credentials.md)** -> [Watch the video on setting up credentials](https://www.youtube.com/watch?v=KngM5bfpttA)
|
||||
|
||||
@ -40,34 +40,35 @@ $ cd my-service
|
||||
|
||||
1. **Deploy the Service**
|
||||
|
||||
Use this when you have made changes to your Functions, Events or Resources in `serverless.yml` or you simply want to deploy all changes within your Service at the same time.
|
||||
|
||||
```bash
|
||||
serverless deploy -v
|
||||
```
|
||||
Use this when you have made changes to your Functions, Events or Resources in `serverless.yml` or you simply want to deploy all changes within your Service at the same time.
|
||||
|
||||
```bash
|
||||
serverless deploy -v
|
||||
```
|
||||
|
||||
2. **Deploy the Function**
|
||||
|
||||
Use this to quickly upload and overwrite your function code, allowing you to develop faster.
|
||||
|
||||
```bash
|
||||
serverless deploy function -f hello
|
||||
```
|
||||
Use this to quickly upload and overwrite your function code, allowing you to develop faster.
|
||||
|
||||
```bash
|
||||
serverless deploy function -f hello
|
||||
```
|
||||
|
||||
3. **Invoke the Function**
|
||||
|
||||
Invokes a Function and returns logs.
|
||||
|
||||
```bash
|
||||
serverless invoke -f hello -l
|
||||
```
|
||||
Invokes a Function and returns logs.
|
||||
|
||||
```bash
|
||||
serverless invoke -f hello -l
|
||||
```
|
||||
|
||||
4. **Fetch the Function Logs**
|
||||
|
||||
Open up a separate tab in your console, set your [Provider Credentials](./credentials.md) and stream all logs for a specific Function using this command.
|
||||
```bash
|
||||
serverless logs -f hello -t
|
||||
```
|
||||
Open up a separate tab in your console, set your [Provider Credentials](./credentials.md) and stream all logs for a specific Function using this command.
|
||||
|
||||
```bash
|
||||
serverless logs -f hello -t
|
||||
```
|
||||
|
||||
## Cleanup
|
||||
|
||||
|
||||
@ -7,20 +7,22 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/resources)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# AWS - Resources
|
||||
|
||||
If you are using AWS as a provider for your Service, all [*Resources*](./intro.md#resources) are other AWS infrastructure resources which the AWS Lambda functions in your [*Service*](./intro.md#services) depend on, like AWS DynamoDB or AWS S3.
|
||||
If you are using AWS as a provider for your Service, all [_Resources_](./intro.md#resources) are other AWS infrastructure resources which the AWS Lambda functions in your [_Service_](./intro.md#services) depend on, like AWS DynamoDB or AWS S3.
|
||||
|
||||
Using the Serverless Framework, you can define the infrastructure resources you need in `serverless.yml`, and easily deploy them.
|
||||
|
||||
## Configuration
|
||||
|
||||
Every stage you deploy to with `serverless.yml` using the `aws` provider is a single AWS CloudFormation stack. This is where your AWS Lambda functions and their event configurations are defined and it's how they are deployed. When you add `resources` those resources are added into your CloudFormation stack upon `serverless deploy`.
|
||||
Every stage you deploy to with `serverless.yml` using the `aws` provider is a single AWS CloudFormation stack. This is where your AWS Lambda functions and their event configurations are defined and it's how they are deployed. When you add `resources` those resources are added into your CloudFormation stack upon `serverless deploy`.
|
||||
|
||||
Define your AWS resources in a property titled `resources`. What goes in this property is raw CloudFormation template syntax, in YAML, like this:
|
||||
Define your AWS resources in a property titled `resources`. What goes in this property is raw CloudFormation template syntax, in YAML, like this:
|
||||
|
||||
```yml
|
||||
# serverless.yml
|
||||
@ -29,7 +31,7 @@ service: usersCrud
|
||||
provider: aws
|
||||
functions:
|
||||
|
||||
resources: # CloudFormation template syntax
|
||||
resources: # CloudFormation template syntax
|
||||
Resources:
|
||||
usersTable:
|
||||
Type: AWS::DynamoDB::Table
|
||||
@ -46,7 +48,7 @@ resources: # CloudFormation template syntax
|
||||
WriteCapacityUnits: 1
|
||||
```
|
||||
|
||||
You can overwrite/attach any kind of resource to your CloudFormation stack. You can add `Resources`, `Outputs` or even overwrite the `Description`. You can also use [Serverless Variables](./variables.md) for sensitive data or reusable configuration in your resources templates. Please be cautious as overwriting existing parts of your CloudFormation stack might introduce unexpected behavior.
|
||||
You can overwrite/attach any kind of resource to your CloudFormation stack. You can add `Resources`, `Outputs` or even overwrite the `Description`. You can also use [Serverless Variables](./variables.md) for sensitive data or reusable configuration in your resources templates. Please be cautious as overwriting existing parts of your CloudFormation stack might introduce unexpected behavior.
|
||||
|
||||
## AWS CloudFormation Resource Reference
|
||||
|
||||
@ -54,10 +56,10 @@ To have consistent naming in the CloudFormation Templates that get deployed we u
|
||||
|
||||
`{Function Name}{Cloud Formation Resource Type}{Resource Name}{SequentialID, instanceId or Random String}`
|
||||
|
||||
* `Function Name` - This is optional for Resources that should be recreated when the function name gets changed. Those resources are also called *function bound*
|
||||
* `Cloud Formation Resource Type` - E.g., S3Bucket
|
||||
* `Resource Name` - An identifier for the specific resource, e.g. for an S3 Bucket the configured bucket name.
|
||||
* `SequentialID, instanceId or Random String` - For a few resources we need to add an optional sequential id, the Serverless instanceId (accessible via `${sls:instanceId}`) or a random string to identify them
|
||||
- `Function Name` - This is optional for Resources that should be recreated when the function name gets changed. Those resources are also called _function bound_
|
||||
- `Cloud Formation Resource Type` - E.g., S3Bucket
|
||||
- `Resource Name` - An identifier for the specific resource, e.g. for an S3 Bucket the configured bucket name.
|
||||
- `SequentialID, instanceId or Random String` - For a few resources we need to add an optional sequential id, the Serverless instanceId (accessible via `${sls:instanceId}`) or a random string to identify them
|
||||
|
||||
All resource names that are deployed by Serverless have to follow this naming scheme. The only exception (for backwards compatibility reasons) is the S3 Bucket that is used to upload artifacts so they can be deployed to your function.
|
||||
|
||||
@ -66,30 +68,30 @@ We're also using the term `normalizedName` or similar terms in this guide. This
|
||||
_Tip:_
|
||||
If you are unsure how a resource is named, that you want to reference from your custom resources, you can issue a `serverless package`. This will create the CloudFormation template for your service in the `.serverless` folder (it is named `cloudformation-template-update-stack.json`). Just open the file and check for the generated resource name.
|
||||
|
||||
| AWS Resource | Name Template | Example |
|
||||
|--- |--- | --- |
|
||||
| S3::Bucket | S3Bucket{normalizedBucketName} | S3BucketMybucket |
|
||||
|IAM::Role | IamRoleLambdaExecution | IamRoleLambdaExecution |
|
||||
|Lambda::Function | {normalizedFunctionName}LambdaFunction | HelloLambdaFunction |
|
||||
|Lambda::Version | {normalizedFunctionName}LambdaVersion{sha256} | HelloLambdaVersionr3pgoTvv1xT4E4NiCL6JG02fl6vIyi7OS1aW0FwAI |
|
||||
|Logs::LogGroup | {normalizedFunctionName}LogGroup | HelloLogGroup |
|
||||
|Lambda::Permission | <ul><li>**Schedule**: {normalizedFunctionName}LambdaPermissionEventsRuleSchedule{index}</li><li>**CloudWatch Event**: {normalizedFunctionName}LambdaPermissionEventsRuleCloudWatchEvent{index}</li><li>**CloudWatch Log**: {normalizedFunctionName}LambdaPermissionLogsSubscriptionFilterCloudWatchLog{index}</li><li>**IoT**: {normalizedFunctionName}LambdaPermissionIotTopicRule{index} </li><li>**S3**: {normalizedFunctionName}LambdaPermission{normalizedBucketName}S3</li><li>**APIG**: {normalizedFunctionName}LambdaPermissionApiGateway</li><li>**SNS**: {normalizedFunctionName}LambdaPermission{normalizedTopicName}SNS</li><li>**Alexa Skill**: {normalizedFunctionName}LambdaPermissionAlexaSkill</li><li>**Alexa Smart Home**: {normalizedFunctionName}LambdaPermissionAlexaSmartHome{index}</li><li>**Cognito User Pool Trigger Source**: {normalizedFunctionName}LambdaPermissionCognitoUserPool{normalizedPoolId}TriggerSource{triggerSource}</li> </ul> | <ul><li>**Schedule**: HelloLambdaPermissionEventsRuleSchedule1</li><li>**CloudWatch Event**: HelloLambdaPermissionEventsRuleCloudWatchEvent1</li><li>**CloudWatch Log**: HelloLambdaPermissionLogsSubscriptionFilterCloudWatchLog1</li><li>**IoT**: HelloLambdaPermissionIotTopicRule1 </li><li>**S3**: HelloLambdaPermissionBucketS3</li><li>**APIG**: HelloLambdaPermissionApiGateway</li><li>**SNS**: HelloLambdaPermissionTopicSNS</li><li>**Alexa Skill**: HelloLambdaPermissionAlexaSkill</li><li>**Alexa Smart Home**: HelloLambdaPermissionAlexaSmartHome1</li><li>**Cognito User Pool Trigger Source**: HelloLambdaPermissionCognitoUserPoolMyPoolTriggerSourceCustomMessage</li> </ul>|
|
||||
|Events::Rule | <ul><li>**Schedule**: {normalizedFunctionName}EventsRuleSchedule{SequentialID}</li><li>**CloudWatch Event**: {normalizedFunctionName}EventsRuleCloudWatchEvent{SequentialID}</li> </ul> | <ul><li>**Schedule**: HelloEventsRuleSchedule1</li><li>**CloudWatch Event**: HelloEventsRuleCloudWatchEvent1</li></ul> |
|
||||
|AWS::Logs::SubscriptionFilter | {normalizedFunctionName}LogsSubscriptionFilterCloudWatchLog{SequentialID} | HelloLogsSubscriptionFilterCloudWatchLog1 |
|
||||
|AWS::IoT::TopicRule | {normalizedFunctionName}IotTopicRule{SequentialID} | HelloIotTopicRule1 |
|
||||
|ApiGateway::RestApi | ApiGatewayRestApi | ApiGatewayRestApi |
|
||||
|ApiGateway::Resource | ApiGatewayResource{normalizedPath} | ApiGatewayResourceUsers |
|
||||
|ApiGateway::Method | ApiGatewayMethod{normalizedPath}{normalizedMethod} | ApiGatewayMethodUsersGet |
|
||||
|ApiGateway::Authorizer | {normalizedFunctionName}ApiGatewayAuthorizer | HelloApiGatewayAuthorizer |
|
||||
|ApiGateway::Deployment | ApiGatewayDeployment{instanceId} | ApiGatewayDeployment12356789 |
|
||||
|ApiGateway::ApiKey | ApiGatewayApiKey{OptionalNormalizedName}{SequentialID} | ApiGatewayApiKeyFree1 |
|
||||
|ApiGateway::UsagePlan | ApiGatewayUsagePlan{OptionalNormalizedName} | ApiGatewayUsagePlanFree |
|
||||
|ApiGateway::UsagePlanKey | ApiGatewayUsagePlanKey{OptionalNormalizedName}{SequentialID} | ApiGatewayUsagePlanKeyFree1 |
|
||||
|ApiGateway::Stage | ApiGatewayStage | ApiGatewayStage |
|
||||
|SNS::Topic | SNSTopic{normalizedTopicName} | SNSTopicSometopic |
|
||||
|SNS::Subscription | {normalizedFunctionName}SnsSubscription{normalizedTopicName} | HelloSnsSubscriptionSomeTopic |
|
||||
|AWS::Lambda::EventSourceMapping | <ul><li>**DynamoDB:** {normalizedFunctionName}EventSourceMappingDynamodb{tableName}</li><li>**Kinesis:** {normalizedFunctionName}EventSourceMappingKinesis{streamName}</li></ul> | <ul><li>**DynamoDB:** HelloLambdaEventSourceMappingDynamodbUsers</li><li>**Kinesis:** HelloLambdaEventSourceMappingKinesisMystream</li></ul> |
|
||||
|Cognito::UserPool | CognitoUserPool{normalizedPoolId} | CognitoUserPoolPoolId |
|
||||
| AWS Resource | Name Template | Example |
|
||||
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| S3::Bucket | S3Bucket{normalizedBucketName} | S3BucketMybucket |
|
||||
| IAM::Role | IamRoleLambdaExecution | IamRoleLambdaExecution |
|
||||
| Lambda::Function | {normalizedFunctionName}LambdaFunction | HelloLambdaFunction |
|
||||
| Lambda::Version | {normalizedFunctionName}LambdaVersion{sha256} | HelloLambdaVersionr3pgoTvv1xT4E4NiCL6JG02fl6vIyi7OS1aW0FwAI |
|
||||
| Logs::LogGroup | {normalizedFunctionName}LogGroup | HelloLogGroup |
|
||||
| Lambda::Permission | <ul><li>**Schedule**: {normalizedFunctionName}LambdaPermissionEventsRuleSchedule{index}</li><li>**CloudWatch Event**: {normalizedFunctionName}LambdaPermissionEventsRuleCloudWatchEvent{index}</li><li>**CloudWatch Log**: {normalizedFunctionName}LambdaPermissionLogsSubscriptionFilterCloudWatchLog{index}</li><li>**IoT**: {normalizedFunctionName}LambdaPermissionIotTopicRule{index} </li><li>**S3**: {normalizedFunctionName}LambdaPermission{normalizedBucketName}S3</li><li>**APIG**: {normalizedFunctionName}LambdaPermissionApiGateway</li><li>**SNS**: {normalizedFunctionName}LambdaPermission{normalizedTopicName}SNS</li><li>**Alexa Skill**: {normalizedFunctionName}LambdaPermissionAlexaSkill</li><li>**Alexa Smart Home**: {normalizedFunctionName}LambdaPermissionAlexaSmartHome{index}</li><li>**Cognito User Pool Trigger Source**: {normalizedFunctionName}LambdaPermissionCognitoUserPool{normalizedPoolId}TriggerSource{triggerSource}</li> </ul> | <ul><li>**Schedule**: HelloLambdaPermissionEventsRuleSchedule1</li><li>**CloudWatch Event**: HelloLambdaPermissionEventsRuleCloudWatchEvent1</li><li>**CloudWatch Log**: HelloLambdaPermissionLogsSubscriptionFilterCloudWatchLog1</li><li>**IoT**: HelloLambdaPermissionIotTopicRule1 </li><li>**S3**: HelloLambdaPermissionBucketS3</li><li>**APIG**: HelloLambdaPermissionApiGateway</li><li>**SNS**: HelloLambdaPermissionTopicSNS</li><li>**Alexa Skill**: HelloLambdaPermissionAlexaSkill</li><li>**Alexa Smart Home**: HelloLambdaPermissionAlexaSmartHome1</li><li>**Cognito User Pool Trigger Source**: HelloLambdaPermissionCognitoUserPoolMyPoolTriggerSourceCustomMessage</li> </ul> |
|
||||
| Events::Rule | <ul><li>**Schedule**: {normalizedFunctionName}EventsRuleSchedule{SequentialID}</li><li>**CloudWatch Event**: {normalizedFunctionName}EventsRuleCloudWatchEvent{SequentialID}</li> </ul> | <ul><li>**Schedule**: HelloEventsRuleSchedule1</li><li>**CloudWatch Event**: HelloEventsRuleCloudWatchEvent1</li></ul> |
|
||||
| AWS::Logs::SubscriptionFilter | {normalizedFunctionName}LogsSubscriptionFilterCloudWatchLog{SequentialID} | HelloLogsSubscriptionFilterCloudWatchLog1 |
|
||||
| AWS::IoT::TopicRule | {normalizedFunctionName}IotTopicRule{SequentialID} | HelloIotTopicRule1 |
|
||||
| ApiGateway::RestApi | ApiGatewayRestApi | ApiGatewayRestApi |
|
||||
| ApiGateway::Resource | ApiGatewayResource{normalizedPath} | ApiGatewayResourceUsers |
|
||||
| ApiGateway::Method | ApiGatewayMethod{normalizedPath}{normalizedMethod} | ApiGatewayMethodUsersGet |
|
||||
| ApiGateway::Authorizer | {normalizedFunctionName}ApiGatewayAuthorizer | HelloApiGatewayAuthorizer |
|
||||
| ApiGateway::Deployment | ApiGatewayDeployment{instanceId} | ApiGatewayDeployment12356789 |
|
||||
| ApiGateway::ApiKey | ApiGatewayApiKey{OptionalNormalizedName}{SequentialID} | ApiGatewayApiKeyFree1 |
|
||||
| ApiGateway::UsagePlan | ApiGatewayUsagePlan{OptionalNormalizedName} | ApiGatewayUsagePlanFree |
|
||||
| ApiGateway::UsagePlanKey | ApiGatewayUsagePlanKey{OptionalNormalizedName}{SequentialID} | ApiGatewayUsagePlanKeyFree1 |
|
||||
| ApiGateway::Stage | ApiGatewayStage | ApiGatewayStage |
|
||||
| SNS::Topic | SNSTopic{normalizedTopicName} | SNSTopicSometopic |
|
||||
| SNS::Subscription | {normalizedFunctionName}SnsSubscription{normalizedTopicName} | HelloSnsSubscriptionSomeTopic |
|
||||
| AWS::Lambda::EventSourceMapping | <ul><li>**DynamoDB:** {normalizedFunctionName}EventSourceMappingDynamodb{tableName}</li><li>**Kinesis:** {normalizedFunctionName}EventSourceMappingKinesis{streamName}</li></ul> | <ul><li>**DynamoDB:** HelloLambdaEventSourceMappingDynamodbUsers</li><li>**Kinesis:** HelloLambdaEventSourceMappingKinesisMystream</li></ul> |
|
||||
| Cognito::UserPool | CognitoUserPool{normalizedPoolId} | CognitoUserPoolPoolId |
|
||||
|
||||
## Override AWS CloudFormation Resource
|
||||
|
||||
@ -117,5 +119,5 @@ resources:
|
||||
WriteDashPostLogGroup:
|
||||
Type: AWS::Logs::LogGroup
|
||||
Properties:
|
||||
RetentionInDays: "30"
|
||||
RetentionInDays: '30'
|
||||
```
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Serverless.yml Reference
|
||||
@ -21,11 +23,11 @@ service:
|
||||
name: myService
|
||||
awsKmsKeyArn: arn:aws:kms:us-east-1:XXXXXX:key/some-hash # Optional KMS key arn which will be used for encryption for all functions
|
||||
|
||||
frameworkVersion: ">=1.0.0 <2.0.0"
|
||||
frameworkVersion: '>=1.0.0 <2.0.0'
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs8.10
|
||||
runtime: nodejs10.x
|
||||
stage: ${opt:stage, 'dev'} # Set the default stage used. Default is dev
|
||||
region: ${opt:region, 'us-east-1'} # Overwrite the default region used. Default is us-east-1
|
||||
stackName: custom-stack-name # Use a custom name for the CloudFormation stack
|
||||
@ -60,6 +62,7 @@ provider:
|
||||
restApiResources: # List of existing resources that were created in the REST API. This is required or the stack will be conflicted
|
||||
'/users': xxxxxxxxxx
|
||||
'/users/create': xxxxxxxxxx
|
||||
websocketApiId: # Websocket API resource ID. Default is generated by the framewok
|
||||
apiKeySourceType: HEADER # Source of API key for usage plan. HEADER or AUTHORIZER.
|
||||
minimumCompressionSize: 1024 # Compress response when larger than specified size in bytes (must be between 0 and 10485760)
|
||||
description: Some Description # Optional description for the API Gateway stage deployment
|
||||
@ -88,12 +91,12 @@ provider:
|
||||
- Ref: ServerlessDeploymentBucket
|
||||
stackPolicy: # Optional CF stack policy. The example below allows updates to all resources except deleting/replacing EC2 instances (use with caution!)
|
||||
- Effect: Allow
|
||||
Principal: "*"
|
||||
Action: "Update:*"
|
||||
Resource: "*"
|
||||
Principal: '*'
|
||||
Action: 'Update:*'
|
||||
Resource: '*'
|
||||
- Effect: Deny
|
||||
Principal: "*"
|
||||
Resource: "*"
|
||||
Principal: '*'
|
||||
Resource: '*'
|
||||
Action:
|
||||
- Update:Replace
|
||||
- Update:Delete
|
||||
@ -112,14 +115,14 @@ provider:
|
||||
- 'arn:aws:sns:us-east-1:XXXXXX:mytopic'
|
||||
resourcePolicy:
|
||||
- Effect: Allow
|
||||
Principal: "*"
|
||||
Principal: '*'
|
||||
Action: execute-api:Invoke
|
||||
Resource:
|
||||
- execute-api:/*/*/*
|
||||
Condition:
|
||||
IpAddress:
|
||||
aws:SourceIp:
|
||||
- "123.123.123.123"
|
||||
- '123.123.123.123'
|
||||
tags: # Optional service wide function tags
|
||||
foo: bar
|
||||
baz: qux
|
||||
@ -128,6 +131,7 @@ provider:
|
||||
lambda: true # Optional, can be true (true equals 'Active'), 'Active' or 'PassThrough'
|
||||
logs:
|
||||
restApi: true # Optional configuration which specifies if API Gateway logs are used
|
||||
websocket: true # Optional configuration which specifies if Websockets logs are used
|
||||
|
||||
package: # Optional deployment packaging configuration
|
||||
include: # Specify the directories and files which should be included in the deployment package
|
||||
@ -140,7 +144,6 @@ package: # Optional deployment packaging configuration
|
||||
artifact: path/to/my-artifact.zip # Own package that should be used. You must provide this file.
|
||||
individually: true # Enables individual packaging for each function. If true you must provide package for each function. Defaults to false
|
||||
|
||||
|
||||
functions:
|
||||
usersCreate: # A Function
|
||||
handler: users.create # The file and module for this specific function.
|
||||
@ -148,7 +151,7 @@ functions:
|
||||
description: My function # The description of your function.
|
||||
memorySize: 512 # memorySize for this specific function.
|
||||
reservedConcurrency: 5 # optional, reserved concurrency limit for this function. By default, AWS uses account concurrency limit
|
||||
runtime: nodejs6.10 # Runtime for this specific function. Overrides the default which is set on the provider level
|
||||
runtime: nodejs10.x # Runtime for this specific function. Overrides the default which is set on the provider level
|
||||
timeout: 10 # Timeout for this specific function. Overrides the default set above.
|
||||
role: arn:aws:iam::XXXXXX:role/role # IAM role which will be used for this function
|
||||
onError: arn:aws:sns:us-east-1:XXXXXX:sns-topic # Optional SNS topic / SQS arn (Ref, Fn::GetAtt and Fn::ImportValue are supported as well) which will be used for the DeadLetterConfig
|
||||
@ -184,7 +187,7 @@ functions:
|
||||
private: true # Requires clients to add API keys values in the `x-api-key` header of their request
|
||||
authorizer: # An AWS API Gateway custom authorizer function
|
||||
name: authorizerFunc # The name of the authorizer function (must be in this service)
|
||||
arn: xxx:xxx:Lambda-Name # Can be used instead of name to reference a function outside of service
|
||||
arn: xxx:xxx:Lambda-Name # Can be used instead of name to reference a function outside of service
|
||||
resultTtlInSeconds: 0
|
||||
identitySource: method.request.header.Authorization
|
||||
identityValidationExpression: someRegex
|
||||
@ -245,9 +248,9 @@ functions:
|
||||
- cloudwatchEvent:
|
||||
event:
|
||||
source:
|
||||
- "aws.ec2"
|
||||
- 'aws.ec2'
|
||||
detail-type:
|
||||
- "EC2 Instance State-change Notification"
|
||||
- 'EC2 Instance State-change Notification'
|
||||
detail:
|
||||
state:
|
||||
- pending
|
||||
@ -268,6 +271,12 @@ functions:
|
||||
- cognitoUserPool:
|
||||
pool: MyUserPool
|
||||
trigger: PreSignUp
|
||||
- alb:
|
||||
listenerArn: arn:aws:elasticloadbalancing:us-east-1:12345:listener/app/my-load-balancer/50dc6c495c0c9188/
|
||||
priority: 1
|
||||
conditions:
|
||||
host: example.com
|
||||
path: /hello
|
||||
|
||||
layers:
|
||||
hello: # A Lambda layer
|
||||
@ -302,7 +311,7 @@ resources:
|
||||
UsersTableArn:
|
||||
Description: The ARN for the User's Table
|
||||
Value:
|
||||
"Fn::GetAtt": [ usersTable, Arn ]
|
||||
'Fn::GetAtt': [usersTable, Arn]
|
||||
Export:
|
||||
Name: ${self:service}:${opt:stage}:UsersTableArn # see Fn::ImportValue to use in other services and http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html for documentation on use.
|
||||
```
|
||||
|
||||
@ -7,25 +7,27 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/services)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Services
|
||||
|
||||
A `service` is like a project. It's where you define your AWS Lambda Functions, the `events` that trigger them and any AWS infrastructure `resources` they require, all in a file called `serverless.yml`.
|
||||
A `service` is like a project. It's where you define your AWS Lambda Functions, the `events` that trigger them and any AWS infrastructure `resources` they require, all in a file called `serverless.yml`.
|
||||
|
||||
To get started building your first Serverless Framework project, create a `service`.
|
||||
|
||||
## Organization
|
||||
|
||||
In the beginning of an application, many people use a single Service to define all of the Functions, Events and Resources for that project. This is what we recommend in the beginning.
|
||||
In the beginning of an application, many people use a single Service to define all of the Functions, Events and Resources for that project. This is what we recommend in the beginning.
|
||||
|
||||
```bash
|
||||
myService/
|
||||
serverless.yml # Contains all functions and infrastructure resources
|
||||
```
|
||||
|
||||
However, as your application grows, you can break it out into multiple services. A lot of people organize their services by workflows or data models, and group the functions related to those workflows and data models together in the service.
|
||||
However, as your application grows, you can break it out into multiple services. A lot of people organize their services by workflows or data models, and group the functions related to those workflows and data models together in the service.
|
||||
|
||||
```bash
|
||||
users/
|
||||
@ -35,13 +37,12 @@ posts/
|
||||
comments/
|
||||
serverless.yml # Contains 4 functions that do Comments CRUD operations and the Comments database
|
||||
```
|
||||
This makes sense since related functions usually use common infrastructure resources, and you want to keep those functions and resources together as a single unit of deployment, for better organization and separation of concerns.
|
||||
|
||||
**Note:** Currently, every service will create a separate REST API on AWS API Gateway. Due to a limitation with AWS API Gateway, you can only have a custom domain per one REST API. If you plan on making a large REST API, please make note of this limitation. Also, [a fix is in the works](https://github.com/serverless/serverless/issues/3078) and is a top priority.
|
||||
This makes sense since related functions usually use common infrastructure resources, and you want to keep those functions and resources together as a single unit of deployment, for better organization and separation of concerns.
|
||||
|
||||
## Creation
|
||||
|
||||
To create a service, use the `create` command. You must also pass in a runtime (e.g., node.js, python etc.) you would like to write the service in. You can also pass in a path to create a directory and auto-name your service:
|
||||
To create a service, use the `create` command. You must also pass in a runtime (e.g., node.js, python etc.) you would like to write the service in. You can also pass in a path to create a directory and auto-name your service:
|
||||
|
||||
```bash
|
||||
# Create service with nodeJS template in the folder ./myService
|
||||
@ -50,32 +51,33 @@ serverless create --template aws-nodejs --path myService
|
||||
|
||||
Here are the available templates for AWS Lambda:
|
||||
|
||||
* aws-clojurescript-gradle
|
||||
* aws-clojure-gradle
|
||||
* aws-nodejs
|
||||
* aws-nodejs-typescript
|
||||
* aws-alexa-typescript
|
||||
* aws-nodejs-ecma-script
|
||||
* aws-python
|
||||
* aws-python3
|
||||
* aws-ruby
|
||||
* aws-provided
|
||||
* aws-kotlin-jvm-maven
|
||||
* aws-kotlin-nodejs-gradle
|
||||
* aws-groovy-gradle
|
||||
* aws-java-gradle
|
||||
* aws-java-maven
|
||||
* aws-scala-sbt
|
||||
* aws-csharp
|
||||
* aws-fsharp
|
||||
* aws-go
|
||||
* aws-go-dep
|
||||
- aws-clojurescript-gradle
|
||||
- aws-clojure-gradle
|
||||
- aws-nodejs
|
||||
- aws-nodejs-typescript
|
||||
- aws-alexa-typescript
|
||||
- aws-nodejs-ecma-script
|
||||
- aws-python
|
||||
- aws-python3
|
||||
- aws-ruby
|
||||
- aws-provided
|
||||
- aws-kotlin-jvm-maven
|
||||
- aws-kotlin-nodejs-gradle
|
||||
- aws-groovy-gradle
|
||||
- aws-java-gradle
|
||||
- aws-java-maven
|
||||
- aws-scala-sbt
|
||||
- aws-csharp
|
||||
- aws-fsharp
|
||||
- aws-go
|
||||
- aws-go-dep
|
||||
|
||||
Check out the [create command docs](../cli-reference/create) for all the details and options.
|
||||
|
||||
## Contents
|
||||
|
||||
You'll see the following files in your working directory:
|
||||
|
||||
- `serverless.yml`
|
||||
- `handler.js`
|
||||
|
||||
@ -83,14 +85,14 @@ You'll see the following files in your working directory:
|
||||
|
||||
Each `service` configuration is managed in the `serverless.yml` file. The main responsibilities of this file are:
|
||||
|
||||
- Declare a Serverless service
|
||||
- Define one or more functions in the service
|
||||
- Define the provider the service will be deployed to (and the runtime if provided)
|
||||
- Define any custom plugins to be used
|
||||
- Define events that trigger each function to execute (e.g. HTTP requests)
|
||||
- Define a set of resources (e.g. 1 DynamoDB table) required by the functions in this service
|
||||
- Allow events listed in the `events` section to automatically create the resources required for the event upon deployment
|
||||
- Allow flexible configuration using Serverless Variables
|
||||
- Declare a Serverless service
|
||||
- Define one or more functions in the service
|
||||
- Define the provider the service will be deployed to (and the runtime if provided)
|
||||
- Define any custom plugins to be used
|
||||
- Define events that trigger each function to execute (e.g. HTTP requests)
|
||||
- Define a set of resources (e.g. 1 DynamoDB table) required by the functions in this service
|
||||
- Allow events listed in the `events` section to automatically create the resources required for the event upon deployment
|
||||
- Allow flexible configuration using Serverless Variables
|
||||
|
||||
You can see the name of the service, the provider configuration and the first function inside the `functions` definition which points to the `handler.js` file. Any further service configuration will be done in this file.
|
||||
|
||||
@ -101,7 +103,7 @@ service: users
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
stage: dev # Set the default stage used. Default is dev
|
||||
region: us-east-1 # Overwrite the default region used. Default is us-east-1
|
||||
stackName: my-custom-stack-name-${self:provider.stage} # Overwrite default CloudFormation stack name. Default is ${self:service}-${self:provider.stage}
|
||||
@ -117,18 +119,18 @@ provider:
|
||||
deploymentPrefix: serverless # Overwrite the default S3 prefix under which deployed artifacts should be stored. Default is serverless
|
||||
versionFunctions: false # Optional function versioning
|
||||
stackTags: # Optional CF stack tags
|
||||
key: value
|
||||
key: value
|
||||
stackPolicy: # Optional CF stack policy. The example below allows updates to all resources except deleting/replacing EC2 instances (use with caution!)
|
||||
- Effect: Allow
|
||||
Principal: "*"
|
||||
Action: "Update:*"
|
||||
Resource: "*"
|
||||
Principal: '*'
|
||||
Action: 'Update:*'
|
||||
Resource: '*'
|
||||
- Effect: Deny
|
||||
Principal: "*"
|
||||
Principal: '*'
|
||||
Action:
|
||||
- Update:Replace
|
||||
- Update:Delete
|
||||
Resource: "*"
|
||||
Resource: '*'
|
||||
Condition:
|
||||
StringEquals:
|
||||
ResourceType:
|
||||
@ -141,7 +143,7 @@ functions:
|
||||
- http: post users/create
|
||||
usersDelete: # A Function
|
||||
handler: users.delete
|
||||
events: # The Events that trigger this Function
|
||||
events: # The Events that trigger this Function
|
||||
- http: delete users/delete
|
||||
|
||||
# The "Resources" your "Functions" use. Raw AWS CloudFormation goes in here.
|
||||
@ -196,7 +198,7 @@ Deployment defaults to `dev` stage and `us-east-1` region on AWS, unless you spe
|
||||
serverless deploy --stage prod --region us-east-1
|
||||
```
|
||||
|
||||
Check out the [deployment guide](https://serverless.com/framework/docs/providers/aws/guide/deploying/) to learn more about deployments and how they work. Or, check out the [deploy command docs](../cli-reference/deploy) for all the details and options.
|
||||
Check out the [deployment guide](https://serverless.com/framework/docs/providers/aws/guide/deploying/) to learn more about deployments and how they work. Or, check out the [deploy command docs](../cli-reference/deploy) for all the details and options.
|
||||
|
||||
## Removal
|
||||
|
||||
@ -231,7 +233,7 @@ service: users
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
memorySize: 512
|
||||
|
||||
…
|
||||
@ -248,7 +250,7 @@ service: users
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
memorySize: 512
|
||||
|
||||
…
|
||||
@ -268,6 +270,7 @@ npm install serverless --save-dev
|
||||
To execute the locally installed Serverless executable you have to reference the binary out of the node modules directory.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
node ./node_modules/serverless/bin/serverless deploy
|
||||
```
|
||||
|
||||
@ -7,22 +7,24 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/testing)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Testing
|
||||
|
||||
While the Serverless Architecture introduces a lot of simplicity when it comes to serving business logic, some of its characteristics present challenges for testing. They are:
|
||||
While the Serverless Architecture introduces a lot of simplicity when it comes to serving business logic, some of its characteristics present challenges for testing. They are:
|
||||
|
||||
* The Serverless Architecture is an integration of separate, distributed services, which must be tested both independently, and together.
|
||||
* The Serverless Architecture is dependent on internet/cloud services, which are hard to emulate locally.
|
||||
* The Serverless Architecture can feature event-driven, asynchronous workflows, which are hard to emulate entirely.
|
||||
- The Serverless Architecture is an integration of separate, distributed services, which must be tested both independently, and together.
|
||||
- The Serverless Architecture is dependent on internet/cloud services, which are hard to emulate locally.
|
||||
- The Serverless Architecture can feature event-driven, asynchronous workflows, which are hard to emulate entirely.
|
||||
|
||||
To get through these challenges, and to keep the [test pyramid](http://martinfowler.com/bliki/TestPyramid.html) in mind, keep the following principles in mind:
|
||||
|
||||
* Write your business logic so that it is separate from your FaaS provider (e.g., AWS Lambda), to keep it provider-independent, reusable and more easily testable.
|
||||
* When your business logic is written separately from the FaaS provider, you can write traditional Unit Tests to ensure it is working properly.
|
||||
* Write Integration Tests to verify integrations with other services are working correctly.
|
||||
- Write your business logic so that it is separate from your FaaS provider (e.g., AWS Lambda), to keep it provider-independent, reusable and more easily testable.
|
||||
- When your business logic is written separately from the FaaS provider, you can write traditional Unit Tests to ensure it is working properly.
|
||||
- Write Integration Tests to verify integrations with other services are working correctly.
|
||||
|
||||
## A Poor Example
|
||||
|
||||
@ -35,10 +37,10 @@ const mailer = require('mailer');
|
||||
module.exports.saveUser = (event, context, callback) => {
|
||||
const user = {
|
||||
email: event.email,
|
||||
created_at: Date.now()
|
||||
}
|
||||
created_at: Date.now(),
|
||||
};
|
||||
|
||||
db.saveUser(user, function (err) {
|
||||
db.saveUser(user, function(err) {
|
||||
if (err) {
|
||||
callback(err);
|
||||
} else {
|
||||
@ -51,8 +53,8 @@ module.exports.saveUser = (event, context, callback) => {
|
||||
|
||||
There are two main problems with this function:
|
||||
|
||||
* The business logic is not separate from the FaaS Provider. It's bounded to how AWS Lambda passes incoming data (Lambda's `event` object).
|
||||
* Testing this function will rely on separate services. Specifically, running a database instance and a mail server.
|
||||
- The business logic is not separate from the FaaS Provider. It's bounded to how AWS Lambda passes incoming data (Lambda's `event` object).
|
||||
- Testing this function will rely on separate services. Specifically, running a database instance and a mail server.
|
||||
|
||||
## Writing Testable AWS Lambda Functions
|
||||
|
||||
@ -68,17 +70,17 @@ class Users {
|
||||
save(email, callback) {
|
||||
const user = {
|
||||
email: email,
|
||||
created_at: Date.now()
|
||||
}
|
||||
created_at: Date.now(),
|
||||
};
|
||||
|
||||
this.db.saveUser(user, function (err) {
|
||||
this.db.saveUser(user, function(err) {
|
||||
if (err) {
|
||||
callback(err);
|
||||
} else {
|
||||
this.mailer.sendWelcomeEmail(email);
|
||||
callback();
|
||||
}
|
||||
});
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
@ -97,14 +99,15 @@ module.exports.saveUser = (event, context, callback) => {
|
||||
};
|
||||
```
|
||||
|
||||
Now, the above class keeps business logic separate. Further, the code responsible for setting up dependencies, injecting them, calling business logic functions and interacting with AWS Lambda is in its own file, which will be changed less often. This way, the business logic is not provider dependent, easier to re-use, and easier to test.
|
||||
Now, the above class keeps business logic separate. Further, the code responsible for setting up dependencies, injecting them, calling business logic functions and interacting with AWS Lambda is in its own file, which will be changed less often. This way, the business logic is not provider dependent, easier to re-use, and easier to test.
|
||||
|
||||
Further, this code doesn't require running any external services. Instead of a real `db` and `mailer` services, we can pass mocks and assert if `saveUser` and `sendWelcomeEmail` has been called with proper arguments.
|
||||
Further, this code doesn't require running any external services. Instead of a real `db` and `mailer` services, we can pass mocks and assert if `saveUser` and `sendWelcomeEmail` has been called with proper arguments.
|
||||
|
||||
Unit Tests can easily be written to cover the above class. An integration test can be added by invoking the function (`serverless invoke`) with fixture email address, check if user is actually saved to DB and check if email was received to see if everything is working together.
|
||||
Unit Tests can easily be written to cover the above class. An integration test can be added by invoking the function (`serverless invoke`) with fixture email address, check if user is actually saved to DB and check if email was received to see if everything is working together.
|
||||
|
||||
## Other
|
||||
|
||||
Here are a few links to services which can help you test locally:
|
||||
* [dynamodb-local](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html)
|
||||
* [kinesalite](https://github.com/mhart/kinesalite)
|
||||
|
||||
- [dynamodb-local](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html)
|
||||
- [kinesalite](https://github.com/mhart/kinesalite)
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/v0_to_v1)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Comparison Of Serverless Framework V.1 & V.0
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/variables)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Variables
|
||||
@ -73,6 +75,7 @@ Likewise, if `sls deploy --stage prod` is run the `config.prod.json` file would
|
||||
If no `--stage` flag is provided, the second parameter defined in `${opt:stage, 'dev'}` a.k.a `dev` will be used and result in `${file(./config.dev.json):CREDS}`.
|
||||
|
||||
## Reference Properties In serverless.yml
|
||||
|
||||
To self-reference properties in `serverless.yml`, use the `${self:someProperty}` syntax in your `serverless.yml`. `someProperty` can contain the empty string for a top-level self-reference or a dotted attribute reference to any depth of attribute, so you can go as shallow or deep in the object tree as you want.
|
||||
|
||||
```yml
|
||||
@ -87,13 +90,13 @@ custom:
|
||||
|
||||
functions:
|
||||
hello:
|
||||
handler: handler.hello
|
||||
events:
|
||||
- schedule: ${self:custom.globalSchedule}
|
||||
handler: handler.hello
|
||||
events:
|
||||
- schedule: ${self:custom.globalSchedule}
|
||||
world:
|
||||
handler: handler.world
|
||||
events:
|
||||
- schedule: ${self:custom.globalSchedule}
|
||||
handler: handler.world
|
||||
events:
|
||||
- schedule: ${self:custom.globalSchedule}
|
||||
resources:
|
||||
Outputs:
|
||||
NewServiceExport:
|
||||
@ -105,6 +108,7 @@ resources:
|
||||
In the above example you're setting a global schedule for all functions by referencing the `globalSchedule` property in the same `serverless.yml` file. This way, you can easily change the schedule for all functions whenever you like.
|
||||
|
||||
## Referencing Serverless Core Variables
|
||||
|
||||
Serverless initializes core variables which are used internally by the Framework itself. Those values are exposed via the Serverless Variables system and can be re-used with the `{sls:}` variable prefix.
|
||||
|
||||
The following variables are available:
|
||||
@ -126,7 +130,8 @@ functions:
|
||||
```
|
||||
|
||||
## Referencing Environment Variables
|
||||
To reference environment variables, use the `${env:SOME_VAR}` syntax in your `serverless.yml` configuration file. It is valid to use the empty string in place of `SOME_VAR`. This looks like "`${env:}`" and the result of declaring this in your `serverless.yml` is to embed the complete `process.env` object (i.e. all the variables defined in your environment).
|
||||
|
||||
To reference environment variables, use the `${env:SOME_VAR}` syntax in your `serverless.yml` configuration file. It is valid to use the empty string in place of `SOME_VAR`. This looks like "`${env:}`" and the result of declaring this in your `serverless.yml` is to embed the complete `process.env` object (i.e. all the variables defined in your environment).
|
||||
|
||||
**Note:**
|
||||
|
||||
@ -147,43 +152,48 @@ functions:
|
||||
In the above example you're dynamically adding a prefix to the function names by referencing the `FUNC_PREFIX` env var. So you can easily change that prefix for all functions by changing the `FUNC_PREFIX` env var.
|
||||
|
||||
## Referencing CLI Options
|
||||
To reference CLI options that you passed, use the `${opt:some_option}` syntax in your `serverless.yml` configuration file. It is valid to use the empty string in place of `some_option`. This looks like "`${opt:}`" and the result of declaring this in your `serverless.yml` is to embed the complete `options` object (i.e. all the command line options from your `serverless` command).
|
||||
|
||||
To reference CLI options that you passed, use the `${opt:some_option}` syntax in your `serverless.yml` configuration file. It is valid to use the empty string in place of `some_option`. This looks like "`${opt:}`" and the result of declaring this in your `serverless.yml` is to embed the complete `options` object (i.e. all the command line options from your `serverless` command).
|
||||
|
||||
```yml
|
||||
service: new-service
|
||||
provider: aws
|
||||
functions:
|
||||
hello:
|
||||
name: ${opt:stage}-hello
|
||||
handler: handler.hello
|
||||
name: ${opt:stage}-hello
|
||||
handler: handler.hello
|
||||
world:
|
||||
name: ${opt:stage}-world
|
||||
handler: handler.world
|
||||
name: ${opt:stage}-world
|
||||
handler: handler.world
|
||||
```
|
||||
|
||||
In the above example, you're dynamically adding a prefix to the function names by referencing the `stage` option that you pass in the CLI when you run `serverless deploy --stage dev`. So when you deploy, the function name will always include the stage you're deploying to.
|
||||
|
||||
## Reference CloudFormation Outputs
|
||||
|
||||
You can reference CloudFormation stack output values as the source of your variables to use in your service with the `cf:stackName.outputKey` syntax. For example:
|
||||
|
||||
```yml
|
||||
service: new-service
|
||||
provider: aws
|
||||
functions:
|
||||
hello:
|
||||
name: ${cf:another-service-dev.functionPrefix}-hello
|
||||
handler: handler.hello
|
||||
name: ${cf:another-service-dev.functionPrefix}-hello
|
||||
handler: handler.hello
|
||||
world:
|
||||
name: ${cf:another-stack.functionPrefix}-world
|
||||
handler: handler.world
|
||||
name: ${cf:another-stack.functionPrefix}-world
|
||||
handler: handler.world
|
||||
```
|
||||
|
||||
In that case, the framework will fetch the values of those `functionPrefix` outputs from the provided stack names and populate your variables. There are many use cases for this functionality and it allows your service to communicate with other services/stacks.
|
||||
|
||||
You can add such custom output to CloudFormation stack. For example:
|
||||
|
||||
```yml
|
||||
service: another-service
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs8.10
|
||||
runtime: nodejs10.x
|
||||
region: ap-northeast-1
|
||||
memorySize: 512
|
||||
functions:
|
||||
@ -191,7 +201,7 @@ functions:
|
||||
name: ${self:custom.functionPrefix}hello
|
||||
handler: handler.hello
|
||||
custom:
|
||||
functionPrefix: "my-prefix-"
|
||||
functionPrefix: 'my-prefix-'
|
||||
resources:
|
||||
Outputs:
|
||||
functionPrefix:
|
||||
@ -205,16 +215,17 @@ resources:
|
||||
```
|
||||
|
||||
You can also reference CloudFormation stack in another regions with the `cf.REGION:stackName.outputKey` syntax. For example:
|
||||
|
||||
```yml
|
||||
service: new-service
|
||||
provider: aws
|
||||
functions:
|
||||
hello:
|
||||
name: ${cf.us-west-2:another-service-dev.functionPrefix}-hello
|
||||
handler: handler.hello
|
||||
name: ${cf.us-west-2:another-service-dev.functionPrefix}-hello
|
||||
handler: handler.hello
|
||||
world:
|
||||
name: ${cf.ap-northeast-1:another-stack.functionPrefix}-world
|
||||
handler: handler.world
|
||||
name: ${cf.ap-northeast-1:another-stack.functionPrefix}-world
|
||||
handler: handler.world
|
||||
```
|
||||
|
||||
You can reference [CloudFormation stack outputs export values](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html) as well. For example:
|
||||
@ -238,18 +249,22 @@ provider:
|
||||
```
|
||||
|
||||
## Referencing S3 Objects
|
||||
|
||||
You can reference S3 values as the source of your variables to use in your service with the `s3:bucketName/key` syntax. For example:
|
||||
|
||||
```yml
|
||||
service: new-service
|
||||
provider: aws
|
||||
functions:
|
||||
hello:
|
||||
name: ${s3:myBucket/myKey}-hello
|
||||
handler: handler.hello
|
||||
name: ${s3:myBucket/myKey}-hello
|
||||
handler: handler.hello
|
||||
```
|
||||
|
||||
In the above example, the value for `myKey` in the `myBucket` S3 bucket will be looked up and used to populate the variable.
|
||||
|
||||
## Reference Variables using the SSM Parameter Store
|
||||
|
||||
You can reference SSM Parameters as the source of your variables with the `ssm:/path/to/param` syntax. For example:
|
||||
|
||||
```yml
|
||||
@ -280,8 +295,8 @@ custom:
|
||||
In this example, the serverless variable will contain the decrypted value of the SecureString.
|
||||
|
||||
## Reference Variables using AWS Secrets Manager
|
||||
Variables in [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) can be referenced [using SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). Use the `ssm:/aws/reference/secretsmanager/secret_ID_in_Secrets_Manager~true` syntax(note `~true` as secrets are always encrypted). For example:
|
||||
|
||||
Variables in [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) can be referenced [using SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). Use the `ssm:/aws/reference/secretsmanager/secret_ID_in_Secrets_Manager~true` syntax(note `~true` as secrets are always encrypted). For example:
|
||||
|
||||
```yml
|
||||
service: new-service
|
||||
@ -326,9 +341,9 @@ custom:
|
||||
- false
|
||||
```
|
||||
|
||||
|
||||
## Reference Variables in Other Files
|
||||
You can reference variables in other YAML or JSON files. To reference variables in other YAML files use the `${file(./myFile.yml):someProperty}` syntax in your `serverless.yml` configuration file. To reference variables in other JSON files use the `${file(./myFile.json):someProperty}` syntax. It is important that the file you are referencing has the correct suffix, or file extension, for its file type (`.yml` for YAML or `.json` for JSON) in order for it to be interpreted correctly. Here's an example:
|
||||
|
||||
You can reference variables in other YAML or JSON files. To reference variables in other YAML files use the `${file(./myFile.yml):someProperty}` syntax in your `serverless.yml` configuration file. To reference variables in other JSON files use the `${file(./myFile.json):someProperty}` syntax. It is important that the file you are referencing has the correct suffix, or file extension, for its file type (`.yml` for YAML or `.json` for JSON) in order for it to be interpreted correctly. Here's an example:
|
||||
|
||||
```yml
|
||||
# myCustomFile.yml
|
||||
@ -342,32 +357,34 @@ provider: aws
|
||||
custom: ${file(./myCustomFile.yml)} # You can reference the entire file
|
||||
functions:
|
||||
hello:
|
||||
handler: handler.hello
|
||||
events:
|
||||
- schedule: ${file(./myCustomFile.yml):globalSchedule} # Or you can reference a specific property
|
||||
handler: handler.hello
|
||||
events:
|
||||
- schedule: ${file(./myCustomFile.yml):globalSchedule} # Or you can reference a specific property
|
||||
world:
|
||||
handler: handler.world
|
||||
events:
|
||||
- schedule: ${self:custom.globalSchedule} # This would also work in this case
|
||||
handler: handler.world
|
||||
events:
|
||||
- schedule: ${self:custom.globalSchedule} # This would also work in this case
|
||||
```
|
||||
|
||||
In the above example, you're referencing the entire `myCustomFile.yml` file in the `custom` property. You need to pass the path relative to your service directory. You can also request specific properties in that file as shown in the `schedule` property. It's completely recursive and you can go as deep as you want. Additionally you can request properties that contain arrays from either YAML or JSON reference files. Here's a YAML example for an events array:
|
||||
In the above example, you're referencing the entire `myCustomFile.yml` file in the `custom` property. You need to pass the path relative to your service directory. You can also request specific properties in that file as shown in the `schedule` property. It's completely recursive and you can go as deep as you want. Additionally you can request properties that contain arrays from either YAML or JSON reference files. Here's a YAML example for an events array:
|
||||
|
||||
```yml
|
||||
myevents:
|
||||
- schedule:
|
||||
rate: rate(1 minute)
|
||||
rate: rate(1 minute)
|
||||
```
|
||||
|
||||
and for JSON:
|
||||
|
||||
```json
|
||||
{
|
||||
"myevents": [{
|
||||
"schedule" : {
|
||||
"rate" : "rate(1 minute)"
|
||||
"myevents": [
|
||||
{
|
||||
"schedule": {
|
||||
"rate": "rate(1 minute)"
|
||||
}
|
||||
}
|
||||
}]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@ -402,21 +419,21 @@ Here are other examples:
|
||||
```js
|
||||
// scheduleConfig.js
|
||||
module.exports.rate = () => {
|
||||
// Code that generates dynamic data
|
||||
return 'rate (10 minutes)';
|
||||
}
|
||||
// Code that generates dynamic data
|
||||
return 'rate (10 minutes)';
|
||||
};
|
||||
```
|
||||
|
||||
```js
|
||||
// config.js
|
||||
module.exports = (serverless) => {
|
||||
module.exports = serverless => {
|
||||
serverless.cli.consoleLog('You can access Serverless config and methods as well!');
|
||||
|
||||
return {
|
||||
property1: 'some value',
|
||||
property2: 'some other value'
|
||||
}
|
||||
}
|
||||
property2: 'some other value',
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
```yml
|
||||
@ -428,12 +445,12 @@ custom: ${file(./config.js)}
|
||||
|
||||
functions:
|
||||
hello:
|
||||
handler: handler.hello
|
||||
events:
|
||||
- schedule: ${file(./scheduleConfig.js):rate} # Reference a specific module
|
||||
handler: handler.hello
|
||||
events:
|
||||
- schedule: ${file(./scheduleConfig.js):rate} # Reference a specific module
|
||||
```
|
||||
|
||||
You can also return an object and reference a specific property. Just make sure you are returning a valid object and referencing a valid property:
|
||||
You can also return an object and reference a specific property. Just make sure you are returning a valid object and referencing a valid property:
|
||||
|
||||
```yml
|
||||
# serverless.yml
|
||||
@ -441,22 +458,23 @@ service: new-service
|
||||
provider: aws
|
||||
functions:
|
||||
scheduledFunction:
|
||||
handler: handler.scheduledFunction
|
||||
events:
|
||||
- schedule: ${file(./myCustomFile.js):schedule.ten}
|
||||
handler: handler.scheduledFunction
|
||||
events:
|
||||
- schedule: ${file(./myCustomFile.js):schedule.ten}
|
||||
```
|
||||
|
||||
```js
|
||||
// myCustomFile.js
|
||||
module.exports.schedule = () => {
|
||||
// Code that generates dynamic data
|
||||
return {
|
||||
ten: 'rate(10 minutes)',
|
||||
twenty: 'rate(20 minutes)',
|
||||
thirty: 'rate(30 minutes)'
|
||||
};
|
||||
}
|
||||
// Code that generates dynamic data
|
||||
return {
|
||||
ten: 'rate(10 minutes)',
|
||||
twenty: 'rate(20 minutes)',
|
||||
thirty: 'rate(30 minutes)',
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
If your use case requires handling dynamic/async data sources (ie. DynamoDB, API calls...etc), you can also return a Promise that would be resolved as the value of the variable:
|
||||
|
||||
```yml
|
||||
@ -465,17 +483,17 @@ service: new-service
|
||||
provider: aws
|
||||
functions:
|
||||
scheduledFunction:
|
||||
handler: handler.scheduledFunction
|
||||
events:
|
||||
- schedule: ${file(./myCustomFile.js):promised}
|
||||
handler: handler.scheduledFunction
|
||||
events:
|
||||
- schedule: ${file(./myCustomFile.js):promised}
|
||||
```
|
||||
|
||||
```js
|
||||
// myCustomFile.js
|
||||
module.exports.promised = () => {
|
||||
// Async code that fetches the rate config...
|
||||
return Promise.resolve('rate(10 minutes)');
|
||||
}
|
||||
// Async code that fetches the rate config...
|
||||
return Promise.resolve('rate(10 minutes)');
|
||||
};
|
||||
```
|
||||
|
||||
## Multiple Configuration Files
|
||||
@ -516,6 +534,7 @@ Resources:
|
||||
```
|
||||
|
||||
## Nesting Variable References
|
||||
|
||||
The Serverless variable system allows you to nest variable references within each other for ultimate flexibility. So you can reference certain variables based on other variables. Here's an example:
|
||||
|
||||
```yml
|
||||
@ -526,12 +545,13 @@ custom:
|
||||
|
||||
functions:
|
||||
hello:
|
||||
handler: handler.hello
|
||||
handler: handler.hello
|
||||
```
|
||||
|
||||
In the above example, if you pass `dev` as a stage option, the framework will look for the `dev_arn` environment variable. If you pass `production`, the framework will look for `production_arn`, and so on. This allows you to creatively use multiple variables by using a certain naming pattern without having to update the values of these variables constantly. You can go as deep as you want in your nesting, and can reference variables at any level of nesting from any source (env, opt, self or file).
|
||||
|
||||
## Overwriting Variables
|
||||
|
||||
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, if you want to reference the stage you're deploying to, but you don't want to keep on providing the `stage` option in the CLI. What you can do in `serverless.yml` is:
|
||||
@ -547,7 +567,7 @@ custom:
|
||||
|
||||
functions:
|
||||
hello:
|
||||
handler: handler.hello
|
||||
handler: handler.hello
|
||||
```
|
||||
|
||||
What this says is to use the `stage` CLI option if it exists, if not, use the default stage (which lives in `provider.stage`). So during development you can safely deploy with `serverless deploy`, but during production you can do `serverless deploy --stage production` and the stage will be picked up for you without having to make any changes to `serverless.yml`.
|
||||
@ -555,6 +575,7 @@ What this says is to use the `stage` CLI option if it exists, if not, use the de
|
||||
You can have as many variable references as you want, from any source you want, and each of them can be of different type and different name.
|
||||
|
||||
## Using Custom Variable Syntax
|
||||
|
||||
In some cases, the `${xxx}` variable syntax conflicts with some CloudFormation functionality. In that case you can provide a custom syntax to overwrite our default `${xxx}` syntax by setting the `provider.variableSyntax` property to the desired regex:
|
||||
|
||||
```yml
|
||||
@ -562,16 +583,18 @@ service: new-service
|
||||
|
||||
provider:
|
||||
name: aws
|
||||
runtime: nodejs6.10
|
||||
runtime: nodejs10.x
|
||||
variableSyntax: "\\${{([ ~:a-zA-Z0-9._@\\'\",\\-\\/\\(\\)]+?)}}" # notice the double quotes for yaml to ignore the escape characters!
|
||||
# variableSyntax: "\\${((?!AWS)[ ~:a-zA-Z0-9._@'\",\\-\\/\\(\\)]+?)}" # Use this for allowing CloudFormation Pseudo-Parameters in your serverless.yml -- e.g. ${AWS::Region}. All other Serverless variables work as usual.
|
||||
|
||||
custom:
|
||||
myStage: ${{opt:stage}}
|
||||
```
|
||||
|
||||
In this example, we're overwriting the default regex for our variable syntax. So whenever you define variables, you now need to use `${{}}` instead of `${}` (double curly brackets).
|
||||
|
||||
## Migrating serverless.env.yml
|
||||
|
||||
Previously we used the `serverless.env.yml` file to track Serverless Variables. It was a completely different system with different concepts. To migrate your variables from `serverless.env.yml`, you'll need to decide where you want to store your variables.
|
||||
|
||||
**Using a config file:** You can still use `serverless.env.yml`, but the difference now is that you can structure the file however you want, and you'll need to reference each variable/property correctly in `serverless.yml`. For more info, you can check the file reference section above.
|
||||
@ -591,12 +614,11 @@ You can reference [AWS Pseudo Parameters](http://docs.aws.amazon.com/AWSCloudFor
|
||||
Here's an example:
|
||||
|
||||
```yml
|
||||
Resources:
|
||||
- 'Fn::Join':
|
||||
- ':'
|
||||
-
|
||||
- 'arn:aws:logs'
|
||||
- Ref: 'AWS::Region'
|
||||
- Ref: 'AWS::AccountId'
|
||||
- 'log-group:/aws/lambda/*:*:*'
|
||||
Resources:
|
||||
- 'Fn::Join':
|
||||
- ':'
|
||||
- - 'arn:aws:logs'
|
||||
- Ref: 'AWS::Region'
|
||||
- Ref: 'AWS::AccountId'
|
||||
- 'log-group:/aws/lambda/*:*:*'
|
||||
```
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/workflow)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Workflow
|
||||
@ -20,54 +22,69 @@ Quick recommendations and tips for various processes.
|
||||
2. Use `serverless deploy` only when you've made changes to `serverless.yml` and in CI/CD systems. For more information on setting up CI/CD for your Serverless app, read [this article](https://serverless.com/blog/ci-cd-workflow-serverless-apps-with-circleci).
|
||||
3. Use `serverless deploy function -f myFunction` to rapidly deploy changes when you are working on a specific AWS Lambda Function.
|
||||
4. Use `serverless invoke -f myFunction -l` to test your AWS Lambda Functions on AWS.
|
||||
5. Open up a separate tab in your console and stream logs in there via `serverless logs -f myFunction -t`.
|
||||
5. Open up a separate tab in your console and stream logs in there via `serverless logs -f myFunction -t`.
|
||||
6. Write tests to run locally.
|
||||
|
||||
### Using stages
|
||||
* At the very least, use a `dev` and `production` stage.
|
||||
* Use different AWS accounts for stages.
|
||||
* In larger teams, each member should use a separate AWS account and their own stage for development.
|
||||
|
||||
- At the very least, use a `dev` and `production` stage.
|
||||
- Use different AWS accounts for stages.
|
||||
- In larger teams, each member should use a separate AWS account and their own stage for development.
|
||||
|
||||
### Larger Projects
|
||||
* Break your application/project into multiple Serverless Services.
|
||||
* Model your Serverless Services around Data Models or Workflows.
|
||||
* Keep the Functions and Resources in your Serverless Services to a minimum.
|
||||
|
||||
- Break your application/project into multiple Serverless Services.
|
||||
- Model your Serverless Services around Data Models or Workflows.
|
||||
- Keep the Functions and Resources in your Serverless Services to a minimum.
|
||||
|
||||
## Cheat Sheet
|
||||
|
||||
A handy list of commands to use when developing with the Serverless Framework.
|
||||
|
||||
##### Create A Service:
|
||||
|
||||
Creates a new Service
|
||||
|
||||
```
|
||||
serverless create -p [SERVICE NAME] -t aws-nodejs
|
||||
```
|
||||
|
||||
##### Install A Service
|
||||
|
||||
This is a convenience method to install a pre-made Serverless Service locally by downloading the Github repo and unzipping it.
|
||||
|
||||
```
|
||||
serverless install -u [GITHUB URL OF SERVICE]
|
||||
```
|
||||
|
||||
##### Deploy All
|
||||
|
||||
Use this when you have made changes to your Functions, Events or Resources in `serverless.yml` or you simply want to deploy all changes within your Service at the same time.
|
||||
|
||||
```
|
||||
serverless deploy -s [STAGE NAME] -r [REGION NAME] -v
|
||||
```
|
||||
|
||||
##### Deploy Function
|
||||
|
||||
Use this to quickly overwrite your AWS Lambda code on AWS, allowing you to develop faster.
|
||||
|
||||
```
|
||||
serverless deploy function -f [FUNCTION NAME] -s [STAGE NAME] -r [REGION NAME]
|
||||
```
|
||||
|
||||
##### Invoke Function
|
||||
|
||||
Invokes an AWS Lambda Function on AWS and returns logs.
|
||||
|
||||
```
|
||||
serverless invoke -f [FUNCTION NAME] -s [STAGE NAME] -r [REGION NAME] -l
|
||||
```
|
||||
|
||||
##### Streaming Logs
|
||||
|
||||
Open up a separate tab in your console and stream all logs for a specific Function using this command.
|
||||
|
||||
```
|
||||
serverless logs -f [FUNCTION NAME] -s [STAGE NAME] -r [REGION NAME]
|
||||
```
|
||||
|
||||
@ -5,7 +5,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Azure Functions Provider Documentation
|
||||
|
||||
@ -5,12 +5,14 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/azure/cli-reference/)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Serverless Azure Functions CLI Reference
|
||||
|
||||
Welcome to the Serverless Azure Functions CLI Reference! Please select a section
|
||||
Welcome to the Serverless Azure Functions CLI Reference! Please select a section
|
||||
on the left to get started.
|
||||
|
||||
If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](http://forum.serverless.com/).
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/azure/cli-reference/create)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Azure - Create
|
||||
@ -28,6 +30,7 @@ serverless create --template azure-nodejs --path myService
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--template` or `-t` The name of one of the available templates. **Required if --template-url and --template-path are not present**.
|
||||
- `--template-url` or `-u` The name of one of the available templates. **Required if --template and --template-path are not present**.
|
||||
- `--template-path` The local path of your template. **Required if --template and --template-url are not present**.
|
||||
@ -35,6 +38,7 @@ serverless create --template azure-nodejs --path myService
|
||||
- `--name` or `-n` the name of the service in `serverless.yml`.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `create:create`
|
||||
|
||||
## Available Templates
|
||||
@ -64,8 +68,7 @@ serverless create --template azure-nodejs --path my-new-service
|
||||
```
|
||||
|
||||
This example will generate scaffolding for a service with `Azure` as a provider
|
||||
and `nodejs` as runtime. The scaffolding will be generated in the `my-new-
|
||||
service` directory. This directory will be created if not present. Otherwise
|
||||
and `nodejs` as runtime. The scaffolding will be generated in the `my-new- service` directory. This directory will be created if not present. Otherwise
|
||||
Serverless will use the already present directory.
|
||||
|
||||
Additionally Serverless will rename the service according to the path you
|
||||
|
||||
@ -7,12 +7,14 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/azure/cli-reference/deploy-function)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Azure - Deploy Function
|
||||
|
||||
The `serverless deploy function` command deploys an individual function. This
|
||||
The `serverless deploy function` command deploys an individual function. This
|
||||
command simply compiles a deployment package with a single function handler. This
|
||||
is a much faster way of deploying changes in code.
|
||||
|
||||
@ -24,4 +26,5 @@ serverless deploy function -f functionName
|
||||
properties such as environment variables and events will **not** be deployed.
|
||||
|
||||
## Options
|
||||
|
||||
- `--function` or `-f` The name of the function which should be deployed
|
||||
|
||||
@ -7,14 +7,16 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/azure/cli-reference/deploy)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Azure - Deploy
|
||||
|
||||
The `serverless deploy` command deploys your entire service via the Azure
|
||||
Resource Manager API. Run this command when you have made service changes (i.e.,
|
||||
you edited `serverless.yml`). Use `serverless deploy function -f myFunction`
|
||||
you edited `serverless.yml`). Use `serverless deploy function -f myFunction`
|
||||
when you have made code changes and you want to quickly upload your updated code
|
||||
to Azure Functions.
|
||||
|
||||
@ -23,6 +25,8 @@ serverless deploy
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--config` or `-c` Path to your conifguration file, if other than `serverless.yml|.yaml|.js|.json`.
|
||||
- `--noDeploy` or `-n` Skips the deployment steps and leaves artifacts in the `.serverless` directory
|
||||
- `--verbose` or `-v` Shows all stack events during deployment, and display any Stack Output.
|
||||
- `--function` or `-f` Invoke `deploy function` (see above). Convenience shortcut.
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/azure/cli-reference/install)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Azure - Install
|
||||
@ -19,12 +21,21 @@ serverless install --url https://github.com/some/service
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--url` or `-u` The services GitHub URL. **Required**.
|
||||
- `--name` or `-n` Name for the service.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `install:install`
|
||||
|
||||
## Supported Code Hosting Platforms
|
||||
|
||||
- GitHub
|
||||
- GitHub Enterprise
|
||||
- GitLab
|
||||
- BitBucket
|
||||
|
||||
## Examples
|
||||
|
||||
### Installing a service from a GitHub URL
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/azure/cli-reference/invoke)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Azure - Invoke
|
||||
@ -20,10 +22,12 @@ serverless invoke --function functionName
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `--function` or `-f` The name of the function in your service that you want to invoke. **Required**.
|
||||
- `--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.
|
||||
|
||||
## Provided lifecycle events
|
||||
|
||||
- `invoke:invoke`
|
||||
|
||||
## Examples
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/azure/cli-reference/login)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Login
|
||||
|
||||
@ -7,7 +7,9 @@ layout: Doc
|
||||
-->
|
||||
|
||||
<!-- DOCS-SITE-LINK:START automatically generated -->
|
||||
|
||||
### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/azure/cli-reference/logs)
|
||||
|
||||
<!-- DOCS-SITE-LINK:END -->
|
||||
|
||||
# Azure - Logs
|
||||
@ -29,4 +31,5 @@ serverless logs -f hello
|
||||
```bash
|
||||
serverless logs -f hello
|
||||
```
|
||||
|
||||
This will stream all future logs for a given Function.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user