Open jleclanche opened 7 years ago
@jleclanche implementing canary release functionality within zappa could be a lot easier now API gateway has released this - http://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html
I'm working with dev
and prod
aliases too and have a related use case:
dev
alias should be triggered when a message is published to an SNS topic (dev topic)production
alias should be triggered when a message is published to another SNS topic (prod topic)Currently there are two (ugly) options for making this work:
Define two different stages in zappa settings that are mostly the same, except for the different SNS topic that is triggering the handler. This means I get two different lambdas with the exact same code
Define a single zappa stage with two SNS events, one for each topic. But then, after the lambda is deployed/updated I always need to disable one of the SNS events (depending on the current alias)
Check the extends option, you can define the base stage and then extend from it.
I'm currently playing with Zappa on a new project to see if I can switch to it on a custom-managed lambda project. One thing I'm confused about is the Zappa stages. It looks like stages are actually separate lambdas, rather than using native functionality; is that correct?
This is confusing for the following reason: AWS Lambda supports qualifier-based stages. Example:
In our custom system, we created two API Gateway stages:
production
andcanary
. The production stage is our usual stage, which points to theproduction
lambda alias. Thecanary
stage always points to thecanary
alias.When we roll out a new version, we first deploy it to
canary
, which then ingests a small percentage of our lambdas (which could be from 0% to n% increasing slowly over time or w/e). We check for errors happening in the canary lambda; if we find more errors than we should, we revert canary back to the old version. Otherwise, we consider the version ready to deploy and we change the production alias to be the latest version.Can something like this be implemented in Zappa? Given the native zappa commands for deploys, rollbacks etc it seems easy at first but if it's using custom logic to implement what AWS natively offers, it might be trickier than I initially thought.