本文介绍了如何安全地部署 AppSync 中的 Lambda 数据源，重点讨论了针对 Java 和 Python 开发的安全策略，以及在大数据和数据库环境下的最佳实践。
appsync软件源
In this post we will walk through the options of running safe deployments of AppSync datasources backed by Lambda functions. This is particularly useful if you are running AppSync in production with substantial real user traffic.
在本文中，我们将逐步介绍运行由Lambda函数支持的AppSync数据源的安全部署的选项。 如果您正在生产中运行AppSync且实际用户流量很高，则此功能特别有用。
部署类型 (Deployment types)
There are different options on how to deploy the function code to the environment:
关于如何将功能代码部署到环境中，有不同的选择：
All at once: all traffic is redirected to the latest version of the function as soon as the stack is deployed
一次全部：部署堆栈后，所有流量都会重定向到该功能的最新版本
Canary: small portion of the traffic is diverted to a new version of the function for a period of time and if no issues — all traffic is redirected to a new version
金丝雀：在一段时间内，只有一小部分流量被转移到该功能的新版本，如果没有问题，所有流量将被重定向到新版本
Linear: traffic is incrementally shifted from an old version of the function to a new version over a period of time
线性：一段时间内流量从功能的旧版本逐渐转移到新版本
Blue/Green type can also be added into the mix, however it is more applicable in the context of deploying a new side-by-side standby environment (new CFN stack) and then shifting traffic to it, rather than deploying a new version of a single component within an existing stack.
也可以将Blue / Green类型添加到组合中，但是它更适用于部署新的并排备用环境(新的CFN堆栈)，然后将流量转移到该环境中，而不是部署新的现有堆栈中的单个组件。
Within the scope of single function, Blue/Green can be implemented by adding PostTraffic hook to an “all-at-once” deployment type.
在单一功能的范围内，可以通过将PostTraffic挂钩添加到“一次性”部署类型来实现Blue / Green。
Each of the methods above has its own place, for example if the function is deployed to a development environment with no real user traffic, “all-at-once” option will be the best choice, however for a production deployments with real user traffic, it’s important to ensure that failed deployments can roll-back quickly and in an automated way with minimum impact on user experience.
上面的每种方法都有自己的位置，例如，如果将功能部署到没有实际用户流量的开发环境中，则“一次全部”选项将是最佳选择，但是对于具有实际用户流量的生产部署而言，因此必须确保失败的部署能够以自动方式快速回滚，并且对用户体验的影响最小。
配置安全部署 (Configuring Safe Deployments)
Gradual deployments can be easily integrated into an existing stack if you are already using AWS SAM in your CI/CD for deployments.
如果您已经在CI / CD中使用AWS SAM进行部署，则可以轻松地将逐步部署集成到现有堆栈中。
Let’s walk through the deployment of an existing project and then simulate a function code change, to see how gradual deployment will work in dev vs production environments.
让我们遍历现有项目的部署，然后模拟功能代码的更改，以了解逐步部署在开发环境与生产环境中如何工作。
The code for the walk-through is located in the github repo.
演练的代码位于github repo中。
First we need to package the main stack, this will upload all nested stack templates and code artifacts to an S3 bucket and will replace local filesystem references with corresponding S3 locations:
首先，我们需要打包主堆栈，这会将所有嵌套的堆栈模板和代码工件上传到S3存储桶，并将本地文件系统引用替换为相应的S3位置：
aws cloudformation package --template-file template.yaml --s3-bucket appsync-gradual-deployment-bucket --output-template-file template-updated.yamlNow using updated template we can deploy main stack to the environment:
现在，使用更新的模板，我们可以将主堆栈部署到环境中：
aws cloudformation deploy --template-file template-updated.yaml --stack-name appsync-gradual-deployment-stack --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPANDExecuting getVersion query from AppSync console, we get the response from an initial version of the deployment:
从AppSync控制台执行getVersion查询，我们从部署的初始版本获得响应：
“一次全部”交通转移 (“All At Once” Traffic Shift)
Let’s update version to 2.0 and deploy without changing the Environment parameter in the master stack template.yaml file, which is set to dev by default:
让我们将版本更新为2.0并进行部署，而不更改主堆栈template.yaml文件中的Environment参数，该文件默认情况下设置为dev ：
100% of the traffic is redirected to a new version of the function as soon as the nested stack finished the deployment:
嵌套堆栈完成部署后，将100％的流量重定向到该功能的新版本：
线性交通转移 (Linear Traffic Shift)
Now let’s bump up the version again, but this time we will override Environment to prod to simulate production deployment.
现在，让我们再次碰到了版本，但这次我们将覆盖Environment ，以prod ，模拟生产部署。
Our serverless function in a SAM template is configured with Linear10PercentEvery1Minute deployment preference for production environment, so we should see a different behavior where traffic shifts in increments of 10% every minute over 10 minutes:
我们的SAM模板中的无服务器功能已针对生产环境配置了Linear10PercentEvery1Minute部署首选项，因此我们应该看到一种不同的行为，其中流量在10分钟内每分钟以10％的增量递增：
aws cloudformation deploy --template-file template-updated.yaml --stack-name appsync-gradual-deployment-stack --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND --parameter-overrides "Environment=prod"When DeploymentPreference is defined on a function in a SAM template, CloudFormation creates additional resources: CodeDeploy Application, CodeDeploy Deployment Group and required IAM role as below:
在SAM模板中的函数上定义DeploymentPreference ，CloudFormation将创建其他资源：CodeDeploy应用程序，CodeDeploy部署组和所需的IAM角色，如下所示：
Now, heading to CodeDeploy Deployments, you will see that the production deployment is in progress and querying API will return the response from both versions of the function until linear traffic shift is fully completed.
现在，转到CodeDeploy部署，您将看到生产部署正在进行中，查询API将返回该函数的两个版本的响应，直到完全完成线性流量转移为止。
部署失败(Deployment Failure)
Let’s simulate a scenario when new deployment has issues.
让我们模拟一个新部署存在问题的场景。
If CloudWatch alarm defined in the template goes into “ALARM” state, CodeDeploy should redirect all traffic to an old version and report a failure to CloudFormation to roll back the changes:
如果模板中定义的CloudWatch警报进入“ ALARM”状态，则CodeDeploy应该将所有流量重定向到旧版本，并向CloudFormation报告失败以回滚更改：
After packaging and deploying, go to AppSync console and try to query API until you get failed response at least 5 times — this should trigger a CloudWatch alarm and initiate an automated deployment roll-back:
打包和部署后，请转到AppSync控制台并尝试查询API，直到响应失败至少5次–这将触发CloudWatch警报并启动自动部署回滚：
陷阱 (Gotchas)
It’s worth to mention that having traffic to your API is necessary if you are planning to use gradual deployments to catch the issues and trigger the roll-back.
值得一提的是，如果您打算使用渐进式部署来捕获问题并触发回滚，则必须对API进行通信。
On a system with low volume of user traffic you may opt into using longer deployment windows to increase the chance of catching the errors during a deployment and also increase CloudWatch alarm sensitivity to go off early by lowering the alarm threshold.
在用户流量较低的系统上，您可以选择使用更长的部署窗口，以增加在部署过程中捕获错误的机会，还可以通过降低警报阈值来提高CloudWatch警报的敏感性，以便尽早解决。
Another option may be to use CloudWatch Synthetics to ensure a steady traffic to your AppSync API (be aware that CloudWatch Synthetics Canaries are not cheap, ~$50USD per 1-minute frequency canary per month) or PostTraffic hook Lambda (integration test is limited to Lambda maximum runtime of 15 minutes, so ensure that your deployment preference allows to hit a new version of back-end frequently enough to identify the issue within 15 minutes).
另一个选择可能是使用CloudWatch Synthetics来确保向您的AppSync API稳定的流量(请注意，CloudWatch Synthetics Canaries并不便宜，每月每1分钟频率Canary约50美元)或PostTraffic挂钩Lambda(集成测试仅限于Lambda的最长运行时间为15分钟，因此请确保您的部署首选项允许足够频繁地命中后端的新版本，以在15分钟内发现问题。
启用了缓存的AppSync (AppSync with Caching Enabled)
On an AppSync with caching enabled, it’s important to understand that for gradual deployment to catch the issues, AppSync needs to hit a new version of the backend all the time instead of using a cached response.
在启用了缓存的AppSync上，重要的是要了解，为了逐步部署以解决问题，AppSync需要始终使用新版本的后端，而不是使用缓存的响应。
To achieve this you can use PreTraffic hook to change AppSync cache TTL to 1 second before the deployment and PostTraffic hook to change TTL back to a desired value after the deployment is completed.
为此，您可以使用PreTraffic挂钩在部署之前将AppSync缓存TTL更改为1秒，并使用PostTraffic挂钩在部署完成后将TTL重新更改为所需的值。
结论 (Conclusion)
It doesn’t take much effort to add gradual deployments for AppSync Lambda datasources into your existing CI/CD process and it can save you a lot of trouble of hunting down failed deployments and rolling back changes manually.
将AppSync Lambda数据源的逐步部署添加到您现有的CI / CD流程中并不需要花费很多精力，它可以为您节省大量查找失败的部署并手动回滚更改的麻烦。
Thumbs up if you liked the post and stay tuned for more serverless articles!
如果您喜欢该帖子，请竖起大拇指，并继续关注更多无服务器文章！
appsync软件源
1048
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
