Wie wird der Cache von index.html für eine statische Site ungültig, die auf S3 mit Cloudfront gehostet wird?

Question

So habe ich meine eckige App auf s3 mit einer Cloudfront dist gehostet. Ich revisioniere Dateien (mit grunt filerev), um sicherzustellen, dass ich nie veraltete Inhalte bekomme. Aber wie sollte ich die Datei index.html versionieren? Dies ist erforderlich, da alle anderen Dateien in index.html referenziert werden.

Ich habe meinen Bucket so konfiguriert, dass er als statische Site verwendet werden kann. Also greift es einfach auf die index.html zu, wenn ich auf den Bucket in der URL referenziere.

Cloudfront sagt, dass Sie min TTL auf 0 setzen sollten, also würde es immer Ursprung treffen, um den Inhalt zu liefern. Aber ich brauche das nicht, da ich alle meine Dateien revisioniere (außer index.html). Ich kann cdn Caching für diese Dateien nutzen.

Sie sagen auch, dass, um ein einzelnes Objekt zu entkräften, die max-age-Header auf 0 gesetzt ich versuchte, indem folgend meinen index.html

<meta http-equiv="Cache-Control" content="public, must-revalidate, proxy-revalidate, max-age=0"/> 

Aber das entspricht nicht einmal Sie laden auf s3. Muss ich Header mit s3cmd oder dem Dashboard explizit auf s3 setzen? Und muss ich das jedes Mal tun, wenn sich index.html ändert und ich es hochlade?

Ich bin mir bewusst, dass ich eine einzelne Datei mit cmd ungültig machen könnte, aber es ist ein sich wiederholender Prozess und es wäre toll, wenn es sich selbst kümmern kann, nur durch die Bereitstellung auf s3.

Answer 1

meine eigene Frage zu beantworten. Ich stelle meine Site unter Verwendung von s3cmd tool auf S3 und es gibt eine Option, die Sie bereitstellen könnten, um den CloudFront-Cache aller geänderten Dateien ungültig zu machen (Unterschied zwischen Ihrem dist-Ordner und S3-Bucket). Dadurch wird der Cache aller geänderten Dateien einschließlich der Indexdatei ungültig. In der Regel dauert es etwa 15-20 Minuten, um die neuen Produktionsänderungen zu berücksichtigen.

Hier ist der Befehl

s3cmd sync --acl-public --reduced-redundancy --delete-removed --cf-invalidate [your-distribution-folder]/* s3://[your-s3-bucket] 

^{Hinweis: brew install s3cmd: Auf macOS, können Sie dieses Tool über installieren können.}

Hoffe, das hilft.

Answer 2

Sie können einen Prozess mit Lambda automatisieren. Es ermöglicht Ihnen, eine Funktion zu erstellen, die bestimmte Aktionen ausführt (in Ihrem Fall eine Invalidierung des Objekts) als Reaktion auf bestimmte Ereignisse (neue Datei in S3).

Weitere Informationen hier: https://aws.amazon.com/documentation/lambda/

Answer 3

Obwohl die akzeptierte Antwort richtig ist, wenn Sie s3cmd verwenden, war ich die AWS CLI verwenden, so, was ich tat, war, die folgenden zwei Befehle aus:

Zunächst tatsächlich einsetzen Sie den Code ein:

aws s3 sync ./ s3://bucket-name-here/ --delete

Dann eine Ungültigkeits auf Cloudfront zu erstellen:

aws cloudfront create-invalidation --distribution-id <distribution-id> --paths /index.html

Answer 4

Wenn Sie s3cmd sync verwenden und die Option --cf-invalidate verwenden, müssen Sie abhängig von Ihrer Konfiguration möglicherweise auch --cf-invalidate-default-index angeben.

Aus der Manpage: wenn aktualisiert oder nicht durch die Sync-

When using Custom Origin and S3 static website, invalidate the default index file.

Dadurch wird sichergestellt, auch Ihren Index Dokument, höchstwahrscheinlich index.html, die sonst übersprungen werden, unabhängig werden ungültig.

Answer 5

Wenn Sie lokales Verzeichnis mit s3 synchronisieren, können Sie dies tun:

aws s3 sync ./dist/ s3://your-bucket --delete 

aws s3 cp \ 
    s3://your-bucket s3://your-bucket \ 
    --exclude 'index.html' --exclude 'robots.txt' \ 
    --cache-control 'max-age=604800' \ 
    --metadata-directive REPLACE --acl public-read \ 
    --recursive 

Der erste Befehl ist nur eine normale Synchronisation, der zweite Befehl S3 ermöglichen zurückzukehren Cache-Control für alle Dateien außer index.html und robots.txt.

Dann kann Ihr SPA vollständig zwischengespeichert werden (außer index.html).