1

When I push a new site, I update the Origin ID to point at a new version, per screenshot:

enter image description here

This in turn triggers the Status change from Deployed to In progress on the main CF Distributions console. My understanding is that this does NOT trigger actual invalidation of the edge caches. Does this mean, I have to wait for the status to change again to Deployed before I can trigger the invalidation? If so, that's a terrible dependency for any automated deployment to manage. I suppose it has to keep checking until the deployment status shows done then trigger invalidation.

In a nutshell, why is updating the CF's Origin Path so painfully slow?

If there is a better way to deploy a new site that has the index page in S3/CF, I'm all ears :)

Slawomir
  • 177
  • 1
  • 8

1 Answers1

2

Use asset versioning.

V1 of your site will refer to /v1/js/app.js, /v1/img/logo.png, etc.

When you push a new version it will refer to /v2/js/app.js, /v2/img/logo.png, etc.

That way clients that still need to refer to v1 assets due to some cached content on their side can do so and won't be disrupted by the invalidation. New visitors will get all-v2 content and will not be confused by any v1 stuff laying around.

Eventually a day later you can remove and invalidate v1, but that won't be a time-sensitive task.

Of course you don't have to use v1, v2, etc, use git hash if you prefer or date or something else.

Update: As @Michael-sqlbot pointed out in the comments the root object returned for "GET /" is a special case as it won't benefit from this path-based versioning. There you've got a couple of options:

  1. Set a short expiration time, say 5 minutes for the root object. That way it will auto-expire shortly after you upload the new website version.

  2. Alternatively upload the new version and invalidate that /index.html - it will be much faster and cheaper than invalidating potentially thousands of file assets.

In both cases there will be a short overlap between uploading V2 and expiring V1's /index.html from all CloudFronts but it doesn't matter because all the V1 assets are still available. Regardless if your visitors receive V1 or V2 index.html in that period they will still get a functional website.

Hope that helps :)

MLu
  • 24,849
  • 5
  • 59
  • 86
  • This is valid but it doesn't address the fact that the object returned for `GET /` isn't a candidate for path-based asset versioning, and still needs to be invalidated. – Michael - sqlbot Aug 13 '19 at 00:22
  • @Michael-sqlbot true but that’s invalidating a single object, not thousands potentially. Possible workaround is to have a short expiration for the ‘/‘ object, say 5 minutes, so it will auto expire soon after pushing out the new site. – MLu Aug 13 '19 at 00:29
  • @mlu I'm already doing versioned assets. The problem is that the index page (GET /) needs to be refreshed since it in turn points at the versioned-asset files. My specific beef is with this: "why is updating the CF's Origin Path so painfully slow?" I consider it a bug of CF since changing the origin path should have no delay, it's not like it's invaliding the edges. – Slawomir Aug 13 '19 at 03:03
  • @Slawomir it’s slow because it has to talk to 187 CloudFront locations around the world (as of today) and confirm with each one that the change has been made before returning a success to you. However you shouldn’t need to remove the previous version when uploading a new one. Keep both sets of assets in place and let it roll over at its own pace, e.g. through setting an expiration header on the root object as detailed above. – MLu Aug 13 '19 at 03:11
  • @mlu I'm not removing anything. I think you're missing the point. The invalidation can take its time I understand the need for reaching out to all the edges. The lag in the change of the origin-path is the problem. Once the origin-path is marked as finished (minutes later) then the invalidation is triggered with a "/*". That second part is justified to take time, not the first part. – Slawomir Aug 13 '19 at 03:41
  • @Slawomir why do you even change the origin path? Don’t. Add your *new* assets under /v2, replace the html files in place, let them auto-expire from CF and reload from origin, done. This works for me. – MLu Aug 13 '19 at 03:45
  • @mlu because the root "index.html" page (GET /) needs to change from v1 to v2 and so on. All the other asset files that the root object refers to already have the versions in their names. But the root object is a generic "index.html" placed under a /index.html S3 key. The origin-path needs to point at it so the rest of the versioned assets will get served. Deploying a new root object under a different S3 key is poorly handled by the CF process. – Slawomir Aug 13 '19 at 03:55
  • @Slawomir simply overwrite `/index.html` (without version). Old one will refer to assets with relative path `v1/*`, new one will refer to assets `v2/*`. For some time after v2 upload the visitors may still get old v1 index.html but that’s ok because the v1 assets are still there. – MLu Aug 13 '19 at 03:59
  • @mlu I agree with the last suggestion. – Slawomir Aug 13 '19 at 14:25