部署之间的Google Frontend Retention [英] Google Frontend Retention between deployments

问题描述

部署期间是否对静态资产的保留策略行为进行了任何定义?

Is there any definition of the retention policy behaviour for static assets during deployments?

换句话说，如果我正在运行v1并部署v2，是否可以确保v1的资产可用于整个app deploy命令?我对定义多个服务的地方特别感兴趣.

In other words if I'm running v1 and deploying v2, are v1's assets assured to be available for the entirety of an app deploy command? I'm particularly interested where multiple services are defined.

我看过这些文章，但对行为没有太多了解；

I've looked at these articles and they don't provide much insight into the behaviour;

https://cloud.google .com/appengine/docs/standard/python/getting-started/serving-static-files

https://cloud.google.com /appengine/docs/standard/python/how-instances-are-managed

https://cloud .google.com/appengine/docs/standard/python/getting-started/hosting-a-static-website

更具体地说，我有一个包含3个服务的项目；

To be more specific I have a project with 3 services;

• assets.yaml-服务:资产，提供静态图像，css，js等，并充当无cookie的域.
• site.yaml-服务:默认情况下，为宣传站点"提供静态html.
• app.yaml-服务应用，go应用提供/healthz，/readyz和/a/*.
• dispatch.yaml-用于路由说明.

# dispatch.yaml

# prod assets
- url: "a.example.net/*"
  service: assets

# local development assets
- url: "*/css/*"
  service: assets

# local development assets
- url: "*/js/*"
  service: assets

# local development assets
- url: "*/media/*"
  service: assets

- url: "*/a/*"
   service: app

- url: "*/healthz"
  service: app

- url: "*/readyz"
  service: app

鉴于v1具有资产css/bootstrap-4b2.min.css，而v2具有资产css/bootstrap-4b3.min.css.

Given v1 has the asset css/bootstrap-4b2.min.css and v2 has css/bootstrap-4b3.min.css.

当我使用以下命令部署v2且v1是当前正在运行的版本时；

When I deploy v2 and v1 is the current running version with the command below;

gcloud app deploy --project=$PROJECT dispatch.yaml assets.yaml default.yaml app.yaml --quiet --version $VERSION

我期望App Engine有什么行为?

What behaviour can I expect from App Engine?

1. 在项目部署期间，两个静态文件都将可用.
2. 在服务部署期间，两个静态文件都将可用.
3. 这两个静态文件将无限期可用.
4. 还有其他/取决于吗?

推荐答案

首先，在应用程序级别没有部署，每个服务都独立于彼此部署.您只需通过在相同的CLI调用中同时(几乎)部署所有服务来模拟应用程序级部署，但是从技术上讲，它们仍然是独立部署的.

To start with, there is no deployment at the app level, each service is deployed independently from each-other. You just emulate an app-level deployment by deploying all the services (almost) at the same time, in the same CLI invocation, but technically they're still deployed independently.

静态文件的可用性由发布它们的服务版本的生存期决定.因此，只要部署了asset服务的v1和v2版本，css/bootstrap-4b2.min.css和css/bootstrap-4b3.min.css都可能可用.但是有一个转折点:它取决于服务的版本接收到请求-只有服务于文件特定版本的服务版本才应该/将服务于该文件版本.否则，服务的行为将无法确定-如果该版本不提供文件，您将在本地服务器上始终收到404，但在GAE上，您将得到404或文件，具体取决于该版本为该文件提供服务仍处于部署状态，这将是一个错误.

The availability of the static files is dictated by the lifetime of the service version publishing them. So as long as both v1 and v2 versions of the asset service are deployed, both css/bootstrap-4b2.min.css and css/bootstrap-4b3.min.css will be potentially available. But with a twist: it depends on which version of the service receives the request - only the service version serving a particular version of the file should/will serve that file version. Otherwise the behaviour of the service would not be deterministic - you'd always get a 404 on the local server if that version doesn't serve the file, but on GAE you'd get either a 404 or the file, depending if the version serving that file is still deployed, which would be a bug.

确定服务的哪个版本接收请求取决于URL路由规则(请参见

Deciding which version of a service receives the request depends on the URL routing rules (see How Requests are Routed - this is where the dispatch.yaml content comes into play) and on the traffic distribution configuration for that service (see Migrating Traffic and Splitting Traffic).

例如，假设asset版本v1被配置为接收该服务的所有流量.在这种情况下:

For example, let's assume that asset version v1 is configured to receive all the traffic for the service. In such case:

• 对https://your_app.appspot.com/css/bootstrap-4b2.min.css的请求应该有效，v1通过dispatch.yaml规则获取请求
• 对https://your_app.appspot.com/css/bootstrap-4b3.min.css的请求应返回404，v1通过dispatch.yaml规则获取请求
• 对https://v1-dot-assets-dot-your_app.appspot.com/css/bootstrap-4b2.min.css的请求应该有效，v1通过软路由获取请求
• 对https://v1-dot-assets-dot-your_app.appspot.com/css/bootstrap-4b3.min.css的请求应返回404，v1通过软路由获取该请求
• 对https://v2-dot-assets-dot-your_app.appspot.com/css/bootstrap-4b2.min.css的请求应返回404，v2通过软路由获取该请求
• 对https://v2-dot-assets-dot-your_app.appspot.com/css/bootstrap-4b3.min.css的请求应该有效，v2通过软路由获取请求

• a request to https://your_app.appspot.com/css/bootstrap-4b2.min.css should work, v1 gets the request via dispatch.yaml rule
• a request to https://your_app.appspot.com/css/bootstrap-4b3.min.css should return 404, v1 gets the request via dispatch.yaml rule
• a request to https://v1-dot-assets-dot-your_app.appspot.com/css/bootstrap-4b2.min.css should work, v1 gets the request via soft routing
• a request to https://v1-dot-assets-dot-your_app.appspot.com/css/bootstrap-4b3.min.css should return 404, v1 gets the request via soft routing
• a request to https://v2-dot-assets-dot-your_app.appspot.com/css/bootstrap-4b2.min.css should return 404, v2 gets the request via soft routing
• a request to https://v2-dot-assets-dot-your_app.appspot.com/css/bootstrap-4b3.min.css should work, v2 gets the request via soft routing

如果配置版本之间的流量拆分，则上面列出的第一种2种情况下的结果可以颠倒，具体取决于请求属于哪种拆分百分比.但这通常不会有问题，因为通常会从动态页面引用静态资产，并且GAE会尝试将流量保持在同一百分位之内.

If you configure traffic splitting between versions, the results in the 1st 2 cases listed above can be reversed, depending in which percentile of the split the request falls into. But that should normally not be a problem, since usually the static assets are referenced from dynamic pages and GAE attempts to keep flows within the same percentile.

最后，以上所有内容均未考虑缓存问题(各个级别).但这只会在您修改文件内容时保留相同的文件名(即URL)的情况下对您产生影响，而在此问题中并非如此.

Finally, all the above doesn't take into account caching issues (at various levels). But those only affect you if you modify file contents while keeping the same filenames (i.e.URLs), which is not the case in this question.

这篇关于部署之间的Google Frontend Retention的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！