如何在 Google App Engine 上设置暂存环境

Posted 2023-02-19

【中文标题】如何在 Google App Engine 上设置暂存环境

【英文标题】：How to set up a staging environment on Google App Engine

【发布时间】：2011-04-17 04:04:54

【问题描述】：

在正确配置了 Development 服务器和 Production 服务器后，我想在 Google App Engine 上设置一个 Staging 环境，以用于在将新开发版本部署到生产环境之前对其进行实时测试。

我知道两种不同的方法：

A.第一个选项是修改app.yaml version参数。

version: app-staging

我不喜欢这种方法的是生产数据被我的暂存测试污染了，因为（如果我错了，请纠正我）：

暂存版本和生产版本共享同一个数据存储 暂存版本和生产版本共享相同的日志

_{关于第一点，不知道能不能用新的namespaces python API“修复”。}

B.第二个选项是通过修改app.yaml application参数

application: foonamestaging

使用这种方法，我将创建完全独立于生产版本的第二个应用程序。 我看到的唯一缺点是我不得不配置第二个应用程序（管理员设置）。 使用像 Gaebar 这样的备份/恢复工具，这个解决方案也很有效。

您使用哪种方法为您的 Web 应用程序设置暂存环境？ 另外，您是否有任何自动化脚本可以在部署之前更改 yaml？

【问题讨论】：

@bdolan 你有什么参考吗？

@bdonlan, IANAL，但我不认为@system 的使用可以解释为“旨在避免产生费用”或“模拟或充当单个应用程序”。 @systempuntoout，我的“登台”实际上是从 SDK 完成的（我不希望登台向整个世界开放），但是您的方法似乎也不错（如果您对“向世界开放”没有问题" 部分;-)。

日志已经按版本分开，所以没有“污染”。使用命名空间来避免破坏生产数据听起来是个好主意。当然，除非您的暂存版本中的错误与您的命名空间被严重破坏有关。

@systempuntoout 我希望我能不止一次地支持你的问题。没有它，我永远不会想到使用命名空间来暂存数据。谢谢！

为暂存/开发环境使用多个应用程序很好，这是大多数用户最终采用的解决方案，因为使用多个版本进行测试时存在隔离问题。

【参考方案1】：

如果需要单独的数据存储，选项 B 对我来说看起来更干净，因为：

您可以保留版本功能以对生产应用程序进行实际版本控制。 您可以保留版本功能以进行流量拆分。 您可以为多租户保留命名空间功能。 您可以轻松地将实体从一个应用程序复制到另一个应用程序。命名空间之间不是那么容易。 仍有少数 API 不支持命名空间。 对于有多个开发人员的团队，您可以为一个人授予上传到生产的权限。

【讨论】：

+1 表示 6。例如我为可以部署到开发人员的个人凭据保存身份验证，每次都必须输入真实帐户和密码。

我也使用选项 B。但是，在尝试开始使用推送部署时，我发现很难使用这种方法，因为我需要为每个环境保留一个 app.yaml（在推送之前- 部署，我只是有一个脚本，在部署之前更改了应用程序参数，然后将其设置回来），或者使用不同的分支，每个分支都有（可能冲突的）app.yamls

由于应用程序标签已从 app.yaml 中删除，是否有更新此问题的答案？

【参考方案2】：

我在设置中选择了第二个选项，因为它是最快的解决方案，而且我还没有编写任何脚本来更改部署时的应用程序参数。

但在我现在看来，选项 A 是一个更清洁的解决方案。您可以使用几行代码根据版本切换数据存储命名空间，您可以从环境变量 CURRENT_VERSION_ID 动态获取，如下所述：http://code.google.com/appengine/docs/python/runtime.html#The_Environment

【讨论】：

我也选择了问题中的第二个选项，但我在单独的命名空间可用之前就开始了。

@systempuntoout 我认为这是可能的：“批量加载程序支持 --namespace=NAMESPACE 标志，允许您指定要使用的命名空间。每个命名空间都是单独处理的，如果您想访问所有命名空间，您将需要遍历它们。”来自code.google.com/appengine/docs/python/multitenancy/…

@Franck 听起来很有趣，所以选项 A 似乎可行且干净

命名空间 API 的其他用途：Creating Separate Datastore Instances for Testing and Production

唯一的问题是如果你想从“staging”转移到“production”，你必须重新部署你的应用程序，因为它们使用不同的命名空间。当然，您也必须使用单独的应用程序来做到这一点。

【参考方案3】：

我们选择了选项 B。我认为总体而言它更好，因为它完全隔离了项目。因此，例如在临时服务器上玩一些配置不会影响也不会损害安全性或导致生产环境中的任何其他蝴蝶效应。

至于部署脚本，您可以在 app.yaml 中使用任何您想要的应用程序名称。一些虚拟/开发名称，在部署时，只需使用 -A 参数：

appcfg.py -A your-app-name update .

这将大大简化您的部署脚本，无需在您的 app.yaml 中进行字符串替换或任何类似的操作

【参考方案4】：

我们使用选项 B。

除了 Zygmantas 关于在应用程序级别将 dev 与 prod 分离的好处的建议外，我们还使用我们的 dev 应用程序来测试性能。

通常情况下，开发实例在没有太多可用资源的情况下运行，这有助于了解应用程序“感觉”缓慢的地方。然后，我们还可以独立调整性能设置，看看有什么不同（例如前端实例类）。

当然，有时我们需要硬着头皮调整并观看直播。但是很高兴有其他应用程序可以玩。

仍然使用命名空间和版本，只是 dev 是肮脏和实验性的。

【参考方案5】：

无需创建单独的项目。您可以使用 dispatch.yaml 将您的暂存 URL 路由到同一项目中的另一个服务（暂存）。

创建自定义域 staging.yourdomain.com

创建一个单独的 app-staging.yaml，用于指定暂存服务。

... 服务：分期 ...

创建包含类似内容的 distpatch.yaml

...

网址：“*staging.mydomain.com/” 服务：登台

网址：“*mydomain.com/” 服务：默认 ...

gloud app deploy app-staging.yaml dispatch.yaml

【讨论】：

虽然从技术上讲这可能是一种解决方案，但 Google 文档不建议这样做

【参考方案6】：

这是 Google 文档所说的：

一般建议是每个应用程序有一个项目 环境。例如，如果您有两个应用程序，“app1”和 “app2”，每个都有一个开发和生产环境，你会 有四个项目：app1-dev、app1-prod、app2-dev、app2-prod。这 将环境彼此隔离，因此更改 开发项目不会意外影响生产，并提供 你更好的访问控制，因为你可以（例如）授予所有 开发人员访问开发项目但限制生产 访问您的 CI/CD 管道

考虑到这一点，在根目录中添加一个dispatch.yaml 文件，并在代表单个服务并包含该服务的每个目录或存储库中，添加一个app.yaml 文件以及相关的源代码，如解释的那样这里：Structuring web services in App Engine

编辑，如果您使用的是 python，请查看 python 部分中的等效链接。

【参考方案7】：

已停止在 app.yaml 中使用 application。

相反，Google 推荐 gcloud app deploy --project [YOUR_PROJECT_ID]

请看https://cloud.google.com/appengine/docs/standard/python/config/appref