Git Product home page Git Product logo

serverless-aws-alias's Introduction

Serverless License NPM npm Build Status Coverage Status Contributors

Serverless AWS alias plugin

The plugin requires Serverless 1.12 or later!

This plugin enables use of AWS aliases on Lambda functions. The term alias must not be mistaken as the stage. Aliases can be deployed to stages, e.g. if you work on different VCS branches in the same service, you can deploy your branch to a new alias. The alias deployment can contain a different set of functions (newly added ones or removed ones) and does not impact any other deployed alias. Aliases also can be used to provide a 'real' version promotion.

As soon as the service is deployed with the plugin activated, it will create a default alias that is named equally to the stage. This is the master alias for the stage.

Each alias creates a CloudFormation stack that is dependent on the stage stack. This approach has multiple advantages including easy removal of any alias deployment, protecting the aliased function versions, and many more.

Installation

Add the plugin to your package.json's devDependencies and to the plugins array in your serverless.yml file

Terminal:

npm install --save-dev serverless-aws-alias

serverless.yml:

plugins:
  - serverless-aws-alias

After installation the plugin will automatically hook into the deployment process. Additionally the new alias command is added to Serverless which offers some functionality for aliases.

Deploy the default alias

The default alias (for the stage) is deployed just by doing a standard stage deployment with serverless deploy. By default the alias is set to the stage name. Optionally you can set the name of the default (master) alias using the option --masterAlias, e.g., serverless deploy --masterAlias. (If you have already created a serverless deployment without manually setting the default alias, this option should not be used.) From now on you can reference the aliased versions on Lambda invokes with the stage qualifier. The aliased version is read only in the AWS console, so it is guaranteed that the environment and function parameters (memory, etc.) cannot be changed for a deployed version by accident, as it can be done with the $LATEST qualifier.This adds an additional level of stability to your deployment process.

Deploy a single function

The plugin supports serverless deploy function and moves the alias to the updated function version. However you must specify the --force switch on the commandline to enforce Serverless to deploy a new function ZIP regardless, if the code has changed or not. This is necessary to prevent setting the alias to a version of the function that has been deployed by another developer.

Deploy an alias

To deploy an alias to a stage, just add the --alias option to serverless deploy with the alias name as option value.

Example: serverless deploy --alias myAlias

Remove an alias

See the alias remove command below.

Maintain versions

By default, when you deploy, the version of the function gets assigned the retention policy of 'Delete'. This means any subsequent deploys will delete any version without an alias. This was done because each lambda version has its own stack. That stack can contain differences in not only the function code, but resources and events. When an alias is removed from a version and the version of the lambda is not deleted, it is no longer possible to tell which stack it came from and which resources/events it was meant to work with. Therefore versions without aliases will get deleted on subsequent deploys.

There are usecases where retaining versions is less risky and as such, you can opt into retaining these versions by deploying with the --retain flag.

Remove a service

To remove a complete service, all deployed user aliases have to be removed first, using the alias remove command.

To finally remove the whole service (same outcome as serverless remove), you have to remove the master (stage) alias with serverless alias remove --alias=MY_STAGE_NAME.

This will trigger a removal of the master alias CF stack followed by a removal of the service stack. After the stacks have been removed, there should be no remains of the service.

The plugin will print reasonable error messages if you miss something so that you're guided through the removal.

Aliases and API Gateway

In Serverless stages are, as above mentioned, parallel stacks with parallel resources. Mapping the API Gateway resources to this semantics, each stage has its own API deployment.

Aliases fit into this very well and exactly as with functions an alias is a kind of "tag" within the API deployment of one stage. Curiously AWS named this "stage" in API Gateway, so it is not to be confused with Serverless stages.

Thus an alias deployment will create an API Gateway stage with the alias name as name.

API Gateway stage and deployment

The created API Gateway stage has the stage variables SERVERLESS_STAGE and SERVERLESS_ALIAS set to the corresponding values.

If you want to test your APIG endpoints in the AWS ApiGateway console, you have to set the SERVERLESS_ALIAS stage variable to the alias that will be used for the Lambda invocation. This will call the aliased function version.

Deployed stages have the alias stage variable set fixed, so a deployed alias stage is hard-wired to the aliased Lambda versions.

Stage configuration (NEW)

The alias plugin supports configuring the deployed API Gateway stages, exactly as you can do it within the AWS APIG console, e.g. you can configure logging (with or without data/request tracing), setup caching or throttling on your endpoints.

The configuration can be done on a service wide level, function level or method level by adding an aliasStage object either to provider, any function or a http event within a function in your serverless.yml. The configuration is applied hierarchically, where the inner configurations overwrite the outer ones.

HTTP Event -> FUNCTION -> SERVICE

API logs

The generated API logs (in case you enable logging with the loggingLevel property) can be shown the same way as the function logs. The plugin adds the serverless logs api command which will show the logs for the service's API. To show logs for a specific deployed alias you can combine it with the --alias option as usual.

The aliasStage configuration object

All settings are optional, and if not specified will be set to the AWS stage defaults.

aliasStage:
  cacheDataEncrypted: (Boolean)
  cacheTtlInSeconds: (Integer)
  cachingEnabled: (Boolean)
  dataTraceEnabled: (Boolean) - Log full request/response bodies
  loggingLevel: ("OFF", "INFO" or "ERROR")
  metricsEnabled: (Boolean) - Enable detailed CW metrics
  throttlingBurstLimit: (Integer)
  throttlingRateLimit: (Number)

There are two further options that can only be specified on a service level and that affect the whole stage:

aliasStage:
  cacheClusterEnabled: (Boolean)
  cacheClusterSize: (Integer)

For more information see the AWS::APIGateway::Stage or MethodSettings documentation on the AWS website.

Sample serverless.yml (partial):

service: sls-test-project

provider:
  ...
  # Enable detailed error logging on all endpoints
  aliasStage:
    loggingLevel: "ERROR"
    dataTraceEnabled: true
  ...

functions:
  myFunc1:
    ...
    # myFunc1 should generally not log anything
    aliasStage:
      loggingLevel: "OFF"
      dataTraceEnabled: false
    events:
      - http:
          method: GET
          path: /func1
      - http:
          method: POST
          path: /func1/create
      - http:
          method: PATCH
          path: /func1/update
          # The update endpoint needs special settings
          aliasStage:
            loggingLevel: "INFO"
            dataTraceEnabled: true
            throttlingBurstLimit: 200
            throttlingRateLimit: 100

  myFunc2:
    ...
    # Will inherit the global settings if nothing is set on function level

Reference the current alias in your service

You can reference the currently deployed alias with ${self:provider.alias} in your service YAML file. It should only be used for information, but not to set any resource names. Making anything hard-wired to the alias name might make the project unusable when deployed to different aliases because the resources are maintained in the master CF stack - the plugin takes care that resources are available.

A valid use is to forward the alias name as environment variable to the lambdas and use it there for tagging of log messages. Then you see immediately which aliased lambda is the origin.

Any other use with the further exception of lambda event subscriptions (see below) is strongly discouraged.

Resources

Resources are deployed per alias. So you can create new resources without destroying the main alias for the stage. If you remove an alias the referenced resources will be removed too.

However, logical resource ids are unique per stage. If you deploy a resource into one alias, it cannot be deployed with the same logical resource id and a different configuration into a different alias. Nevertheless, you can have the same resource defined within multiple aliases with the same configuration.

This behavior exactly resembles the workflow of multiple developers working on different VCS branches.

The master alias for the stage has a slightly different behavior. If you deploy here, you are allowed to change the configuration of the resource (e.g. the capacities of a DynamoDB table). This deployment will reconfigure the resource and on the next alias deployment of other developers, they will get an error that they have to update their configuration too - most likely, they updated it already, because normally you rebase or merge your upstream and get the changes automatically.

Event subscriptions

Event subscriptions that are defined for a lambda function will be deployed per alias, i.e. the event will trigger the correct deployed aliased function.

SNS

Subscriptions to SNS topics can be implicitly defined by adding an sns event to any existing lambda function definition. Serverless will create the topic for you and add a subscription to the deployed function.

With the alias plugin the subscription will be per alias. Additionally the created topic is renamed and the alias name is added (e.g. myTopic-myAlias). This is done because SNS topics are independent per stage. Imagine you want to introduce a new topic or change the data/payload format of an existing one. Just attaching different aliases to one central topic would eventually break the system, as functions from different stages will receive the new data format. The topic-per-alias approach effectively solves the problem.

If you want to refer to the topic programmatically, you just can add -${process.env.SERVERLESS_ALIAS} to the base topic name.

Use with global resources

Event subscriptions can reference resources that are available throughout all aliases if they reference the same resource id. That means that an event will trigger all aliases that are deployed with the subscription defined.

Example:

functions:
  testfct1:
    description: 'My test function'
    handler: handlers/testfct1/handler.handle
    events:
      - stream:
          type: kinesis
          arn: "arn:aws:kinesis:${self:provider.region}:XXXXXX:stream/my-kinesis"
      - http:
          method: GET
          path: /func1
resources:
  Resources:
    myKinesis:
      Type: AWS::Kinesis::Stream
      Properties:
        Name: my-kinesis
        ShardCount: 1

When a function is deployed to an alias it will now also listen to the my-kinesis stream events. This is useful, if you want to test new implementations with an existing resource.

Use with per alias resources

Currently this feature is not available. The Serverless framework does not support variable substitution in property names (see #49). As soon as this has been implemented there, this note will be removed.

There might be cases where you want to test with your private resources first, before you deploy changes to the master alias. Or you just want to create separate resources and event subscriptions per alias.

The solution here is to make the resource id dependent on the alias name, so that the alias effectively owns the resource and the event subscription is bound to it.

Example:

functions:
  testfct1:
    description: 'My test function'
    handler: handlers/testfct1/handler.handle
    events:
      - stream:
          type: kinesis
          arn: "arn:aws:kinesis:${self:provider.region}:XXXXXX:stream/my-kinesis-${self.provider.alias}"
      - http:
          method: GET
          path: /func1
resources:
  Resources:
    myKinesis${self:provider.alias}:
      Type: AWS::Kinesis::Stream
      Properties:
        Name: my-kinesis-${self.provider.alias}
        ShardCount: 1

Named streams

The examples above use named streams. I know that this is not perfect as changes that require replacement are not possible. The reason for the named resources is, that Serverless currently only supports event arns that are strings. The change is already in the pipeline there. Afterwards you just can reference the event arns with CF functions like "Fn::GetAtt" or "Ref". I will update the examples as soon as it is fixed there and publicly available.

Serverless info integration

The plugin integrates with the Serverless info command. It will extend the information that is printed with the list of deployed aliases.

In verbose mode (serverless info -v) it will additionally print the names of the lambda functions deployed to each stage with the version numbers the alias points to.

Given an alias with --alias=XXXX info will show information for the alias.

Serverless logs integration

The plugin integrates with the Serverless logs command (all standard options will work). Additionally, given an alias with --alias=XXXX, logs will show the logs for the selected alias. Without the alias option it will show the master alias (aka. stage alias).

The generated API logs (in case you enable logging with the stage loggingLevel property) can be shown the same way as the function logs. The plugin adds the serverless logs api command which will show the logs for the service's API. To show logs for a specific deployed alias you can combine it with the --alias option as usual.

The alias command

Subcommands

alias remove

Removes an alias and all its uniquely referenced functions and function versions. The alias name has to be specified with the --alias option.

Functions and resources owned by removed aliases will be physically removed after the alias stack has been removed.

Compatibility

The alias plugin is compatible with all standard Serverless commands and switches. For example, you can use --noDeploy and the plugin will behave accordingly.

Interoperability

Care has to be taken when using other plugins that modify the CF output too. I will add configuration instructions in this section for these plugin combinations.

The warmup plugin will keep your Lambdas warm and reduce the cold start time effectively. When using the plugin, it must be listed before the alias plugin in the plugin list of serverless.yml. The warmup lambda created by the plugin will be aliased too, so that the warmup plugin can be configured differently per deployed alias.

Test it

In case you wanna test how it behaves, I provided a predefined test service in the sample folder, that creates two functions and a DynamoDB table. Feel free to check everything - and of course report bugs immediately ;-) as I could not test each and every combination of resources, functions, etc.

Use case examples

Multiple developers work on different branches

A common use case is that multiple developers work on different branches on the same service, e.g. they add new functions individually. Every developer can just deploy his version of the service to different aliases and use them. Neither the main (stage) alias is affected by them nor the other developers.

If work is ceased on a branch and it is deleted, the alias can just be removed and on the next deployment of any other alias, the obsoleted functions will disappear automatically.

Sample project

A preconfigured sample project can be found here. It lets you start testing right away. See the project's README for instructions. The sample project will evolve over time - when new features or changes are integrated into the plugin.

Uninstall

If you are not happy with the plugin or just do not like me, you can easily get rid of the plugin without doing any harm to the deployed stuff. The plugin is non-intrusive and does only add some output variables to the main stack:

  • Remove all alias stacks via the CloudFormation console or with 'alias remove'
  • Remove the plugin from your serverless.yml and your package.json
  • Deploy the service again (serverless deploy)

You're all set.

Advanced use cases

VPC settings

Aliases can have different VPC settings (serverless.yml:provider.vpc). So you can use an alias deployment also for testing lambda functions within other internal networks. This is possible because each deployed AWS lambda version contains its entire configuration (VPC settings, environment, etc.)

For developers

Lifecycle events

currently the exposed hooks are not available after the change to the new SLS lifecycle model

The plugin adds the following lifecycle events that can be hooked by other plugins:

  • alias:deploy:uploadArtifacts

    Upload alias dependent CF definitions to S3.

  • alias:deploy:updateAliasStack

    Update the alias CF stack.

  • alias:deploy:done

    The Alias plugin is successfully finished. Hook this instead of 'after:deploy:deploy' to make sure that your plugin gets triggered right after the alias plugin is done.

  • alias:remove:removeStack

    The alias stack is removed from CF.

CF template information (not yet implemented)

If you hook after the alias:deploy:loadTemplates hook, you have access to the currently deployed CloudFormation templates which are stored within the global Serverless object: serverless.service.provider.deployedCloudFormationTemplate and serverless.service.provider.deployedAliasTemplates[].

Ideas

  • The master alias for a stage could be protected by a separate stack policy that only allows admin users to deploy or change it. The stage stack does not have to be protected individually because the stack cross references prohibit changes naturally. It might be possible to introduce some kind of per alias policy.

Version history

  • 1.8.0

    • Option to retain lambda function versions #160
    • Breaking drop Node.js 6 support #161
  • 1.7.2

    • Added support for Lambda custom roles #87 #88
    • Added support for dash in alias name when creating api gateway authorizers #140
    • Configurable master alias #127
    • Fix for "functionnames" where "functionname" A starts with function name B #159
    • Dependencies updated
  • 1.7.1

    • Restore compatibility with Serverless 1.27 #120
  • 1.7.0

    • Support existing custom authorizers #101
    • Support domain-manager plugin #110
    • Support pseudo-parameter plugin #112
    • Show logs from arbitrary versions #62, #89
  • 1.6.1

  • Fixed custom authorizer references #102

  • Fixed broken DynamoDB stream deployments #85

  • Security: Updated moment

  • 1.6.0

  • Fixed issue with request authorizers #96

  • Support subscription to existing SNS topic #94

  • 1.5.1

    • Support prewarmup with the warmup plugin #72
    • Support _ - + in alias names #68
    • Support ANY method type with stage configuration #80
  • 1.5.0

    • Support serverless deploy function #29
  • 1.4.1

    • Fixed crash when using logs --tail
  • 1.4.0

    • Add support for S3 server side encryption #63
    • Add serverless logs api command to watch API logs #60
  • 1.3.0

    • Support full stage configuration at multiple levels #57
    • Fix issue when trying to remove a stage completely #56
  • 1.2.1

    • Fix issue when using a Cognito User Pools authorizer #51
    • IAM roles of removed aliases are not deleted #50
    • Added note to README to state that per-alias resources do not work until fixed/added in Serverless
  • 1.2.0

    • Fix issue when stage is specified as Serverless variable #45
    • Add support for SNS Lambda subscriptions #43
    • Add support for custom authorizers #22
  • 1.1.0

    • Use stage variable in APIG #40
    • Fix tail logging #42
  • 1.0.0 Support "serverless logs" with aliases. First non-alpha!

serverless-aws-alias's People

Contributors

enase avatar hyperbrain avatar martinrisk avatar mcjfunk avatar romeara avatar vkkis93 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

serverless-aws-alias's Issues

Serverless logs with --tail does not work

Serverless logs in general works to print the CW logs of an aliased function version.
Nevertheless, when you try to use --tail it just prints the same information as without the option and exits.

The expected behavior would be, that Serverless keeps running and prints new log events periodically.
Additionally there is a crash, if you specify the -i option to set an interval, but omit the value.

Custom resource support

The plugin should support different resource sets per alias. This is important for feature development, where different developers might deploy their current sources to a separate alias. Naturally they work on features that also differ by their needed CF/AWS resources.

Support API keys (per alias)

In AWS API Gateway API keys are set per stage. They can be configured completely different, even with different usage plans per stage.

After experimenting with the Serverless implementation and workflow I will describe the feature as it will be implemented in detail here.

Plugin aborts with Serverless <1.7.0

With Serverless versions less than 1.7.0 the plugin exits with
' Policy count should be 1! Please report this error to the alias plugin owner.'

This is due to a breaking change in Serverless 1.7.0 (IAM inline policies).

Add alias information to serverless info command

serverless alias should show a list of deployed aliases.

This is helpful if you want to get an overview or want to remove aliases that are not needed anymore and consume resources for nothing.

Add alias support to "rollback" command

The rollback command should support alias rollbacks.

The semantics here is quite difficult, because multiple aliases could be deployed currently. There are a variety of different cases that can appear:

  1. Rollback everything (all aliases) to the selected timestamp
    To enable this functionality, the plugin has to store the status (CF templates) of every alias on every deploy to S3. Then these files can be used to reconstruct the whole stage to the state as it was.

  2. Rollback only one alias to the selected timestamp
    This is more difficult as resources might have been changed over time and it could be possible that the old alias state does not match the state of the other aliases (most importantly the master alias) anymore. In the worst case a rollback of a single alias is only possible through to a timestamp that is newer than the requested one.

I would favor 1 as the initial implementation and discuss 2 further to find the best solution for that case.

Allow monitoring API logs with "serverless logs"

Now that APIG stage logs can be enabled, it would be very useful, if the "serverless logs" command could show these logs too. This would add the same convinience as for function logs.

Proposal

Add an --api switch to the command, that can be used instead of --function.

Samples

serverless logs --api --alias=myAlias --stage=dev --tail
serverless logs --api --stage=dev --tail
serverless logs --function=myFunc --alias=myAlias --stage=dev --tail

Error when creating aliases with "-" in the name

I've tried to deploy a new alias called "my-test" using sls deploy --alias my-test. Unfortunately this fails with an exception:

  The CloudFormation template is invalid: Template format error: Resource name IamRoleLambdaExecutionmy-test is non alphanumeric.

The alias stack is still created and not cleaned up properly. I suggest to simply use camel casing when appending the alias name to CloudFormation resources. That would fix this while still allowing non alphanumeric characters in the alias name itself.

Support version flag for serverless logs to show logs for any previously deployed function version

serverless logs --function=XXXX --alias=XXXX will only show the logs of the currently deployed function version. In case you want to compare the current logs with logs from versions that had been deployed previously, they will not be accessible with the command, but only with the AWS CW console. The old function logs normally are kept until the CW logs expiration is triggered.

This could be solved with a --version switch, that lets you select a specific version of the logs to show.
E.g. serverless logs --function=myFunc --version=130 would show the myFunc logs of version 130.

Support use of service role

Serverless services can specify a role as service role in provider.role.

The plugin should handle this, especially if different aliases use different settings.
E.g. alias A is deployed with a role definition and alias B with auto generation by Serverless.

Optimally the plugin should maintain the roles and keep a reference count to uninstall not needed autogenerated roles.

Support events for aliases

All possible event types (besides HTTP) should be supported in a feasible way for aliases.

CloudWatch triggers are excluded here - we first need a consistent behavior definition for them. The other event types should be straight forward.

Policy count should be 1

Getting the following error when trying to execute my initial deploy using "sls deploy -s dev -r us-east-1"

Error --------------------------------------------------

 Policy count should be 1! Please report this error to
 the alias plugin owner.

 For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.

Stack Trace --------------------------------------------

Error: Policy count should be 1! Please report this error to the alias plugin owner.
at AwsAlias.aliasHandleLambdaRole (C:\Apps\Workspaces\Development\Services\development\Services\apitest\nodejs\node_modules\serverless-aws-alias\lib\aliasRestructureStack.js:396:28)
at runCallback (timers.js:649:20)
at tryOnImmediate (timers.js:622:5)
at processImmediate [as _immediateCallback] (timers.js:594:5)
From previous event:
at PluginManager.run (C:\Users\xxxxx\AppData\Roaming\npm\node_modules\serverless\lib\classes\PluginManager.js:156:22)
at Serverless.run (C:\Users\xxxxx\AppData\Roaming\npm\node_modules\serverless\lib\Serverless.js:95:31)
at serverless.init.then (C:\Users\xxxxx\AppData\Roaming\npm\node_modules\serverless\bin\serverless:23:50)

Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues

 Please report this error. We think it might be a bug.

Your Environment Information -----------------------------
OS: win32
Node Version: 6.9.4

URL output format

Hi there,

I intend to use this plugin for versioning purposes:

Master
serverless --stage dev

Versions
serverless --stage dev --alias v1

serverless --stage dev --alias v2

Endpoints
https://{{domain}}.execute-api.eu-west-1.amazonaws.com/{{alias}}/resource

My question is, can I customize the alias format so it becomes with the plugin?
https://{{domain}}.execute-api.eu-west-1.amazonaws.com/api/{{alias}}/resource

Note the /api/ before the {{alias}}

@thanks!

Support "deploy function" with aliases

Currently deploy function will not work with the plugin as this uploads a function ZIP unconditionally to the $LATEST version, but the tagged alias does not move.

The plugin should correctly intercept the deploy function command and shift the alias accordingly.

Support alias in SNS Topic subscription

Hello,
When you create SNS Topic in AWS Console you can add Lambda subscription with alias.
Now if you deploys different aliases - subscription will be always ${functionName}.
Can we do like this ${functionName}:${alias} ?
Is it possible?
http://prntscr.com/fcbdfc
First subscription - it's what I need
Second subscription - current state.

Thank you.

Full AWS APIG stage configuration

Is there a way to set the settings Enable CloudWatch Logs and Enable Detailed CloudWatch Metrics for the APIG stage?
In Cloudformation that would be the params in AWS::ApiGateway::Stage -> MethodSettings.

Complete stage removal not possible

When the alias plugin is used and only the master alias is left, serverless remove will error out, and serverless alias remove does not remove the master alias.

The alias plugin should support removing the master alias including the whole service stack.
Removal should only be possible if there are no other aliases deployed.

See thread serverless/serverless#3805

Should the plugin leave the alpha state?

In the current state I consider the plugin to be stable enough to leave the alpha state.

Standard projects are now fully supported including several other plugins.
Please vote here if I should switch to a release version with the next release,
beginning with correct SemVer 1.0.0.

Invalid CloudFormation Template on initial deploy

I just tried to deploy my project with the plugin enabled but it fails with this error message:

Serverless: Packaging service...
Serverless: Preparing alias ...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading CloudFormation alias file to S3...
Serverless: Validating template...

Error --------------------------------------------------

The CloudFormation template is invalid: Template format error: Unresolved resource dependencies [ApiGatewayDeployment1499436937655] in the Resources block of the template

 For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.

Stack Trace --------------------------------------------

Error: The CloudFormation template is invalid: Template format error: Unresolved resource dependencies [ApiGatewayDeployment1499436937655] in the Resources block of the template
at provider.request.catch (/usr/local/lib/node_modules/serverless/lib/plugins/aws/deploy/lib/validateTemplate.js:25:13)
From previous event:
at AwsDeploy.validateTemplate (/usr/local/lib/node_modules/serverless/lib/plugins/aws/deploy/lib/validateTemplate.js:20:12)
From previous event:
at Object.aws:deploy:deploy:validateTemplate [as hook] (/usr/local/lib/node_modules/serverless/lib/plugins/aws/deploy/index.js:102:10)
at BbPromise.reduce (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:233:55)
From previous event:
at PluginManager.invoke (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:233:22)
at PluginManager.spawn (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:245:17)
at AwsDeploy.BbPromise.bind.then (/usr/local/lib/node_modules/serverless/lib/plugins/aws/deploy/index.js:88:48)
From previous event:
at Object.deploy:deploy [as hook] (/usr/local/lib/node_modules/serverless/lib/plugins/aws/deploy/index.js:84:10)
at BbPromise.reduce (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:233:55)
From previous event:
at PluginManager.invoke (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:233:22)
at PluginManager.run (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:252:17)
at variables.populateService.then (/usr/local/lib/node_modules/serverless/lib/Serverless.js:104:33)
at runCallback (timers.js:800:20)
at tryOnImmediate (timers.js:762:5)
at processImmediate [as _immediateCallback] (timers.js:733:5)
From previous event:
at Serverless.run (/usr/local/lib/node_modules/serverless/lib/Serverless.js:91:74)
at serverless.init.then (/usr/local/lib/node_modules/serverless/bin/serverless:23:50)
at

Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Forums: forum.serverless.com
Chat: gitter.im/serverless/serverless

Your Environment Information -----------------------------
OS: darwin
Node Version: 8.1.2
Serverless Version: 1.14.0

Warmup

Hi,
Thanks for this very useful project.
I've add the warmup plugin with the prewarm option.
I've seen the integration in the warmup plugin of the alias var.

I was wondering if it's possible to warmup the new version of the lambda deployed before the alias is changed to point on it.
The aim is to avoid lambda timeout after the alias is changed because of the long coldstart period.

Any ideas ?
Thanks,

Fred.

Stage is added twice and erroneous

Hi there

if I define the stage with a variable the stage is added twice and the second add is erroneous because the variable is not mapped
myLambda-myStage-${self:custom.stage}

reproduce

serverless create --template aws-java-maven --path myLambda

in the created directory:
change serverless.yml to

service: myLambda
custom:
  stage: myStage
provider:
  name: aws
  runtime: java8
  stage: ${self:custom.stage}
package:
  artifact: target/hello-dev.jar
functions:
  hello:
    handler: com.serverless.Handler
plugins:
  - serverless-aws-alias

then run commands

mvn clean package
npm install --save serverless-aws-alias
serverless deploy -v

The output of the deploy step is

Serverless: Packaging service...
Serverless: Preparing alias ...
Serverless: Processing custom resources
Serverless: Removing resources: 
Serverless: Processing functions
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
CloudFormation - CREATE_IN_PROGRESS - AWS::CloudFormation::Stack - myLambda-myStage
CloudFormation - CREATE_IN_PROGRESS - AWS::S3::Bucket - ServerlessDeploymentBucket
CloudFormation - CREATE_IN_PROGRESS - AWS::S3::Bucket - ServerlessDeploymentBucket
CloudFormation - CREATE_COMPLETE - AWS::S3::Bucket - ServerlessDeploymentBucket
CloudFormation - CREATE_COMPLETE - AWS::CloudFormation::Stack - myLambda-myStage
Serverless: Stack create finished...
 
  Serverless Error ---------------------------------------
 
     The stack alias name "myLambda-myStage-${self:custom.stage}"
     is not valid. A service name should only contain alphanumeric
     (case sensitive) and hyphens. It should start with an
     alphabetic character and shouldn't exceed 128 characters.
 
  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Forums:        forum.serverless.com
     Chat:          gitter.im/serverless/serverless
 
  Your Environment Information -----------------------------
     OS:                 linux
     Node Version:       6.9.1
     Serverless Version: 1.13.2

Best regards

Use stage variables to specify lambda qualifier in APIG

On Integration request page field lambda function always has value of last deployed stage.
For Example
getUser:staging or getUser:production.
I think it should be like getUser:${functionAlias}
Where functionAlias value should be specified in stage variables tab

Support custom authorizers

Custom authorizers should also be supported by the plugin, i.e. if a service defines custom authorizers, they have to be assigned to the correct stage and either the referenced alias lambda has to be set as target or, in case a full qualified arn has been given, this has to be set.

#21 Is caused by the missing feature.

Cannot read property 'Fn::Join' of undefined when specifying a User Pools authorizer

Attempting to deploy i get error Cannot read property 'Fn::Join' of undefined, this is the logs terminals.

Serverless: Packaging service...
Serverless: Preparing alias ...

Type Error ---------------------------------------------

 Cannot read property 'Fn::Join' of undefined

 For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.

Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Forums: forum.serverless.com
Chat: gitter.im/serverless/serverless

Your Environment Information -----------------------------
OS: darwin
Node Version: 6.9.1
Serverless Version: 1.14.0

can you help me, thanks?

Option to use git branch name automatically as alias

Feature request

The alias plugin is especially valuable for development in a multi-developer scenario with features developed in separate branches. An idea is that the plugin offers an option (either in serverless.yml or as a commandline parameter) that automatically derives the alias name from the branch that is deployed from.

If enabled the plugin would use git to determine the current branch. Then it would automatically set the alias name to the branch name on "serverless deploy".

The exception are builds done on build servers, where in general a commit is checked out and not a special branch. The plugin should determine this scenario and refuse deployment on such systems without specifying an explicit alias (via the --alias switch).

Alias always generates same stack

Hi there,

Serverless version: 1.17

For some reason I am always generating the same stack no matter what Alias I put on. I followed the installation instructions and it seems the Alias plugin is giving some feedback while deploying, but its always deploying / overwriting the same content with the same endpoints

I created first the first stage deploy
serverless deploy

And then I tried to create aliases for v1
serverless deploy --alias v1

and v2
serverless deploy --alias v2

But I always end up overwriting the API Gateway, Lambdas and everything
POST - https://{same_endpoint}.execute-api.eu-west-1.amazonaws.com/...

More info

  1. In my lambda console I only have one version of the lambdas, I would expect to have one version per alias, is that right?

  2. Reading your<alias_here> I understand that API Gateway should contain as many initial resources as aliases and then the master API hanging from there although it doesn't, but this is just a guess

/
  /v1
    /my
      /master
        /api
  /v2
    /my
      /master
        /api 
  1. In my .serverless folder I have 2 new files:

cloudformation-template-update-alias-stack.json
cloudformation-template-create-alias-stack.json

Both containing information only about the last alias deployed, in this case v2

Any suggestion?

IAM role for alias is not removed

On removal of an alias, the IAM role for the alias will stay in the base stack. As a consequence the physical role resource does not get removed.

Expectation:
On removal of an alias all alias resources should be removed correctly.

Add preconfigured sample service

The sample service mentioned in the README should be made available.

As it should show how the plugin behaves with different configurations, it has to be offered as a separate GitHub repository rather than within a subfolder.
The sample respository will have different branches set up, that simulate real development and can just be deployed from the branches after it has been cloned.

Serverless logs crashes if there are no logs available for an aliased function

If you try to show the logs for a function with serverless logs --function=XXXX [--alias=YYYY] and the aliased function has not been called (i.e. there are no log streams available for the function version), the command crashes with:

From previous event:
    at persistentRequest (node_modules/serverless/lib/plugins/aws/provider/awsProvider.js:143:38)
    at AwsProvider.request (node_modules/serverless/lib/plugins/aws/provider/awsProvider.js:159:12)
    at AwsAlias.logsShowLogs (node_modules/serverless-aws-alias/lib/logs.js:117:5)

Instead of the crash, the plugin should show a proper error message like No logs found for function 'XXXX' and alias 'YYYY'

BTW: The same issue is present in the Serverless core framework - I reused the logging code in the plugin.

Thanks to @arabold for finding the issue.

Support CloudWatch events

CW events can be used to trigger functions.

CW events deployed in an aliased deployment should trigger the aliased functions. This makes it possible to deploy events independently per alias. If a stage is removed, the associated events will automatically be removed too.

Expose alias as ${self:alias}

The alias can be made accessible during deployment in the serverless.yml file. This will make it possible to use aliases instead of stages in the same way it was with Serverless 0.5.

Removal of IAM policy statements sometimes does not remove the policy in IAM

It happens that, if a policy statement in "IamLambdaRoleExecution" that references an external resource is removed, the statement will actually not be removed.

This causes no runtime failures, but should be handled correcty, i.e. the policy statement should be removed afterwards.

A better solution to handle policies and aliases than the current one is, that the plugin should create one role per alias and set the lambda role for the aliased function versions correctly.
This has the advantage that each user can deploy completely different access policies per alias.

Serverless logs does not work with alias plugin

Invoking serverless logs leads to error message.

$ node node_modules/serverless/bin/serverless logs --stage=dev --function=authen               ticate

  Serverless Error ---------------------------------------

     1 validation error detected: Value '[]' at 'logStreamNames'
     failed to satisfy constraint: Member must have length
     greater than or equal to 1

  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Forums:        forum.serverless.com
     Chat:          gitter.im/serverless/serverless

  Your Environment Information -----------------------------
     OS:                 win32
     Node Version:       6.10.1
     Serverless Version: 1.12.1

Additionally to this defect, the alias plugin should add support for the --alias option to show the log from an aliased function.

Create Examples

Problem
Difficult to use with confidence while testing which settings work for various use cases.

Proposed Solution
Create some examples of some popular constellations of configs.

Per alias resourcing does not appear to work

Attempting to deploy a previously packaged serverless build that makes use of the example under Use with per alias resource heading in the README results in the error -

Template format error: Resource name myKinesis${self:provider.alias} is non alphanumeric.

Section in question:

 resources:
  Resources:
    myKinesis${self:provider.alias}:
	  Type: AWS::Kinesis::Stream
		Properties:
		  Name: my-kinesis-${self.provider.alias}
		  ShardCount: 1

The next update will be breaking for APIG. Support "alias upgrade" command.

The next update will fix issues with APIG deployment and make APIG much more stable.
Alias remove will now remove the stage correctly (I introduced a separate ApiGateway::Stage resource which gives better control over the APIG stage).

To make the update smooth the plugin should support an "alias upgrade" command which will do the needed changes without having the need to delete anything manually (as this could break some resources).

The only manual intervention to be done would be a redeploy of aliases that use APIG.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.