From a01d080fe44301ed95a85e0600005aa75286a40e Mon Sep 17 00:00:00 2001 From: James Thomas Date: Tue, 24 Jan 2017 13:29:13 +0000 Subject: [PATCH 01/30] Add OpenWhisk docs --- docs/providers/openwhisk/README.md | 19 + .../openwhisk/cli-reference/README.md | 17 + .../cli-reference/config-credentials.md | 46 ++ .../openwhisk/cli-reference/create.md | 84 +++ .../cli-reference/deploy-function.md | 38 ++ .../openwhisk/cli-reference/deploy-list.md | 32 + .../openwhisk/cli-reference/deploy.md | 59 ++ .../providers/openwhisk/cli-reference/info.md | 79 +++ .../openwhisk/cli-reference/install.md | 52 ++ .../openwhisk/cli-reference/invoke-local.md | 63 ++ .../openwhisk/cli-reference/invoke.md | 86 +++ .../providers/openwhisk/cli-reference/logs.md | 79 +++ .../openwhisk/cli-reference/metrics.md | 63 ++ .../openwhisk/cli-reference/remove.md | 37 + .../openwhisk/cli-reference/rollback.md | 77 +++ .../openwhisk/cli-reference/slstats.md | 36 + docs/providers/openwhisk/events/README.md | 19 + .../providers/openwhisk/events/alexa-skill.md | 27 + docs/providers/openwhisk/events/apigateway.md | 645 ++++++++++++++++++ docs/providers/openwhisk/events/iot.md | 71 ++ docs/providers/openwhisk/events/s3.md | 75 ++ docs/providers/openwhisk/events/schedule.md | 62 ++ docs/providers/openwhisk/events/sns.md | 69 ++ docs/providers/openwhisk/events/streams.md | 44 ++ docs/providers/openwhisk/examples/README.md | 31 + .../openwhisk/examples/hello-world/README.md | 22 + .../hello-world/csharp/AssemblyInfo.cs | 3 + .../examples/hello-world/csharp/Handler.cs | 36 + .../examples/hello-world/csharp/README.md | 52 ++ .../examples/hello-world/csharp/project.json | 33 + .../hello-world/csharp/serverless.yml | 84 +++ .../examples/hello-world/node/README.md | 36 + .../examples/hello-world/node/handler.js | 11 + .../examples/hello-world/node/serverless.yml | 10 + .../examples/hello-world/python/README.md | 36 + .../examples/hello-world/python/handler.py | 6 + .../hello-world/python/serverless.yml | 10 + docs/providers/openwhisk/guide/README.md | 19 + docs/providers/openwhisk/guide/credentials.md | 138 ++++ docs/providers/openwhisk/guide/deploying.md | 63 ++ docs/providers/openwhisk/guide/events.md | 57 ++ docs/providers/openwhisk/guide/functions.md | 97 +++ .../providers/openwhisk/guide/installation.md | 65 ++ docs/providers/openwhisk/guide/intro.md | 77 +++ docs/providers/openwhisk/guide/packaging.md | 101 +++ docs/providers/openwhisk/guide/plugins.md | 318 +++++++++ .../openwhisk/guide/serverless.yml.md | 65 ++ docs/providers/openwhisk/guide/services.md | 174 +++++ docs/providers/openwhisk/guide/testing.md | 108 +++ docs/providers/openwhisk/guide/variables.md | 213 ++++++ docs/providers/openwhisk/guide/workflow.md | 68 ++ 51 files changed, 3812 insertions(+) create mode 100644 docs/providers/openwhisk/README.md create mode 100644 docs/providers/openwhisk/cli-reference/README.md create mode 100644 docs/providers/openwhisk/cli-reference/config-credentials.md create mode 100644 docs/providers/openwhisk/cli-reference/create.md create mode 100644 docs/providers/openwhisk/cli-reference/deploy-function.md create mode 100644 docs/providers/openwhisk/cli-reference/deploy-list.md create mode 100644 docs/providers/openwhisk/cli-reference/deploy.md create mode 100644 docs/providers/openwhisk/cli-reference/info.md create mode 100644 docs/providers/openwhisk/cli-reference/install.md create mode 100644 docs/providers/openwhisk/cli-reference/invoke-local.md create mode 100644 docs/providers/openwhisk/cli-reference/invoke.md create mode 100644 docs/providers/openwhisk/cli-reference/logs.md create mode 100644 docs/providers/openwhisk/cli-reference/metrics.md create mode 100644 docs/providers/openwhisk/cli-reference/remove.md create mode 100644 docs/providers/openwhisk/cli-reference/rollback.md create mode 100644 docs/providers/openwhisk/cli-reference/slstats.md create mode 100644 docs/providers/openwhisk/events/README.md create mode 100644 docs/providers/openwhisk/events/alexa-skill.md create mode 100644 docs/providers/openwhisk/events/apigateway.md create mode 100644 docs/providers/openwhisk/events/iot.md create mode 100644 docs/providers/openwhisk/events/s3.md create mode 100644 docs/providers/openwhisk/events/schedule.md create mode 100644 docs/providers/openwhisk/events/sns.md create mode 100644 docs/providers/openwhisk/events/streams.md create mode 100644 docs/providers/openwhisk/examples/README.md create mode 100644 docs/providers/openwhisk/examples/hello-world/README.md create mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/AssemblyInfo.cs create mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/Handler.cs create mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/README.md create mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/project.json create mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/serverless.yml create mode 100644 docs/providers/openwhisk/examples/hello-world/node/README.md create mode 100644 docs/providers/openwhisk/examples/hello-world/node/handler.js create mode 100644 docs/providers/openwhisk/examples/hello-world/node/serverless.yml create mode 100644 docs/providers/openwhisk/examples/hello-world/python/README.md create mode 100644 docs/providers/openwhisk/examples/hello-world/python/handler.py create mode 100644 docs/providers/openwhisk/examples/hello-world/python/serverless.yml create mode 100644 docs/providers/openwhisk/guide/README.md create mode 100644 docs/providers/openwhisk/guide/credentials.md create mode 100644 docs/providers/openwhisk/guide/deploying.md create mode 100644 docs/providers/openwhisk/guide/events.md create mode 100644 docs/providers/openwhisk/guide/functions.md create mode 100644 docs/providers/openwhisk/guide/installation.md create mode 100644 docs/providers/openwhisk/guide/intro.md create mode 100644 docs/providers/openwhisk/guide/packaging.md create mode 100644 docs/providers/openwhisk/guide/plugins.md create mode 100644 docs/providers/openwhisk/guide/serverless.yml.md create mode 100644 docs/providers/openwhisk/guide/services.md create mode 100644 docs/providers/openwhisk/guide/testing.md create mode 100644 docs/providers/openwhisk/guide/variables.md create mode 100644 docs/providers/openwhisk/guide/workflow.md diff --git a/docs/providers/openwhisk/README.md b/docs/providers/openwhisk/README.md new file mode 100644 index 000000000..7a6629265 --- /dev/null +++ b/docs/providers/openwhisk/README.md @@ -0,0 +1,19 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/) + + +# Serverless AWS Provider Documentation + +Welcome to the Serverless Amazon Web Services documentation! + +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](https://gitter.im/serverless/serverless) + +**Note:** Before continuing [AWS system credentials](./guide/credentials.md) are required for using the CLI. diff --git a/docs/providers/openwhisk/cli-reference/README.md b/docs/providers/openwhisk/cli-reference/README.md new file mode 100644 index 000000000..6eb1af6c1 --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/README.md @@ -0,0 +1,17 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/) + + +# Serverless AWS Lambda CLI Reference + +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. + +If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](https://gitter.im/serverless/serverless) diff --git a/docs/providers/openwhisk/cli-reference/config-credentials.md b/docs/providers/openwhisk/cli-reference/config-credentials.md new file mode 100644 index 000000000..1fc5536ec --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/config-credentials.md @@ -0,0 +1,46 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/config-credentials) + + +# Config Credentials + +```bash +serverless config credentials --provider provider --key key --secret secret +``` + +## Options + +- `--provider` or `-p` The provider (in this case `aws`). **Required**. +- `--key` or `-k` The `aws_access_key_id`. **Required**. +- `--secret` or `-s` The `aws_secret_access_key`. **Required**. +- `--profile` or `-n` The name of the profile which should be created. + +## Provided lifecycle events + +- `config:credentials:config` + +## Examples + +### Configure the `default` profile + +```bash +serverless config credentials --provider aws --key 1234 --secret 5678 +``` + +This example will configure the `default` profile with the `aws_access_key_id` of `1234` and the `aws_secret_access_key` of `5678`. + +### Configure a custom profile + +```bash +serverless config credentials --provider aws --key 1234 --secret 5678 --profile custom-profile +``` + +This example create and configure a `custom-profile` profile with the `aws_access_key_id` of `1234` and the `aws_secret_access_key` of `5678`. diff --git a/docs/providers/openwhisk/cli-reference/create.md b/docs/providers/openwhisk/cli-reference/create.md new file mode 100644 index 000000000..1c4d3c021 --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/create.md @@ -0,0 +1,84 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/create) + + +# Create + +Creates a new service in the current working directory based on the provided template. + +**Create service in current working directory:** + +```bash +serverless create --template aws-nodejs +``` + +**Create service in new folder:** + +```bash +serverless create --template aws-nodejs --path myService +``` + +## Options +- `--template` or `-t` The name of one of the available templates. **Required**. +- `--path` or `-p` The path where the service should be created. +- `--name` or `-n` the name of the service in `serverless.yml`. + +## Provided lifecycle events +- `create:create` + +## Available Templates + +To see a list of available templates run `serverless create --help` + +Most commonly used templates: + +- aws-nodejs +- aws-python +- aws-java-maven +- aws-java-gradle +- aws-scala-sbt +- aws-csharp +- plugin + +## Examples + +### Creating a new service + +```bash +serverless create --template aws-nodejs --name my-special-service +``` + +This example will generate scaffolding for a service with `AWS` as a provider and `nodejs` as runtime. The scaffolding +will be generated in the current working directory. + +Your new service will have a default stage called `dev` and a default region inside that stage called `us-east-1`. +The provider which is used for deployment later on is AWS (Amazon web services). + +### Creating a named service in a (new) directory + +```bash +serverless create --template aws-nodejs --path my-new-service +``` + +This example will generate scaffolding for a service with `AWS` 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 Serverless +will use the already present directory. + +Additionally Serverless will rename the service according to the path you provide. In this example the service will be +renamed to `my-new-service`. + +### Creating a new plugin + +``` +serverless create --template plugin +``` + +This example will generate scaffolding for a hello world plugin that demonstrates how to create a new command and how to listen to the various events available. diff --git a/docs/providers/openwhisk/cli-reference/deploy-function.md b/docs/providers/openwhisk/cli-reference/deploy-function.md new file mode 100644 index 000000000..986c1ee72 --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/deploy-function.md @@ -0,0 +1,38 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy-function) + + +# 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. + +```bash +serverless deploy function -f functionName +``` + +## 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. + +## Examples + +### Deployment without stage and region options + +```bash +serverless deploy function --function helloWorld +``` + +### Deployment with stage and region options + +```bash +serverless deploy function --function helloWorld --stage dev --region us-east-1 +``` diff --git a/docs/providers/openwhisk/cli-reference/deploy-list.md b/docs/providers/openwhisk/cli-reference/deploy-list.md new file mode 100644 index 000000000..edbbfa10a --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/deploy-list.md @@ -0,0 +1,32 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy-list) + + +# Deploy List + +The `sls deploy list` command will list your recent deployments available in your S3 deployment bucket. It will use stage and region from the provider config and show the timestamp of each deployment so you can roll back if necessary using `sls rollback`. + +## 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. + +## Artifacts + +After the `serverless deploy` command runs all created deployment artifacts are placed in the `.serverless` folder of the service. + +## Examples + +### List existing deploys + +```bash +serverless deploy list --stage dev --region us-east-1 +``` diff --git a/docs/providers/openwhisk/cli-reference/deploy.md b/docs/providers/openwhisk/cli-reference/deploy.md new file mode 100644 index 000000000..35c94e18e --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/deploy.md @@ -0,0 +1,59 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy) + + +# 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. + +```bash +serverless deploy +``` + +## 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. +- `--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. + +## Artifacts + +After the `serverless deploy` command runs all created deployment artifacts are placed in the `.serverless` folder of the service. + +## Examples + +### Deployment without stage and region options + +```bash +serverless deploy +``` + +This is the simplest deployment usage possible. With this command Serverless will deploy your service to the defined +provider in the default stage (`dev`) to the default region (`us-east-1`). + +### Deployment with stage and region options + +```bash +serverless deploy --stage production --region eu-central-1 +``` + +With this example we've defined that we want our service to be deployed to the `production` stage in the region +`eu-central-1`. + +## Provided lifecycle events +- `deploy:cleanup` +- `deploy:initialize` +- `deploy:setupProviderConfiguration` +- `deploy:createDeploymentArtifacts` +- `deploy:compileFunctions` +- `deploy:compileEvents` +- `deploy:deploy` +- `deploy:function:deploy` diff --git a/docs/providers/openwhisk/cli-reference/info.md b/docs/providers/openwhisk/cli-reference/info.md new file mode 100644 index 000000000..7e71a4eb0 --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/info.md @@ -0,0 +1,79 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/info) + + +# Info + +Displays information about the deployed service. + +```bash +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 + +### AWS + +On AWS the info plugin uses the `Outputs` section of the CloudFormation stack and the AWS SDK to gather the necessary information. +See the example below for an example output. + +**Example:** + +```bash +$ serverless info + +Service Information +service: my-serverless-service +stage: dev +region: us-east-1 +api keys: + myKey: some123valid456api789key1011for1213api1415gateway +endpoints: + GET - https://dxaynpuzd4.execute-api.us-east-1.amazonaws.com/dev/users +functions: + my-serverless-service-dev-hello: arn:aws:lambda:us-east-1:377024778620:function:my-serverless-service-dev-hello +``` + +#### Verbose + +When using the `--verbose` flag, the `info` command will also append all Stack Outputs to the output: + +```bash +$ serverless info --verbose + +Service Information +service: my-serverless-service +stage: dev +region: us-east-1 +api keys: + myKey: some123valid456api789key1011for1213api1415gateway +endpoints: + GET - https://dxaynpuzd4.execute-api.us-east-1.amazonaws.com/dev/users +functions: + my-serverless-service-dev-hello: arn:aws:lambda:us-east-1:377024778620:function:my-serverless-service-dev-hello + +Stack Outputs +CloudFrontUrl: d2d10e2tyk1pei.cloudfront.net +ListScreenshotsLambdaFunctionArn: arn:aws:lambda:us-east-1:377024778620:function:lambda-screenshots-dev-listScreenshots +ScreenshotBucket: dev-svdgraaf-screenshots +CreateThumbnailsLambdaFunctionArn: arn:aws:lambda:us-east-1:377024778620:function:lambda-screenshots-dev-createThumbnails +TakeScreenshotLambdaFunctionArn: arn:aws:lambda:us-east-1:377024778620:function:lambda-screenshots-dev-takeScreenshot +ServiceEndpoint: https://12341jc801.execute-api.us-east-1.amazonaws.com/dev +ServerlessDeploymentBucketName: lambda-screenshots-dev-serverlessdeploymentbucket-15b7pkc04f98a +``` diff --git a/docs/providers/openwhisk/cli-reference/install.md b/docs/providers/openwhisk/cli-reference/install.md new file mode 100644 index 000000000..ec72c4f34 --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/install.md @@ -0,0 +1,52 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/install) + + +# Install + +Installs a service from a GitHub URL in the current working directory. + +```bash +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` + +## Examples + +### Installing a service from a GitHub URL + +```bash +serverless install --url https://github.com/pmuens/serverless-crud +``` + +This example will download the .zip file of the `serverless-crud` service from GitHub, create a new directory with the name `serverless-crud` in the current working directory and unzips the files in this directory. + +### Installing a service from a GitHub URL with a new service name + +```bash +serverless install --url https://github.com/pmuens/serverless-crud --name my-crud +``` + +This example will download the .zip file of the `serverless-crud` service from GitHub, create a new directory with the name `my-crud` in the current working directory and unzips the files in this directory and renames the service to `my-crud` if `serverless.yml` exists in the service root. + +### Installing a service from a directory in a GitHub URL + +```bash +serverless install --url https://github.com/serverless/examples/tree/master/rest-api-with-dynamodb +``` + +This example will download the `rest-api-with-dynamodb` service from GitHub. diff --git a/docs/providers/openwhisk/cli-reference/invoke-local.md b/docs/providers/openwhisk/cli-reference/invoke-local.md new file mode 100644 index 000000000..253cae873 --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/invoke-local.md @@ -0,0 +1,63 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/invoke-local) + + +# 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. + +```bash +serverless invoke local --function functionName +``` + +## Options + +- `--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. This path is relative to the root directory of the service. The json file should have event and context properties to hold your mocked event and context data. +- `--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. + +## Examples + +### Local function invocation + +```bash +serverless invoke local --function functionName +``` + +This example will locally invoke your function. + +### Local function invocation with data + +```bash +serverless invoke --function functionName --data "hello world" +``` + +```bash +serverless invoke --function functionName --data '{"a":"bar"}' +``` + +### Local function invocation with data from standard input + +```bash +node dataGenerator.js | serverless invoke local --function functionName +``` + +### Local function invocation with data passing + +```bash +serverless invoke local --function functionName --path lib/data.json +``` + +This example will pass the json data in the `lib/data.json` file (relative to the root of the service) while invoking the specified/deployed function. + +### Limitations + +Currently, `invoke local` only supports the NodeJs and Python runtimes. diff --git a/docs/providers/openwhisk/cli-reference/invoke.md b/docs/providers/openwhisk/cli-reference/invoke.md new file mode 100644 index 000000000..5b88d2f58 --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/invoke.md @@ -0,0 +1,86 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/invoke) + + +# Invoke + +Invokes deployed function. It allows to send event data to the function, read logs and display other important information of the function invocation. + +```bash +serverless invoke [local] --function functionName +``` + +## 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. +- `--data` or `-d` String data to be passed as an event to your function. By default data is read from standard input. +- `--path` or `-p` The path to a json file with input data to be passed to the invoked function. This path is relative to the root directory of the service. +- `--type` or `-t` The type of invocation. Either `RequestResponse`, `Event` or `DryRun`. Default is `RequestResponse`. +- `--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 + +Invokes a function locally for testing and logs the output. You can only invoke Node.js runtime locally at the moment. Keep in mind that we mock the `context` with simple mock data. + +```bash +serverless invoke local --function functionName +``` + +## Options +- `--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. This path is relative to the +root directory of the service. The json file should have event and context properties to hold your mocked event and context data. +- `--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. + +## Examples + +### AWS + +```bash +serverless invoke --function functionName --stage dev --region us-east-1 +``` + +This example will invoke your deployed function named `functionName` in region `us-east-1` in stage `dev`. This will +output the result of the invocation in your terminal. + +#### Function invocation with data + +```bash +serverless invoke --function functionName --stage dev --region us-east-1 --data "hello world" +``` + +#### Function invocation with data from standard input + +```bash +node dataGenerator.js | serverless invoke --function functionName --stage dev --region us-east-1 +``` + +#### Function invocation with logging + +```bash +serverless invoke --function functionName --stage dev --region us-east-1 --log +``` + +Just like the first example, but will also outputs logging information about your invocation. + +#### Function invocation with data passing + +```bash +serverless invoke --function functionName --stage dev --region us-east-1 --path lib/data.json +``` + +This example will pass the json data in the `lib/data.json` file (relative to the root of the service) while invoking +the specified/deployed function. diff --git a/docs/providers/openwhisk/cli-reference/logs.md b/docs/providers/openwhisk/cli-reference/logs.md new file mode 100644 index 000000000..b364e79ef --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/logs.md @@ -0,0 +1,79 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/logs) + + +# Logs + +Lets you watch the logs of a specific function. + +```bash +serverless logs -f hello +``` + +## Options + +- `--function` or `-f` The function you want to fetch the logs for. **Required** +- `--stage` or `-s` The stage you want to view the function logs for. If not provided, the plugin will use the default stage listed in `serverless.yml`. If that doesn't exist either it'll just fetch the logs from the `dev` stage. +- `--region` or `-r` The region you want to view the function logs for. If not provided, the plugin will use the default region listed in `serverless.yml`. If that doesn't exist either it'll just fetch the logs from the `us-east-1` region. +- `--startTime` A specific unit in time to start fetching logs from (ie: `2010-10-20` or `1469705761`). Here's a list of the supported string formats: + +```bash +30m # since 30 minutes ago +2h # since 2 hours ago +3d # since 3 days ago + +2013-02-08 # A calendar date part +2013-W06-5 # A week date part +2013-039 # An ordinal date part + +20130208 # Basic (short) full date +2013W065 # Basic (short) week, weekday +2013W06 # Basic (short) week only +2013050 # Basic (short) ordinal date + +2013-02-08T09 # An hour time part separated by a T +20130208T080910,123 # Short date and time up to ms, separated by comma +20130208T080910.123 # Short date and time up to ms +20130208T080910 # Short date and time up to seconds +20130208T0809 # Short date and time up to minutes +20130208T08 # Short date and time, hours only +``` + +- `--filter` You can specify a filter string to filter the log output. This is useful if you want to to get the `error` logs for example. +- `--tail` or `-t` You can optionally tail the logs and keep listening for new logs in your terminal session by passing this option. +- `--interval` or `-i` If you choose to tail the output, you can control the interval at which the framework polls the logs with this option. The default is `1000`ms. + +## Examples + +### AWS + +**Note:** There's a small lag between invoking the function and actually having the log event registered in CloudWatch. So it takes a few seconds for the logs to show up right after invoking the function. + +```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 +serverless logs -f hello -t +``` + +Serverless will tail the CloudWatch log output and print new log messages coming in. + +```bash +serverless logs -f hello --filter serverless +``` +This will fetch only the logs that contain the string `serverless` diff --git a/docs/providers/openwhisk/cli-reference/metrics.md b/docs/providers/openwhisk/cli-reference/metrics.md new file mode 100644 index 000000000..64a3c98bf --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/metrics.md @@ -0,0 +1,63 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/metrics) + + +# Metrics + +Lets you watch the metrics of a specific function. + +```bash +serverless metrics +``` + +## Options + +- `--function` or `-f` The function you want to fetch the metrics for. +- `--stage` or `-s` The stage you want to view the function metrics for. If not provided, the plugin will use the default stage listed in `serverless.yml`. If that doesn't exist either it'll just fetch the metrics from the `dev` stage. +- `--region` or `-r` The region you want to view the function metrics for. If not provided, the plugin will use the default region listed in `serverless.yml`. If that doesn't exist either it'll just fetch the metrics from the `us-east-1` region. +- `--startTime` A specific unit in time to start fetching metrics from (ie: `2010-10-20`, `1469705761`, `30m` (30 minutes ago), `2h` (2 days ago) or `3d` (3 days ago)). Date formats should be written in ISO 8601. Defaults to 24h ago. +- `--endTime` A specific unit in time to end fetching metrics from (ie: `2010-10-21` or `1469705761`). Date formats should be written in ISO 8601. Defaults to now. + +## Examples + +**Note:** There's a small lag between invoking the function and actually having access to the metrics. It takes a few seconds for the metrics to show up right after invoking the function. + +### See service wide metrics for the last 24h + +```bash +serverless metrics +``` + +Displays service wide metrics for the last 24h. + +### See service wide metrics for a specific timespan + +```bash +serverless metrics --startTime 2016-01-01 --endTime 2016-01-02 +``` + +Displays service wide metrics for the time between January 1, 2016 and January 2, 2016. + +### See all metrics for the function `hello` of the last 24h + +```bash +serverless metrics --function hello +``` + +Displays all `hello` function metrics for the last 24h. + +### See metrics for the function `hello` of a specific timespan + +```bash +serverless metrics --function hello --startTime 2016-01-01 --endTime 2016-01-02 +``` + +Displays all `hello` function metrics for the time between January 1, 2016 and January 2, 2016. diff --git a/docs/providers/openwhisk/cli-reference/remove.md b/docs/providers/openwhisk/cli-reference/remove.md new file mode 100644 index 000000000..65aa190c6 --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/remove.md @@ -0,0 +1,37 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/remove) + + +# Remove + +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 + +### Removal of service in specific stage and region + +```bash +serverless remove --stage dev --region us-east-1 +``` + +This example will remove the deployed service of your current working directory with the stage `dev` and the region `us-east-1`. diff --git a/docs/providers/openwhisk/cli-reference/rollback.md b/docs/providers/openwhisk/cli-reference/rollback.md new file mode 100644 index 000000000..013677d9d --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/rollback.md @@ -0,0 +1,77 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/rollback) + + + +# Rollback + +Rollback the Serverless service to a specific deployment. + +```bash +serverless rollback --timestamp timestamp +``` + +## 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` + +## Examples + +### AWS + +At first you want to run `serverless deploy list` to show your existing deployments. This will provide you with a list of the deployments stored in your S3 bucket. You can then use the timestamp of one of these deployments to set your infrastructure stack to this specific deployment. + +**Example:** + +``` +$ serverless deploy list +Serverless: Listing deployments: +Serverless: ------------- +Serverless: Timestamp: 1476790110568 +Serverless: Datetime: 2016-10-18T11:28:30.568Z +Serverless: Files: +Serverless: - compiled-cloudformation-template.json +Serverless: - mail-service.zip +Serverless: ------------- +Serverless: Timestamp: 1476889476243 +Serverless: Datetime: 2016-10-19T15:04:36.243Z +Serverless: Files: +Serverless: - compiled-cloudformation-template.json +Serverless: - mail-service.zip +Serverless: ------------- +Serverless: Timestamp: 1476893957131 +Serverless: Datetime: 2016-10-19T16:19:17.131Z +Serverless: Files: +Serverless: - compiled-cloudformation-template.json +Serverless: - mail-service.zip +Serverless: ------------- +Serverless: Timestamp: 1476895175540 +Serverless: Datetime: 2016-10-19T16:39:35.540Z +Serverless: Files: +Serverless: - compiled-cloudformation-template.json +Serverless: - mail-service.zip +Serverless: ------------- +Serverless: Timestamp: 1476993293402 +Serverless: Datetime: 2016-10-20T19:54:53.402Z +Serverless: Files: +Serverless: - compiled-cloudformation-template.json +Serverless: - mail-service.zip + +$ serverless rollback -t 1476893957131 +Serverless: Updating Stack... +Serverless: Checking Stack update progress... +..... +Serverless: Stack update finished... +``` diff --git a/docs/providers/openwhisk/cli-reference/slstats.md b/docs/providers/openwhisk/cli-reference/slstats.md new file mode 100644 index 000000000..23a5ee1aa --- /dev/null +++ b/docs/providers/openwhisk/cli-reference/slstats.md @@ -0,0 +1,36 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/slstats) + + +# Serverless Statistics + +This plugin implements a way to toggle framework statistics. + +```bash +serverless slstats --enable +``` + +## Options +- `--enable` or `-e`. +- `--disable` or `-d` + +## Provided lifecycle events +- `slstats:slstats` + +## Examples + +### Disabling it + +```bash +serverless slstats --disable +``` + +This example will disable framework statistics. diff --git a/docs/providers/openwhisk/events/README.md b/docs/providers/openwhisk/events/README.md new file mode 100644 index 000000000..3efa50d92 --- /dev/null +++ b/docs/providers/openwhisk/events/README.md @@ -0,0 +1,19 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/) + + +# Serverless AWS Lambda Events + +Welcome to the Serverless AWS Lambda Events Glossary! + +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](https://gitter.im/serverless/serverless) + +**Note:** Before continuing [AWS system credentials](../guide/credentials.md) are required for using the CLI. diff --git a/docs/providers/openwhisk/events/alexa-skill.md b/docs/providers/openwhisk/events/alexa-skill.md new file mode 100644 index 000000000..915464bcf --- /dev/null +++ b/docs/providers/openwhisk/events/alexa-skill.md @@ -0,0 +1,27 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/alexa-skill) + + +# Alexa Skill + +## Event definition + +This will enable your Lambda function to be called by an Alexa skill kit. + +```yml +functions: + mySkill: + handler: mySkill.handler + events: + - alexaSkill +``` + +You can find detailed guides on how to create an Alexa Skill with Serverless using NodeJS [here](https://github.com/serverless/examples/tree/master/aws-node-alexa-skill) as well as in combination with Python [here](https://github.com/serverless/examples/tree/master/aws-python-alexa-skill). diff --git a/docs/providers/openwhisk/events/apigateway.md b/docs/providers/openwhisk/events/apigateway.md new file mode 100644 index 000000000..da0b22511 --- /dev/null +++ b/docs/providers/openwhisk/events/apigateway.md @@ -0,0 +1,645 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/apigateway) + + +# API Gateway + +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 two ways you can configure your HTTP endpoints to integrate with your AWS Lambda Functions: +* lambda-proxy (Recommended) +* lambda + +The difference between these is `lambda-proxy` 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. + +By default, the Framework uses the `lambda-proxy` method (i.e., everything is passed into your Lambda), and nothing is required by you to enable it. + +## Lambda Proxy Integration + +### Simple HTTP Endpoint + +This setup specifies that the `hello` function should be run when someone accesses the API gateway at `hello` via +a `GET` request. + +Here's an example: + +```yml +# serverless.yml + +functions: + index: + handler: handler.hello + events: + - http: GET hello +``` + +```javascript +// handler.js + +'use strict'; + +module.exports.hello = function(event, context, callback) { + + 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!" }) + }; + + callback(null, response); +}; +``` + +**Note:** When the body is a JSON-Document, you must parse it yourself: +``` +JSON.parse(event.body); +``` + +### HTTP Endpoint with Extended Options + +Here we've defined an POST endpoint for the path `posts/create`. + +```yml +# serverless.yml + +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post +``` + +### Enabling CORS +To set CORS configurations for your HTTP endpoints, simply modify your event configurations as follows: + +```yml +# serverless.yml + +functions: + hello: + handler: handler.hello + events: + - http: + path: hello + method: get + cors: true +``` + +If you want to use CORS with the lambda-proxy integration, remember to include `Access-Control-Allow-Origin` in your returned headers object, like this: + +```javascript +// handler.js + +'use strict'; + +module.exports.hello = function(event, context, callback) { + + const response = { + statusCode: 200, + headers: { + "Access-Control-Allow-Origin" : "*" // Required for CORS support to work + }, + body: JSON.stringify({ "message": "Hello World!" }) + }; + + callback(null, response); +}; +``` + +### 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. + +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: + +```yml +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post + authorizer: authorizerFunc + authorizerFunc: + handler: handlers.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: + +```yml +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post + authorizer: + name: authorizerFunc + resultTtlInSeconds: 0 + identitySource: method.request.header.Authorization + identityValidationExpression: someRegex + authorizerFunc: + handler: handlers.authorizerFunc +``` + +If the Authorizer function does not exist in your service but exists in AWS, you can provide the ARN of the Lambda +function instead of the function name, as shown in the following example: + +```yml +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post + authorizer: xxx:xxx:Lambda-Name +``` + +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: + +```yml +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post + authorizer: + arn: xxx:xxx:Lambda-Name + resultTtlInSeconds: 0 + identitySource: method.request.header.Authorization + identityValidationExpression: someRegex +``` + +You can also configure an existing Cognito User Pool as the authorizer, as shown +in the following example: + +```yml +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post + authorizer: + arn: arn:aws:cognito-idp:us-east-1:xxx:userpool/us-east-1_ZZZ +``` + +By default the `sub` claim will be exposed in `events.cognitoPoolClaims`, you can add extra claims like so: + +```yml +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post + integration: lambda + authorizer: + arn: arn:aws:cognito-idp:us-east-1:xxx:userpool/us-east-1_ZZZ + claims: + - email + - nickname +``` + +Note: Since claims must be explicitly listed to be exposed, you must use `integration: lambda` integration type to access any claims. + +### Catching Exceptions In Your Lambda Function + +In case an exception is thrown in your lambda function AWS will send an error message with `Process exited before completing request`. This will be caught by the regular expression for the 500 HTTP status and the 500 status will be returned. + +### Setting API keys for your Rest API + +**Note:** Due to a CloudFormation restriction you need to wire up API Keys and usage plans manually in the AWS console. + +You can specify a list of API keys to be used by your service Rest API by adding an `apiKeys` array property to the +`provider` object in `serverless.yml`. You'll also need to explicitly specify which endpoints are `private` and require +one of the api keys to be included in the request by adding a `private` boolean property to the `http` event object you +want to set as private. API Keys are created globally, so if you want to deploy your service to different stages make sure +your API key contains a stage variable as defined below. + +Here's an example configuration for setting API keys for your service Rest API: + +```yml +service: my-service +provider: + name: aws + apiKeys: + - myFirstKey + - ${opt:stage}-myFirstKey + - ${env:MY_API_KEY} # you can hide it in a serverless variable +functions: + hello: + events: + - http: + path: user/create + method: get + private: true +``` + +Please note that those are the API keys names, not the actual values. Once you deploy your service, the value of those API keys will be auto generated by AWS and printed on the screen for you to use. + +Clients connecting to this Rest API will then need to set any of these API keys values in the `x-api-key` header of their request. This is only necessary for functions where the `private` property is set to true. + +## Lambda Integration + +This method is more complicated and involves a lot more configuration of the `http` event syntax. + +### Request Parameters + +To pass optional and required parameters to your functions, so you can use them in API Gateway tests and SDK generation, marking them as `true` will make them required, `false` will make them optional. + +```yml +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post + integration: lambda + request: + parameters: + querystrings: + url: true + headers: + foo: false + bar: true + paths: + bar: false +``` + +In order for path variables to work, API Gateway also needs them in the method path itself, like so: + +```yml +functions: + create: + handler: posts.post_detail + events: + - http: + path: posts/{id} + method: get + integration: lambda + request: + parameters: + paths: + id: true +``` + +### Request templates + +#### Default Request Templates + +Serverless ships with the following default request templates you can use out of the box: + +1. `application/json` +2. `application/x-www-form-urlencoded` + +Both templates give you access to the following properties you can access with the help of the `event` object: + +- body +- method +- principalId +- stage +- headers +- query +- path +- identity +- stageVariables + +#### Custom Request Templates + +However you can define and use your own request templates as follows (you can even overwrite the default request templates +by defining a new request template for an existing content type): + +```yml +functions: + create: + handler: posts.create + events: + - http: + method: get + path: whatever + integration: lambda + request: + template: + text/xhtml: '{ "stage" : "$context.stage" }' + application/json: '{ "httpMethod" : "$context.httpMethod" }' +``` + +**Note:** The templates are defined as plain text here. However you can also reference an external file with the help of the `${file(templatefile)}` syntax. + +**Note 2:** In .yml, strings containing `:`, `{`, `}`, `[`, `]`, `,`, `&`, `*`, `#`, `?`, `|`, `-`, `<`, `>`, `=`, `!`, `%`, `@`, `` ` `` must be quoted. + +If you want to map querystrings to the event object, you can use the `$input.params('hub.challenge')` syntax from API Gateway, as follows: + +```yml +functions: + create: + handler: posts.create + events: + - http: + method: get + path: whatever + integration: lambda + request: + template: + application/json: '{ "foo" : "$input.params(''bar'')" }' +``` + +**Note:** Notice when using single-quoted strings, any single quote `'` inside its contents must be doubled (`''`) to escape it. +You can then access the query string `https://example.com/dev/whatever?bar=123` by `event.foo` in the lambda function. +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): + +```yml +functions: + create: + handler: posts.create + events: + - http: + method: get + path: whatever + integration: lambda + request: + passThrough: NEVER +``` + +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 | + +See the [api gateway documentation](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#integration-passthrough-behaviors) for detailed descriptions of these options. + +**Notes:** + +- A missing/empty request Content-Type is considered to be the API Gateway default (`application/json`) +- API Gateway docs refer to "WHEN_NO_TEMPLATE" (singular), but this will fail during creation as the actual value should be "WHEN_NO_TEMPLATES" (plural) + +### Responses + +Serverless lets you setup custom headers and a response template for your `http` event. + +#### Custom Response Headers + +Here's an example which shows you how you can setup a custom response header: + +```yml +functions: + create: + handler: posts.create + events: + - http: + method: get + path: whatever + integration: lambda + response: + headers: + Content-Type: integration.response.header.Content-Type + Cache-Control: "'max-age=120'" +``` + +**Note:** You're able to use the [integration response variables](http://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#mapping-response-parameters) +for your header values. Headers are passed to API Gateway exactly like you define them. Passing the `Cache-Control` header +as `"'max-age=120'"` means API Gateway will receive the value as `'max-age=120'` (enclosed with single quotes). + +### Custom Response Templates + +Sometimes you'll want to define a custom response template API Gateway should use to transform your lambdas output. +Here's an example which will transform the return value of your lambda so that the browser renders it as HTML: + +```yml +functions: + create: + handler: posts.create + events: + - http: + method: get + path: whatever + integration: lambda + response: + headers: + Content-Type: "'text/html'" + template: $input.path('$') +``` + +**Note:** The template is defined as plain text here. However you can also reference an external file with the help of +the `${file(templatefile)}` syntax. + +### Status codes + +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. + +#### 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 | + +#### Using Status Codes + +To return a given status code you simply need to add square brackets with the status code of your choice to your +returned message like this: `[401] You are not authorized to access this resource!`. + +Here's an example which shows you how you can raise a 404 HTTP status from within your lambda function. + +```javascript +module.exports.hello = (event, context, callback) => { + callback(new Error('[404] Not found')); +} +``` + +#### Custom Status Codes + +You can override the defaults status codes supplied by Serverless. You can use this to change the default status code, add/remove status codes, or change the templates and headers used for each status code. Use the pattern key to change the selection process that dictates what code is returned. + +If you specify a status code with a pattern of '' that will become the default response code. See below on how to change the default to 201 for post requests. + +If you omit any default status code. A standard default 200 status code will be generated for you. + +```yml +functions: + create: + handler: posts.create + events: + - http: + method: post + path: whatever + integration: lambda + response: + headers: + 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'" +``` + +You can also create varying response templates for each code and content type by creating an object with the key as the content type + +```yml +functions: + create: + handler: posts.create + events: + - http: + method: post + path: whatever + integration: lambda + response: + headers: + 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'" +``` + +## Enabling CORS with the Lambda Integration Method + +```yml +functions: + hello: + handler: handler.hello + events: + - http: + path: user/create + method: get + integration: lambda + cors: true +``` + +You can equally set your own attributes: + +```yml +functions: + hello: + handler: handler.hello + events: + - http: + path: user/create + method: get + integration: lambda + cors: + origins: + - '*' + headers: + - Content-Type + - X-Amz-Date + - Authorization + - X-Api-Key + - X-Amz-Security-Token +``` + +This example is the default setting and is exactly the same as the previous example. The `Access-Control-Allow-Methods` header is set automatically, based on the endpoints specified in your service configuration with CORS enabled. + +**Note:** If you are using the default lambda proxy integration, remember to include `Access-Control-Allow-Origin` in your returned headers object otherwise CORS will fail. + +``` +module.exports.hello = (event, context, callback) => { + return callback(null, { + statusCode: 200, + headers: { + 'Access-Control-Allow-Origin': '*' + }, + body: 'Hello World!' + }); +} +``` + +## Setting an HTTP Proxy on API Gateway + +To set up an HTTP proxy, you'll need two CloudFormation templates, one for the endpoint (known as resource in CF), and +one for method. These two templates will work together to construct your proxy. So if you want to set `your-app.com/serverless` as a proxy for `serverless.com`, you'll need the following two templates in your `serverless.yml`: + +```yml +service: service-name +provider: aws +functions: + ... + +resources: + Resources: + ProxyResource: + Type: AWS::ApiGateway::Resource + Properties: + ParentId: + Fn::GetAtt: + - ApiGatewayRestApi # our default Rest API logical ID + - RootResourceId + PathPart: serverless # the endpoint in your API that is set as proxy + RestApiId: + Ref: ApiGatewayRestApi + ProxyMethod: + Type: AWS::ApiGateway::Method + Properties: + ResourceId: + Ref: ProxyResource + RestApiId: + Ref: ApiGatewayRestApi + HttpMethod: GET # the method of your proxy. Is it GET or POST or ... ? + MethodResponses: + - StatusCode: 200 + Integration: + IntegrationHttpMethod: POST + Type: HTTP + Uri: http://serverless.com # the URL you want to set a proxy to + IntegrationResponses: + - StatusCode: 200 +``` + +There's a lot going on in these two templates, but all you need to know to set up a simple proxy is setting the method & +endpoint of your proxy, and the URI you want to set a proxy to. + +Now that you have these two CloudFormation templates defined in your `serverless.yml` file, you can simply run +`serverless deploy` and that will deploy these custom resources for you along with your service and set up a proxy on your Rest API. diff --git a/docs/providers/openwhisk/events/iot.md b/docs/providers/openwhisk/events/iot.md new file mode 100644 index 000000000..4ba21e9a7 --- /dev/null +++ b/docs/providers/openwhisk/events/iot.md @@ -0,0 +1,71 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/iot) + + +# IoT + +## Simple event definition + +This will enable your Lambda function to be called by an AWS IoT rule. + +```yml +functions: + myIoT: + handler: myIoT.handler + events: + - iot: + sql: "SELECT * FROM 'some_topic'" +``` + +## Enabling / Disabling + +**Note:** `iot` events are enabled by default. + +This will create and attach a disabled `iot` event for the `myIoT` function. + +```yml +functions: + myIoT: + handler: myIoT.handler + events: + - iot: + sql: "SELECT * FROM 'some_topic'" + enabled: false +``` + +## Specify Name and Description + +Name and Description can be specified with the help of the `name` and `description` properties. + +```yml +functions: + myIoT: + handler: myIoT.handler + events: + - iot: + name: "myIotEvent" + sql: "SELECT * FROM 'some_topic'" + description: "My IoT Event Description" +``` + +## Specify SQL Versions + +[SQL Versions](http://docs.aws.amazon.com/iot/latest/developerguide/iot-rule-sql-version.html) can be specified for an `iot` event. However the `sqlVersion` is not a required property. + +```yml +functions: + myIoT: + handler: myIoT.handler + events: + - iot: + sql: "SELECT * FROM 'some_topic'" + sqlVersion: "beta" +``` diff --git a/docs/providers/openwhisk/events/s3.md b/docs/providers/openwhisk/events/s3.md new file mode 100644 index 000000000..673fd7c78 --- /dev/null +++ b/docs/providers/openwhisk/events/s3.md @@ -0,0 +1,75 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/s3) + + +# S3 + +## Simple event definition + +This will create a `photos` bucket which fires the `resize` function when an object is added or modified inside the bucket. A hardcoded bucket name can lead to issues as a bucket name can only be used once in S3. For that you can use the [Serverless Variable syntax](../guide/variables.md) and add dynamic elements to the bucket name. + +```yaml +functions: + resize: + handler: resize.handler + events: + - s3: photos +``` + +## Setting the specific trigger event + +This will create a bucket `photos`. The `users` function is called whenever an object is removed from the bucket. Check out the [AWS documentation](http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html#notification-how-to-event-types-and-destinations) to learn more about all the different event types that can be configured. + +```yaml +functions: + users: + handler: users.handler + events: + - s3: + bucket: photos + event: s3:ObjectRemoved:* +``` + +## Setting filter rules + +This will create a bucket `photos`. The `users` function is called whenever an image with `.jpg` extension is uploaded to folder `uploads` in the bucket. Check out the [AWS documentation](http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html#notification-how-to-filtering) to learn more about all the different filter types that can be configured. + +```yaml +functions: + users: + handler: users.handler + events: + - s3: + bucket: photos + event: s3:ObjectCreated:* + rules: + - prefix: uploads/ + - suffix: .jpg +``` + +## Triggering separate functions from the same bucket + +You're able to repeat the S3 event configuration in the same or separate functions so one bucket can call these functions. One caveat though is that you can't repeat the same configuration in both functions, e.g. the event type has to be different. + +The following example will work: + +```yaml +functions: + users: + handler: users.handler + events: + - s3: + bucket: photos + event: s3:ObjectCreated:* + - s3: + bucket: photos + event: s3:ObjectRemoved:* +``` diff --git a/docs/providers/openwhisk/events/schedule.md b/docs/providers/openwhisk/events/schedule.md new file mode 100644 index 000000000..7e2178c8c --- /dev/null +++ b/docs/providers/openwhisk/events/schedule.md @@ -0,0 +1,62 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/schedule) + + +# Schedule + +The following config will attach a schedule event and causes the function `crawl` to be called every 2 hours. The configuration allows you to attach multiple schedules to the same function. You can either use the `rate` or `cron` syntax. Take a look at the [AWS schedule syntax documentation](http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html) for more details. + +```yaml +functions: + crawl: + handler: crawl + events: + - schedule: rate(2 hours) + - schedule: cron(0 12 * * ? *) +``` + +## Enabling / Disabling + +**Note:** `schedule` events are enabled by default. + +This will create and attach a schedule event for the `aggregate` function which is disabled. If enabled it will call +the `aggregate` function every 10 minutes. + +```yaml +functions: + aggregate: + handler: statistics.handler + events: + - schedule: + rate: rate(10 minutes) + enabled: false + input: + key1: value1 + key2: value2 + stageParams: + stage: dev + - schedule: + rate: cron(0 12 * * ? *) + enabled: false + inputPath: '$.stageVariables' +``` + +## Specify Name and Description + +Name and Description can be specified for a schedule event. These are not required properties. + +```yaml +events: + - schedule: + name: your-scheduled-rate-event-name + description: 'your scheduled rate event description' + rate: rate(2 hours) +``` diff --git a/docs/providers/openwhisk/events/sns.md b/docs/providers/openwhisk/events/sns.md new file mode 100644 index 000000000..fa0efbffc --- /dev/null +++ b/docs/providers/openwhisk/events/sns.md @@ -0,0 +1,69 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/sns) + + +# SNS + +In the following example we create a new SNS topic with the name `dispatch` which is bound to the `dispatcher` function. The function will be called every time a message is sent to the `dispatch` topic. + +```yml +functions: + dispatcher: + handler: dispatcher.dispatch + events: + - sns: dispatch +``` + +You're also able to add the same SNS topic to multiple functions: + +```yml +functions: + dispatcher: + handler: dispatcher.dispatch + events: + - sns: dispatch + dispatcher2: + handler: dispatcher2.dispatch + events: + - sns: dispatch +``` + +This will run both functions for a message sent to the dispatch topic. + +## Creating the permission for a pre-existing topic + +If you want to run a function from a preexisting SNS topic you need to connect the topic to a Lambda function yourself. By defining a topic arn inside of the SNS topic we're able to set up the Lambda Permission so SNS is allowed to call this function. + +```yml +functions: + dispatcher: + handler: dispatcher.dispatch + events: + - sns: arn:xxx +``` + +Just make sure your function is already subscribed to the topic, as there's no way to add subscriptions to pre-existing topics in CF. The framework will just give permission to SNS to invoke the function. + +## Setting a display name + +This event definition ensures that the `aggregator` function get's called every time a message is sent to the +`aggregate` topic. `Data aggregation pipeline` will be shown in the AWS console so that the user can understand what the +SNS topic is used for. + +```yml +functions: + aggregator: + handler: aggregator.handler + events: + - sns: + topicName: aggregate + displayName: Data aggregation pipeline +``` diff --git a/docs/providers/openwhisk/events/streams.md b/docs/providers/openwhisk/events/streams.md new file mode 100644 index 000000000..9e506e3de --- /dev/null +++ b/docs/providers/openwhisk/events/streams.md @@ -0,0 +1,44 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/streams) + + +# DynamoDB / Kinesis Streams + +This setup specifies that the `compute` function should be triggered whenever the corresponding DynamoDB table is modified (e.g. a new entry is added). + +**Note:** The `stream` event will hook up your existing streams to a Lambda function. Serverless won't create a new stream for you. + +```yml +functions: + compute: + handler: handler.compute + events: + - stream: arn:aws:dynamodb:region:XXXXXX:table/foo/stream/1970-01-01T00:00:00.000 +``` + +## Setting the BatchSize and StartingPosition + +This configuration sets up a disabled Kinesis stream event for the `preprocess` function which has a batch size of `100`. The starting position is +`LATEST`. + +**Note:** The `stream` event will hook up your existing streams to a Lambda function. Serverless won't create a new stream for you. + +```yml +functions: + preprocess: + handler: handler.preprocess + events: + - stream: + arn: arn:aws:kinesis:region:XXXXXX:stream/foo + batchSize: 100 + startingPosition: LATEST + enabled: false +``` diff --git a/docs/providers/openwhisk/examples/README.md b/docs/providers/openwhisk/examples/README.md new file mode 100644 index 000000000..d180c60f6 --- /dev/null +++ b/docs/providers/openwhisk/examples/README.md @@ -0,0 +1,31 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/) + + +# 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://github.com/serverless/examples/tree/master/aws-node-auth0-custom-authorizers-api)
Demonstration of protecting API gateway endpoints with auth0 | nodeJS | +| [Env Variables Encrypted In A File](https://github.com/serverless/examples/tree/master/aws-node-env-variables-encrypted-in-a-file)
Serverless example managing secrets in an encrypted file | nodeJS | +| [Serverless Node Env Variables](https://github.com/serverless/examples/tree/master/aws-node-env-variables)
This example demonstrates how to use environment variables for AWS Lambdas. | nodeJS | +| [Fetch File And Store In S3](https://github.com/serverless/examples/tree/master/aws-node-fetch-file-and-store-in-s3)
Fetch an image from remote source (URL) and then upload the image to a S3 bucket. | nodeJS | +| [Function Compiled With Babel](https://github.com/serverless/examples/tree/master/aws-node-function-compiled-with-babel)
Demonstrating how to compile all your code with Babel | nodeJS | +| [Serverless Rest With Dynamodb](https://github.com/serverless/examples/tree/master/aws-node-rest-api-with-dynamodb)
Serverless CRUD service exposing a REST HTTP interface | nodeJS | +| [Serverless Aws Cron Job Example](https://github.com/serverless/examples/tree/master/aws-node-scheduled-cron)
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://github.com/serverless/examples/tree/master/aws-node-serve-dynamic-html-via-http-endpoint)
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://github.com/serverless/examples/tree/master/aws-node-simple-http-endpoint)
Example demonstrates how to setup a simple HTTP GET endpoint | nodeJS | +| [Single Page App Via Cloudfront](https://github.com/serverless/examples/tree/master/aws-node-single-page-app-via-cloudfront)
Demonstrating how to deploy a Single Page Application with Serverless | nodeJS | +| [Serverless Single Page App Plugin](https://github.com/serverless/examples/tree/master/aws-node-single-page-app-via-cloudfront/serverless-single-page-app-plugin)
A plugin to simplify deploying Single Page Application using S3 and CloudFront | nodeJS | +| [Serverless Data Pipeline](https://github.com/serverless/examples/tree/master/aws-node-text-analysis-via-sns-post-processing)
Example demonstrates how to setup a simple data processing pipeline | nodeJS | +| [Aws Python Simple Http Endpoint](https://github.com/serverless/examples/tree/master/aws-python-simple-http-endpoint)
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://gitter.im/serverless/serverless) diff --git a/docs/providers/openwhisk/examples/hello-world/README.md b/docs/providers/openwhisk/examples/hello-world/README.md new file mode 100644 index 000000000..d1f1d070a --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/README.md @@ -0,0 +1,22 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/) + + +# Hello World Serverless Example 🌍 + +Welcome to the Hello World example. + +Pick your language of choice: + +* [JavaScript](./node) +* [Python](./python) +* [csharp](./csharp) + +[View all examples](https://www.serverless.com/framework/docs/providers/aws/examples/) diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/AssemblyInfo.cs b/docs/providers/openwhisk/examples/hello-world/csharp/AssemblyInfo.cs new file mode 100644 index 000000000..59e636f29 --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/csharp/AssemblyInfo.cs @@ -0,0 +1,3 @@ +using Amazon.Lambda.Core; + +[assembly:LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))] diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/Handler.cs b/docs/providers/openwhisk/examples/hello-world/csharp/Handler.cs new file mode 100644 index 000000000..2b6f9728e --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/csharp/Handler.cs @@ -0,0 +1,36 @@ +using System; + +namespace AwsDotnetCsharp +{ + public class Handler + { + public Response Hello(Request request) + { + return new Response("Go Serverless v1.0! Your function executed successfully!", request); + } + } + + public class Response + { + public string Message {get; set;} + public Request Request {get; set;} + + public Response(string message, Request request){ + Message = message; + Request = request; + } + } + + public class Request + { + public string Key1 {get; set;} + public string Key2 {get; set;} + public string Key3 {get; set;} + + public Request(string key1, string key2, string key3){ + Key1 = key1; + Key2 = key2; + Key3 = key3; + } + } +} diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/README.md b/docs/providers/openwhisk/examples/hello-world/csharp/README.md new file mode 100644 index 000000000..3fa1f425e --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/csharp/README.md @@ -0,0 +1,52 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/csharp/) + + +# Hello World C# Example + +Make sure `serverless` is installed. [See installation guide](../../../guide/installation.md). + +## 1. Create a service +`serverless create --template aws-csharp --path myService` or `sls create --template aws-csharp --path myService`, where 'myService' is a new folder to be created with template service files. Change directories into this new folder. + +## 2. Build using .NET CLI tools and create zip package + +``` +# Linux or OSX +./build.sh +``` + +``` +# Windows PowerShell +./build.ps1 +``` + +## 3. Deploy +`serverless deploy` or `sls deploy`. `sls` is shorthand for the Serverless CLI command + +## 4. Invoke deployed function +`serverless invoke --function hello` or `serverless invoke -f hello` + +`-f` is shorthand for `--function` + +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 just deployed and run your Hello World function! diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/project.json b/docs/providers/openwhisk/examples/hello-world/csharp/project.json new file mode 100644 index 000000000..da4b806ad --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/csharp/project.json @@ -0,0 +1,33 @@ +{ + "version": "1.0.0-*", + "buildOptions": { + "outputName": "CsharpHandlers" + }, + + "dependencies": { + "Microsoft.NETCore.App": { + "type": "platform", + "version": "1.0.1" + }, + + "Newtonsoft.Json": "9.0.1", + + "Amazon.Lambda.Core": "1.0.0*", + "Amazon.Lambda.Serialization.Json": "1.0.0", + + "Amazon.Lambda.Tools" : { + "type" :"build", + "version":"0.9.0-preview1" + } + }, + + "tools": { + "Amazon.Lambda.Tools" : "0.9.0-preview1" + }, + + "frameworks": { + "netcoreapp1.0": { + "imports": "dnxcore50" + } + } +} diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/serverless.yml b/docs/providers/openwhisk/examples/hello-world/csharp/serverless.yml new file mode 100644 index 000000000..4f8212227 --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/csharp/serverless.yml @@ -0,0 +1,84 @@ +# Welcome to Serverless! +# +# This file is the main config file for your service. +# It's very minimal at this point and uses default values. +# You can always add more config options for more control. +# We've included some commented out config examples here. +# Just uncomment any of them to get that config option. +# +# For full config options, check the docs: +# docs.serverless.com +# +# Happy Coding! + +service: aws-csharp # NOTE: update this with your service name + +# You can pin your service to only deploy with a specific Serverless version +# Check out our docs for more details +# frameworkVersion: "=X.X.X" + +provider: + name: aws + runtime: dotnetcore1.0 + +# you can overwrite defaults here +# stage: dev +# region: us-east-1 + +# you can add statements to the Lambda function's IAM Role here +# 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" + +# you can define service wide environment variables here +# environment: +# variable1: value1 + +# you can add packaging information here +package: + artifact: bin/release/netcoreapp1.0/publish/deploy-package.zip +# exclude: +# - exclude-me.js +# - exclude-me-dir/** + +functions: + hello: + handler: CsharpHandlers::AwsDotnetCsharp.Handler::Hello + +# The following are a few example events you can configure +# NOTE: Please make sure to change your handler code to work with those events +# Check the event documentation for details +# events: +# - http: +# path: users/create +# method: get +# - s3: ${env:BUCKET} +# - schedule: rate(10 minutes) +# - sns: greeter-topic +# - stream: arn:aws:dynamodb:region:XXXXXX:table/foo/stream/1970-01-01T00:00:00.000 + +# Define function environment variables here +# environment: +# variable2: value2 + +# you can add CloudFormation resource templates here +#resources: +# Resources: +# NewResource: +# Type: AWS::S3::Bucket +# Properties: +# BucketName: my-new-bucket +# Outputs: +# NewOutput: +# Description: "Description for the output" +# Value: "Some output value" diff --git a/docs/providers/openwhisk/examples/hello-world/node/README.md b/docs/providers/openwhisk/examples/hello-world/node/README.md new file mode 100644 index 000000000..792bd4e8d --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/node/README.md @@ -0,0 +1,36 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/node/) + + +# Hello World Node.js Example + +Make sure `serverless` is installed. [See installation guide](../../../guide/installation.md). + +## 1. Create a service +`serverless create --template aws-nodejs --path myService` or `sls create --template aws-nodejs --path myService`, where 'myService' is a new folder to be created with template service files. Change directories into this new folder. + +## 2. Deploy +`serverless deploy` or `sls deploy`. `sls` is shorthand for the Serverless CLI command + +## 3. Invoke deployed function +`serverless invoke --function hello` or `serverless invoke -f hello` + +`-f` is shorthand for `--function` + +In your terminal window you should see the response from AWS Lambda + +```bash +{ + "statusCode": 200, + "body": "{\"message\":\"Go Serverless v1.0! Your function executed successfully!\",\"input\":{}}" +} +``` + +Congrats you have just deployed and run your Hello World function! diff --git a/docs/providers/openwhisk/examples/hello-world/node/handler.js b/docs/providers/openwhisk/examples/hello-world/node/handler.js new file mode 100644 index 000000000..12a311f42 --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/node/handler.js @@ -0,0 +1,11 @@ +'use strict'; + +// Your function handler +module.exports.helloWorldHandler = function (event, context, callback) { + const message = { + message: 'Hello World', + event, + }; + // callback will send message object back + callback(null, message); +}; diff --git a/docs/providers/openwhisk/examples/hello-world/node/serverless.yml b/docs/providers/openwhisk/examples/hello-world/node/serverless.yml new file mode 100644 index 000000000..08bf9b3b8 --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/node/serverless.yml @@ -0,0 +1,10 @@ +# Hello World for AWS Lambda +service: hello-world # Service Name + +provider: + name: aws + runtime: nodejs4.3 + +functions: + helloWorld: + handler: handler.helloWorldHandler diff --git a/docs/providers/openwhisk/examples/hello-world/python/README.md b/docs/providers/openwhisk/examples/hello-world/python/README.md new file mode 100644 index 000000000..d1e432b60 --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/python/README.md @@ -0,0 +1,36 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/python/) + + +# Hello World Python Example + +Make sure `serverless` is installed. [See installation guide](../../../guide/installation.md). + +## 1. Create a service +`serverless create --template aws-python --path myService` or `sls create --template aws-python --path myService`, where 'myService' is a new folder to be created with template service files. Change directories into this new folder. + +## 2. Deploy +`serverless deploy` or `sls deploy`. `sls` is shorthand for the serverless CLI command + +## 3. Invoke deployed function +`serverless invoke --function hello` or `serverless invoke -f hello` + +`-f` is shorthand for `--function` + +In your terminal window you should see the response from AWS Lambda + +```bash +{ + "statusCode": 200, + "body": "{\"message\":\"Go Serverless v1.0! Your function executed successfully!\",\"input\":{}}" +} +``` + +Congrats you have just deployed and ran your Hello World function! diff --git a/docs/providers/openwhisk/examples/hello-world/python/handler.py b/docs/providers/openwhisk/examples/hello-world/python/handler.py new file mode 100644 index 000000000..7ba5ed97f --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/python/handler.py @@ -0,0 +1,6 @@ +def helloWorldHandler(event, context): + message = { + 'message': 'Hello World' + } + + return message diff --git a/docs/providers/openwhisk/examples/hello-world/python/serverless.yml b/docs/providers/openwhisk/examples/hello-world/python/serverless.yml new file mode 100644 index 000000000..0b2f4cae5 --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/python/serverless.yml @@ -0,0 +1,10 @@ +# Hello World for AWS Lambda +service: hello-world # Service Name + +provider: + name: aws + runtime: python2.7 + +functions: + helloWorld: + handler: handler.helloWorldHandler diff --git a/docs/providers/openwhisk/guide/README.md b/docs/providers/openwhisk/guide/README.md new file mode 100644 index 000000000..334316f04 --- /dev/null +++ b/docs/providers/openwhisk/guide/README.md @@ -0,0 +1,19 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/) + + +# Serverless Apache OpenWhisk Guide + +Welcome to the Serverless Apache OpenWhisk Guide! + +Get started with the **[Introduction to the framework](./intro.md)** + +If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](https://gitter.im/serverless/serverless) + +**Note:** Before continuing [Apache OpenWhisk user credentials](./credentials.md) are required for using the CLI. diff --git a/docs/providers/openwhisk/guide/credentials.md b/docs/providers/openwhisk/guide/credentials.md new file mode 100644 index 000000000..8b660ae2c --- /dev/null +++ b/docs/providers/openwhisk/guide/credentials.md @@ -0,0 +1,138 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/credentials) + + +# Credentials + +The Serverless Framework needs access to account credentials for your OpenWhisk provider so that it can create and manage resources on your behalf. + +OpenWhisk is an open-source serverless platform. This means you can either choose to run the platform yourself or choose to use a hosted provider's instance. + +Here we'll provide setup instructions for both options, just pick the one that you're using. + +## Register with OpenWhisk platform (IBM Bluemix) + +IBM's Bluemix cloud platform provides a hosted serverless solution based upon Apache OpenWhisk. + +Here's how to get started… + +- Sign up for a free account @ [https://bluemix.net](https://console.ng.bluemix.net/registration/) + ​ + +IBM Bluemix comes with a [free trial](https://www.ibm.com/cloud-computing/bluemix/pricing?cm_mc_uid=22424350960514851832143&cm_mc_sid_50200000=1485183214) that doesn't need credit card details for the first 30 days. Following the trial, developers have to enrol using a credit card but get a free tier for the platform and services. + +**All IBM Bluemix users get access to the [Free Tier for OpenWhisk](https://console.ng.bluemix.net/openwhisk/learn/pricing). This includes 400,000 GB-seconds of serverless function compute time per month.** + +Additional execution time is charged at $0.000017 per GB-second of execution, rounded to the nearest 100ms. + +### Access Account Credentials + +Once you have signed up for IBM Bluemix, we need to retrieve your account credentials. These are available on [the page](https://console.ng.bluemix.net/openwhisk/learn/cli) about installing the command-line tool from the [service homepage](https://console.ng.bluemix.net/openwhisk/). + +The second point in the instructions contains a command-line which includes the platform endpoint and authentication keys. + +``` +wsk property set --apihost openwhisk.ng.bluemix.net --auth XXX:YYY +``` + +**Make a note of the `apihost` and `auth` command flag values.** + +### (optional) Install command-line utility + +The command-line utility is linked from [the previous page](https://console.ng.bluemix.net/openwhisk/learn/cli). Download and install the binary into a location in your [shell path](http://unix.stackexchange.com/questions/26047/how-to-correctly-add-a-path-to-path). + + + +## Register with OpenWhisk platform (Self-Hosted) + +Following the [Quick Start guide](https://github.com/openwhisk/openwhisk#quick-start) will let you run the platform locally using a Virtual Machine. + +- Download and install [Vagrant](https://www.vagrantup.com/) for your platform. +- Run the following commands to retrieve, build and start an instance of the platform. + +``` +# Clone openwhisk +git clone --depth=1 https://github.com/openwhisk/openwhisk.git + +# Change directory to tools/vagrant +cd openwhisk/tools/vagrant + +# Run script to create vm and run hello action +./hello +``` + +This platform will now be running inside a virtual machine at the following IP address: `192.168.33.13` + +### Access Account Credentials + +The default environment has a guest account configured with the authentication key available here: https://github.com/openwhisk/openwhisk/blob/master/ansible/files/auth.guest + +Use the `192.168.33.13` address as the `apihost` value needed below. + +### (optional) Install command-line utility + +Building OpenWhisk from a cloned repository will result in the generation of the command line interface in `openwhisk/bin/go-cli/`. The default executable in this location will run on the operating system and CPU architecture on which it was built. + +Executables for other operating system, and CPU architectures are located in the following directories: `openwhisk/bin/go-cli/mac`, `openwhisk/bin/go-cli/linux`, `openwhisk/bin/go-cli/windows`. + +Download and install the correct binary into a location in your [shell path](http://unix.stackexchange.com/questions/26047/how-to-correctly-add-a-path-to-path). + + + +## Using Account Credentials + +You can configure the Serverless Framework to use your OpenWhisk credentials in two ways: + +#### Quick Setup + +As a quick setup to get started you can export them as environment variables so they would be accessible to Serverless Framework: + +```bash +export OW_AUTH= +export OW_APIHOST= +# OW_AUTH and OW_APIHOST are now available for serverless to use +serverless deploy +``` + +#### Using Configuration File + +For a more permanent solution you can also set up credentials through a configuration file. Here are different methods you can use to do so. + +##### Setup with `serverless config credentials` command + +Serverless provides a convenient way to configure OpenWhisk credentials with the help of the `serverless config credentials` command. + +Here's an example how you can configure the `default` AWS profile: + +```bash +serverless config credentials --provider openwhisk --auth USER_AUTH_KEY --apihost PLATFORM_API_HOST +``` + +Take a look at the [`config` CLI reference](../cli-reference/config-credentials.md) for more information about credential configuration. + +##### Setup with the `wsk` cli + +If you have followed the instructions above to install the `wsk` command-line utility, run the following command to create the configuration file. + +```bash +$ wsk property set --apihost PLATFORM_API_HOST --auth USER_AUTH_KEY +``` + +Credentials are stored in `~/.wskprops`, which you can edit directly if needed. + +##### Edit file manually + +The following configuration values should be stored in a new file (`.wskprops`) in your home directory. Replace the `PLATFORM_API_HOST` and `USER_AUTH_KEY` values will the credentials from above. + +``` +APIHOST=PLATFORM_API_HOST +AUTH=USER_AUTH_KEY +``` \ No newline at end of file diff --git a/docs/providers/openwhisk/guide/deploying.md b/docs/providers/openwhisk/guide/deploying.md new file mode 100644 index 000000000..aae193496 --- /dev/null +++ b/docs/providers/openwhisk/guide/deploying.md @@ -0,0 +1,63 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/deploying) + + +# Deploying + +The Serverless Framework was designed to provision your Apache OpenWhisk Functions, Triggers and Rules safely and quickly. It does this via a couple of methods designed for different types of deployments. + +## Deploy All + +This is the main method for doing deployments with the Serverless Framework: + +```bash +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 Apache OpenWhisk. + +### How It Works + +The Serverless Framework translates all syntax in `serverless.yml` to [platform API](http://petstore.swagger.io/?url=https://raw.githubusercontent.com/openwhisk/openwhisk/master/core/controller/src/main/resources/whiskswagger.json) calls to provision your Actions, Triggers, Rules and APIs. + +* Provider plugin parses `serverless.yml` configuration and translates to OpenWhisk resources. +* The code of your Functions is then packaged into zip files. +* Resources are deployed in the following order: *Functions, Function Sequences, API Routes, Triggers, Feeds, Rules.* +* Resources stages are deployed sequentially due to potential dependencies between the stages. +* Resources within a stage are deployed in parallel. +* Stages without any resources defined will be skipped. + +### Tips + +* Use this in your CI/CD systems, as it is the safest method of deployment. +* Apache OpenWhisk has a [maximum action artefact](https://github.com/openwhisk/openwhisk/blob/master/docs/reference.md#per-action-artifact-mb-fixed-48mb) size of 48MB. This might be an issue if you are using lots of NPM packages. JavaScript build tools like webpack can help to minify your code and save space. + +Check out the [deploy command docs](../cli-reference/deploy.md) for all details and options. + +## Deploy Function + +This deployment method updates a single function. It performs the platform API call to deploy your package without the other resources. It is much faster than redeploying your whole service each time. + +```bash +serverless deploy function --function myFunction +``` + +### How It Works + +* The Framework packages up the targeted Apache OpenWhisk Action into a zip file. +* That zip file is deployed to Apache OpenWhisk using the platform API. + +### Tips + +* Use this when you are developing and want to test on Apache OpenWhisk 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. diff --git a/docs/providers/openwhisk/guide/events.md b/docs/providers/openwhisk/guide/events.md new file mode 100644 index 000000000..712dfb83e --- /dev/null +++ b/docs/providers/openwhisk/guide/events.md @@ -0,0 +1,57 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/events) + + +# Events + +Simply put, events are the things that trigger your functions to run. + +If you are using Apache OpenWhisk as your provider, all `events` in the service are anything in Apache OpenWhisk that can trigger your Actions, like HTTP endpoints, message queues, database updates and cron-scheduled events. + +[View the Apache OpenWhisk events section for a list of supported events](../events) + +Upon deployment, the framework will set up the Triggers and Rules that correspond to that event and configure your `function` to listen to it. + +## Configuration + +Events belong to each Function and can be found in the `events` property in `serverless.yml`. + +```yml +# 'functions' in serverless.yml +functions: + createUser: # Function name + handler: handler.createUser # Reference to file handler.js & exported function 'createUser' + events: # All events associated with this function + - http: GET /users/create +``` + +The `events` property is an array, because it is possible for functions to be triggered by multiple events, as shown + +You can set multiple Events per Function, as long as that is supported by Apache OpenWhisk. + +```yml +# 'functions' in serverless.yml +functions: + createUser: # Function name + handler: handler.users # Reference to file handler.js & exported function 'users' + events: # All events associated with this function + - http: GET /users/create + - http: POST /users/update + - trigger: "custom trigger" +``` + +## Types + +The Serverless Framework supports all of the Apache OpenWhisk 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 + +To deploy or update your Functions, Events and Routes, run `serverless deploy`. diff --git a/docs/providers/openwhisk/guide/functions.md b/docs/providers/openwhisk/guide/functions.md new file mode 100644 index 000000000..8555c0c76 --- /dev/null +++ b/docs/providers/openwhisk/guide/functions.md @@ -0,0 +1,97 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/functions) + + +# Functions + +If you are using OpenWhisk as a provider, all *functions* inside the service are OpenWhisk Actions. + +## Configuration + +All of the OpenWhisk Actions in your serverless service can be found in `serverless.yml` under the `functions` property. + +```yml +# serverless.yml +service: myService + +provider: + name: openwhisk + runtime: nodejs:6 # optional, default is nodejs:default + memorySize: 512 # optional, default is 256 + timeout: 30 # optional, default is 60 + +functions: + hello: + handler: handler.hello # required, handler set in Apache OpenWhisk + name: some_custom_name # optional, default is ${service}_${function} + runtime: nodejs # optional overwrite, default is provider runtime + memory: 512 # optional overwrite, default is 256 + timeout: 10 # optional overwrite, default is 60 +``` + +The `handler` property points to the file and module containing the code you want to run in your function. + +```javascript +// handler.js +exports.handler = function(params) {} +``` + +You can add as many functions as you want within this property. + +```yml +# serverless.yml + +service: myService + +provider: + name: openwhisk + +functions: + functionOne: + handler: handler.functionOne + description: optional description for your Action + functionTwo: + handler: handler.functionTwo + functionThree: + handler: handler.functionThree +``` + +Your functions can either inherit their settings from the `provider` property. + +```yml +# serverless.yml +service: myService + +provider: + name: openwhisk + runtime: nodejs:6 + memory: 512 # will be inherited by all functions + +functions: + functionOne: + handler: handler.functionOne +``` + +Or you can specify properties at the function level. + +```yml +# serverless.yml +service: myService + +provider: + name: openwhisk + runtime: nodejs:6 + +functions: + functionOne: + handler: handler.functionOne + memory: 512 # function specific +``` diff --git a/docs/providers/openwhisk/guide/installation.md b/docs/providers/openwhisk/guide/installation.md new file mode 100644 index 000000000..23ce12e61 --- /dev/null +++ b/docs/providers/openwhisk/guide/installation.md @@ -0,0 +1,65 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/installation) + + +# Installation + +### Installing Node.js + +Serverless is a [Node.js](https://nodejs.org) CLI tool so the first thing you need to do is to install Node.js on your machine. + +Go to the official [Node.js website](https://nodejs.org), download and follow the [installation instructions](https://nodejs.org/en/download/) to install Node.js on your local machine. + +**Note:** Serverless runs on Node v4 or higher. + +You can verify that Node.js is installed successfully by runnning `node --version` in your terminal. You should see the corresponding Node version number printed out. + +### Installing the Serverless Framework + +Next, install the Serverless Framework via [npm](https://npmjs.org) which was already installed when you installed Node.js. + +Open up a terminal and type `npm install -g serverless` to install Serverless. + +```bash +npm install -g serverless +``` + +Once the installation process is done you can verify that Serverless is installed successfully by running the following command in your terminal: + +```bash +serverless +``` + +To see which version of serverless you have installed run: + +```bash +serverless --version +``` + + + +### Installing OpenWhisk Provider Plugin + +Now we need to install the provider plugin to allow the framework to deploy services to the platform. This plugin is also [published](http://npmjs.com/package/serverless-openwhisk) on [npm](https://npmjs.org) and can installed using the same `npm install` command. + +``` +npm install -g serverless-openwhisk +``` + +*Due to an [outstanding issue](https://github.com/serverless/serverless/issues/2895) with provider plugins, the [OpenWhisk provider](https://github.com/serverless/serverless-openwhisk) must be installed as a global module.* + + + +### Setting up OpenWhisk + +To run serverless commands that interface with the OpenWhisk platform, you will need to setup your OpenWhisk account credentials on your machine. + +[Follow these instructions on setting up OpenWhisk credentials](./credentials.md) diff --git a/docs/providers/openwhisk/guide/intro.md b/docs/providers/openwhisk/guide/intro.md new file mode 100644 index 000000000..abb70f59a --- /dev/null +++ b/docs/providers/openwhisk/guide/intro.md @@ -0,0 +1,77 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/intro) + + +# Introduction + +The Serverless Framework helps you develop and deploy serverless applications using Apache OpenWhisk. 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 than other application frameworks because: +* It manages your code as well as your infrastructure +* It supports multiple languages (Node.js, Python, Java, and more) + +## Core Concepts + +Here are the Framework's main concepts and how they pertain to Apache OpenWhisk… + +### Functions + +A Function is an [Apache OpenWhisk Action](https://github.com/openwhisk/openwhisk/blob/master/docs/actions.md). 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* + +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 Apache OpenWhisk Action to execute is regarded by the Framework as an **Event**. Events are platform events on Apache OpenWhisk such as: + +* *An API Gateway HTTP endpoint (e.g., for a REST API)* +* *A NoSQL database update (e.g., for a user profile)* +* *A scheduled timer (e.g., run every 5 minutes)* +* *A Kafka queue message (e.g., a message)* +* *A Webhook fires (e.g., Github project update)* +* *And more...* + +When you define an event for your Apache OpenWhisk Action in the Serverless Framework, the Framework will automatically translate this into [Triggers and Rules](https://github.com/openwhisk/openwhisk/blob/master/docs/triggers_rules.md) needed for that event and configure your functions to listen to it. + +### 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`. It looks like this: + +```yml +# serverless.yml + +service: users + +functions: # Your "Functions" + usersCreate: + events: # The "Events" that trigger this function + - http: post /users/create + usersDelete: + events: + - http: delete /users/delete +``` +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. + +```yml +# serverless.yml + +plugins: + - serverless-offline + - serverless-secrets +``` diff --git a/docs/providers/openwhisk/guide/packaging.md b/docs/providers/openwhisk/guide/packaging.md new file mode 100644 index 000000000..a22e8a92b --- /dev/null +++ b/docs/providers/openwhisk/guide/packaging.md @@ -0,0 +1,101 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/packaging) + + +# Packaging + +Sometimes you might like to have more control over your function artifacts and how they are packaged. + +You can use the `package` and `exclude` configuration for more control over the packaging process. + +## Exclude / include + +Exclude and include allows you to define globs that will be excluded / included from the resulting artifact. If you wish to +include files you can use a glob pattern prefixed with `!` such as `!re-include-me/**` in `exclude` or the dedicated `include` config. +Serverless will run the glob patterns in order. + +At first it will apply the globs defined in `exclude`. After that it'll add all the globs from `include`. This way you can always re-include +previously excluded files and directories. + +## Examples + +Exclude all node_modules but then re-include a specific modules (in this case node-fetch) using `exclude` exclusively + +``` yml +package: + exclude: + - node_modules/** + - '!node_modules/node-fetch/**' +``` + +Exclude all files but `handler.js` using `exclude` and `include` + +``` yml +package: + exclude: + - src/** + include: + - src/function/handler.js +``` + +**Note:** Don't forget to use the correct glob syntax if you want to exclude directories + +``` +exclude: + - tmp/** + - .git/** +``` + +## Artifact + +For complete control over the packaging process you can specify your own artifact zip file. +Serverless won't zip your service if this is configured and therefore `exclude` and `include` will be ignored. Either you use artifact or include / 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 + +```yml +service: my-service +package: + exclude: + - tmp/** + - .git/** + include: + - some-file + artifact: path/to/my-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 wide packaging settings. + +Then for every function you can use the same `exclude`, `include` or `artifact` config options as you can service wide. The `exclude` and `include` option will be merged with the service wide options to create one `exclude` and `include` config per function during packaging. + +```yml +service: my-service +package: + individually: true + exclude: + - excluded-by-default.json +functions: + hello: + handler: handler.hello + package: + # We're including this file so it will be in the final package of this function only + include: + - excluded-by-default.json + world: + handler: handler.hello + package: + exclude: + - some-file.js +``` diff --git a/docs/providers/openwhisk/guide/plugins.md b/docs/providers/openwhisk/guide/plugins.md new file mode 100644 index 000000000..be21e76ea --- /dev/null +++ b/docs/providers/openwhisk/guide/plugins.md @@ -0,0 +1,318 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/plugins) + + +# 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. + +## 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: + +``` +npm install --save custom-serverless-plugin +``` + +We need to tell Serverless that we want to use the plugin inside our service. We do this by adding the name of the Plugin to the `plugins` section in the `serverless.yml` file. + +```yml +# serverless.yml file + +plugins: + - custom-serverless-plugin +``` + +Plugins might want to add extra information which should be accessible to Serverless. The `custom` section in the `serverless.yml` file is the place where you can add necessary +configurations for your plugins (the plugins author / documentation will tell you if you need to add anything there): + +```yml +plugins: + - custom-serverless-plugin + +custom: + customkey: customvalue +``` + +## Service local plugin + +If you are working on a plugin or have a plugin that is just designed for one project you can add them to the `.serverless_plugins` directory at the root of your service, and in the `plugins` array in `serverless.yml`. + +The plugin will be loaded based on being named `custom-serverless-plugin.js` or `custom-serverless-plugin\index.js` in the root of `.serverless_plugins` folder. + +### 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. + +```yml +# serverless.yml + +plugins: + - plugin1 + - plugin2 +``` + +In this case `plugin1` is loaded before `plugin2`. + +## Writing Plugins + +### Concepts + +#### Plugin + +Code which defines *Commands*, any *Events* within a *Command*, and any *Hooks* assigned to an *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 + +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'; + +class MyPlugin { + constructor() { + this.commands = { + deploy: { + lifecycleEvents: [ + 'resources', + 'functions' + ] + }, + }; + } +} + +module.exports = MyPlugin; +``` + +#### Lifecycle Events + +Events that fire sequentially during a Command. The above example list two Events. However, for each Event, and additional `before` and `after` event is created. Therefore, six Events exist in the above example: + +- `before:deploy:resources` +- `deploy:resources` +- `after:deploy:resources` +- `before:deploy:functions` +- `deploy:functions` +- `after:deploy:functions` + +The name of the command in front of lifecycle events when they are used for Hooks. + +#### Hooks + +A Hook binds code to any lifecycle event from any command. + +```javascript +'use strict'; + +class Deploy { + constructor() { + this.commands = { + deploy: { + lifecycleEvents: [ + 'resources', + 'functions' + ] + }, + }; + + this.hooks = { + 'before:deploy:resources': this.beforeDeployResources, + 'deploy:resources': this.deployResources, + 'after:deploy:functions': this.afterDeployFunctions + }; + } + + beforeDeployResources() { + console.log('Before Deploy Resources'); + } + + deployResources() { + console.log('Deploy Resources'); + } + + afterDeployFunctions() { + console.log('After Deploy Functions'); + } +} + +module.exports = Deploy; +``` + +### Nesting Commands + +You can also nest commands, e.g. if you want to provide a command `serverless deploy single`. Those nested commands have their own lifecycle events and do not inherit them from their parents. + +```javascript +'use strict'; + +class MyPlugin { + constructor() { + this.commands = { + deploy: { + lifecycleEvents: [ + 'resources', + 'functions' + ], + commands: { + function: { + lifecycleEvents: [ + 'package', + 'deploy' + ], + }, + }, + }, + } + } +} + +module.exports = MyPlugin; +``` + +### Defining Options + +Each (sub)command can have multiple Options. + +Options are passed in with a double dash (`--`) like this: `serverless function deploy --function functionName`. + +Option Shortcuts are passed in with a single dash (`-`) like this: `serverless function deploy -f functionName`. + +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. + +**Note:** At this time, the Serverless Framework does not use parameters. + +```javascript +'use strict'; + +class Deploy { + constructor(serverless, options) { + this.serverless = serverless; + this.options = options; + + this.commands = { + deploy: { + lifecycleEvents: [ + 'functions' + ], + options: { + function: { + usage: 'Specify the function you want to deploy (e.g. "--function myFunction")', + shortcut: 'f', + required: true + } + } + }, + }; + + this.hooks = { + 'deploy:functions': this.deployFunction.bind(this) + } + } + + deployFunction() { + console.log('Deploying function: ', this.options.function); + } +} + +module.exports = Deploy; +``` + +### Provider Specific Plugins + +Plugins can be provider specific which means that they are bound to a provider. + +**Note:** Binding a plugin to a provider is optional. Serverless will always consider your plugin if you don't specify a `provider`. + +The provider definition should be added inside the plugins constructor: + +```javascript +'use strict'; + +class ProviderDeploy { + constructor(serverless, options) { + this.serverless = serverless; + this.options = options; + + // set the providers name here + this.provider = this.serverless.getProvider('providerName'); + + this.commands = { + deploy: { + lifecycleEvents: [ + 'functions' + ], + options: { + function: { + usage: 'Specify the function you want to deploy (e.g. "--function myFunction")', + required: true + } + } + }, + }; + + this.hooks = { + 'deploy:functions': this.deployFunction.bind(this) + } + } + + deployFunction() { + console.log('Deploying function: ', this.options.function); + } +} + +module.exports = ProviderDeploy; +``` + +The Plugin's functionality will now only be executed when the Serverless Service's provider matches the provider name which is defined inside the plugins constructor. + +### Serverless Instance + +The `serverless` instance which enables access to global service config during runtime is passed in as the first parameter to the plugin constructor. + +```javascript +'use strict'; + +class MyPlugin { + constructor(serverless, options) { + this.serverless = serverless; + this.options = options; + + this.commands = { + log: { + lifecycleEvents: [ + 'serverless' + ], + }, + }; + + this.hooks = { + 'log:serverless': this.logServerless.bind(this) + } + } + + logServerless() { + console.log('Serverless instance: ', this.serverless); + } +} + +module.exports = MyPlugin; +``` + +### Command Naming + +Command names need to be unique. If we load two commands and both want to specify the same command (e.g. we have an integrated command `deploy` and an external command also wants to use `deploy`) the Serverless CLI will print an error and exit. If you want to have your own `deploy` command you need to name it something different like `myCompanyDeploy` so they don't clash with existing plugins. diff --git a/docs/providers/openwhisk/guide/serverless.yml.md b/docs/providers/openwhisk/guide/serverless.yml.md new file mode 100644 index 000000000..d286616b8 --- /dev/null +++ b/docs/providers/openwhisk/guide/serverless.yml.md @@ -0,0 +1,65 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml) + + +# Serverless.yml Reference + +Here is a list of all available properties in `serverless.yml` when the provider is set to `openwhisk`. + +```yml +# serverless.yml + +service: myService + +frameworkVersion: ">=1.0.0 <2.0.0" + +provider: + name: openwhisk + runtime: nodejs:default + memory: 256 # Overwrite default memory size. Default is 512. + timeout: 10 # The default is 60 + overwrite: true # Can we overwrite deployed functions? default is true + namespace: 'custom' # use custom namespace, defaults to '_' + +functions: + usersCreate: # A Function + handler: users.create # The file and module for this specific function. + sequence: # Use sequences rather than handler to handle events. handler and sequence properties are mutually exclusive. + - function_a + - function_b + - function_c + memory: 256 # memorySize for this specific function. + timeout: 10 # Timeout for this specific function. Overrides the default set above. + runtime: nodejs:6 + overwrite: false # Can we overwrite deployed function? + namespace: 'custom' # use custom namespace, defaults to '_' + events: # The Events that trigger this Function + # This creates an API Gateway HTTP endpoint which can be used to trigger this function. Learn more in "events/apigateway" + - http: METHOD /path/to/url + - trigger: my_trigger # bind function to trigger event + - trigger: + name: my_trigger + rule: rule_name + +# The "Resources" your "Functions" use. This can be used to define custom Triggers and Rules which are bound to your Actions. +resources: + triggers: + my_trigger: # trigger with default parameter bound. + parameters: + hello: world + alarm_trigger: # trigger connected to event feed + parameters: + hello: world + feed: /whisk.system/alarms/alarm + feed_parameters: + cron: '*/8 * * * * *' + +``` diff --git a/docs/providers/openwhisk/guide/services.md b/docs/providers/openwhisk/guide/services.md new file mode 100644 index 000000000..e3c324c4c --- /dev/null +++ b/docs/providers/openwhisk/guide/services.md @@ -0,0 +1,174 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/services) + + +# Services + +A `service` is like a project. It's where you define your Apache OpenWhisk Functions, the `events` that trigger them and any `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. + +```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. + +```bash +users/ + serverless.yml # Contains 4 functions that do Users CRUD operations and the Users database +posts/ + serverless.yml # Contains 4 functions that do Posts CRUD operations and the Posts database +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. + +## 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: + +```bash +# Create service with nodeJS template in the folder ./myService +serverless create --template openwhisk-nodejs --path myService +``` + +Here are the available runtimes for Apache OpenWhisk: + +* openwhisk-nodejs + +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` + +### serverless.yml + +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) + - 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. + +```yml +# serverless.yml + +service: users + +provider: + name: openwhisk + runtime: nodejs:6 + memory: 512 # Overwrite the default memory size. Default is 256 + +functions: + usersCreate: # A Function + handler: users.create + events: # The Events that trigger this Function + - http: post /users/create + usersDelete: # A Function + handler: users.delete + events: # The Events that trigger this Function + - http: delete /users/delete +``` + +Every `serverless.yml` translates to a single AWS CloudFormation template and a CloudFormation stack is created from that resulting CloudFormation template. + +### handler.js + +The `handler.js` file contains your function code. The function definition in `serverless.yml` will point to this `handler.js` file and the function exported here. + +### event.json + +**Note:** This file is not created by default + +Create this file and add event data so you can invoke your function with the data via `serverless invoke -p event.json` + +## Deployment + +When you deploy a Service, all of the Functions, Events and Resources in your `serverless.yml` are translated into calls to the platform API to dynamically define those resources. + +To deploy a service, use the `deploy` command: + +```bash +serverless deploy +``` + +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 + +To easily remove your Service from your Apache OpenWhisk account, you can use the `remove` command. + +Run `serverless remove -v` to trigger the removal process. As in the deploy step we're also running in the `verbose` mode so you can see all details of the remove process. + +Serverless will start the removal and informs you about it's process on the console. A success message is printed once the whole service is removed. + +The removal process will only remove the service on your provider's infrastructure. The service directory will still remain on your local machine so you can still modify and (re)deploy it to another stage, region or provider later on. + +## Version Pinning + +The Serverless framework is usually installed globally via `npm install -g serverless`. This way you have the Serverless CLI available for all your services. + +Installing tools globally has the downside that the version can't be pinned inside package.json. This can lead to issues if you upgrade Serverless, but your colleagues or CI system don't. You can now use a new feature in your serverless.yml which is available only in the latest version without worrying that your CI system will deploy with an old version of Serverless. + +### Pinning a Version + +To configure version pinning define a `frameworkVersion` property in your serverless.yaml. Whenever you run a Serverless command from the CLI it checks if your current Serverless version is matching the `frameworkVersion` range. The CLI uses [Semantic Versioning](http://semver.org/) so you can pin it to an exact version or provide a range. In general we recommend to pin to an exact version to ensure everybody in your team has the exact same setup and no unexpected problems happen. + +### Examples + +#### Exact Version + +```yml +# serverless.yml + +frameworkVersion: "=1.0.3" + +service: users + +provider: + name: openwhisk + runtime: nodejs + memorySize: 512 + +… +``` + +#### Version Range + +```yml +# serverless.yml + +frameworkVersion: ">=1.0.0 <2.0.0" + +service: users + +provider: + name: openwhisk + runtime: nodejs + memorySize: 512 + +… +``` diff --git a/docs/providers/openwhisk/guide/testing.md b/docs/providers/openwhisk/guide/testing.md new file mode 100644 index 000000000..05561fb45 --- /dev/null +++ b/docs/providers/openwhisk/guide/testing.md @@ -0,0 +1,108 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/testing) + + +# 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: + +* 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., Apache OpenWhisk), 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 + +Here is an example in Node.js of how to follow the practices above. The job this Function should perform is to save a user in a database and then send a welcome email: + +```javascript +const db = require('db').connect(); +const mailer = require('mailer'); + +module.exports.saveUser = (params) => { + return Promise((resolve, reject) => { + const user = { + email: params.email, + created_at: Date.now() + } + + db.saveUser(user, function (err) { + if (err) { + reject(err); + } else { + mailer.sendWelcomeEmail(event.email); + resolve(); + } + }); + }) +}; +``` + +There are two main problems with this function: + +* The business logic is not separate from the FaaS Provider. It's bounded to how Apache OpenWhisk passes incoming data (`params` object). +* Testing this function will rely on separate services. Specifically, running a database instance and a mail server. + +## Writing Testable Apache OpenWhisk Functions + +Let's refactor the above example to separate the business logic from the FaaS Provider. + +```javascript +class Users { + constructor(db, mailer) { + this.db = db; + this.mailer = mailer; + } + + save(email, callback) { + return new Promise((resolve, reject) => { + const user = { + email: email, + created_at: Date.now() + } + + this.db.saveUser(user, function (err) { + if (err) { + reject(err); + } else { + this.mailer.sendWelcomeEmail(email); + resolve(); + } + }); + }) + } +} + +module.exports = Users; +``` + +```javascript +const db = require('db').connect(); +const mailer = require('mailer'); +const Users = require('users'); + +let users = new Users(db, mailer); + +module.exports.saveUser = (params) => { + return users.save(params.email); +}; +``` + +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 Apache OpenWhisk 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. + +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. diff --git a/docs/providers/openwhisk/guide/variables.md b/docs/providers/openwhisk/guide/variables.md new file mode 100644 index 000000000..0df7a975f --- /dev/null +++ b/docs/providers/openwhisk/guide/variables.md @@ -0,0 +1,213 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/variables) + + +# Variables + +The Serverless framework provides a powerful variable system which allows you to add dynamic data into your `serverless.yml`. With Serverless Variables, you'll be able to do the following: + +- Reference & load variables from environment variables +- Reference & load variables from CLI options +- Recursively reference properties of any type from the same `serverless.yml` file +- Recursively reference properties of any type from other YAML/JSON files +- Recursively nest variable references within each other for ultimate flexibility +- Combine multiple variable references to overwrite each other + +**Note:** You can only use variables in `serverless.yml` property **values**, not property keys. So you can't use variables to generate dynamic logical IDs in the custom resources section for example. + +## Reference Properties In serverless.yml +To self-reference properties in `serverless.yml`, use the `${self:someProperty}` syntax in your `serverless.yml`. This functionality is recursive, so you can go as deep in the object tree as you want. + +```yml +service: new-service +provider: aws +custom: + globalSchedule: rate(10 minutes) + +functions: + hello: + handler: handler.hello + events: + - schedule: ${self:custom.globalSchedule} + world: + handler: handler.world + events: + - schedule: ${self:custom.globalSchedule} +``` + +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 Environment Variables +To reference environment variables, use the `${env:SOME_VAR}` syntax in your `serverless.yml` configuration file. + +```yml +service: new-service +provider: aws +functions: + hello: + name: ${env:FUNC_PREFIX}-hello + handler: handler.hello + world: + name: ${env:FUNC_PREFIX}-world + handler: handler.world +``` + +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. + +```yml +service: new-service +provider: aws +functions: + hello: + name: ${opt:stage}-hello + handler: handler.hello + 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 Variables in Other Files +To reference variables in other YAML or JSON files, use the `${file(./myFile.yml):someProperty}` syntax in your `serverless.yml` configuration file. This functionality is recursive, so you can go as deep in that file as you want. Here's an example: + +```yml +# myCustomFile.yml +globalSchedule: rate(10 minutes) +``` + +```yml +# serverless.yml +service: new-service +provider: openwhisk +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 + world: + 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. + +## Reference Variables in Javascript Files +To add dynamic data into your variables, reference javascript files by putting `${file(./myFile.js):someModule}` syntax in your `serverless.yml`. Here's an example: + +```js +// myCustomFile.js +module.exports.hello = () => { + // Code that generates dynamic data + return 'rate (10 minutes)'; +} +``` + +```yml +# serverless.yml +service: new-service +provider: openwhisk +functions: + hello: + handler: handler.hello + events: + - schedule: ${file(./myCustomFile.js):hello} # 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: + +```yml +# serverless.yml +service: new-service +provider: aws +functions: + scheduledFunction: + 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)' + }; +} +``` + +## Multiple Configuration Files + +Adding many custom resources to your `serverless.yml` file could bloat the whole file, so you can use the Serverless Variable syntax to split this up. + +```yml +resources: + Resources: ${file(cloudformation-resources.json)} +``` + +The corresponding resources which are defined inside the `cloudformation-resources.json` file will be resolved and loaded into the `Resources` section. + +## 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 +service: new-service +provider: aws +custom: + myFlexibleArn: ${env:${opt:stage}_arn} + +functions: + 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: + +```yml +service: new-service +provider: + name: aws + stage: dev +custom: + myStage: ${opt:stage, self:provider.stage} + +functions: + 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`. + +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. + +## 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. + +**Using the same `serverless.yml` file:** You can store your variables in `serverless.yml` if they don't contain sensitive data, and then reference them elsewhere in the file using `self:someProperty`. For more info, you can check the self reference section above. + +**Using environment variables:** You can instead store your variables in environment variables and reference them with `env.someEnvVar`. For more info, you can check the environment variable reference section above. + +Now you don't need `serverless.env.yml` at all, but you can still use it if you want. It's just not required anymore. Migrating to the new variable system is easy and you just need to know how the new system works and make small adjustments to how you store & reference your variables. diff --git a/docs/providers/openwhisk/guide/workflow.md b/docs/providers/openwhisk/guide/workflow.md new file mode 100644 index 000000000..126595627 --- /dev/null +++ b/docs/providers/openwhisk/guide/workflow.md @@ -0,0 +1,68 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/workflow) + + +# Workflow + +Intro. Quick recommendations and tips for various processes. + +### Development Workflow + +1. Write your functions +2. Use `serverless deploy` only when you've made changes to `serverless.yml` and in CI/CD systems. +3. Use `serverless deploy function -f myFunction` to rapidly deploy changes when you are working on a specific Apache OpenWhisk Function. +4. Use `serverless invoke -f myFunction -l` to test your Apache OpenWhisk Functions on AWS. +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. + +### 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. + +## 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 openwhisk-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 +``` + +##### Deploy Function +Use this to quickly overwrite your OpenWhisk Actions, allowing you to develop faster. +``` +serverless deploy function -f [FUNCTION NAME] +``` + +##### Invoke Function +Invokes an OpenWhisk Action and returns logs. +``` +serverless invoke function -f [FUNCTION 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] +``` From 969e6d1be6685e2da326359124953edcae5a7ae8 Mon Sep 17 00:00:00 2001 From: James Thomas Date: Tue, 24 Jan 2017 14:15:27 +0000 Subject: [PATCH 02/30] Add OpenWhisk example for Node --- docs/providers/openwhisk/README.md | 10 +-- docs/providers/openwhisk/examples/README.md | 22 ++--- .../openwhisk/examples/hello-world/README.md | 8 +- .../hello-world/csharp/AssemblyInfo.cs | 3 - .../examples/hello-world/csharp/Handler.cs | 36 -------- .../examples/hello-world/csharp/README.md | 52 ----------- .../examples/hello-world/csharp/project.json | 33 ------- .../hello-world/csharp/serverless.yml | 84 ------------------ .../node/.serverless/hello-world.zip | Bin 0 -> 1348 bytes .../examples/hello-world/node/README.md | 18 ++-- .../examples/hello-world/node/handler.js | 10 +-- .../examples/hello-world/node/package.json | 9 ++ .../examples/hello-world/node/serverless.yml | 7 +- .../examples/hello-world/python/README.md | 36 -------- .../examples/hello-world/python/handler.py | 6 -- .../hello-world/python/serverless.yml | 10 --- 16 files changed, 40 insertions(+), 304 deletions(-) delete mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/AssemblyInfo.cs delete mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/Handler.cs delete mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/README.md delete mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/project.json delete mode 100644 docs/providers/openwhisk/examples/hello-world/csharp/serverless.yml create mode 100644 docs/providers/openwhisk/examples/hello-world/node/.serverless/hello-world.zip create mode 100644 docs/providers/openwhisk/examples/hello-world/node/package.json delete mode 100644 docs/providers/openwhisk/examples/hello-world/python/README.md delete mode 100644 docs/providers/openwhisk/examples/hello-world/python/handler.py delete mode 100644 docs/providers/openwhisk/examples/hello-world/python/serverless.yml diff --git a/docs/providers/openwhisk/README.md b/docs/providers/openwhisk/README.md index 7a6629265..df38e3a97 100644 --- a/docs/providers/openwhisk/README.md +++ b/docs/providers/openwhisk/README.md @@ -1,6 +1,6 @@ @@ -8,12 +8,12 @@ layout: Doc ### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/) -# Serverless AWS Provider Documentation +# Serverless Apache OpenWhisk Provider Documentation -Welcome to the Serverless Amazon Web Services documentation! +Welcome to the Serverless Apache OpenWhisk documentation! 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](https://gitter.im/serverless/serverless) -**Note:** Before continuing [AWS system credentials](./guide/credentials.md) are required for using the CLI. +**Note:** Before continuing [Apache OpenWhisk system credentials](./guide/credentials.md) are required for using the CLI. diff --git a/docs/providers/openwhisk/examples/README.md b/docs/providers/openwhisk/examples/README.md index d180c60f6..dfeacb048 100644 --- a/docs/providers/openwhisk/examples/README.md +++ b/docs/providers/openwhisk/examples/README.md @@ -1,31 +1,19 @@ -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/examples/) -# Serverless AWS Lambda Examples +# Serverless Apache OpenWhisk Examples Have an example? Submit a PR or [open an issue](https://github.com/serverless/examples/issues). ⚡️ | Example | Runtime | |:--------------------------- |:-----| -| [Aws Auth0 Api Gateway](https://github.com/serverless/examples/tree/master/aws-node-auth0-custom-authorizers-api)
Demonstration of protecting API gateway endpoints with auth0 | nodeJS | -| [Env Variables Encrypted In A File](https://github.com/serverless/examples/tree/master/aws-node-env-variables-encrypted-in-a-file)
Serverless example managing secrets in an encrypted file | nodeJS | -| [Serverless Node Env Variables](https://github.com/serverless/examples/tree/master/aws-node-env-variables)
This example demonstrates how to use environment variables for AWS Lambdas. | nodeJS | -| [Fetch File And Store In S3](https://github.com/serverless/examples/tree/master/aws-node-fetch-file-and-store-in-s3)
Fetch an image from remote source (URL) and then upload the image to a S3 bucket. | nodeJS | -| [Function Compiled With Babel](https://github.com/serverless/examples/tree/master/aws-node-function-compiled-with-babel)
Demonstrating how to compile all your code with Babel | nodeJS | -| [Serverless Rest With Dynamodb](https://github.com/serverless/examples/tree/master/aws-node-rest-api-with-dynamodb)
Serverless CRUD service exposing a REST HTTP interface | nodeJS | -| [Serverless Aws Cron Job Example](https://github.com/serverless/examples/tree/master/aws-node-scheduled-cron)
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://github.com/serverless/examples/tree/master/aws-node-serve-dynamic-html-via-http-endpoint)
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://github.com/serverless/examples/tree/master/aws-node-simple-http-endpoint)
Example demonstrates how to setup a simple HTTP GET endpoint | nodeJS | -| [Single Page App Via Cloudfront](https://github.com/serverless/examples/tree/master/aws-node-single-page-app-via-cloudfront)
Demonstrating how to deploy a Single Page Application with Serverless | nodeJS | -| [Serverless Single Page App Plugin](https://github.com/serverless/examples/tree/master/aws-node-single-page-app-via-cloudfront/serverless-single-page-app-plugin)
A plugin to simplify deploying Single Page Application using S3 and CloudFront | nodeJS | -| [Serverless Data Pipeline](https://github.com/serverless/examples/tree/master/aws-node-text-analysis-via-sns-post-processing)
Example demonstrates how to setup a simple data processing pipeline | nodeJS | -| [Aws Python Simple Http Endpoint](https://github.com/serverless/examples/tree/master/aws-python-simple-http-endpoint)
Example demonstrates how to setup a simple HTTP GET endpoint with python | python | +| [OpenWhisk Node Simple](https://github.com/serverless/examples/tree/master/openwhisk-node-simple)
Boilerplate project repository for OpenWhisk provider with Serverless Framework. | nodeJS | If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](https://gitter.im/serverless/serverless) diff --git a/docs/providers/openwhisk/examples/hello-world/README.md b/docs/providers/openwhisk/examples/hello-world/README.md index d1f1d070a..8a92035e5 100644 --- a/docs/providers/openwhisk/examples/hello-world/README.md +++ b/docs/providers/openwhisk/examples/hello-world/README.md @@ -1,12 +1,12 @@ -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/examples/hello-world/) # Hello World Serverless Example 🌍 @@ -16,7 +16,5 @@ Welcome to the Hello World example. Pick your language of choice: * [JavaScript](./node) -* [Python](./python) -* [csharp](./csharp) -[View all examples](https://www.serverless.com/framework/docs/providers/aws/examples/) +[View all examples](https://www.serverless.com/framework/docs/providers/openwhisk/examples/) diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/AssemblyInfo.cs b/docs/providers/openwhisk/examples/hello-world/csharp/AssemblyInfo.cs deleted file mode 100644 index 59e636f29..000000000 --- a/docs/providers/openwhisk/examples/hello-world/csharp/AssemblyInfo.cs +++ /dev/null @@ -1,3 +0,0 @@ -using Amazon.Lambda.Core; - -[assembly:LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))] diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/Handler.cs b/docs/providers/openwhisk/examples/hello-world/csharp/Handler.cs deleted file mode 100644 index 2b6f9728e..000000000 --- a/docs/providers/openwhisk/examples/hello-world/csharp/Handler.cs +++ /dev/null @@ -1,36 +0,0 @@ -using System; - -namespace AwsDotnetCsharp -{ - public class Handler - { - public Response Hello(Request request) - { - return new Response("Go Serverless v1.0! Your function executed successfully!", request); - } - } - - public class Response - { - public string Message {get; set;} - public Request Request {get; set;} - - public Response(string message, Request request){ - Message = message; - Request = request; - } - } - - public class Request - { - public string Key1 {get; set;} - public string Key2 {get; set;} - public string Key3 {get; set;} - - public Request(string key1, string key2, string key3){ - Key1 = key1; - Key2 = key2; - Key3 = key3; - } - } -} diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/README.md b/docs/providers/openwhisk/examples/hello-world/csharp/README.md deleted file mode 100644 index 3fa1f425e..000000000 --- a/docs/providers/openwhisk/examples/hello-world/csharp/README.md +++ /dev/null @@ -1,52 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/csharp/) - - -# Hello World C# Example - -Make sure `serverless` is installed. [See installation guide](../../../guide/installation.md). - -## 1. Create a service -`serverless create --template aws-csharp --path myService` or `sls create --template aws-csharp --path myService`, where 'myService' is a new folder to be created with template service files. Change directories into this new folder. - -## 2. Build using .NET CLI tools and create zip package - -``` -# Linux or OSX -./build.sh -``` - -``` -# Windows PowerShell -./build.ps1 -``` - -## 3. Deploy -`serverless deploy` or `sls deploy`. `sls` is shorthand for the Serverless CLI command - -## 4. Invoke deployed function -`serverless invoke --function hello` or `serverless invoke -f hello` - -`-f` is shorthand for `--function` - -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 just deployed and run your Hello World function! diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/project.json b/docs/providers/openwhisk/examples/hello-world/csharp/project.json deleted file mode 100644 index da4b806ad..000000000 --- a/docs/providers/openwhisk/examples/hello-world/csharp/project.json +++ /dev/null @@ -1,33 +0,0 @@ -{ - "version": "1.0.0-*", - "buildOptions": { - "outputName": "CsharpHandlers" - }, - - "dependencies": { - "Microsoft.NETCore.App": { - "type": "platform", - "version": "1.0.1" - }, - - "Newtonsoft.Json": "9.0.1", - - "Amazon.Lambda.Core": "1.0.0*", - "Amazon.Lambda.Serialization.Json": "1.0.0", - - "Amazon.Lambda.Tools" : { - "type" :"build", - "version":"0.9.0-preview1" - } - }, - - "tools": { - "Amazon.Lambda.Tools" : "0.9.0-preview1" - }, - - "frameworks": { - "netcoreapp1.0": { - "imports": "dnxcore50" - } - } -} diff --git a/docs/providers/openwhisk/examples/hello-world/csharp/serverless.yml b/docs/providers/openwhisk/examples/hello-world/csharp/serverless.yml deleted file mode 100644 index 4f8212227..000000000 --- a/docs/providers/openwhisk/examples/hello-world/csharp/serverless.yml +++ /dev/null @@ -1,84 +0,0 @@ -# Welcome to Serverless! -# -# This file is the main config file for your service. -# It's very minimal at this point and uses default values. -# You can always add more config options for more control. -# We've included some commented out config examples here. -# Just uncomment any of them to get that config option. -# -# For full config options, check the docs: -# docs.serverless.com -# -# Happy Coding! - -service: aws-csharp # NOTE: update this with your service name - -# You can pin your service to only deploy with a specific Serverless version -# Check out our docs for more details -# frameworkVersion: "=X.X.X" - -provider: - name: aws - runtime: dotnetcore1.0 - -# you can overwrite defaults here -# stage: dev -# region: us-east-1 - -# you can add statements to the Lambda function's IAM Role here -# 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" - -# you can define service wide environment variables here -# environment: -# variable1: value1 - -# you can add packaging information here -package: - artifact: bin/release/netcoreapp1.0/publish/deploy-package.zip -# exclude: -# - exclude-me.js -# - exclude-me-dir/** - -functions: - hello: - handler: CsharpHandlers::AwsDotnetCsharp.Handler::Hello - -# The following are a few example events you can configure -# NOTE: Please make sure to change your handler code to work with those events -# Check the event documentation for details -# events: -# - http: -# path: users/create -# method: get -# - s3: ${env:BUCKET} -# - schedule: rate(10 minutes) -# - sns: greeter-topic -# - stream: arn:aws:dynamodb:region:XXXXXX:table/foo/stream/1970-01-01T00:00:00.000 - -# Define function environment variables here -# environment: -# variable2: value2 - -# you can add CloudFormation resource templates here -#resources: -# Resources: -# NewResource: -# Type: AWS::S3::Bucket -# Properties: -# BucketName: my-new-bucket -# Outputs: -# NewOutput: -# Description: "Description for the output" -# Value: "Some output value" diff --git a/docs/providers/openwhisk/examples/hello-world/node/.serverless/hello-world.zip b/docs/providers/openwhisk/examples/hello-world/node/.serverless/hello-world.zip new file mode 100644 index 0000000000000000000000000000000000000000..86fb3e0333fa0cf67dfb2dfaf7b03bc38220eec3 GIT binary patch literal 1348 zcmWIWW@Zs#-~hs~TnjG-B)|n^XC&sO+*F^?(Y7c)iB{# z>mkmA9`lz>JQHiSd`^45x)~x4*j~yY01yna1-^zjs~}%iGHO z>(z7_PX53ei|=7OPiXned2TG4`QfK|Z}+ag_h;|A-P`f3T7Q0dqfVGb{=dj9-_RXtaaC!#FZ}4HZpK+}EK;H91F$FyPzUAFJYYy`Hw%M#V z4gme7%!tqDoIn*pu8uCgu6nsCQ$u32ZySizUSGeXP;Qq~?)JOU8qJfY=&pIafOE=4 zku?$5H%3JpO_DL6^6z`>O}{ygnmQ~^OMVxg+xh%imPp$f&+rE?OR~adK!YkyfQ2gEJflRqsDNmP#3D1yv!q+IDC3}7U)2C4dC$gsg$_V=~ciqZg zKFf7@_8XSD9!U6By^BNq^Hbjn>;1niBX!olpMD^Fx%a!2Q{74I(jgfu`WZe{KK>{n z_kJRG!OkrUME@#HiP74Su`PpZi&%@FZp6zEFTLNzq^cL*G4VBVaapPN_{;|(>D;&^ zdHHa+{G|@b$@gwZSSRMpslMvOrR}oDW9yGE&Tq`iH;XAq*RL}EeKcMmCs$w+qaV`| zSFP6_MqM0o;vK(@H63-#O&zO$3Aq-2&plr_|5BUFQj1;*P8RWt2GaMPm!0UF<#>x% zk4N^>o7<9RW?$}{5J-$DobJ3cx@0D2hI0V-@A;YO7oK?N`14Kmv+?BPl0H%5=+u09 z!?Atq8r*{JGcS>|NSUN2#pqMK&WyuJ%4e>b(B6cQ1zQgWYz}^4)Fc_!dhhSy=q=&Q z3;)S%{c=n2MvSz3FN>l|#S@+NPWh`|zLhy)rfR$0sJ=I0-L_fBZi*^(%e|@7+5V>K zP{Dt$wM(mHod4FwT-$Fvt>q^BhDi&94&8`h%oS^N4fZ<9Jt>g$?hkJTE7P~TRE;b3 z*m9Rnbv@Ce_wZLDt z_EszO_-?&*;neME&gZssoZnj7e5%fF*}F>l|1aN2_uYsGCFI!$4r)wdVqo~r0!qk? zOuEd7VhA~VgNh*tP+(Zn2x1`$C3JnrnFEyhApoTB5Ri#n6rk%wb`2==KmbVR9$-d; XXQcpdRyL3nGZ3x>(yc(pGcW)El?)#= literal 0 HcmV?d00001 diff --git a/docs/providers/openwhisk/examples/hello-world/node/README.md b/docs/providers/openwhisk/examples/hello-world/node/README.md index 792bd4e8d..6db34ca01 100644 --- a/docs/providers/openwhisk/examples/hello-world/node/README.md +++ b/docs/providers/openwhisk/examples/hello-world/node/README.md @@ -1,12 +1,12 @@ -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/node/) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/examples/hello-world/node/) # Hello World Node.js Example @@ -16,20 +16,22 @@ Make sure `serverless` is installed. [See installation guide](../../../guide/ins ## 1. Create a service `serverless create --template aws-nodejs --path myService` or `sls create --template aws-nodejs --path myService`, where 'myService' is a new folder to be created with template service files. Change directories into this new folder. -## 2. Deploy +## 2. Install Provider Plugin +`npm install -g serverless-openwhisk` followed by `npm install` in the service directory. + +## 3. Deploy `serverless deploy` or `sls deploy`. `sls` is shorthand for the Serverless CLI command -## 3. Invoke deployed function -`serverless invoke --function hello` or `serverless invoke -f hello` +## 4. Invoke deployed function +`serverless invoke --function helloWorld` or `serverless invoke -f helloWorld` `-f` is shorthand for `--function` -In your terminal window you should see the response from AWS Lambda +In your terminal window you should see the response from Apache OpenWhisk ```bash { - "statusCode": 200, - "body": "{\"message\":\"Go Serverless v1.0! Your function executed successfully!\",\"input\":{}}" + "payload": "Hello, World!" } ``` diff --git a/docs/providers/openwhisk/examples/hello-world/node/handler.js b/docs/providers/openwhisk/examples/hello-world/node/handler.js index 12a311f42..98edcb3ea 100644 --- a/docs/providers/openwhisk/examples/hello-world/node/handler.js +++ b/docs/providers/openwhisk/examples/hello-world/node/handler.js @@ -1,11 +1,7 @@ 'use strict'; // Your function handler -module.exports.helloWorldHandler = function (event, context, callback) { - const message = { - message: 'Hello World', - event, - }; - // callback will send message object back - callback(null, message); +module.exports.helloWorldHandler = function (params) { + const name = params.name || 'World'; + return { payload: `Hello, ${name}!` }; }; diff --git a/docs/providers/openwhisk/examples/hello-world/node/package.json b/docs/providers/openwhisk/examples/hello-world/node/package.json new file mode 100644 index 000000000..d41fc10e8 --- /dev/null +++ b/docs/providers/openwhisk/examples/hello-world/node/package.json @@ -0,0 +1,9 @@ +{ + "name": "serverless-openwhisk-hello-world", + "version": "0.1.0", + "description": "Hello World example for OpenWhisk provider with Serverless Framework.", + "scripts": { + "postinstall": "npm link serverless-openwhisk", + "test": "echo \"Error: no test specified\" && exit 1" + } +} diff --git a/docs/providers/openwhisk/examples/hello-world/node/serverless.yml b/docs/providers/openwhisk/examples/hello-world/node/serverless.yml index 08bf9b3b8..f4a7c6960 100644 --- a/docs/providers/openwhisk/examples/hello-world/node/serverless.yml +++ b/docs/providers/openwhisk/examples/hello-world/node/serverless.yml @@ -2,9 +2,12 @@ service: hello-world # Service Name provider: - name: aws - runtime: nodejs4.3 + name: openwhisk functions: helloWorld: handler: handler.helloWorldHandler + +# remember to run npm install to download the provider plugin. +plugins: + - serverless-openwhisk diff --git a/docs/providers/openwhisk/examples/hello-world/python/README.md b/docs/providers/openwhisk/examples/hello-world/python/README.md deleted file mode 100644 index d1e432b60..000000000 --- a/docs/providers/openwhisk/examples/hello-world/python/README.md +++ /dev/null @@ -1,36 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/python/) - - -# Hello World Python Example - -Make sure `serverless` is installed. [See installation guide](../../../guide/installation.md). - -## 1. Create a service -`serverless create --template aws-python --path myService` or `sls create --template aws-python --path myService`, where 'myService' is a new folder to be created with template service files. Change directories into this new folder. - -## 2. Deploy -`serverless deploy` or `sls deploy`. `sls` is shorthand for the serverless CLI command - -## 3. Invoke deployed function -`serverless invoke --function hello` or `serverless invoke -f hello` - -`-f` is shorthand for `--function` - -In your terminal window you should see the response from AWS Lambda - -```bash -{ - "statusCode": 200, - "body": "{\"message\":\"Go Serverless v1.0! Your function executed successfully!\",\"input\":{}}" -} -``` - -Congrats you have just deployed and ran your Hello World function! diff --git a/docs/providers/openwhisk/examples/hello-world/python/handler.py b/docs/providers/openwhisk/examples/hello-world/python/handler.py deleted file mode 100644 index 7ba5ed97f..000000000 --- a/docs/providers/openwhisk/examples/hello-world/python/handler.py +++ /dev/null @@ -1,6 +0,0 @@ -def helloWorldHandler(event, context): - message = { - 'message': 'Hello World' - } - - return message diff --git a/docs/providers/openwhisk/examples/hello-world/python/serverless.yml b/docs/providers/openwhisk/examples/hello-world/python/serverless.yml deleted file mode 100644 index 0b2f4cae5..000000000 --- a/docs/providers/openwhisk/examples/hello-world/python/serverless.yml +++ /dev/null @@ -1,10 +0,0 @@ -# Hello World for AWS Lambda -service: hello-world # Service Name - -provider: - name: aws - runtime: python2.7 - -functions: - helloWorld: - handler: handler.helloWorldHandler From 380cb999c67293b71b59b7a5d53cae00c4ecd170 Mon Sep 17 00:00:00 2001 From: James Thomas Date: Tue, 24 Jan 2017 14:40:10 +0000 Subject: [PATCH 03/30] Updating CLI reference documentatin --- .../openwhisk/cli-reference/README.md | 8 +- .../cli-reference/config-credentials.md | 21 ++--- .../openwhisk/cli-reference/create.md | 24 +++--- .../cli-reference/deploy-function.md | 22 +----- .../openwhisk/cli-reference/deploy-list.md | 32 -------- .../openwhisk/cli-reference/deploy.md | 17 +--- .../providers/openwhisk/cli-reference/info.md | 65 +++++----------- .../openwhisk/cli-reference/install.md | 4 +- .../openwhisk/cli-reference/invoke-local.md | 8 +- .../openwhisk/cli-reference/invoke.md | 23 +++--- .../providers/openwhisk/cli-reference/logs.md | 12 +-- .../openwhisk/cli-reference/metrics.md | 63 --------------- .../openwhisk/cli-reference/remove.md | 15 ++-- .../openwhisk/cli-reference/rollback.md | 77 ------------------- 14 files changed, 71 insertions(+), 320 deletions(-) delete mode 100644 docs/providers/openwhisk/cli-reference/deploy-list.md delete mode 100644 docs/providers/openwhisk/cli-reference/metrics.md delete mode 100644 docs/providers/openwhisk/cli-reference/rollback.md diff --git a/docs/providers/openwhisk/cli-reference/README.md b/docs/providers/openwhisk/cli-reference/README.md index 6eb1af6c1..ae4e7cdd5 100644 --- a/docs/providers/openwhisk/cli-reference/README.md +++ b/docs/providers/openwhisk/cli-reference/README.md @@ -1,5 +1,5 @@ @@ -8,10 +8,10 @@ layout: Doc ### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/) -# Serverless AWS Lambda CLI Reference +# Serverless Apache OpenWhisk CLI Reference -Welcome to the Serverless AWS Lambda CLI Reference! Please select a section on the left to get started. +Welcome to the Serverless Apache OpenWhisk 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. +**Note:** Before continuing [Apache OpenWhisk system credentials](../guide/credentials.md) are required for using the CLI. If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](https://gitter.im/serverless/serverless) diff --git a/docs/providers/openwhisk/cli-reference/config-credentials.md b/docs/providers/openwhisk/cli-reference/config-credentials.md index 1fc5536ec..bc50e8aaa 100644 --- a/docs/providers/openwhisk/cli-reference/config-credentials.md +++ b/docs/providers/openwhisk/cli-reference/config-credentials.md @@ -13,15 +13,14 @@ layout: Doc # Config Credentials ```bash -serverless config credentials --provider provider --key key --secret secret +serverless config credentials --provider provider --apihost apihost --auth auth ``` ## Options - `--provider` or `-p` The provider (in this case `aws`). **Required**. -- `--key` or `-k` The `aws_access_key_id`. **Required**. -- `--secret` or `-s` The `aws_secret_access_key`. **Required**. -- `--profile` or `-n` The name of the profile which should be created. +- `--apihost` or `-h` The `openwhisk_apihost`. **Required**. +- `--auth` or `-a` The `openwhisk_auth`. **Required**. ## Provided lifecycle events @@ -29,18 +28,10 @@ serverless config credentials --provider provider --key key --secret secret ## Examples -### Configure the `default` profile +### Configure the default profile ```bash -serverless config credentials --provider aws --key 1234 --secret 5678 +serverless config credentials --provider aws --apihost openwhisk.ng.bluemix.net --auth username:password ``` -This example will configure the `default` profile with the `aws_access_key_id` of `1234` and the `aws_secret_access_key` of `5678`. - -### Configure a custom profile - -```bash -serverless config credentials --provider aws --key 1234 --secret 5678 --profile custom-profile -``` - -This example create and configure a `custom-profile` profile with the `aws_access_key_id` of `1234` and the `aws_secret_access_key` of `5678`. +Credentials are stored in `~/.wskprops`, which you can edit directly if needed. diff --git a/docs/providers/openwhisk/cli-reference/create.md b/docs/providers/openwhisk/cli-reference/create.md index 1c4d3c021..58d20ed16 100644 --- a/docs/providers/openwhisk/cli-reference/create.md +++ b/docs/providers/openwhisk/cli-reference/create.md @@ -1,5 +1,5 @@ -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/create) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/create) # Create @@ -17,13 +17,13 @@ Creates a new service in the current working directory based on the provided tem **Create service in current working directory:** ```bash -serverless create --template aws-nodejs +serverless create --template openwhisk-nodejs ``` **Create service in new folder:** ```bash -serverless create --template aws-nodejs --path myService +serverless create --template openwhisk-nodejs --path myService ``` ## Options @@ -40,12 +40,7 @@ To see a list of available templates run `serverless create --help` Most commonly used templates: -- aws-nodejs -- aws-python -- aws-java-maven -- aws-java-gradle -- aws-scala-sbt -- aws-csharp +- openwhisk-nodejs - plugin ## Examples @@ -53,19 +48,18 @@ Most commonly used templates: ### Creating a new service ```bash -serverless create --template aws-nodejs --name my-special-service +serverless create --template openwhisk-nodejs --name my-special-service ``` -This example will generate scaffolding for a service with `AWS` as a provider and `nodejs` as runtime. The scaffolding +This example will generate scaffolding for a service with `openwhisk` as a provider and `nodejs:6` as runtime. The scaffolding will be generated in the current working directory. -Your new service will have a default stage called `dev` and a default region inside that stage called `us-east-1`. -The provider which is used for deployment later on is AWS (Amazon web services). +The provider which is used for deployment later on is Apache OpenWhisk. ### Creating a named service in a (new) directory ```bash -serverless create --template aws-nodejs --path my-new-service +serverless create --template openwhisk-nodejs --path my-new-service ``` This example will generate scaffolding for a service with `AWS` as a provider and `nodejs` as runtime. The scaffolding diff --git a/docs/providers/openwhisk/cli-reference/deploy-function.md b/docs/providers/openwhisk/cli-reference/deploy-function.md index 986c1ee72..0ef28ccb6 100644 --- a/docs/providers/openwhisk/cli-reference/deploy-function.md +++ b/docs/providers/openwhisk/cli-reference/deploy-function.md @@ -1,8 +1,8 @@ @@ -12,7 +12,7 @@ layout: Doc # 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. This command simply compiles a deployment package with a single function handler. This is a much faster way of deploying changes in code. ```bash serverless deploy function -f functionName @@ -20,19 +20,3 @@ serverless deploy function -f functionName ## 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. - -## Examples - -### Deployment without stage and region options - -```bash -serverless deploy function --function helloWorld -``` - -### Deployment with stage and region options - -```bash -serverless deploy function --function helloWorld --stage dev --region us-east-1 -``` diff --git a/docs/providers/openwhisk/cli-reference/deploy-list.md b/docs/providers/openwhisk/cli-reference/deploy-list.md deleted file mode 100644 index edbbfa10a..000000000 --- a/docs/providers/openwhisk/cli-reference/deploy-list.md +++ /dev/null @@ -1,32 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy-list) - - -# Deploy List - -The `sls deploy list` command will list your recent deployments available in your S3 deployment bucket. It will use stage and region from the provider config and show the timestamp of each deployment so you can roll back if necessary using `sls rollback`. - -## 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. - -## Artifacts - -After the `serverless deploy` command runs all created deployment artifacts are placed in the `.serverless` folder of the service. - -## Examples - -### List existing deploys - -```bash -serverless deploy list --stage dev --region us-east-1 -``` diff --git a/docs/providers/openwhisk/cli-reference/deploy.md b/docs/providers/openwhisk/cli-reference/deploy.md index 35c94e18e..052fd09e9 100644 --- a/docs/providers/openwhisk/cli-reference/deploy.md +++ b/docs/providers/openwhisk/cli-reference/deploy.md @@ -1,5 +1,5 @@ @@ -19,8 +19,6 @@ 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 @@ -28,52 +26,31 @@ serverless info ## Examples -### AWS +### Apache OpenWhisk -On AWS the info plugin uses the `Outputs` section of the CloudFormation stack and the AWS SDK to gather the necessary information. -See the example below for an example output. +On Apache OpenWhisk the info plugin uses platform API to gather the necessary +information about deployed functions, events, routes and more. See the example +below for an example output. **Example:** ```bash $ serverless info - Service Information -service: my-serverless-service -stage: dev -region: us-east-1 -api keys: - myKey: some123valid456api789key1011for1213api1415gateway +platform: openwhisk.ng.bluemix.net +namespace: _ +service: hello-world + +actions: +hello-world-dev-helloWorld + +triggers: +my-hello-world-event + +rules: +my-hello-world-event-rule + endpoints: - GET - https://dxaynpuzd4.execute-api.us-east-1.amazonaws.com/dev/users -functions: - my-serverless-service-dev-hello: arn:aws:lambda:us-east-1:377024778620:function:my-serverless-service-dev-hello -``` - -#### Verbose - -When using the `--verbose` flag, the `info` command will also append all Stack Outputs to the output: - -```bash -$ serverless info --verbose - -Service Information -service: my-serverless-service -stage: dev -region: us-east-1 -api keys: - myKey: some123valid456api789key1011for1213api1415gateway -endpoints: - GET - https://dxaynpuzd4.execute-api.us-east-1.amazonaws.com/dev/users -functions: - my-serverless-service-dev-hello: arn:aws:lambda:us-east-1:377024778620:function:my-serverless-service-dev-hello - -Stack Outputs -CloudFrontUrl: d2d10e2tyk1pei.cloudfront.net -ListScreenshotsLambdaFunctionArn: arn:aws:lambda:us-east-1:377024778620:function:lambda-screenshots-dev-listScreenshots -ScreenshotBucket: dev-svdgraaf-screenshots -CreateThumbnailsLambdaFunctionArn: arn:aws:lambda:us-east-1:377024778620:function:lambda-screenshots-dev-createThumbnails -TakeScreenshotLambdaFunctionArn: arn:aws:lambda:us-east-1:377024778620:function:lambda-screenshots-dev-takeScreenshot -ServiceEndpoint: https://12341jc801.execute-api.us-east-1.amazonaws.com/dev -ServerlessDeploymentBucketName: lambda-screenshots-dev-serverlessdeploymentbucket-15b7pkc04f98a +https://xyz1234-gws.api-gw.mybluemix.net +/hello-world GET -> hello-world ``` diff --git a/docs/providers/openwhisk/cli-reference/install.md b/docs/providers/openwhisk/cli-reference/install.md index ec72c4f34..9f985325f 100644 --- a/docs/providers/openwhisk/cli-reference/install.md +++ b/docs/providers/openwhisk/cli-reference/install.md @@ -1,8 +1,8 @@ diff --git a/docs/providers/openwhisk/cli-reference/invoke-local.md b/docs/providers/openwhisk/cli-reference/invoke-local.md index 253cae873..fdd50024b 100644 --- a/docs/providers/openwhisk/cli-reference/invoke-local.md +++ b/docs/providers/openwhisk/cli-reference/invoke-local.md @@ -1,8 +1,8 @@ @@ -12,7 +12,7 @@ layout: Doc # 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 Apache OpenWhisk 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. ```bash serverless invoke local --function functionName @@ -60,4 +60,4 @@ This example will pass the json data in the `lib/data.json` file (relative to th ### Limitations -Currently, `invoke local` only supports the NodeJs and Python runtimes. +Currently, `invoke local` only supports the NodeJs diff --git a/docs/providers/openwhisk/cli-reference/invoke.md b/docs/providers/openwhisk/cli-reference/invoke.md index 5b88d2f58..9e362830a 100644 --- a/docs/providers/openwhisk/cli-reference/invoke.md +++ b/docs/providers/openwhisk/cli-reference/invoke.md @@ -1,8 +1,8 @@ @@ -20,8 +20,6 @@ serverless invoke [local] --function functionName ## 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. - `--data` or `-d` String data to be passed as an event to your function. By default data is read from standard input. - `--path` or `-p` The path to a json file with input data to be passed to the invoked function. This path is relative to the root directory of the service. - `--type` or `-t` The type of invocation. Either `RequestResponse`, `Event` or `DryRun`. Default is `RequestResponse`. @@ -30,7 +28,6 @@ serverless invoke [local] --function functionName ## Provided lifecycle events - `invoke:invoke` - # Invoke Local Invokes a function locally for testing and logs the output. You can only invoke Node.js runtime locally at the moment. Keep in mind that we mock the `context` with simple mock data. @@ -47,31 +44,31 @@ root directory of the service. The json file should have event and context prope ## Examples -### AWS +### Apache OpenWhisk ```bash -serverless invoke --function functionName --stage dev --region us-east-1 +serverless invoke --function functionName ``` -This example will invoke your deployed function named `functionName` in region `us-east-1` in stage `dev`. This will -output the result of the invocation in your terminal. +This example will invoke your deployed function on the configured platform +endpoint. This will output the result of the invocation in your terminal. #### Function invocation with data ```bash -serverless invoke --function functionName --stage dev --region us-east-1 --data "hello world" +serverless invoke --function functionName --data '{"name": "Bernie"}' ``` #### Function invocation with data from standard input ```bash -node dataGenerator.js | serverless invoke --function functionName --stage dev --region us-east-1 +node dataGenerator.js | serverless invoke --function functionName ``` #### Function invocation with logging ```bash -serverless invoke --function functionName --stage dev --region us-east-1 --log +serverless invoke --function functionName --log ``` Just like the first example, but will also outputs logging information about your invocation. @@ -79,7 +76,7 @@ Just like the first example, but will also outputs logging information about you #### Function invocation with data passing ```bash -serverless invoke --function functionName --stage dev --region us-east-1 --path lib/data.json +serverless invoke --function functionName --path lib/data.json ``` This example will pass the json data in the `lib/data.json` file (relative to the root of the service) while invoking diff --git a/docs/providers/openwhisk/cli-reference/logs.md b/docs/providers/openwhisk/cli-reference/logs.md index b364e79ef..b1e662a68 100644 --- a/docs/providers/openwhisk/cli-reference/logs.md +++ b/docs/providers/openwhisk/cli-reference/logs.md @@ -1,8 +1,8 @@ @@ -21,8 +21,6 @@ serverless logs -f hello ## Options - `--function` or `-f` The function you want to fetch the logs for. **Required** -- `--stage` or `-s` The stage you want to view the function logs for. If not provided, the plugin will use the default stage listed in `serverless.yml`. If that doesn't exist either it'll just fetch the logs from the `dev` stage. -- `--region` or `-r` The region you want to view the function logs for. If not provided, the plugin will use the default region listed in `serverless.yml`. If that doesn't exist either it'll just fetch the logs from the `us-east-1` region. - `--startTime` A specific unit in time to start fetching logs from (ie: `2010-10-20` or `1469705761`). Here's a list of the supported string formats: ```bash @@ -53,9 +51,7 @@ serverless logs -f hello ## Examples -### AWS - -**Note:** There's a small lag between invoking the function and actually having the log event registered in CloudWatch. So it takes a few seconds for the logs to show up right after invoking the function. +### Apache OpenWhisk ```bash serverless logs -f hello --startTime 5h @@ -71,7 +67,7 @@ This will fetch the logs that happened starting at epoch `1469694264`. serverless logs -f hello -t ``` -Serverless will tail the CloudWatch log output and print new log messages coming in. +Serverless will tail the platform log output and print new log messages coming in. ```bash serverless logs -f hello --filter serverless diff --git a/docs/providers/openwhisk/cli-reference/metrics.md b/docs/providers/openwhisk/cli-reference/metrics.md deleted file mode 100644 index 64a3c98bf..000000000 --- a/docs/providers/openwhisk/cli-reference/metrics.md +++ /dev/null @@ -1,63 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/metrics) - - -# Metrics - -Lets you watch the metrics of a specific function. - -```bash -serverless metrics -``` - -## Options - -- `--function` or `-f` The function you want to fetch the metrics for. -- `--stage` or `-s` The stage you want to view the function metrics for. If not provided, the plugin will use the default stage listed in `serverless.yml`. If that doesn't exist either it'll just fetch the metrics from the `dev` stage. -- `--region` or `-r` The region you want to view the function metrics for. If not provided, the plugin will use the default region listed in `serverless.yml`. If that doesn't exist either it'll just fetch the metrics from the `us-east-1` region. -- `--startTime` A specific unit in time to start fetching metrics from (ie: `2010-10-20`, `1469705761`, `30m` (30 minutes ago), `2h` (2 days ago) or `3d` (3 days ago)). Date formats should be written in ISO 8601. Defaults to 24h ago. -- `--endTime` A specific unit in time to end fetching metrics from (ie: `2010-10-21` or `1469705761`). Date formats should be written in ISO 8601. Defaults to now. - -## Examples - -**Note:** There's a small lag between invoking the function and actually having access to the metrics. It takes a few seconds for the metrics to show up right after invoking the function. - -### See service wide metrics for the last 24h - -```bash -serverless metrics -``` - -Displays service wide metrics for the last 24h. - -### See service wide metrics for a specific timespan - -```bash -serverless metrics --startTime 2016-01-01 --endTime 2016-01-02 -``` - -Displays service wide metrics for the time between January 1, 2016 and January 2, 2016. - -### See all metrics for the function `hello` of the last 24h - -```bash -serverless metrics --function hello -``` - -Displays all `hello` function metrics for the last 24h. - -### See metrics for the function `hello` of a specific timespan - -```bash -serverless metrics --function hello --startTime 2016-01-01 --endTime 2016-01-02 -``` - -Displays all `hello` function metrics for the time between January 1, 2016 and January 2, 2016. diff --git a/docs/providers/openwhisk/cli-reference/remove.md b/docs/providers/openwhisk/cli-reference/remove.md index 65aa190c6..8e9dee1c0 100644 --- a/docs/providers/openwhisk/cli-reference/remove.md +++ b/docs/providers/openwhisk/cli-reference/remove.md @@ -1,8 +1,8 @@ @@ -12,17 +12,12 @@ layout: Doc # 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` @@ -31,7 +26,7 @@ serverless remove ### Removal of service in specific stage and region ```bash -serverless remove --stage dev --region us-east-1 +serverless remove ``` -This example will remove the deployed service of your current working directory with the stage `dev` and the region `us-east-1`. +This example will remove the deployed service of your current working directory from the current platform endpoint. diff --git a/docs/providers/openwhisk/cli-reference/rollback.md b/docs/providers/openwhisk/cli-reference/rollback.md deleted file mode 100644 index 013677d9d..000000000 --- a/docs/providers/openwhisk/cli-reference/rollback.md +++ /dev/null @@ -1,77 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/rollback) - - - -# Rollback - -Rollback the Serverless service to a specific deployment. - -```bash -serverless rollback --timestamp timestamp -``` - -## 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` - -## Examples - -### AWS - -At first you want to run `serverless deploy list` to show your existing deployments. This will provide you with a list of the deployments stored in your S3 bucket. You can then use the timestamp of one of these deployments to set your infrastructure stack to this specific deployment. - -**Example:** - -``` -$ serverless deploy list -Serverless: Listing deployments: -Serverless: ------------- -Serverless: Timestamp: 1476790110568 -Serverless: Datetime: 2016-10-18T11:28:30.568Z -Serverless: Files: -Serverless: - compiled-cloudformation-template.json -Serverless: - mail-service.zip -Serverless: ------------- -Serverless: Timestamp: 1476889476243 -Serverless: Datetime: 2016-10-19T15:04:36.243Z -Serverless: Files: -Serverless: - compiled-cloudformation-template.json -Serverless: - mail-service.zip -Serverless: ------------- -Serverless: Timestamp: 1476893957131 -Serverless: Datetime: 2016-10-19T16:19:17.131Z -Serverless: Files: -Serverless: - compiled-cloudformation-template.json -Serverless: - mail-service.zip -Serverless: ------------- -Serverless: Timestamp: 1476895175540 -Serverless: Datetime: 2016-10-19T16:39:35.540Z -Serverless: Files: -Serverless: - compiled-cloudformation-template.json -Serverless: - mail-service.zip -Serverless: ------------- -Serverless: Timestamp: 1476993293402 -Serverless: Datetime: 2016-10-20T19:54:53.402Z -Serverless: Files: -Serverless: - compiled-cloudformation-template.json -Serverless: - mail-service.zip - -$ serverless rollback -t 1476893957131 -Serverless: Updating Stack... -Serverless: Checking Stack update progress... -..... -Serverless: Stack update finished... -``` From b68bcce72c83494f067c1773c6a91214c4f01645 Mon Sep 17 00:00:00 2001 From: James Thomas Date: Tue, 24 Jan 2017 16:29:24 +0000 Subject: [PATCH 04/30] Add events documentation --- docs/providers/openwhisk/events/README.md | 8 +- .../providers/openwhisk/events/alexa-skill.md | 27 - docs/providers/openwhisk/events/apigateway.md | 628 ++---------------- docs/providers/openwhisk/events/iot.md | 71 -- docs/providers/openwhisk/events/s3.md | 75 --- docs/providers/openwhisk/events/sns.md | 69 -- docs/providers/openwhisk/events/streams.md | 44 -- docs/providers/openwhisk/events/triggers.md | 82 +++ .../node/.serverless/hello-world.zip | Bin 1348 -> 0 bytes .../examples/hello-world/node/serverless.yml | 2 + 10 files changed, 131 insertions(+), 875 deletions(-) delete mode 100644 docs/providers/openwhisk/events/alexa-skill.md delete mode 100644 docs/providers/openwhisk/events/iot.md delete mode 100644 docs/providers/openwhisk/events/s3.md delete mode 100644 docs/providers/openwhisk/events/sns.md delete mode 100644 docs/providers/openwhisk/events/streams.md create mode 100644 docs/providers/openwhisk/events/triggers.md delete mode 100644 docs/providers/openwhisk/examples/hello-world/node/.serverless/hello-world.zip diff --git a/docs/providers/openwhisk/events/README.md b/docs/providers/openwhisk/events/README.md index 3efa50d92..91ba74bcb 100644 --- a/docs/providers/openwhisk/events/README.md +++ b/docs/providers/openwhisk/events/README.md @@ -1,5 +1,5 @@ @@ -8,12 +8,12 @@ layout: Doc ### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/) -# Serverless AWS Lambda Events +# Serverless Apache OpenWhisk Events -Welcome to the Serverless AWS Lambda Events Glossary! +Welcome to the Serverless Apache OpenWhisk Events Glossary! 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](https://gitter.im/serverless/serverless) -**Note:** Before continuing [AWS system credentials](../guide/credentials.md) are required for using the CLI. +**Note:** Before continuing [Apache OpenWhisk system credentials](../guide/credentials.md) are required for using the CLI. diff --git a/docs/providers/openwhisk/events/alexa-skill.md b/docs/providers/openwhisk/events/alexa-skill.md deleted file mode 100644 index 915464bcf..000000000 --- a/docs/providers/openwhisk/events/alexa-skill.md +++ /dev/null @@ -1,27 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/alexa-skill) - - -# Alexa Skill - -## Event definition - -This will enable your Lambda function to be called by an Alexa skill kit. - -```yml -functions: - mySkill: - handler: mySkill.handler - events: - - alexaSkill -``` - -You can find detailed guides on how to create an Alexa Skill with Serverless using NodeJS [here](https://github.com/serverless/examples/tree/master/aws-node-alexa-skill) as well as in combination with Python [here](https://github.com/serverless/examples/tree/master/aws-python-alexa-skill). diff --git a/docs/providers/openwhisk/events/apigateway.md b/docs/providers/openwhisk/events/apigateway.md index da0b22511..692c34660 100644 --- a/docs/providers/openwhisk/events/apigateway.md +++ b/docs/providers/openwhisk/events/apigateway.md @@ -1,8 +1,8 @@ @@ -12,22 +12,17 @@ layout: Doc # API Gateway -To create HTTP endpoints as Event sources for your AWS Lambda Functions, use the Serverless Framework's easy AWS API Gateway Events syntax. +Apache OpenWhisk has an [API gateway](https://github.com/openwhisk/openwhisk/blob/master/docs/apigateway.md) included within the platform. This service +allows you to define public HTTP endpoints for your serverless functions. -There are two ways you can configure your HTTP endpoints to integrate with your AWS Lambda Functions: -* lambda-proxy (Recommended) -* lambda +To create HTTP endpoints as Event sources for your Apache OpenWhisk Functions, use the Serverless Framework's easy API Gateway Events syntax. -The difference between these is `lambda-proxy` 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. - -By default, the Framework uses the `lambda-proxy` method (i.e., everything is passed into your Lambda), and nothing is required by you to enable it. - -## Lambda Proxy Integration +## API Gateway Events ### Simple HTTP Endpoint -This setup specifies that the `hello` function should be run when someone accesses the API gateway at `hello` via -a `GET` request. +This setup specifies that the `hello` function should be run when someone accesses the API gateway at `example/hello` via +a `GET` request. Here's an example: @@ -35,39 +30,42 @@ Here's an example: # serverless.yml functions: - index: + example: handler: handler.hello events: - http: GET hello ``` +URL paths for the serverless functions are prefixed with the function name, e.g. +`/function_name/some/path`. + ```javascript // handler.js 'use strict'; -module.exports.hello = function(event, context, callback) { - - 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!" }) - }; - - callback(null, response); +module.exports.hello = function(params) { + // Your function handler + return { payload: 'Hello world!' }; }; ``` -**Note:** When the body is a JSON-Document, you must parse it yourself: +When this service is deployed, the base API Gateway url will be +printed to the console. Combine this with your custom HTTP path to create +the full HTTP endpoint exposing your serverless function. + ``` -JSON.parse(event.body); +$ serverless deploy +... +Serverless: Configured API endpoint: https://xxx-yyy-gws.api-gw.mybluemix.net/example + +$ http get https://xxx-yyy-gws.api-gw.mybluemix.net/example/hello +{ + "payload": "Hello, World!" +} ``` -### HTTP Endpoint with Extended Options +### HTTP Endpoint with Parameters Here we've defined an POST endpoint for the path `posts/create`. @@ -75,571 +73,31 @@ Here we've defined an POST endpoint for the path `posts/create`. # serverless.yml functions: - create: - handler: posts.create + greeting: + handler: greeting.handler events: - - http: - path: posts/create - method: post + - http: POST greeting/generate ``` -### Enabling CORS -To set CORS configurations for your HTTP endpoints, simply modify your event configurations as follows: - -```yml -# serverless.yml - -functions: - hello: - handler: handler.hello - events: - - http: - path: hello - method: get - cors: true -``` - -If you want to use CORS with the lambda-proxy integration, remember to include `Access-Control-Allow-Origin` in your returned headers object, like this: - ```javascript -// handler.js +// posts.js 'use strict'; -module.exports.hello = function(event, context, callback) { - - const response = { - statusCode: 200, - headers: { - "Access-Control-Allow-Origin" : "*" // Required for CORS support to work - }, - body: JSON.stringify({ "message": "Hello World!" }) - }; - - callback(null, response); +module.exports.handler = function(params) { + const name = params.name || 'stranger'; + // Your function handler + return { payload: `Hello ${name}!` }; }; ``` -### HTTP Endpoints with Custom Authorizers +The body of the incoming request is parsed as JSON and passed as the +`params` argument to the function handler. -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. +The returned JavaScript object will be serialised as JSON and returned in the +HTTP response body. -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: +### CORS Support -```yml -functions: - create: - handler: posts.create - events: - - http: - path: posts/create - method: post - authorizer: authorizerFunc - authorizerFunc: - handler: handlers.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: - -```yml -functions: - create: - handler: posts.create - events: - - http: - path: posts/create - method: post - authorizer: - name: authorizerFunc - resultTtlInSeconds: 0 - identitySource: method.request.header.Authorization - identityValidationExpression: someRegex - authorizerFunc: - handler: handlers.authorizerFunc -``` - -If the Authorizer function does not exist in your service but exists in AWS, you can provide the ARN of the Lambda -function instead of the function name, as shown in the following example: - -```yml -functions: - create: - handler: posts.create - events: - - http: - path: posts/create - method: post - authorizer: xxx:xxx:Lambda-Name -``` - -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: - -```yml -functions: - create: - handler: posts.create - events: - - http: - path: posts/create - method: post - authorizer: - arn: xxx:xxx:Lambda-Name - resultTtlInSeconds: 0 - identitySource: method.request.header.Authorization - identityValidationExpression: someRegex -``` - -You can also configure an existing Cognito User Pool as the authorizer, as shown -in the following example: - -```yml -functions: - create: - handler: posts.create - events: - - http: - path: posts/create - method: post - authorizer: - arn: arn:aws:cognito-idp:us-east-1:xxx:userpool/us-east-1_ZZZ -``` - -By default the `sub` claim will be exposed in `events.cognitoPoolClaims`, you can add extra claims like so: - -```yml -functions: - create: - handler: posts.create - events: - - http: - path: posts/create - method: post - integration: lambda - authorizer: - arn: arn:aws:cognito-idp:us-east-1:xxx:userpool/us-east-1_ZZZ - claims: - - email - - nickname -``` - -Note: Since claims must be explicitly listed to be exposed, you must use `integration: lambda` integration type to access any claims. - -### Catching Exceptions In Your Lambda Function - -In case an exception is thrown in your lambda function AWS will send an error message with `Process exited before completing request`. This will be caught by the regular expression for the 500 HTTP status and the 500 status will be returned. - -### Setting API keys for your Rest API - -**Note:** Due to a CloudFormation restriction you need to wire up API Keys and usage plans manually in the AWS console. - -You can specify a list of API keys to be used by your service Rest API by adding an `apiKeys` array property to the -`provider` object in `serverless.yml`. You'll also need to explicitly specify which endpoints are `private` and require -one of the api keys to be included in the request by adding a `private` boolean property to the `http` event object you -want to set as private. API Keys are created globally, so if you want to deploy your service to different stages make sure -your API key contains a stage variable as defined below. - -Here's an example configuration for setting API keys for your service Rest API: - -```yml -service: my-service -provider: - name: aws - apiKeys: - - myFirstKey - - ${opt:stage}-myFirstKey - - ${env:MY_API_KEY} # you can hide it in a serverless variable -functions: - hello: - events: - - http: - path: user/create - method: get - private: true -``` - -Please note that those are the API keys names, not the actual values. Once you deploy your service, the value of those API keys will be auto generated by AWS and printed on the screen for you to use. - -Clients connecting to this Rest API will then need to set any of these API keys values in the `x-api-key` header of their request. This is only necessary for functions where the `private` property is set to true. - -## Lambda Integration - -This method is more complicated and involves a lot more configuration of the `http` event syntax. - -### Request Parameters - -To pass optional and required parameters to your functions, so you can use them in API Gateway tests and SDK generation, marking them as `true` will make them required, `false` will make them optional. - -```yml -functions: - create: - handler: posts.create - events: - - http: - path: posts/create - method: post - integration: lambda - request: - parameters: - querystrings: - url: true - headers: - foo: false - bar: true - paths: - bar: false -``` - -In order for path variables to work, API Gateway also needs them in the method path itself, like so: - -```yml -functions: - create: - handler: posts.post_detail - events: - - http: - path: posts/{id} - method: get - integration: lambda - request: - parameters: - paths: - id: true -``` - -### Request templates - -#### Default Request Templates - -Serverless ships with the following default request templates you can use out of the box: - -1. `application/json` -2. `application/x-www-form-urlencoded` - -Both templates give you access to the following properties you can access with the help of the `event` object: - -- body -- method -- principalId -- stage -- headers -- query -- path -- identity -- stageVariables - -#### Custom Request Templates - -However you can define and use your own request templates as follows (you can even overwrite the default request templates -by defining a new request template for an existing content type): - -```yml -functions: - create: - handler: posts.create - events: - - http: - method: get - path: whatever - integration: lambda - request: - template: - text/xhtml: '{ "stage" : "$context.stage" }' - application/json: '{ "httpMethod" : "$context.httpMethod" }' -``` - -**Note:** The templates are defined as plain text here. However you can also reference an external file with the help of the `${file(templatefile)}` syntax. - -**Note 2:** In .yml, strings containing `:`, `{`, `}`, `[`, `]`, `,`, `&`, `*`, `#`, `?`, `|`, `-`, `<`, `>`, `=`, `!`, `%`, `@`, `` ` `` must be quoted. - -If you want to map querystrings to the event object, you can use the `$input.params('hub.challenge')` syntax from API Gateway, as follows: - -```yml -functions: - create: - handler: posts.create - events: - - http: - method: get - path: whatever - integration: lambda - request: - template: - application/json: '{ "foo" : "$input.params(''bar'')" }' -``` - -**Note:** Notice when using single-quoted strings, any single quote `'` inside its contents must be doubled (`''`) to escape it. -You can then access the query string `https://example.com/dev/whatever?bar=123` by `event.foo` in the lambda function. -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): - -```yml -functions: - create: - handler: posts.create - events: - - http: - method: get - path: whatever - integration: lambda - request: - passThrough: NEVER -``` - -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 | - -See the [api gateway documentation](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#integration-passthrough-behaviors) for detailed descriptions of these options. - -**Notes:** - -- A missing/empty request Content-Type is considered to be the API Gateway default (`application/json`) -- API Gateway docs refer to "WHEN_NO_TEMPLATE" (singular), but this will fail during creation as the actual value should be "WHEN_NO_TEMPLATES" (plural) - -### Responses - -Serverless lets you setup custom headers and a response template for your `http` event. - -#### Custom Response Headers - -Here's an example which shows you how you can setup a custom response header: - -```yml -functions: - create: - handler: posts.create - events: - - http: - method: get - path: whatever - integration: lambda - response: - headers: - Content-Type: integration.response.header.Content-Type - Cache-Control: "'max-age=120'" -``` - -**Note:** You're able to use the [integration response variables](http://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#mapping-response-parameters) -for your header values. Headers are passed to API Gateway exactly like you define them. Passing the `Cache-Control` header -as `"'max-age=120'"` means API Gateway will receive the value as `'max-age=120'` (enclosed with single quotes). - -### Custom Response Templates - -Sometimes you'll want to define a custom response template API Gateway should use to transform your lambdas output. -Here's an example which will transform the return value of your lambda so that the browser renders it as HTML: - -```yml -functions: - create: - handler: posts.create - events: - - http: - method: get - path: whatever - integration: lambda - response: - headers: - Content-Type: "'text/html'" - template: $input.path('$') -``` - -**Note:** The template is defined as plain text here. However you can also reference an external file with the help of -the `${file(templatefile)}` syntax. - -### Status codes - -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. - -#### 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 | - -#### Using Status Codes - -To return a given status code you simply need to add square brackets with the status code of your choice to your -returned message like this: `[401] You are not authorized to access this resource!`. - -Here's an example which shows you how you can raise a 404 HTTP status from within your lambda function. - -```javascript -module.exports.hello = (event, context, callback) => { - callback(new Error('[404] Not found')); -} -``` - -#### Custom Status Codes - -You can override the defaults status codes supplied by Serverless. You can use this to change the default status code, add/remove status codes, or change the templates and headers used for each status code. Use the pattern key to change the selection process that dictates what code is returned. - -If you specify a status code with a pattern of '' that will become the default response code. See below on how to change the default to 201 for post requests. - -If you omit any default status code. A standard default 200 status code will be generated for you. - -```yml -functions: - create: - handler: posts.create - events: - - http: - method: post - path: whatever - integration: lambda - response: - headers: - 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'" -``` - -You can also create varying response templates for each code and content type by creating an object with the key as the content type - -```yml -functions: - create: - handler: posts.create - events: - - http: - method: post - path: whatever - integration: lambda - response: - headers: - 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'" -``` - -## Enabling CORS with the Lambda Integration Method - -```yml -functions: - hello: - handler: handler.hello - events: - - http: - path: user/create - method: get - integration: lambda - cors: true -``` - -You can equally set your own attributes: - -```yml -functions: - hello: - handler: handler.hello - events: - - http: - path: user/create - method: get - integration: lambda - cors: - origins: - - '*' - headers: - - Content-Type - - X-Amz-Date - - Authorization - - X-Api-Key - - X-Amz-Security-Token -``` - -This example is the default setting and is exactly the same as the previous example. The `Access-Control-Allow-Methods` header is set automatically, based on the endpoints specified in your service configuration with CORS enabled. - -**Note:** If you are using the default lambda proxy integration, remember to include `Access-Control-Allow-Origin` in your returned headers object otherwise CORS will fail. - -``` -module.exports.hello = (event, context, callback) => { - return callback(null, { - statusCode: 200, - headers: { - 'Access-Control-Allow-Origin': '*' - }, - body: 'Hello World!' - }); -} -``` - -## Setting an HTTP Proxy on API Gateway - -To set up an HTTP proxy, you'll need two CloudFormation templates, one for the endpoint (known as resource in CF), and -one for method. These two templates will work together to construct your proxy. So if you want to set `your-app.com/serverless` as a proxy for `serverless.com`, you'll need the following two templates in your `serverless.yml`: - -```yml -service: service-name -provider: aws -functions: - ... - -resources: - Resources: - ProxyResource: - Type: AWS::ApiGateway::Resource - Properties: - ParentId: - Fn::GetAtt: - - ApiGatewayRestApi # our default Rest API logical ID - - RootResourceId - PathPart: serverless # the endpoint in your API that is set as proxy - RestApiId: - Ref: ApiGatewayRestApi - ProxyMethod: - Type: AWS::ApiGateway::Method - Properties: - ResourceId: - Ref: ProxyResource - RestApiId: - Ref: ApiGatewayRestApi - HttpMethod: GET # the method of your proxy. Is it GET or POST or ... ? - MethodResponses: - - StatusCode: 200 - Integration: - IntegrationHttpMethod: POST - Type: HTTP - Uri: http://serverless.com # the URL you want to set a proxy to - IntegrationResponses: - - StatusCode: 200 -``` - -There's a lot going on in these two templates, but all you need to know to set up a simple proxy is setting the method & -endpoint of your proxy, and the URI you want to set a proxy to. - -Now that you have these two CloudFormation templates defined in your `serverless.yml` file, you can simply run -`serverless deploy` and that will deploy these custom resources for you along with your service and set up a proxy on your Rest API. +**Note:** All HTTP endpoints defined in this manner have cross-site requests +enabled for all source domains. diff --git a/docs/providers/openwhisk/events/iot.md b/docs/providers/openwhisk/events/iot.md deleted file mode 100644 index 4ba21e9a7..000000000 --- a/docs/providers/openwhisk/events/iot.md +++ /dev/null @@ -1,71 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/iot) - - -# IoT - -## Simple event definition - -This will enable your Lambda function to be called by an AWS IoT rule. - -```yml -functions: - myIoT: - handler: myIoT.handler - events: - - iot: - sql: "SELECT * FROM 'some_topic'" -``` - -## Enabling / Disabling - -**Note:** `iot` events are enabled by default. - -This will create and attach a disabled `iot` event for the `myIoT` function. - -```yml -functions: - myIoT: - handler: myIoT.handler - events: - - iot: - sql: "SELECT * FROM 'some_topic'" - enabled: false -``` - -## Specify Name and Description - -Name and Description can be specified with the help of the `name` and `description` properties. - -```yml -functions: - myIoT: - handler: myIoT.handler - events: - - iot: - name: "myIotEvent" - sql: "SELECT * FROM 'some_topic'" - description: "My IoT Event Description" -``` - -## Specify SQL Versions - -[SQL Versions](http://docs.aws.amazon.com/iot/latest/developerguide/iot-rule-sql-version.html) can be specified for an `iot` event. However the `sqlVersion` is not a required property. - -```yml -functions: - myIoT: - handler: myIoT.handler - events: - - iot: - sql: "SELECT * FROM 'some_topic'" - sqlVersion: "beta" -``` diff --git a/docs/providers/openwhisk/events/s3.md b/docs/providers/openwhisk/events/s3.md deleted file mode 100644 index 673fd7c78..000000000 --- a/docs/providers/openwhisk/events/s3.md +++ /dev/null @@ -1,75 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/s3) - - -# S3 - -## Simple event definition - -This will create a `photos` bucket which fires the `resize` function when an object is added or modified inside the bucket. A hardcoded bucket name can lead to issues as a bucket name can only be used once in S3. For that you can use the [Serverless Variable syntax](../guide/variables.md) and add dynamic elements to the bucket name. - -```yaml -functions: - resize: - handler: resize.handler - events: - - s3: photos -``` - -## Setting the specific trigger event - -This will create a bucket `photos`. The `users` function is called whenever an object is removed from the bucket. Check out the [AWS documentation](http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html#notification-how-to-event-types-and-destinations) to learn more about all the different event types that can be configured. - -```yaml -functions: - users: - handler: users.handler - events: - - s3: - bucket: photos - event: s3:ObjectRemoved:* -``` - -## Setting filter rules - -This will create a bucket `photos`. The `users` function is called whenever an image with `.jpg` extension is uploaded to folder `uploads` in the bucket. Check out the [AWS documentation](http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html#notification-how-to-filtering) to learn more about all the different filter types that can be configured. - -```yaml -functions: - users: - handler: users.handler - events: - - s3: - bucket: photos - event: s3:ObjectCreated:* - rules: - - prefix: uploads/ - - suffix: .jpg -``` - -## Triggering separate functions from the same bucket - -You're able to repeat the S3 event configuration in the same or separate functions so one bucket can call these functions. One caveat though is that you can't repeat the same configuration in both functions, e.g. the event type has to be different. - -The following example will work: - -```yaml -functions: - users: - handler: users.handler - events: - - s3: - bucket: photos - event: s3:ObjectCreated:* - - s3: - bucket: photos - event: s3:ObjectRemoved:* -``` diff --git a/docs/providers/openwhisk/events/sns.md b/docs/providers/openwhisk/events/sns.md deleted file mode 100644 index fa0efbffc..000000000 --- a/docs/providers/openwhisk/events/sns.md +++ /dev/null @@ -1,69 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/sns) - - -# SNS - -In the following example we create a new SNS topic with the name `dispatch` which is bound to the `dispatcher` function. The function will be called every time a message is sent to the `dispatch` topic. - -```yml -functions: - dispatcher: - handler: dispatcher.dispatch - events: - - sns: dispatch -``` - -You're also able to add the same SNS topic to multiple functions: - -```yml -functions: - dispatcher: - handler: dispatcher.dispatch - events: - - sns: dispatch - dispatcher2: - handler: dispatcher2.dispatch - events: - - sns: dispatch -``` - -This will run both functions for a message sent to the dispatch topic. - -## Creating the permission for a pre-existing topic - -If you want to run a function from a preexisting SNS topic you need to connect the topic to a Lambda function yourself. By defining a topic arn inside of the SNS topic we're able to set up the Lambda Permission so SNS is allowed to call this function. - -```yml -functions: - dispatcher: - handler: dispatcher.dispatch - events: - - sns: arn:xxx -``` - -Just make sure your function is already subscribed to the topic, as there's no way to add subscriptions to pre-existing topics in CF. The framework will just give permission to SNS to invoke the function. - -## Setting a display name - -This event definition ensures that the `aggregator` function get's called every time a message is sent to the -`aggregate` topic. `Data aggregation pipeline` will be shown in the AWS console so that the user can understand what the -SNS topic is used for. - -```yml -functions: - aggregator: - handler: aggregator.handler - events: - - sns: - topicName: aggregate - displayName: Data aggregation pipeline -``` diff --git a/docs/providers/openwhisk/events/streams.md b/docs/providers/openwhisk/events/streams.md deleted file mode 100644 index 9e506e3de..000000000 --- a/docs/providers/openwhisk/events/streams.md +++ /dev/null @@ -1,44 +0,0 @@ - - - -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/streams) - - -# DynamoDB / Kinesis Streams - -This setup specifies that the `compute` function should be triggered whenever the corresponding DynamoDB table is modified (e.g. a new entry is added). - -**Note:** The `stream` event will hook up your existing streams to a Lambda function. Serverless won't create a new stream for you. - -```yml -functions: - compute: - handler: handler.compute - events: - - stream: arn:aws:dynamodb:region:XXXXXX:table/foo/stream/1970-01-01T00:00:00.000 -``` - -## Setting the BatchSize and StartingPosition - -This configuration sets up a disabled Kinesis stream event for the `preprocess` function which has a batch size of `100`. The starting position is -`LATEST`. - -**Note:** The `stream` event will hook up your existing streams to a Lambda function. Serverless won't create a new stream for you. - -```yml -functions: - preprocess: - handler: handler.preprocess - events: - - stream: - arn: arn:aws:kinesis:region:XXXXXX:stream/foo - batchSize: 100 - startingPosition: LATEST - enabled: false -``` diff --git a/docs/providers/openwhisk/events/triggers.md b/docs/providers/openwhisk/events/triggers.md new file mode 100644 index 000000000..f40a3e862 --- /dev/null +++ b/docs/providers/openwhisk/events/triggers.md @@ -0,0 +1,82 @@ + + + +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/streams) + + +# Triggers + +Functions are connected to event sources in OpenWhisk [using triggers and rules](https://github.com/openwhisk/openwhisk/blob/master/docs/triggers_rules.md). +Triggers create a named event stream within the system. Triggers can be fired +manually or connected to external data sources, like databases or message +queues. + +Rules set up a binding between triggers and serverless functions. With an active +rule, each time a trigger is fired, the function will be executed with the +trigger payload. + +Event binding using triggers and rules for functions can be configured through the `serverless.yaml` file. + +```yaml +functions: + my_function: + handler: index.main + events: + - trigger: my_trigger +``` +This configuration will create a trigger called `servicename-my_trigger` with an active rule binding `my_function` to this event stream. + +## Customising Rules + +Rule names default to the following format `servicename-trigger-to-action`. These names be explicitly set through configuration. + +```yaml +functions: + my_function: + handler: index.main + events: + - trigger: + name: "my_trigger" + rule: "rule_name" +``` + +## Customing Triggers + +Triggers can be defined as separate resources in the `serverless.yaml` file. This allows you to set up trigger properties like default parameters. + +```yaml +functions: + my_function: + handler: index.main + events: + - trigger: my_trigger + +resources: + triggers: + my_trigger: + parameters: + hello: world +``` + +## Trigger Feeds + +Triggers can be bound to external event sources using the `feed` property. OpenWhisk [provides a catalogue](https://github.com/openwhisk/openwhisk/blob/master/docs/catalog.md) of third-party event sources bundled as [packages](https://github.com/openwhisk/openwhisk/blob/master/docs/packages.md#creating-and-using-trigger-feeds). + +This example demonstrates setting up a trigger which uses the `/whisk.system/alarms/alarm` feed. The `alarm` feed will fire a trigger according to a user-supplied cron schedule. + +```yaml +resources: + triggers: + alarm_trigger: + parameters: + hello: world + feed: /whisk.system/alarms/alarm + feed_parameters: + cron: '*/8 * * * * *' +``` diff --git a/docs/providers/openwhisk/examples/hello-world/node/.serverless/hello-world.zip b/docs/providers/openwhisk/examples/hello-world/node/.serverless/hello-world.zip deleted file mode 100644 index 86fb3e0333fa0cf67dfb2dfaf7b03bc38220eec3..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1348 zcmWIWW@Zs#-~hs~TnjG-B)|n^XC&sO+*F^?(Y7c)iB{# z>mkmA9`lz>JQHiSd`^45x)~x4*j~yY01yna1-^zjs~}%iGHO z>(z7_PX53ei|=7OPiXned2TG4`QfK|Z}+ag_h;|A-P`f3T7Q0dqfVGb{=dj9-_RXtaaC!#FZ}4HZpK+}EK;H91F$FyPzUAFJYYy`Hw%M#V z4gme7%!tqDoIn*pu8uCgu6nsCQ$u32ZySizUSGeXP;Qq~?)JOU8qJfY=&pIafOE=4 zku?$5H%3JpO_DL6^6z`>O}{ygnmQ~^OMVxg+xh%imPp$f&+rE?OR~adK!YkyfQ2gEJflRqsDNmP#3D1yv!q+IDC3}7U)2C4dC$gsg$_V=~ciqZg zKFf7@_8XSD9!U6By^BNq^Hbjn>;1niBX!olpMD^Fx%a!2Q{74I(jgfu`WZe{KK>{n z_kJRG!OkrUME@#HiP74Su`PpZi&%@FZp6zEFTLNzq^cL*G4VBVaapPN_{;|(>D;&^ zdHHa+{G|@b$@gwZSSRMpslMvOrR}oDW9yGE&Tq`iH;XAq*RL}EeKcMmCs$w+qaV`| zSFP6_MqM0o;vK(@H63-#O&zO$3Aq-2&plr_|5BUFQj1;*P8RWt2GaMPm!0UF<#>x% zk4N^>o7<9RW?$}{5J-$DobJ3cx@0D2hI0V-@A;YO7oK?N`14Kmv+?BPl0H%5=+u09 z!?Atq8r*{JGcS>|NSUN2#pqMK&WyuJ%4e>b(B6cQ1zQgWYz}^4)Fc_!dhhSy=q=&Q z3;)S%{c=n2MvSz3FN>l|#S@+NPWh`|zLhy)rfR$0sJ=I0-L_fBZi*^(%e|@7+5V>K zP{Dt$wM(mHod4FwT-$Fvt>q^BhDi&94&8`h%oS^N4fZ<9Jt>g$?hkJTE7P~TRE;b3 z*m9Rnbv@Ce_wZLDt z_EszO_-?&*;neME&gZssoZnj7e5%fF*}F>l|1aN2_uYsGCFI!$4r)wdVqo~r0!qk? zOuEd7VhA~VgNh*tP+(Zn2x1`$C3JnrnFEyhApoTB5Ri#n6rk%wb`2==KmbVR9$-d; XXQcpdRyL3nGZ3x>(yc(pGcW)El?)#= diff --git a/docs/providers/openwhisk/examples/hello-world/node/serverless.yml b/docs/providers/openwhisk/examples/hello-world/node/serverless.yml index f4a7c6960..8500b8c8f 100644 --- a/docs/providers/openwhisk/examples/hello-world/node/serverless.yml +++ b/docs/providers/openwhisk/examples/hello-world/node/serverless.yml @@ -7,6 +7,8 @@ provider: functions: helloWorld: handler: handler.helloWorldHandler + events: + - http: GET hello # remember to run npm install to download the provider plugin. plugins: From 16eae684b8052de030046fac18cc4422183e7399 Mon Sep 17 00:00:00 2001 From: James Thomas Date: Wed, 25 Jan 2017 15:11:58 +0000 Subject: [PATCH 05/30] update docs for schedule event --- .../cli-reference/config-credentials.md | 2 +- docs/providers/openwhisk/events/schedule.md | 55 +++++++++---------- docs/providers/openwhisk/guide/credentials.md | 15 +---- 3 files changed, 27 insertions(+), 45 deletions(-) diff --git a/docs/providers/openwhisk/cli-reference/config-credentials.md b/docs/providers/openwhisk/cli-reference/config-credentials.md index bc50e8aaa..5ad12ebdf 100644 --- a/docs/providers/openwhisk/cli-reference/config-credentials.md +++ b/docs/providers/openwhisk/cli-reference/config-credentials.md @@ -18,7 +18,7 @@ serverless config credentials --provider provider --apihost apihost --auth auth ## Options -- `--provider` or `-p` The provider (in this case `aws`). **Required**. +- `--provider` or `-p` The provider (in this case `openwhisk`). **Required**. - `--apihost` or `-h` The `openwhisk_apihost`. **Required**. - `--auth` or `-a` The `openwhisk_auth`. **Required**. diff --git a/docs/providers/openwhisk/events/schedule.md b/docs/providers/openwhisk/events/schedule.md index 7e2178c8c..4269c8f1b 100644 --- a/docs/providers/openwhisk/events/schedule.md +++ b/docs/providers/openwhisk/events/schedule.md @@ -12,23 +12,35 @@ layout: Doc # Schedule -The following config will attach a schedule event and causes the function `crawl` to be called every 2 hours. The configuration allows you to attach multiple schedules to the same function. You can either use the `rate` or `cron` syntax. Take a look at the [AWS schedule syntax documentation](http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html) for more details. +This event allows you to set up scheduled invocations of your function. + +The plugin automatically configures a trigger and rule to connect your function +to the trigger feed from the [alarm package](https://github.com/openwhisk/openwhisk/blob/master/docs/catalog.md#using-the-alarm-package). + +## Configuration + +The `schedule` event configuration is controlled by a string, based on the UNIX +crontab syntax, in the format `cron(X X X X X)`. This can either be passed in +as a native string or through the `rate` parameter. + +### Simple + +The following config will attach a schedule event and causes the function `crawl` to be called every minute. ```yaml functions: crawl: handler: crawl events: - - schedule: rate(2 hours) - - schedule: cron(0 12 * * ? *) + - schedule: cron(* * * * * *) // run every minute ``` -## Enabling / Disabling +This automatically generates a new trigger (``${service}_crawl_schedule_trigger`) +and rule (`${service}_crawl_schedule_rule`) during deployment. -**Note:** `schedule` events are enabled by default. +### Customise Parameters -This will create and attach a schedule event for the `aggregate` function which is disabled. If enabled it will call -the `aggregate` function every 10 minutes. +Other schedule event parameters can be manually configured, e.g trigger or rule names. ```yaml functions: @@ -36,27 +48,10 @@ functions: handler: statistics.handler events: - schedule: - rate: rate(10 minutes) - enabled: false - input: - key1: value1 - key2: value2 - stageParams: - stage: dev - - schedule: - rate: cron(0 12 * * ? *) - enabled: false - inputPath: '$.stageVariables' -``` - -## Specify Name and Description - -Name and Description can be specified for a schedule event. These are not required properties. - -```yaml -events: - - schedule: - name: your-scheduled-rate-event-name - description: 'your scheduled rate event description' - rate: rate(2 hours) + rate: cron(0 * * * *) // call once an hour + trigger: triggerName + rule: ruleName + max: 10000 // max invocations, default: 1000, max: 10000 + params: // event params for invocation + hello: world ``` diff --git a/docs/providers/openwhisk/guide/credentials.md b/docs/providers/openwhisk/guide/credentials.md index 8b660ae2c..d58dda480 100644 --- a/docs/providers/openwhisk/guide/credentials.md +++ b/docs/providers/openwhisk/guide/credentials.md @@ -25,7 +25,6 @@ IBM's Bluemix cloud platform provides a hosted serverless solution based upon Ap Here's how to get started… - Sign up for a free account @ [https://bluemix.net](https://console.ng.bluemix.net/registration/) - ​ IBM Bluemix comes with a [free trial](https://www.ibm.com/cloud-computing/bluemix/pricing?cm_mc_uid=22424350960514851832143&cm_mc_sid_50200000=1485183214) that doesn't need credit card details for the first 30 days. Following the trial, developers have to enrol using a credit card but get a free tier for the platform and services. @@ -106,18 +105,6 @@ serverless deploy For a more permanent solution you can also set up credentials through a configuration file. Here are different methods you can use to do so. -##### Setup with `serverless config credentials` command - -Serverless provides a convenient way to configure OpenWhisk credentials with the help of the `serverless config credentials` command. - -Here's an example how you can configure the `default` AWS profile: - -```bash -serverless config credentials --provider openwhisk --auth USER_AUTH_KEY --apihost PLATFORM_API_HOST -``` - -Take a look at the [`config` CLI reference](../cli-reference/config-credentials.md) for more information about credential configuration. - ##### Setup with the `wsk` cli If you have followed the instructions above to install the `wsk` command-line utility, run the following command to create the configuration file. @@ -135,4 +122,4 @@ The following configuration values should be stored in a new file (`.wskprops`) ``` APIHOST=PLATFORM_API_HOST AUTH=USER_AUTH_KEY -``` \ No newline at end of file +``` From 8b6b3033f93b1cd35e7a38e1b141ddcc767ae948 Mon Sep 17 00:00:00 2001 From: "Ryan S. Brown" Date: Wed, 25 Jan 2017 20:16:12 -0500 Subject: [PATCH 06/30] Reduce memory usage of deploy/upload step Switch to using a stream to read artifacts at upload, because it was being read into a `const` that the AWS SDK had to then copy to a bytearray that was wrapped in a TLSStream object, duplicating the artifact several times. --- lib/plugins/aws/deploy/lib/uploadArtifacts.js | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/plugins/aws/deploy/lib/uploadArtifacts.js b/lib/plugins/aws/deploy/lib/uploadArtifacts.js index 0c833d57f..0d70cda86 100644 --- a/lib/plugins/aws/deploy/lib/uploadArtifacts.js +++ b/lib/plugins/aws/deploy/lib/uploadArtifacts.js @@ -32,14 +32,13 @@ module.exports = { throw new this.serverless.classes.Error('artifactFilePath was not supplied'); } - const body = fs.readFileSync(artifactFilePath); const fileName = artifactFilePath.split(path.sep).pop(); const params = { Bucket: this.bucketName, Key: `${this.serverless.service.package.artifactDirectoryName}/${fileName}`, - Body: body, + Body: fs.createReadStream(artifactFilePath), ContentType: 'application/zip', }; From 12c2ad906cadd7bc3d98ae479a65a08e4683f58a Mon Sep 17 00:00:00 2001 From: "Ryan S. Brown" Date: Thu, 26 Jan 2017 16:46:13 -0500 Subject: [PATCH 07/30] Update test to match the S3 object body readStream points to the artifact zipfile path --- lib/plugins/aws/deploy/lib/uploadArtifacts.test.js | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/lib/plugins/aws/deploy/lib/uploadArtifacts.test.js b/lib/plugins/aws/deploy/lib/uploadArtifacts.test.js index 33fa54de7..c21988996 100644 --- a/lib/plugins/aws/deploy/lib/uploadArtifacts.test.js +++ b/lib/plugins/aws/deploy/lib/uploadArtifacts.test.js @@ -71,10 +71,6 @@ describe('uploadArtifacts', () => { const artifactFilePath = path.join(tmpDirPath, 'artifact.zip'); serverless.utils.writeFileSync(artifactFilePath, 'artifact.zip file content'); - const artifactFileBuffer = new Buffer( - serverless.utils.readFileSync(artifactFilePath), 'binary' - ); - const putObjectStub = sinon .stub(awsDeploy.provider, 'request').returns(BbPromise.resolve()); @@ -86,7 +82,7 @@ describe('uploadArtifacts', () => { { Bucket: awsDeploy.bucketName, Key: `${awsDeploy.serverless.service.package.artifactDirectoryName}/artifact.zip`, - Body: artifactFileBuffer, + Body: sinon.match.object.and(sinon.match.has('path', artifactFilePath)), ContentType: 'application/zip', }, awsDeploy.options.stage, From 0d2d4848eb1c54b8f19f62e4cbd9e0374430cbeb Mon Sep 17 00:00:00 2001 From: Danny King Date: Thu, 26 Jan 2017 16:44:23 -0800 Subject: [PATCH 08/30] update docs page to include whisk guide --- docs/README.md | 88 +++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 84 insertions(+), 4 deletions(-) diff --git a/docs/README.md b/docs/README.md index 57784b2ab..fbc3cae64 100644 --- a/docs/README.md +++ b/docs/README.md @@ -16,7 +16,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
- Serverless Framework AWS Lambda Guide + Serverless Framework AWS Lambda Guide
@@ -43,7 +43,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
- Serverless Framework AWS Lambda CLI Reference + Serverless Framework AWS Lambda CLI Reference
@@ -69,7 +69,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
- Serverless Framework AWS Lambda Events + Serverless Framework AWS Lambda Events
@@ -88,7 +88,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
- Serverless Framework AWS Lambda Examples + Serverless Framework AWS Lambda Examples
@@ -100,3 +100,83 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
+ +
+
+
+ + Serverless Framework IBM OpenWhisk Guide + +
+
+ +
+
+ +
+
+ + Serverless Framework IBM OpenWhisk CLI Reference + +
+ +
+ +
+
+ + Serverless Framework IBM OpenWhisk Events + +
+ +
+ +
+
+ + Serverless Framework IBM OpenWhisk Examples + +
+
+
+ +
+
+
+
From df544067270eae6e61ecb430f1925755c4966ed4 Mon Sep 17 00:00:00 2001 From: Danny King Date: Thu, 26 Jan 2017 16:49:30 -0800 Subject: [PATCH 09/30] update copy --- docs/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/README.md b/docs/README.md index fbc3cae64..b856cbe1d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -10,7 +10,7 @@ layout: Doc # Documentation -The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, event-driven functions to any cloud. We currently support Amazon Web Service's Lambda, and are expanding to support other cloud providers. +The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, event-driven functions to any cloud. We currently support AWS Lambda, IBM OpenWhisk, and are expanding to support other cloud providers.
From 7c5c1a0924cfd3e36ad5da0ff9d3701e258bbadf Mon Sep 17 00:00:00 2001 From: James Thomas Date: Fri, 27 Jan 2017 10:17:28 +0000 Subject: [PATCH 10/30] Removing AWS references. There were some remaining AWS references caught during code reivew. --- docs/providers/openwhisk/README.md | 2 +- .../openwhisk/cli-reference/README.md | 6 ++-- .../cli-reference/config-credentials.md | 4 +-- .../openwhisk/cli-reference/create.md | 2 +- .../cli-reference/deploy-function.md | 2 +- .../openwhisk/cli-reference/deploy.md | 2 +- .../providers/openwhisk/cli-reference/info.md | 4 +-- .../openwhisk/cli-reference/install.md | 2 +- .../openwhisk/cli-reference/invoke-local.md | 2 +- .../openwhisk/cli-reference/invoke.md | 2 +- .../providers/openwhisk/cli-reference/logs.md | 2 +- .../openwhisk/cli-reference/remove.md | 2 +- .../openwhisk/cli-reference/slstats.md | 4 +-- docs/providers/openwhisk/events/README.md | 6 ++-- docs/providers/openwhisk/events/apigateway.md | 4 +-- docs/providers/openwhisk/events/schedule.md | 6 ++-- docs/providers/openwhisk/events/triggers.md | 2 +- docs/providers/openwhisk/examples/README.md | 2 +- .../examples/hello-world/node/README.md | 2 +- .../examples/hello-world/node/serverless.yml | 2 +- docs/providers/openwhisk/guide/README.md | 4 +-- docs/providers/openwhisk/guide/credentials.md | 2 +- docs/providers/openwhisk/guide/deploying.md | 2 +- docs/providers/openwhisk/guide/events.md | 2 +- docs/providers/openwhisk/guide/functions.md | 2 +- .../providers/openwhisk/guide/installation.md | 2 +- docs/providers/openwhisk/guide/intro.md | 6 ++-- docs/providers/openwhisk/guide/packaging.md | 2 +- docs/providers/openwhisk/guide/plugins.md | 2 +- .../openwhisk/guide/serverless.yml.md | 2 +- docs/providers/openwhisk/guide/services.md | 6 ++-- docs/providers/openwhisk/guide/testing.md | 2 +- docs/providers/openwhisk/guide/variables.md | 30 +++++++++---------- docs/providers/openwhisk/guide/workflow.md | 4 +-- 34 files changed, 62 insertions(+), 66 deletions(-) diff --git a/docs/providers/openwhisk/README.md b/docs/providers/openwhisk/README.md index df38e3a97..daf7afc24 100644 --- a/docs/providers/openwhisk/README.md +++ b/docs/providers/openwhisk/README.md @@ -5,7 +5,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/) # Serverless Apache OpenWhisk Provider Documentation diff --git a/docs/providers/openwhisk/cli-reference/README.md b/docs/providers/openwhisk/cli-reference/README.md index ae4e7cdd5..9ed4202e6 100644 --- a/docs/providers/openwhisk/cli-reference/README.md +++ b/docs/providers/openwhisk/cli-reference/README.md @@ -1,11 +1,11 @@ -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/) # Serverless Apache OpenWhisk CLI Reference @@ -14,4 +14,4 @@ Welcome to the Serverless Apache OpenWhisk CLI Reference! Please select a secti **Note:** Before continuing [Apache OpenWhisk system credentials](../guide/credentials.md) are required for using the CLI. -If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](https://gitter.im/serverless/serverless) +If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](http://forum.serverless.com/). diff --git a/docs/providers/openwhisk/cli-reference/config-credentials.md b/docs/providers/openwhisk/cli-reference/config-credentials.md index 5ad12ebdf..401a6b14f 100644 --- a/docs/providers/openwhisk/cli-reference/config-credentials.md +++ b/docs/providers/openwhisk/cli-reference/config-credentials.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/config-credentials) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/config-credentials) # Config Credentials @@ -31,7 +31,7 @@ serverless config credentials --provider provider --apihost apihost --auth auth ### Configure the default profile ```bash -serverless config credentials --provider aws --apihost openwhisk.ng.bluemix.net --auth username:password +serverless config credentials --provider openwhisk --apihost openwhisk.ng.bluemix.net --auth username:password ``` Credentials are stored in `~/.wskprops`, which you can edit directly if needed. diff --git a/docs/providers/openwhisk/cli-reference/create.md b/docs/providers/openwhisk/cli-reference/create.md index 58d20ed16..7803c0bad 100644 --- a/docs/providers/openwhisk/cli-reference/create.md +++ b/docs/providers/openwhisk/cli-reference/create.md @@ -62,7 +62,7 @@ The provider which is used for deployment later on is Apache OpenWhisk. serverless create --template openwhisk-nodejs --path my-new-service ``` -This example will generate scaffolding for a service with `AWS` as a provider and `nodejs` as runtime. The scaffolding +This example will generate scaffolding for a service with `openwhisk` 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 Serverless will use the already present directory. diff --git a/docs/providers/openwhisk/cli-reference/deploy-function.md b/docs/providers/openwhisk/cli-reference/deploy-function.md index 0ef28ccb6..ae4c616ac 100644 --- a/docs/providers/openwhisk/cli-reference/deploy-function.md +++ b/docs/providers/openwhisk/cli-reference/deploy-function.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy-function) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/deploy-function) # Deploy Function diff --git a/docs/providers/openwhisk/cli-reference/deploy.md b/docs/providers/openwhisk/cli-reference/deploy.md index 052fd09e9..c1d63d5ae 100644 --- a/docs/providers/openwhisk/cli-reference/deploy.md +++ b/docs/providers/openwhisk/cli-reference/deploy.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/deploy) # Deploy diff --git a/docs/providers/openwhisk/cli-reference/info.md b/docs/providers/openwhisk/cli-reference/info.md index f69a42e1b..0fb8e17f0 100644 --- a/docs/providers/openwhisk/cli-reference/info.md +++ b/docs/providers/openwhisk/cli-reference/info.md @@ -2,12 +2,12 @@ title: Serverless Framework Commands - Apache OpenWhisk - Info menuText: Info menuOrder: 11 -description: Display information about your deployed service and the Apache OpenWhisk Functions, Events and AWS Resources it contains. +description: Display information about your deployed service and the Apache OpenWhisk Functions, Events and Resources it contains. layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/info) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/info) # Info diff --git a/docs/providers/openwhisk/cli-reference/install.md b/docs/providers/openwhisk/cli-reference/install.md index 9f985325f..a21f4c32b 100644 --- a/docs/providers/openwhisk/cli-reference/install.md +++ b/docs/providers/openwhisk/cli-reference/install.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/install) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/install) # Install diff --git a/docs/providers/openwhisk/cli-reference/invoke-local.md b/docs/providers/openwhisk/cli-reference/invoke-local.md index fdd50024b..c6f078f06 100644 --- a/docs/providers/openwhisk/cli-reference/invoke-local.md +++ b/docs/providers/openwhisk/cli-reference/invoke-local.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/invoke-local) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/invoke-local) # Invoke Local diff --git a/docs/providers/openwhisk/cli-reference/invoke.md b/docs/providers/openwhisk/cli-reference/invoke.md index 9e362830a..5bdebe8a4 100644 --- a/docs/providers/openwhisk/cli-reference/invoke.md +++ b/docs/providers/openwhisk/cli-reference/invoke.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/invoke) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/invoke) # Invoke diff --git a/docs/providers/openwhisk/cli-reference/logs.md b/docs/providers/openwhisk/cli-reference/logs.md index b1e662a68..73ef2dba6 100644 --- a/docs/providers/openwhisk/cli-reference/logs.md +++ b/docs/providers/openwhisk/cli-reference/logs.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/logs) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/logs) # Logs diff --git a/docs/providers/openwhisk/cli-reference/remove.md b/docs/providers/openwhisk/cli-reference/remove.md index 8e9dee1c0..c6894fc3d 100644 --- a/docs/providers/openwhisk/cli-reference/remove.md +++ b/docs/providers/openwhisk/cli-reference/remove.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/remove) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/remove) # Remove diff --git a/docs/providers/openwhisk/cli-reference/slstats.md b/docs/providers/openwhisk/cli-reference/slstats.md index 23a5ee1aa..adc6bb7ce 100644 --- a/docs/providers/openwhisk/cli-reference/slstats.md +++ b/docs/providers/openwhisk/cli-reference/slstats.md @@ -1,5 +1,5 @@ -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/slstats) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/cli-reference/slstats) # Serverless Statistics diff --git a/docs/providers/openwhisk/events/README.md b/docs/providers/openwhisk/events/README.md index 91ba74bcb..f84c2db1d 100644 --- a/docs/providers/openwhisk/events/README.md +++ b/docs/providers/openwhisk/events/README.md @@ -1,11 +1,11 @@ -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/events/) # Serverless Apache OpenWhisk Events @@ -14,6 +14,6 @@ Welcome to the Serverless Apache OpenWhisk Events Glossary! 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](https://gitter.im/serverless/serverless) +If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](http://forum.serverless.com/) **Note:** Before continuing [Apache OpenWhisk system credentials](../guide/credentials.md) are required for using the CLI. diff --git a/docs/providers/openwhisk/events/apigateway.md b/docs/providers/openwhisk/events/apigateway.md index 692c34660..46c254073 100644 --- a/docs/providers/openwhisk/events/apigateway.md +++ b/docs/providers/openwhisk/events/apigateway.md @@ -2,12 +2,12 @@ title: Serverless Framework - Apache OpenWhisk Events - API Gateway menuText: API Gateway menuOrder: 1 -description: Setting up AWS API Gateway Events with Apache OpenWhisk via the Serverless Framework +description: Setting up API Gateway Events with Apache OpenWhisk via the Serverless Framework layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/apigateway) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/events/apigateway) # API Gateway diff --git a/docs/providers/openwhisk/events/schedule.md b/docs/providers/openwhisk/events/schedule.md index 4269c8f1b..733bfe888 100644 --- a/docs/providers/openwhisk/events/schedule.md +++ b/docs/providers/openwhisk/events/schedule.md @@ -1,13 +1,13 @@ -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/schedule) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/events/schedule) # Schedule diff --git a/docs/providers/openwhisk/events/triggers.md b/docs/providers/openwhisk/events/triggers.md index f40a3e862..e894218b9 100644 --- a/docs/providers/openwhisk/events/triggers.md +++ b/docs/providers/openwhisk/events/triggers.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/events/streams) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/events/streams) # Triggers diff --git a/docs/providers/openwhisk/examples/README.md b/docs/providers/openwhisk/examples/README.md index dfeacb048..9878100d6 100644 --- a/docs/providers/openwhisk/examples/README.md +++ b/docs/providers/openwhisk/examples/README.md @@ -16,4 +16,4 @@ Have an example? Submit a PR or [open an issue](https://github.com/serverless/ex |:--------------------------- |:-----| | [OpenWhisk Node Simple](https://github.com/serverless/examples/tree/master/openwhisk-node-simple)
Boilerplate project repository for OpenWhisk provider with Serverless Framework. | nodeJS | -If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](https://gitter.im/serverless/serverless) +If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](http://forum.serverless.com/) diff --git a/docs/providers/openwhisk/examples/hello-world/node/README.md b/docs/providers/openwhisk/examples/hello-world/node/README.md index 6db34ca01..f9a6d3999 100644 --- a/docs/providers/openwhisk/examples/hello-world/node/README.md +++ b/docs/providers/openwhisk/examples/hello-world/node/README.md @@ -14,7 +14,7 @@ layout: Doc Make sure `serverless` is installed. [See installation guide](../../../guide/installation.md). ## 1. Create a service -`serverless create --template aws-nodejs --path myService` or `sls create --template aws-nodejs --path myService`, where 'myService' is a new folder to be created with template service files. Change directories into this new folder. +`serverless create --template openwhisk-nodejs --path myService` or `sls create --template openwhisk-nodejs --path myService`, where 'myService' is a new folder to be created with template service files. Change directories into this new folder. ## 2. Install Provider Plugin `npm install -g serverless-openwhisk` followed by `npm install` in the service directory. diff --git a/docs/providers/openwhisk/examples/hello-world/node/serverless.yml b/docs/providers/openwhisk/examples/hello-world/node/serverless.yml index 8500b8c8f..3b24c663b 100644 --- a/docs/providers/openwhisk/examples/hello-world/node/serverless.yml +++ b/docs/providers/openwhisk/examples/hello-world/node/serverless.yml @@ -1,4 +1,4 @@ -# Hello World for AWS Lambda +# Hello World for Apache OpenWhisk service: hello-world # Service Name provider: diff --git a/docs/providers/openwhisk/guide/README.md b/docs/providers/openwhisk/guide/README.md index 334316f04..2a567541a 100644 --- a/docs/providers/openwhisk/guide/README.md +++ b/docs/providers/openwhisk/guide/README.md @@ -5,7 +5,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/) # Serverless Apache OpenWhisk Guide @@ -14,6 +14,6 @@ Welcome to the Serverless Apache OpenWhisk Guide! Get started with the **[Introduction to the framework](./intro.md)** -If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](https://gitter.im/serverless/serverless) +If you have questions, join the [chat in gitter](https://gitter.im/serverless/serverless) or [post over on the forums](http://forum.serverless.com/) **Note:** Before continuing [Apache OpenWhisk user credentials](./credentials.md) are required for using the CLI. diff --git a/docs/providers/openwhisk/guide/credentials.md b/docs/providers/openwhisk/guide/credentials.md index d58dda480..61b704bcd 100644 --- a/docs/providers/openwhisk/guide/credentials.md +++ b/docs/providers/openwhisk/guide/credentials.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/credentials) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/credentials) # Credentials diff --git a/docs/providers/openwhisk/guide/deploying.md b/docs/providers/openwhisk/guide/deploying.md index aae193496..63a2d1c9a 100644 --- a/docs/providers/openwhisk/guide/deploying.md +++ b/docs/providers/openwhisk/guide/deploying.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/deploying) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/deploying) # Deploying diff --git a/docs/providers/openwhisk/guide/events.md b/docs/providers/openwhisk/guide/events.md index 712dfb83e..3727d6760 100644 --- a/docs/providers/openwhisk/guide/events.md +++ b/docs/providers/openwhisk/guide/events.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/events) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/events) # Events diff --git a/docs/providers/openwhisk/guide/functions.md b/docs/providers/openwhisk/guide/functions.md index 8555c0c76..38f5fb23b 100644 --- a/docs/providers/openwhisk/guide/functions.md +++ b/docs/providers/openwhisk/guide/functions.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/functions) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/functions) # Functions diff --git a/docs/providers/openwhisk/guide/installation.md b/docs/providers/openwhisk/guide/installation.md index 23ce12e61..07d152dc3 100644 --- a/docs/providers/openwhisk/guide/installation.md +++ b/docs/providers/openwhisk/guide/installation.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/installation) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/installation) # Installation diff --git a/docs/providers/openwhisk/guide/intro.md b/docs/providers/openwhisk/guide/intro.md index abb70f59a..469b2962c 100644 --- a/docs/providers/openwhisk/guide/intro.md +++ b/docs/providers/openwhisk/guide/intro.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/intro) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/intro) # Introduction @@ -72,6 +72,6 @@ You can overwrite or extend the functionality of the Framework using **Plugins** # serverless.yml plugins: - - serverless-offline - - serverless-secrets + - serverless-plugin-identifier + - serverless-another-plugin ``` diff --git a/docs/providers/openwhisk/guide/packaging.md b/docs/providers/openwhisk/guide/packaging.md index a22e8a92b..9af0acd58 100644 --- a/docs/providers/openwhisk/guide/packaging.md +++ b/docs/providers/openwhisk/guide/packaging.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/packaging) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/packaging) # Packaging diff --git a/docs/providers/openwhisk/guide/plugins.md b/docs/providers/openwhisk/guide/plugins.md index be21e76ea..04ea5ee48 100644 --- a/docs/providers/openwhisk/guide/plugins.md +++ b/docs/providers/openwhisk/guide/plugins.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/plugins) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/plugins) # Plugins diff --git a/docs/providers/openwhisk/guide/serverless.yml.md b/docs/providers/openwhisk/guide/serverless.yml.md index d286616b8..97f27511f 100644 --- a/docs/providers/openwhisk/guide/serverless.yml.md +++ b/docs/providers/openwhisk/guide/serverless.yml.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/serverless.yml) # Serverless.yml Reference diff --git a/docs/providers/openwhisk/guide/services.md b/docs/providers/openwhisk/guide/services.md index e3c324c4c..a8f27791c 100644 --- a/docs/providers/openwhisk/guide/services.md +++ b/docs/providers/openwhisk/guide/services.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/services) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/services) # Services @@ -93,8 +93,6 @@ functions: - http: delete /users/delete ``` -Every `serverless.yml` translates to a single AWS CloudFormation template and a CloudFormation stack is created from that resulting CloudFormation template. - ### handler.js The `handler.js` file contains your function code. The function definition in `serverless.yml` will point to this `handler.js` file and the function exported here. @@ -115,7 +113,7 @@ To deploy a service, use the `deploy` command: serverless deploy ``` -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/openwhisk/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 diff --git a/docs/providers/openwhisk/guide/testing.md b/docs/providers/openwhisk/guide/testing.md index 05561fb45..a2d996817 100644 --- a/docs/providers/openwhisk/guide/testing.md +++ b/docs/providers/openwhisk/guide/testing.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/testing) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/testing) # Testing diff --git a/docs/providers/openwhisk/guide/variables.md b/docs/providers/openwhisk/guide/variables.md index 0df7a975f..f86dc6008 100644 --- a/docs/providers/openwhisk/guide/variables.md +++ b/docs/providers/openwhisk/guide/variables.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/variables) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/variables) # Variables @@ -28,9 +28,9 @@ To self-reference properties in `serverless.yml`, use the `${self:someProperty}` ```yml service: new-service -provider: aws +provider: openwhisk custom: - globalSchedule: rate(10 minutes) + globalSchedule: cron(0 * * * *) functions: hello: @@ -50,7 +50,7 @@ To reference environment variables, use the `${env:SOME_VAR}` syntax in your `se ```yml service: new-service -provider: aws +provider: openwhisk functions: hello: name: ${env:FUNC_PREFIX}-hello @@ -67,7 +67,7 @@ To reference CLI options that you passed, use the `${opt:some_option}` syntax in ```yml service: new-service -provider: aws +provider: openwhisk functions: hello: name: ${opt:stage}-hello @@ -84,7 +84,7 @@ To reference variables in other YAML or JSON files, use the `${file(./myFile.yml ```yml # myCustomFile.yml -globalSchedule: rate(10 minutes) +globalSchedule: cron(0 * * * *) ``` ```yml @@ -112,7 +112,7 @@ To add dynamic data into your variables, reference javascript files by putting ` // myCustomFile.js module.exports.hello = () => { // Code that generates dynamic data - return 'rate (10 minutes)'; + return 'cron(0 * * * *)'; } ``` @@ -132,12 +132,12 @@ You can also return an object and reference a specific property. Just make sure ```yml # serverless.yml service: new-service -provider: aws +provider: openwhisk functions: scheduledFunction: handler: handler.scheduledFunction events: - - schedule: ${file(./myCustomFile.js):schedule.ten} + - schedule: ${file(./myCustomFile.js):schedule.hour} ``` ```js @@ -145,9 +145,7 @@ functions: module.exports.schedule = () => { // Code that generates dynamic data return { - ten: 'rate(10 minutes)', - twenty: 'rate(20 minutes)', - thirty: 'rate(30 minutes)' + hour: 'cron(0 * * * *)' }; } ``` @@ -158,17 +156,17 @@ Adding many custom resources to your `serverless.yml` file could bloat the whole ```yml resources: - Resources: ${file(cloudformation-resources.json)} + Resources: ${file(openwhisk-resources.json)} ``` -The corresponding resources which are defined inside the `cloudformation-resources.json` file will be resolved and loaded into the `Resources` section. +The corresponding resources which are defined inside the `openwhisk-resources.json` file will be resolved and loaded into the `Resources` section. ## 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 service: new-service -provider: aws +provider: openwhisk custom: myFlexibleArn: ${env:${opt:stage}_arn} @@ -187,7 +185,7 @@ For example, if you want to reference the stage you're deploying to, but you don ```yml service: new-service provider: - name: aws + name: openwhisk stage: dev custom: myStage: ${opt:stage, self:provider.stage} diff --git a/docs/providers/openwhisk/guide/workflow.md b/docs/providers/openwhisk/guide/workflow.md index 126595627..ff4a5750f 100644 --- a/docs/providers/openwhisk/guide/workflow.md +++ b/docs/providers/openwhisk/guide/workflow.md @@ -7,7 +7,7 @@ layout: Doc --> -### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/guide/workflow) +### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/openwhisk/guide/workflow) # Workflow @@ -19,7 +19,7 @@ Intro. Quick recommendations and tips for various processes. 1. Write your functions 2. Use `serverless deploy` only when you've made changes to `serverless.yml` and in CI/CD systems. 3. Use `serverless deploy function -f myFunction` to rapidly deploy changes when you are working on a specific Apache OpenWhisk Function. -4. Use `serverless invoke -f myFunction -l` to test your Apache OpenWhisk Functions on AWS. +4. Use `serverless invoke -f myFunction -l` to test your Apache OpenWhisk Functions. 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. From 3c2ad1dc64453b0d199cc38c8994eb7c48374362 Mon Sep 17 00:00:00 2001 From: James Thomas Date: Fri, 27 Jan 2017 10:22:37 +0000 Subject: [PATCH 11/30] Changing Github repo links to OpenWhisk examples --- docs/providers/openwhisk/cli-reference/install.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/providers/openwhisk/cli-reference/install.md b/docs/providers/openwhisk/cli-reference/install.md index a21f4c32b..2cd8b8a80 100644 --- a/docs/providers/openwhisk/cli-reference/install.md +++ b/docs/providers/openwhisk/cli-reference/install.md @@ -30,23 +30,24 @@ serverless install --url https://github.com/some/service ### Installing a service from a GitHub URL ```bash -serverless install --url https://github.com/pmuens/serverless-crud +serverless install --url https://github.com/jthomas/serverless-openwhisk-boilerplate ``` -This example will download the .zip file of the `serverless-crud` service from GitHub, create a new directory with the name `serverless-crud` in the current working directory and unzips the files in this directory. +This example will download the .zip file of the `serverless-openwhisk-boilerplate` service from GitHub, create a new directory with the name `serverless-openwhisk-boilerplate` in the current working directory and unzips the files in this directory. ### Installing a service from a GitHub URL with a new service name ```bash -serverless install --url https://github.com/pmuens/serverless-crud --name my-crud +serverless install --url https://github.com/jthomas/serverless-openwhisk-boilerplate --name my-app ``` -This example will download the .zip file of the `serverless-crud` service from GitHub, create a new directory with the name `my-crud` in the current working directory and unzips the files in this directory and renames the service to `my-crud` if `serverless.yml` exists in the service root. +This example will download the .zip file of the `serverless-openwhisk-boilerplate` service from GitHub, create a new directory with the name `my-app` in the current working directory and unzips the files in this directory and renames the service to `my-app` if `serverless.yml` exists in the service root. ### Installing a service from a directory in a GitHub URL ```bash -serverless install --url https://github.com/serverless/examples/tree/master/rest-api-with-dynamodb +serverless install --url +https://github.com/serverless/examples/tree/master/openwhisk-node-simple ``` -This example will download the `rest-api-with-dynamodb` service from GitHub. +This example will download the `openwhisk-node-simple` service from GitHub. From fb14b0ca82a21808f746c1a98cb446bf4c5dd896 Mon Sep 17 00:00:00 2001 From: Chris Anderson Date: Fri, 27 Jan 2017 18:46:44 -0800 Subject: [PATCH 12/30] link to FaunaDB CRUD example from README This links to a fork of the CRUD example that uses FaunaDB instead of DynamoDB. --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index defd67243..24405f1e4 100755 --- a/README.md +++ b/README.md @@ -106,6 +106,7 @@ The following are services you can instantly install and use by running `serverl * [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 From fca148268b9fb0a438e03369b60c354dac008094 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eslam=20=CE=BB=20Hefnawy?= Date: Sat, 28 Jan 2017 19:37:31 +0700 Subject: [PATCH 13/30] added homepage to package.json --- package.json | 1 + 1 file changed, 1 insertion(+) diff --git a/package.json b/package.json index 35fb340cc..20db00061 100644 --- a/package.json +++ b/package.json @@ -5,6 +5,7 @@ "node": ">=4.0" }, "preferGlobal": true, + "homepage": "https://github.com/serverless/serverless#readme", "description": "Serverless Framework - Build web, mobile and IoT applications with serverless architectures using AWS Lambda, Azure Functions, Google CloudFunctions & more", "author": "serverless.com", "license": "MIT", From 796cdf7a9ef15a688b69d8cbecd73349cfc7c482 Mon Sep 17 00:00:00 2001 From: Philipp Muens Date: Mon, 30 Jan 2017 10:43:47 +0100 Subject: [PATCH 14/30] Update PR template --- .github/PULL_REQUEST_TEMPLATE.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index e9693c9d5..3dfa2d2bc 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -6,7 +6,7 @@ ## What did you implement: -Closes #12345 +Closes #XXXXX - ## Todos: - [ ] Write tests - [ ] Write documentation - [ ] Fix linting errors - [ ] Make sure code coverage hasn't dropped -- [ ] Provide verification config/commands/resources -- [ ] Enable ["Allow edits from maintainers"](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) for this PR -- [ ] Change ready for review message below - +- [ ] 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 From 54fbaadede8b65ac1cbf5b376cbb783dca125ef4 Mon Sep 17 00:00:00 2001 From: Philipp Muens Date: Tue, 24 Jan 2017 13:38:40 +0100 Subject: [PATCH 15/30] Remove defaults service property --- lib/classes/Service.js | 50 +--------------------------- lib/classes/Service.test.js | 13 ++++---- lib/classes/Utils.js | 6 ---- lib/classes/Utils.test.js | 2 -- lib/classes/Variables.js | 6 ++-- lib/classes/Variables.test.js | 14 ++++---- lib/plugins/aws/lib/validate.js | 4 +-- lib/plugins/aws/lib/validate.test.js | 8 ++--- 8 files changed, 21 insertions(+), 82 deletions(-) diff --git a/lib/classes/Service.js b/lib/classes/Service.js index 9d721cde7..cb90677e0 100644 --- a/lib/classes/Service.js +++ b/lib/classes/Service.js @@ -13,8 +13,7 @@ class Service { // Default properties this.service = null; - this.provider = {}; - this.defaults = { + this.provider = { stage: 'dev', region: 'us-east-1', variableSyntax: '\\${([ :a-zA-Z0-9._,\\-\\/\\(\\)]+?)}', @@ -106,53 +105,6 @@ class Service { that.package.include = serverlessFile.package.include; } - if (serverlessFile.defaults && serverlessFile.defaults.stage) { - this.defaults.stage = serverlessFile.defaults.stage; - } - if (serverlessFile.defaults && serverlessFile.defaults.region) { - this.defaults.region = serverlessFile.defaults.region; - } - if (serverlessFile.defaults && serverlessFile.defaults.variableSyntax) { - this.defaults.variableSyntax = serverlessFile.defaults.variableSyntax; - } - - // load defaults property for backward compatibility - if (serverlessFile.defaults) { - const warningMessage = [ - 'Deprecation Notice: the "defaults" property in serverless.yml', - ' is deprecated. The "stage", "region" & "variableSyntax" properties', - ' has been moved to the "provider" property instead. Please update', - ' your serverless.yml file asap. For more info, you can check our docs.', - ].join(''); - this.serverless.cli.log(warningMessage); - - if (serverlessFile.defaults.stage) { - this.defaults.stage = serverlessFile.defaults.stage; - } - if (serverlessFile.defaults.region) { - this.defaults.region = serverlessFile.defaults.region; - } - if (serverlessFile.defaults.variableSyntax) { - this.defaults.variableSyntax = serverlessFile.defaults.variableSyntax; - } - } - - // if exists, move provider to defaults for backward compatibility - if (serverlessFile.provider.stage) { - this.defaults.stage = serverlessFile.provider.stage; - } - if (serverlessFile.provider.region) { - this.defaults.region = serverlessFile.provider.region; - } - if (serverlessFile.provider.variableSyntax) { - this.defaults.variableSyntax = serverlessFile.provider.variableSyntax; - } - - // make sure provider obj is in sync with default for backward compatibility - this.provider.stage = this.defaults.stage; - this.provider.region = this.defaults.region; - this.provider.variableSyntax = this.defaults.variableSyntax; - // setup function.name property const stageNameForFunction = options.stage || this.provider.stage; _.forEach(that.functions, (functionObj, functionName) => { diff --git a/lib/classes/Service.test.js b/lib/classes/Service.test.js index 3f1676559..67d044e7e 100644 --- a/lib/classes/Service.test.js +++ b/lib/classes/Service.test.js @@ -22,8 +22,7 @@ describe('Service', () => { const serviceInstance = new Service(serverless); expect(serviceInstance.service).to.be.equal(null); - expect(serviceInstance.provider).to.deep.equal({}); - expect(serviceInstance.defaults).to.deep.equal({ + expect(serviceInstance.provider).to.deep.equal({ stage: 'dev', region: 'us-east-1', variableSyntax: '\\${([ :a-zA-Z0-9._,\\-\\/\\(\\)]+?)}', @@ -121,8 +120,8 @@ describe('Service', () => { const SUtils = new Utils(); const serverlessYml = { service: 'new-service', - provider: 'aws', - defaults: { + provider: { + name: 'aws', stage: 'dev', region: 'us-east-1', variableSyntax: '\\${{([\\s\\S]+?)}}', @@ -156,7 +155,7 @@ describe('Service', () => { return serviceInstance.load().then(() => { expect(serviceInstance.service).to.be.equal('new-service'); expect(serviceInstance.provider.name).to.deep.equal('aws'); - expect(serviceInstance.defaults.variableSyntax).to.equal('\\${{([\\s\\S]+?)}}'); + expect(serviceInstance.provider.variableSyntax).to.equal('\\${{([\\s\\S]+?)}}'); expect(serviceInstance.plugins).to.deep.equal(['testPlugin']); expect(serviceInstance.resources.aws).to.deep.equal({ resourcesProp: 'value' }); expect(serviceInstance.resources.azure).to.deep.equal({}); @@ -204,8 +203,8 @@ describe('Service', () => { const SUtils = new Utils(); const serverlessYml = { service: 'new-service', - provider: 'aws', - defaults: { + provider: { + name: 'aws', stage: 'dev', region: 'us-east-1', variableSyntax: '\\${{([\\s\\S]+?)}}', diff --git a/lib/classes/Utils.js b/lib/classes/Utils.js index ec57f161c..0dead5014 100644 --- a/lib/classes/Utils.js +++ b/lib/classes/Utils.js @@ -282,12 +282,6 @@ class Utils { let hasCustomVariableSyntaxDefined = false; const defaultVariableSyntax = '\\${([ :a-zA-Z0-9._,\\-\\/\\(\\)]+?)}'; - // check if the variableSyntax in the defaults section is defined - if (serverless.service.defaults && - serverless.service.defaults.variableSyntax && - serverless.service.defaults.variableSyntax !== defaultVariableSyntax) { - hasCustomVariableSyntaxDefined = true; - } // check if the variableSyntax in the provider section is defined if (serverless.service.provider && diff --git a/lib/classes/Utils.test.js b/lib/classes/Utils.test.js index 03f438d1b..3c338b488 100644 --- a/lib/classes/Utils.test.js +++ b/lib/classes/Utils.test.js @@ -396,8 +396,6 @@ describe('Utils', () => { provider: { name: 'aws', runtime: 'nodejs4.3', - }, - defaults: { stage: 'dev', region: 'us-east-1', variableSyntax: '\\${foo}', diff --git a/lib/classes/Variables.js b/lib/classes/Variables.js index 1e95bf03e..5c5678582 100644 --- a/lib/classes/Variables.js +++ b/lib/classes/Variables.js @@ -19,7 +19,7 @@ class Variables { } loadVariableSyntax() { - this.variableSyntax = RegExp(this.service.defaults.variableSyntax, 'g'); + this.variableSyntax = RegExp(this.service.provider.variableSyntax, 'g'); } populateService(processedOptions) { @@ -28,10 +28,9 @@ class Variables { this.loadVariableSyntax(); - const variableSyntaxProperty = this.service.defaults.variableSyntax; + const variableSyntaxProperty = this.service.provider.variableSyntax; // temporally remove variable syntax from service otherwise it'll match - this.service.defaults.variableSyntax = true; this.service.provider.variableSyntax = true; /* @@ -48,7 +47,6 @@ class Variables { } }); - this.service.defaults.variableSyntax = variableSyntaxProperty; this.service.provider.variableSyntax = variableSyntaxProperty; return this.service; } diff --git a/lib/classes/Variables.test.js b/lib/classes/Variables.test.js index 6d9290082..213ae1014 100644 --- a/lib/classes/Variables.test.js +++ b/lib/classes/Variables.test.js @@ -28,7 +28,7 @@ describe('Variables', () => { it('should set variableSyntax', () => { const serverless = new Serverless(); - serverless.service.defaults.variableSyntax = '\\${{([\\s\\S]+?)}}'; + serverless.service.provider.variableSyntax = '\\${{([\\s\\S]+?)}}'; serverless.variables.loadVariableSyntax(); expect(serverless.variables.variableSyntax).to.be.a('RegExp'); @@ -55,7 +55,6 @@ describe('Variables', () => { const fooValue = '${clientId()}'; const barValue = 'test'; - serverless.service.defaults.variableSyntax = variableSyntax; serverless.service.provider.variableSyntax = variableSyntax; serverless.service.custom = { @@ -68,7 +67,7 @@ describe('Variables', () => { }; serverless.variables.populateService(); - expect(serverless.service.defaults.variableSyntax).to.equal(variableSyntax); + expect(serverless.service.provider.variableSyntax).to.equal(variableSyntax); expect(serverless.service.resources.foo).to.equal(fooValue); expect(serverless.service.resources.bar).to.equal(barValue); }); @@ -352,14 +351,13 @@ describe('Variables', () => { const serverless = new Serverless(); serverless.variables.service = { service: 'testService', - provider: 'testProvider', - defaults: serverless.service.defaults, + provider: serverless.service.provider, }; serverless.variables.loadVariableSyntax(); - const valueToPopulate = serverless.variables.getValueFromSelf('self:provider'); - expect(valueToPopulate).to.be.equal('testProvider'); + const valueToPopulate = serverless.variables.getValueFromSelf('self:service'); + expect(valueToPopulate).to.be.equal('testService'); }); }); @@ -554,7 +552,7 @@ describe('Variables', () => { }, anotherVar: '${self:custom.var}', }, - defaults: serverless.service.defaults, + provider: serverless.service.provider, }; serverless.variables.loadVariableSyntax(); diff --git a/lib/plugins/aws/lib/validate.js b/lib/plugins/aws/lib/validate.js index 038754327..b0333ff95 100644 --- a/lib/plugins/aws/lib/validate.js +++ b/lib/plugins/aws/lib/validate.js @@ -10,10 +10,10 @@ module.exports = { } this.options.stage = this.options.stage - || (this.serverless.service.defaults && this.serverless.service.defaults.stage) + || (this.serverless.service.provider && this.serverless.service.provider.stage) || 'dev'; this.options.region = this.options.region - || (this.serverless.service.defaults && this.serverless.service.defaults.region) + || (this.serverless.service.provider && this.serverless.service.provider.region) || 'us-east-1'; return BbPromise.resolve(); diff --git a/lib/plugins/aws/lib/validate.test.js b/lib/plugins/aws/lib/validate.test.js index 1489cbdc0..d0c6a8dbf 100644 --- a/lib/plugins/aws/lib/validate.test.js +++ b/lib/plugins/aws/lib/validate.test.js @@ -39,9 +39,9 @@ describe('#validate', () => { }); }); - it('should use the service.defaults stage if present', () => { + it('should use the service.provider stage if present', () => { awsPlugin.options.stage = false; - awsPlugin.serverless.service.defaults = { + awsPlugin.serverless.service.provider = { stage: 'some-stage', }; @@ -57,9 +57,9 @@ describe('#validate', () => { }); }); - it('should use the service.defaults region if present', () => { + it('should use the service.provider region if present', () => { awsPlugin.options.region = false; - awsPlugin.serverless.service.defaults = { + awsPlugin.serverless.service.provider = { region: 'some-region', }; From b32803a8ffd6fe64a97baaa23e9a05ef37e77e6d Mon Sep 17 00:00:00 2001 From: Philipp Muens Date: Mon, 30 Jan 2017 13:33:15 +0100 Subject: [PATCH 16/30] Fix wrong provider value assigning --- lib/classes/Service.js | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lib/classes/Service.js b/lib/classes/Service.js index cb90677e0..02d408e20 100644 --- a/lib/classes/Service.js +++ b/lib/classes/Service.js @@ -92,12 +92,15 @@ class Service { } that.service = serverlessFile.service; - that.provider = serverlessFile.provider; that.custom = serverlessFile.custom; that.plugins = serverlessFile.plugins; that.resources = serverlessFile.resources; that.functions = serverlessFile.functions || {}; + // merge so that the default settings are still in place and + // won't be overwritten + that.provider = _.merge(that.provider, serverlessFile.provider); + if (serverlessFile.package) { that.package.individually = serverlessFile.package.individually; that.package.artifact = serverlessFile.package.artifact; From 3a7bfa64d8840d13ac22fd53f871bc86b18edc0d Mon Sep 17 00:00:00 2001 From: "Eslam A. Hefnawy" Date: Mon, 30 Jan 2017 22:17:31 +0700 Subject: [PATCH 17/30] releasing v1.6 --- CHANGELOG.md | 39 +++++++++++++++++++++++++++++++++++++++ npm-shrinkwrap.json | 2 +- package.json | 2 +- 3 files changed, 41 insertions(+), 2 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 1d8ff1aa7..2fbcded82 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,42 @@ +# 1.6.0 (30.01.2017) + +**Important Note:** This release includes breaking changes. If your services stopped working after upgrading to v1.6.0, please read the following section. + +## Breaking Changes + +### CloudWatch logs are created explicitly +Up until this release, CloudWatch log groups were created implicitly by AWS/Lambda by default and were not included in your service stack. However, some users were able to easily reach the CloudWatch log group limits (currently at 500 log groups), and it wasn't an easy task to clear them all. Because of that we decided to explicitly create the log groups using CloudFormation so that you can easily remove them with `sls remove`. This was also optionally possible with the `cfLogs: true` config option. + +If your service doesn't have the `cfLogs: true` set, and one of the function has been invoked at least once (hence the log groups were created implicitly by AWS), then it's very likely that you'll receive a "log group already exists" error after upgrading to v1.6.0. That's because CF is now trying to create the already created log groups from scratch to include it in the stack resources. **To fix this breaking change,** simply delete the old log group, or rename your service if you **must** keep the old logs. + +### Removed function Arns from CloudFormation outputs +Up until this release, the output section of the generated CloudFormation template included an output resource for each function Arn. This caused deploying big services to fail because users were hitting the 60 outputs per stack limit. This effectively means that you can't have a service that has more than 60 functions. To avoid this AWS limit, we decided to remove those function output resources completely, to keep the stack clean. This also means removing the function Arns from the `sls info` command, and at the end of the deployment command. + +This is a breaking change for your project if you're depending on those function output resources in anyway, or if you're depending on function arn outputs from the deploy or info commands. Otherwise, your project shouldn't be affected by this change. Fixing this issue depends on your needs, but just remember that you can always create your own CF outputs in `serverless.yml`. + +### Moved `getStackName()` method +This is a breaking change for plugin authors only. If your plugin used the `provider.getStackName()` method, it has been moved to `naming.js`, and should be referenced with `provider.naming.getStackName()` instead. + +### Removed the `defaults` property from `serverless.yml` +We've finally dropped support for the `defaults` property which we introduced in v1. All child properties should now be moved to the `provider` object instead. + +### Function version resources are now optional +In version 1.5.0, we've introduced support for lambda versioning, which means on every deploy, a new version resource for each function is added to the stack. In this release, we're making it optional with the `--versionFunctions` flag in `serverless.yml` so that the stack wouldn't be too bloated by default. + +## Non-breaking changes +- Reduce memory consumption on deploy by at least 50% (#3145) +- Added openwhisk template to `sls create` command (#3122) +- Allow Role 'Fn::GetAtt' for Lambda `role` (#3083) +- Added Access-Control-Allow-Credentials for CORS settings (#2736) +- add Support for SNS Subscription to existing topics (#2796) +- Function version resources are now optional. (#3042) +- Invoke local now supports python runtime. (#2937) +- Fixed "deployment bucket doesn't exist" error (#3107) +- Allowed function events value to be variables (#2434) + +## Meta +- [Comparison since last release](https://github.com/serverless/serverless/compare/v1.5.1...v1.6.0) + # 1.5.1 (19.01.2017) ## Bug Fixes diff --git a/npm-shrinkwrap.json b/npm-shrinkwrap.json index f07034a84..5d0e7df24 100644 --- a/npm-shrinkwrap.json +++ b/npm-shrinkwrap.json @@ -1,6 +1,6 @@ { "name": "serverless", - "version": "1.5.1", + "version": "1.6.0", "dependencies": { "agent-base": { "version": "2.0.1", diff --git a/package.json b/package.json index 20db00061..3732da8a8 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "serverless", - "version": "1.5.1", + "version": "1.6.0", "engines": { "node": ">=4.0" }, From 83a8d897cb079b561072009269d2e4092af767f6 Mon Sep 17 00:00:00 2001 From: "Eslam A. Hefnawy" Date: Mon, 30 Jan 2017 22:24:41 +0700 Subject: [PATCH 18/30] edit changelog --- CHANGELOG.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2fbcded82..04a567b50 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,9 +20,6 @@ This is a breaking change for plugin authors only. If your plugin used the `prov ### Removed the `defaults` property from `serverless.yml` We've finally dropped support for the `defaults` property which we introduced in v1. All child properties should now be moved to the `provider` object instead. -### Function version resources are now optional -In version 1.5.0, we've introduced support for lambda versioning, which means on every deploy, a new version resource for each function is added to the stack. In this release, we're making it optional with the `--versionFunctions` flag in `serverless.yml` so that the stack wouldn't be too bloated by default. - ## Non-breaking changes - Reduce memory consumption on deploy by at least 50% (#3145) - Added openwhisk template to `sls create` command (#3122) From ffd6152de0d1b38368b3ec954c822e6778c4eb65 Mon Sep 17 00:00:00 2001 From: Andrey Tserkus Date: Tue, 31 Jan 2017 01:03:42 -0800 Subject: [PATCH 19/30] cover Error with tests; rename `SError` export to `ServerlessError` --- lib/Serverless.js | 4 +- lib/Serverless.test.js | 4 +- lib/classes/Error.js | 5 +- lib/classes/Error.test.js | 149 ++++++++++++++++++++++++++++++++++++++ lib/classes/Service.js | 16 ++-- 5 files changed, 165 insertions(+), 13 deletions(-) create mode 100644 lib/classes/Error.test.js diff --git a/lib/Serverless.js b/lib/Serverless.js index 376cd8719..fd25eab20 100644 --- a/lib/Serverless.js +++ b/lib/Serverless.js @@ -12,7 +12,7 @@ const PluginManager = require('./classes/PluginManager'); const Utils = require('./classes/Utils'); const Service = require('./classes/Service'); const Variables = require('./classes/Variables'); -const SError = require('./classes/Error').SError; +const ServerlessError = require('./classes/Error').ServerlessError; const Version = require('./../package.json').version; class Serverless { @@ -42,7 +42,7 @@ class Serverless { this.classes.Utils = Utils; this.classes.Service = Service; this.classes.Variables = Variables; - this.classes.Error = SError; + this.classes.Error = ServerlessError; this.serverlessDirPath = path.join(os.homedir(), '.serverless'); } diff --git a/lib/Serverless.test.js b/lib/Serverless.test.js index ad0e1d940..aed7cfd8c 100644 --- a/lib/Serverless.test.js +++ b/lib/Serverless.test.js @@ -13,7 +13,7 @@ const PluginManager = require('../lib/classes/PluginManager'); const Utils = require('../lib/classes/Utils'); const Service = require('../lib/classes/Service'); const CLI = require('../lib/classes/CLI'); -const Error = require('../lib/classes/Error').SError; +const ServerlessError = require('../lib/classes/Error').ServerlessError; const testUtils = require('../tests/utils'); describe('Serverless', () => { @@ -105,7 +105,7 @@ describe('Serverless', () => { }); it('should store the Error class inside the classes object', () => { - expect(serverless.classes.Error).to.deep.equal(Error); + expect(serverless.classes.Error).to.deep.equal(ServerlessError); }); }); diff --git a/lib/classes/Error.js b/lib/classes/Error.js index 695b25aca..c34fa9535 100644 --- a/lib/classes/Error.js +++ b/lib/classes/Error.js @@ -2,7 +2,7 @@ const chalk = require('chalk'); const version = require('./../../package.json').version; -module.exports.SError = class ServerlessError extends Error { +module.exports.ServerlessError = class ServerlessError extends Error { constructor(message, statusCode) { super(message); this.name = this.constructor.name; @@ -12,6 +12,9 @@ module.exports.SError = class ServerlessError extends Error { } }; +// Deprecated - use ServerlessError instead +module.exports.SError = module.exports.ServerlessError; + module.exports.logError = (e) => { try { const words = e.message.split(' '); diff --git a/lib/classes/Error.test.js b/lib/classes/Error.test.js new file mode 100644 index 000000000..cff701fbd --- /dev/null +++ b/lib/classes/Error.test.js @@ -0,0 +1,149 @@ +'use strict'; +/* eslint-disable no-console */ + +const expect = require('chai').expect; +const ServerlessError = require('../../lib/classes/Error').ServerlessError; +const logError = require('../../lib/classes/Error').logError; + +describe('ServerlessError', () => { + describe('#constructor()', () => { + it('should store message', () => { + const error = new ServerlessError('a message', 'a status code'); + expect(error.message).to.be.equal('a message'); + }); + + it('should store name', () => { + const error = new ServerlessError('a message', 'a status code'); + expect(error.name).to.be.equal('ServerlessError'); + }); + + it('should store status code', () => { + const error = new ServerlessError('a message', 'a status code'); + expect(error.statusCode).to.be.equal('a status code'); + }); + + it('should have stack trace', () => { + let expectedError; + function testStackFrame() { + expectedError = new ServerlessError('a message', 'a status code'); + throw expectedError; + } + + let thrownError; + try { + testStackFrame(); + } catch (e) { + thrownError = e; + } + + expect(thrownError).to.exist; // eslint-disable-line no-unused-expressions + expect(thrownError).to.deep.equal(expectedError); + expect(thrownError.stack).to.exist; // eslint-disable-line no-unused-expressions + expect(thrownError.stack).to.have.string('testStackFrame'); + expect(thrownError.stack).to.not.have.string('new ServerlessError'); + expect(thrownError.stack).to.not.have.string('Error.js'); + }); + }); +}); + +describe('Error', () => { + describe('#logError()', () => { + beforeEach(() => { + this.cbProcessExit = null; + this.processExitCodes = []; + this.processExit = process.exit; + process.exit = (code) => { + this.processExitCodes.push(code); + if (this.cbProcessExit) { + this.cbProcessExit(); + } + }; + + this.consoleLogMessages = []; + this.consoleLog = console.log; + console.log = (msg) => { + this.consoleLogMessages.push(msg); + }; + }); + + afterEach(() => { + process.exit = this.processExit; + console.log = this.consoleLog; + + delete process.env.SLS_DEBUG; + }); + + it('should log error and exit', () => { + const error = new ServerlessError('a message', 'a status code'); + logError(error); + console.log = this.consoleLog; // For mocha to echo status of the test + + expect(this.processExitCodes.length).to.be.equal(1); + expect(this.processExitCodes).gt(0); + + const message = this.consoleLogMessages.join('\n'); + expect(message).to.have.string('Serverless Error'); + expect(message).to.have.string('a message'); + }); + + it('should shorten long messages', () => { + const error = new ServerlessError( + 'a message which is way to long so it gets shortened automatically to fit'); + logError(error); + console.log = this.consoleLog; + + const message = this.consoleLogMessages.join('\n'); + expect(message).to.have.string('Serverless Error'); + expect(message).to.have.string('a message which is way to long so it gets shortened'); + expect(message).to.not.have.string( + 'a message which is way to long so it gets shortened automatically to fit'); + }); + + it('should notify about SLS_DEBUG and ask report for unexpected errors', () => { + const error = new Error('an unexpected error'); + logError(error); + console.log = this.consoleLog; + + const message = this.consoleLogMessages.join('\n'); + expect(message).to.have.string('SLS_DEBUG=*'); + expect(message).to.have.string('Please report this error'); + }); + + it('should print stack trace with SLS_DEBUG', () => { + process.env.SLS_DEBUG = 1; + const error = new ServerlessError('a message'); + logError(error); + console.log = this.consoleLog; + + const message = this.consoleLogMessages.join('\n'); + expect(message).to.have.string('Stack Trace'); + expect(message).to.have.string(error.stack); + }); + + it('should not print stack trace without SLS_DEBUG', () => { + const error = new ServerlessError('a message'); + logError(error); + console.log = this.consoleLog; + + const message = this.consoleLogMessages.join('\n'); + expect(message).to.not.have.string('Stack Trace'); + expect(message).to.not.have.string(error.stack); + }); + + it('should re-throw error when handling raises an exception itself', () => { + const error = new ServerlessError('a message'); + const handlingError = new Error('an unexpected error'); + this.cbProcessExit = () => { throw handlingError; }; + + let thrownError = null; + try { + logError(error); + } catch (e) { + thrownError = e; + } + console.log = this.consoleLog; + + expect(thrownError).to.deep.equal(handlingError); + }); + }); +}); diff --git a/lib/classes/Service.js b/lib/classes/Service.js index 02d408e20..fe5550d1e 100644 --- a/lib/classes/Service.js +++ b/lib/classes/Service.js @@ -1,6 +1,6 @@ 'use strict'; -const SError = require('./Error').SError; +const ServerlessError = require('./Error').ServerlessError; const path = require('path'); const _ = require('lodash'); const BbPromise = require('bluebird'); @@ -59,13 +59,13 @@ class Service { `The Serverless version (${version}) does not satisfy the`, ` "frameworkVersion" (${ymlVersion}) in serverless.yml`, ].join(''); - throw new SError(errorMessage); + throw new ServerlessError(errorMessage); } if (!serverlessFile.service) { - throw new SError('"service" property is missing in serverless.yml'); + throw new ServerlessError('"service" property is missing in serverless.yml'); } if (!serverlessFile.provider) { - throw new SError('"provider" property is missing in serverless.yml'); + throw new ServerlessError('"provider" property is missing in serverless.yml'); } if (typeof serverlessFile.provider !== 'object') { @@ -82,7 +82,7 @@ class Service { ` Valid values for provider are: ${providers.join(', ')}.`, ' Please provide one of those values to the "provider" property in serverless.yml.', ].join(''); - throw new SError(errorMessage); + throw new ServerlessError(errorMessage); } if (Array.isArray(serverlessFile.resources)) { @@ -128,7 +128,7 @@ class Service { validate() { _.forEach(this.functions, (functionObj, functionName) => { if (!_.isArray(functionObj.events)) { - throw new SError(`Events for "${functionName}" must be an array,` + + throw new ServerlessError(`Events for "${functionName}" must be an array,` + ` not an ${typeof functionObj.events}`); } }); @@ -148,14 +148,14 @@ class Service { if (functionName in this.functions) { return this.functions[functionName]; } - throw new SError(`Function "${functionName}" doesn't exist in this Service`); + throw new ServerlessError(`Function "${functionName}" doesn't exist in this Service`); } getEventInFunction(eventName, functionName) { if (eventName in this.getFunction(functionName).events) { return this.getFunction(functionName).events[eventName]; } - throw new SError(`Event "${eventName}" doesn't exist in function "${functionName}"`); + throw new ServerlessError(`Event "${eventName}" doesn't exist in function "${functionName}"`); } getAllEventsInFunction(functionName) { From 634f11511849b5961480cc1b573b311baa254920 Mon Sep 17 00:00:00 2001 From: Andrey Tserkus Date: Tue, 31 Jan 2017 01:04:22 -0800 Subject: [PATCH 20/30] fix typo in `CLI` test: `construtor` -> `constructor` --- lib/classes/CLI.test.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/classes/CLI.test.js b/lib/classes/CLI.test.js index 03a9f3f68..3a1d6b326 100644 --- a/lib/classes/CLI.test.js +++ b/lib/classes/CLI.test.js @@ -21,7 +21,7 @@ describe('CLI', () => { serverless = new Serverless({}); }); - describe('#construtor()', () => { + describe('#constructor()', () => { it('should set the serverless instance', () => { cli = new CLI(serverless); expect(cli.serverless).to.deep.equal(serverless); From 01dcea635ccfafd0085c9b5f04f547c016322c56 Mon Sep 17 00:00:00 2001 From: "Eslam A. Hefnawy" Date: Tue, 31 Jan 2017 17:02:20 +0700 Subject: [PATCH 21/30] releasing 1.6.1 --- CHANGELOG.md | 3 +++ npm-shrinkwrap.json | 2 +- package.json | 2 +- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 04a567b50..380629fa0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,6 @@ +# 1.6.1 (31.01.2017) +A minimal patch release that fixes an issue with rendering README.md on npm registry. + # 1.6.0 (30.01.2017) **Important Note:** This release includes breaking changes. If your services stopped working after upgrading to v1.6.0, please read the following section. diff --git a/npm-shrinkwrap.json b/npm-shrinkwrap.json index 5d0e7df24..8860e4d0d 100644 --- a/npm-shrinkwrap.json +++ b/npm-shrinkwrap.json @@ -1,6 +1,6 @@ { "name": "serverless", - "version": "1.6.0", + "version": "1.6.1", "dependencies": { "agent-base": { "version": "2.0.1", diff --git a/package.json b/package.json index 3732da8a8..681f95440 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "serverless", - "version": "1.6.0", + "version": "1.6.1", "engines": { "node": ">=4.0" }, From 8ff0b30c490536b6badfab38863fda02a85215c6 Mon Sep 17 00:00:00 2001 From: David Wells Date: Tue, 31 Jan 2017 17:08:19 -0800 Subject: [PATCH 22/30] Update README.md --- docs/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/README.md b/docs/README.md index b856cbe1d..920b9c1a2 100644 --- a/docs/README.md +++ b/docs/README.md @@ -105,7 +105,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
- Serverless Framework IBM OpenWhisk Guide + Serverless Framework IBM OpenWhisk Guide
@@ -130,7 +130,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
- Serverless Framework IBM OpenWhisk CLI Reference + Serverless Framework IBM OpenWhisk CLI Reference
@@ -153,7 +153,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
- Serverless Framework IBM OpenWhisk Events + Serverless Framework IBM OpenWhisk Events
@@ -168,7 +168,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
- Serverless Framework IBM OpenWhisk Examples + Serverless Framework IBM OpenWhisk Examples
From caf3a468195004c0092e9c15ea09154ed1fbaf8c Mon Sep 17 00:00:00 2001 From: Bruno Belotti Date: Sun, 5 Feb 2017 15:30:30 +0000 Subject: [PATCH 23/30] permissions details Add a paragraph to (hopefully) clarity the mechanism behind AWS roles and permissions, while we come up with a better implementation (see issue #2903) --- .../providers/aws/cli-reference/invoke-local.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/providers/aws/cli-reference/invoke-local.md b/docs/providers/aws/cli-reference/invoke-local.md index e0f2efb95..ff74f03d7 100644 --- a/docs/providers/aws/cli-reference/invoke-local.md +++ b/docs/providers/aws/cli-reference/invoke-local.md @@ -61,3 +61,20 @@ This example will pass the json data in the `lib/data.json` file (relative to th ### Limitations Currently, `invoke local` only supports the NodeJs and Python runtimes. + +## Resource permissions + +Lambda functions assume an *IAM role* during exection: the framework creates this role, and set all the permission provided in the `iamRoleStatements` section of `serverless.yaml`. + +Unless you explicitly state otherwise, every call to the AWS SDK inside the lambda function is made using this role (a temporary pair of key/secret is generated and set by AWS as environment variables, `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`). + +When you use `lambda invoke local`, the situation is quite different: the role isn't available (the function is executed on your local machine), so unless you set a different user directly in the code (or via a key pair of environment variables), the AWS SDK will use the default profile speficied inside you AWS credential configuration file. + +Take a look to the official AWS documentation (in this particular instance, for the javascript SDK, but should be similar for all SDKs): + +- [http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-node-credentials-shared.html](http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-node-credentials-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. + + From 28e0e331e5cef00e9a3466db8a5338e2645668d7 Mon Sep 17 00:00:00 2001 From: Philipp Muens Date: Mon, 6 Feb 2017 09:49:50 +0100 Subject: [PATCH 24/30] Minor typo fixes --- docs/providers/aws/cli-reference/invoke-local.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/docs/providers/aws/cli-reference/invoke-local.md b/docs/providers/aws/cli-reference/invoke-local.md index ff74f03d7..1549bc848 100644 --- a/docs/providers/aws/cli-reference/invoke-local.md +++ b/docs/providers/aws/cli-reference/invoke-local.md @@ -64,11 +64,11 @@ Currently, `invoke local` only supports the NodeJs and Python runtimes. ## Resource permissions -Lambda functions assume an *IAM role* during exection: the framework creates this role, and set all the permission provided in the `iamRoleStatements` section of `serverless.yaml`. +Lambda functions assume an *IAM role* during execution: the framework creates this role, and set all the permission provided in the `iamRoleStatements` section of `serverless.yml`. -Unless you explicitly state otherwise, every call to the AWS SDK inside the lambda function is made using this role (a temporary pair of key/secret is generated and set by AWS as environment variables, `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`). - -When you use `lambda invoke local`, the situation is quite different: the role isn't available (the function is executed on your local machine), so unless you set a different user directly in the code (or via a key pair of environment variables), the AWS SDK will use the default profile speficied inside you AWS credential configuration file. +Unless you explicitly state otherwise, every call to the AWS SDK inside the lambda function is made using this role (a temporary pair of key / secret is generated and set by AWS as environment variables, `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`). + +When you use `serverless invoke local`, the situation is quite different: the role isn't available (the function is executed on your local machine), so unless you set a different user directly in the code (or via a key pair of environment variables), the AWS SDK will use the default profile specified inside you AWS credential configuration file. Take a look to the official AWS documentation (in this particular instance, for the javascript SDK, but should be similar for all SDKs): @@ -76,5 +76,3 @@ 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-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. - - From 8e86d35191ad0a49d075a492a9f336f6b2755592 Mon Sep 17 00:00:00 2001 From: Marc Abramowitz Date: Mon, 6 Feb 2017 06:54:39 -0800 Subject: [PATCH 25/30] README.md: Coudwatch => Cloudwatch --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 24405f1e4..ed2c00a92 100755 --- a/README.md +++ b/README.md @@ -159,7 +159,7 @@ This table is generated from https://github.com/serverless/plugins/blob/master/p | **[Serverless Crypt](https://github.com/marcy-terui/serverless-crypt)**
Securing the secrets on Serverless Framework by AWS KMS encryption. | [marcy-terui](http://github.com/marcy-terui) | | **[Serverless Dotnet](https://github.com/fruffin/serverless-dotnet)**
A serverless plugin to run 'dotnet' commands as part of the deploy process | [fruffin](http://github.com/fruffin) | | **[Serverless Dynamodb Local](https://github.com/99xt/serverless-dynamodb-local)**
Serverless Dynamodb Local Plugin - Allows to run dynamodb locally for serverless | [99xt](http://github.com/99xt) | -| **[Serverless Enable Api Logs](https://github.com/paulSambolin/serverless-enable-api-logs)**
Enables Coudwatch logging for API Gateway events | [paulSambolin](http://github.com/paulSambolin) | +| **[Serverless Enable Api Logs](https://github.com/paulSambolin/serverless-enable-api-logs)**
Enables Cloudwatch logging for API Gateway events | [paulSambolin](http://github.com/paulSambolin) | | **[Serverless Event Constant Inputs](https://github.com/dittto/serverless-event-constant-inputs)**
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 Jest Plugin](https://github.com/SC5/serverless-jest-plugin)**
A Serverless Plugin for the Serverless Framework which adds support for test-driven development using Jest | [SC5](http://github.com/SC5) | | **[Serverless Mocha Plugin](https://github.com/SC5/serverless-mocha-plugin)**
A Serverless Plugin for the Serverless Framework which adds support for test-driven development using Mocha | [SC5](http://github.com/SC5) | From 7b366a54b29a14f5b21c1d89c4c2f0122acef260 Mon Sep 17 00:00:00 2001 From: James Thomas Date: Tue, 7 Feb 2017 17:52:35 +0000 Subject: [PATCH 26/30] Update HTTP Event for extended options --- docs/providers/openwhisk/events/apigateway.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/providers/openwhisk/events/apigateway.md b/docs/providers/openwhisk/events/apigateway.md index 46c254073..536d57b03 100644 --- a/docs/providers/openwhisk/events/apigateway.md +++ b/docs/providers/openwhisk/events/apigateway.md @@ -97,6 +97,22 @@ The body of the incoming request is parsed as JSON and passed as the The returned JavaScript object will be serialised as JSON and returned in the HTTP response body. +### HTTP Endpoint with Extended Options + +Here we've defined an POST endpoint for the path `posts/create`. + +```yml +# serverless.yml + +functions: + create: + handler: posts.create + events: + - http: + path: posts/create + method: post +``` + ### CORS Support **Note:** All HTTP endpoints defined in this manner have cross-site requests From 5c061a8af7279912eafa486b281a7fe28c3af0af Mon Sep 17 00:00:00 2001 From: Joey van Dijk Date: Tue, 7 Feb 2017 21:59:09 +0100 Subject: [PATCH 27/30] Provide example how to switch between AWS profiles Due to a gitter question and my personal experience, I missed the option to use an existing development stack and implement `serverless` into it by providing an example how to switch AWS profiles. This is useful when developing multiple projects / microservices. --- docs/providers/aws/guide/credentials.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/providers/aws/guide/credentials.md b/docs/providers/aws/guide/credentials.md index 13056cb66..0a66bc7fd 100644 --- a/docs/providers/aws/guide/credentials.md +++ b/docs/providers/aws/guide/credentials.md @@ -104,6 +104,27 @@ provider: profile: devProfile ``` +##### Use an existing AWS Profile + +To easily switch between projects without the need to do `aws configure` every time you can use environment variables. +For example you define different profiles in `~/.aws/credentials` + +```ini +[profileName1] +aws_access_key_id=*************** +aws_secret_access_key=*************** + +[profileName2] +aws_access_key_id=*************** +aws_secret_access_key=*************** +``` + +Now you can switch per project (/ API) by executing + +`export AWS_PROFILE="profileName2" && export AWS_REGION=eu-west-1`. + +in the Terminal. The AWS region setting is to prevent issues with specific services, so adapt if you need another default region. + #### Per Stage Profiles As an advanced use-case, you can deploy different stages to different accounts by using different profiles per stage. In order to use different profiles per stage, you must leverage [variables](https://serverless.com/framework/docs/providers/aws/guide/variables) and the provider profile setting. From 24f703134260bbb8c7b26912978aef2ccfd2ba05 Mon Sep 17 00:00:00 2001 From: Joey van Dijk Date: Tue, 7 Feb 2017 22:09:39 +0100 Subject: [PATCH 28/30] Update credentials.md --- docs/providers/aws/guide/credentials.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/providers/aws/guide/credentials.md b/docs/providers/aws/guide/credentials.md index 0a66bc7fd..abcd45ce1 100644 --- a/docs/providers/aws/guide/credentials.md +++ b/docs/providers/aws/guide/credentials.md @@ -119,11 +119,12 @@ aws_access_key_id=*************** aws_secret_access_key=*************** ``` -Now you can switch per project (/ API) by executing +Now you can switch per project (/ API) by executing once when you start your project: `export AWS_PROFILE="profileName2" && export AWS_REGION=eu-west-1`. -in the Terminal. The AWS region setting is to prevent issues with specific services, so adapt if you need another default region. +in the Terminal. Now everything is set to execute all the `serverless` CLI options like `sls deploy`. +The AWS region setting is to prevent issues with specific services, so adapt if you need another default region. #### Per Stage Profiles From a3b715935bb879b5aebc2da2f2ae1eef46a2afa0 Mon Sep 17 00:00:00 2001 From: dan moore Date: Wed, 8 Feb 2017 06:27:47 +0000 Subject: [PATCH 29/30] Minor docs readability improvement DIdn't make sense - the endpoint is not an event, a request to the endpoint is. --- docs/providers/aws/guide/intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/providers/aws/guide/intro.md b/docs/providers/aws/guide/intro.md index 7c4a52984..a749ef3e0 100644 --- a/docs/providers/aws/guide/intro.md +++ b/docs/providers/aws/guide/intro.md @@ -36,7 +36,7 @@ You can perform multiple jobs in your code, but we don't recommend doing that wi 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 (e.g., for a REST API)* +* *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)* From ab5820333dc0c0f0a75d4b0b695152222a3ac9cb Mon Sep 17 00:00:00 2001 From: Francesc Rosas Date: Wed, 8 Feb 2017 15:40:15 +0000 Subject: [PATCH 30/30] Fix indentation --- docs/providers/aws/events/apigateway.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/providers/aws/events/apigateway.md b/docs/providers/aws/events/apigateway.md index 12651e12e..cfeed2f1c 100644 --- a/docs/providers/aws/events/apigateway.md +++ b/docs/providers/aws/events/apigateway.md @@ -277,11 +277,11 @@ provider: - ${env:MY_API_KEY} # you can hide it in a serverless variable functions: hello: - events: - - http: - path: user/create - method: get - private: true + events: + - http: + path: user/create + method: get + private: true ``` Please note that those are the API keys names, not the actual values. Once you deploy your service, the value of those API keys will be auto generated by AWS and printed on the screen for you to use.