在Google App Engine上持续集成/部署/交付是否太冒险了？

Question

我们最近在Google App Engine上设置了Node.js Web应用程序的持续集成/部署/交付。CI服务器（GitLabCI）根据分支（开发/母版）运行依赖项安装，构建，测试和部署到集成/产品。在今天，我们所面对的唯一错误是在依赖步骤中，因此我们对此并不在意。但是昨天（16/10/16），发生了大规模的DNS中断，并且在部署步骤的中间，管道失败了，从而导致了产品故障。只需重新运行管道就可以完成工作，但是问题可以随时重现。我的问题是：在持续部署过程中，我们如何处理此类网络问题？在Google App Engine上进行持续部署真的是一个好主意吗？如果是，那么App Engine部署方法是什么？我找不到任何相关的文档...目前，我们只有两个版本“ dev”和“ prod”在提交后进行了更新，但是在随机时间，我可以观察到奇怪的行为。任何回应/建议/反馈都非常欢迎！关于我正在谈论的网络问题的stacktrace示例：DEBUG: Error sending result: 'MetadataServerException(HTTPError(),)'. Reason: 'PicklingError("Can't pickle <type 'cStringIO.StringO'>: attribute lookup cStringIO.StringO failed",)'Traceback (most recent call last):  File "/google-cloud-sdk/lib/googlecloudsdk/calliope/cli.py", line 733, in Execute    resources = args.calliope_command.Run(cli=self, args=args)  File "/google-cloud-sdk/lib/googlecloudsdk/calliope/backend.py", line 1630, in Run    resources = command_instance.Run(args)  File "/google-cloud-sdk/lib/surface/app/deploy.py", line 53, in Run    return deploy_util.RunDeploy(self, args)  File "/google-cloud-sdk/lib/googlecloudsdk/command_lib/app/deploy_util.py", line 387, in RunDeploy    all_services)  File "/google-cloud-sdk/lib/googlecloudsdk/command_lib/app/deploy_util.py", line 247, in Deploy    manifest = _UploadFiles(service, code_bucket_ref)  File "/google-cloud-sdk/lib/googlecloudsdk/command_lib/app/deploy_util.py", line 115, in _UploadFiles    service, code_bucket_ref)  File "/google-cloud-sdk/lib/googlecloudsdk/api_lib/app/deploy_app_command_util.py", line 277, in CopyFilesToCodeBucketNoGsUtil    _UploadFiles(files_to_upload, bucket_ref)  File "/google-cloud-sdk/lib/googlecloudsdk/api_lib/app/deploy_app_command_util.py", line 219, in _UploadFiles    results = pool.map(_UploadFile, tasks)  File "/usr/lib/python2.7/multiprocessing/pool.py", line 251, in map    return self.map_async(func, iterable, chunksize).get()  File "/usr/lib/python2.7/multiprocessing/pool.py", line 558, in get    raise self._value

Answer 1

好坏？主观的-因此对SO来说是题外话。假设问题是如何使连续部署可靠：)

好吧，问题在于您正在使用应用程序版本作为CI环境，这意味着您无法避免由于特定版本不良而造成的损坏。您只能希望通过重新部署版本（中断结束时）来尽快恢复-这可以自动进行。

您不应让生产站点直接在CI production管道覆盖的版本上运行，否则会因部署不当而冒着站点中断的风险。相反，你可以使用一个新的/唯一版本的CI的每个执行production管线并且只有完成之后成功你最终使用流量如下所述切换网站流量到它的版本（也可以在CI管线内使用，如果使用不同的应用程序，而不是CI 版本的应用程序版本）

从部署程序开始：

默认情况下，deploy命令每次使用时都会自动生成一个新的版本ID，并将所有流量路由到该新版本。

要覆盖此行为，可以使用version标志指定版本ID：

gcloud app deploy --version myID

您也可以使用--no-promote标志指定不立即将所有流量发送到新版本：

gcloud app deploy --no-promote

因此，请确保不要部署一个版本，并且不要在同一步骤中将该版本设置为默认的流量目标（如果从客户端驱动，则可能不是原子的）。特别是对于生产应用程序。代替：

部署新版本（gcloud app deploy --no-promote --version ...）

启动新版本（gcloud app versions ...）并检查其是否有效

如果工作正常，则将实际流量切换到（gcloud app services set-traffic ...）

这样，唯一关键的操作是流量切换，（有希望）这是成功的原子操作，或者它已完全退回到GAE端（如果不是，则是GAE错误）。如果此步骤失败，则该应用仍应继续使用旧版本。

当然，这假设网络问题仅在您和GAE之间，如果它们也影响GAE的内部运营，那么所有的赌注都没有了（但是我相信应该及时解决）。