Ошибка кэширования при развертывании AWS Cloudfront S3 - PullRequest
Новая
       45

Ошибка кэширования при развертывании AWS Cloudfront S3

0 голосов
/ 02 декабря 2018

Я пытаюсь обслуживать сайт создания-реакции-приложения на AWS Cloudfront после развертывания на S3.

index.html все еще пытается получить старый файл main.xxxxx.js после развертывания на S3.Для кэширования сайта в браузере используется файл service-worker.js по умолчанию.

Если вы перезагрузите браузер, приложение загружается правильно.

Может возникнуть конфликт между кэшем service-worker.js икэш облачного фронта.серверный работник не получает вновь загруженный файл main.xxx.js, а вместо него старый, а в облачном фронте - новый файл main.xxxxx.js после того, как мы аннулируем существующие файлы

Повторное создание: 

npm run build.

aws s3 sync ./build s3://$S3_BUCKET/frontend --delete --acl 'public-read'

aws cloudfront create-invalidation --distribution-id $CLOUDFRONT_ID --paths '/*'

aws s3 cp ./build/service-worker.js s3://$S3_BUCKET/frontend/service-worker.js --cache-control max-age=0

В облачном фронте задано использование заголовков исходного кэша (будут использоваться заголовки файлового кэша)

Ожидаемое поведение: после нового развертывания с указанными шагами при попытке доступа к приложению с первой попытки это должно получитьновый файл main.xxxx.js и загрузить обновленное содержимое

Ответы [ 2 ]

0 голосов
/ 03 декабря 2018

Из вашего вопроса не совсем ясно, связана ли проблема с кешем CloudFront или кешем браузера.Вы пишете, что при перезагрузке страницы приложение загружается правильно, поэтому я подозреваю, что кеш объекта, а не CloudFront.

В любом случае, create-реагировать-приложение создает артефакты, которые легко кэшировать.Любой файл в статической папке может иметь долгосрочную настройку кэша, поскольку он имеет уникальные имена, то есть имя файла изменяется при изменении содержимого.

Однако файлы в корневой папке сборки не имеют уникальных имен, например, индекс.html не изменяется между сборками (то же самое для файла рабочего сервиса).

Мы делаем следующее:

  1. Синхронизируем статическую папку с длинными максимальнымиуправление кэшированием возраста

    aws s3 синхронная сборка / статическое / s3: // $ S3_BUCKET / статическое / --cache-control "max-age = 604800"

  2. Синхронизация корневой папки с коротким управлением кэшем

    aws s3 sync build / static / s3: // $ S3_BUCKET / static / --cache-control "max-age = 600"

  3. (Необязательно) сделать недействительными корневые ресурсы

    aws cloudfront create-invalidation --distribution-id $ DIST_ID --paths /index.html /service-worker.js /asset-manifest.json

Чтобы это работало, вы должны настроить CloudFront на использование настроек исходного кэша, а также убедиться, что минимальный TTL равенess или равно настройкам кэша индекса / манифеста.

Подробнее о настройках кэша источника и настройках кэша CF см. здесь https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

0 голосов
/ 02 декабря 2018

Это происходит потому, что эти вещи также были кэшированы в CDN CloudFront. Пожалуйста, попробуйте сделать их недействительными. Выполните следующие действия: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

после этого подождите некоторое время, и вы увидите, что оно запускаетсячитая новые файлы, пожалуйста, позвольте мне, если есть какие-либо проблемы при этом.Спасибо

...