Итак, я разместил приложение angular на s3 с облачным диском. Я делаю обновление файла (используя grunt filerev), чтобы убедиться, что я никогда не получаю устаревшее содержимое. Но как я должен изменить файл index.html. Его необходимо, потому что все другие файлы ссылаются на index.html.
Я сконфигурировал свой ковш для использования в качестве статического сайта. Поэтому он просто подбирает index.html, когда я ссылаюсь на ведро в URL-адресе.
Cloudfront говорит, что вы должны установить min TTL равным 0, поэтому он всегда будет удалять исходный код, чтобы обслуживать контент. Но мне это не нужно, поскольку я выполняю проверку файлов всех моих файлов (кроме index.html). Я могу использовать кэширование cdn для этих файлов.
Они также говорят, что для того, чтобы сделать недействительным один объект, установите максимальные заголовки в 0. Я попытался добавить следующее к моему index.html
<meta http-equiv="Cache-Control" content="public, must-revalidate, proxy-revalidate, max-age=0"/>
Но это не отражается после загрузки на s3. Нужно ли явно указывать заголовки на s3 с помощью s3cmd или панели мониторинга? И нужно ли это делать каждый раз, когда index.html изменяется, и я его загружаю?
Мне известно, что я могу сделать недействительным один файл, используя cmd, но его повторяющийся процесс. Было бы здорово, если бы он мог позаботиться о себе, просто развернув на s3.
Хотя принятый ответ правильный, если вы используете s3cmd, я использовал AWS CLI, поэтому я сделал следующие две команды:
Во-первых, для фактического развертывания кода:
aws s3 sync ./ s3://bucket-name-here/ --delete
Затем, чтобы создать недействительность на CloudFront:
aws cloudfront create-invalidation --distribution-id <distribution-id> --paths /index.html
Отвечая на мой вопрос. Я развертываю свой сайт на S3 с помощью s3cmd tool, и есть опция, которую вы могли бы предоставить, чтобы недействить кэш CloudFront всех измененных файлов (diff между вашей папкой dist и ведро S3). Это делает недействительным кеш всех файлов, включая индексный файл. Обычно это занимает около 15-20 минут, чтобы отразить новые изменения в производстве.
Вот команда
s3cmd sync --acl-public --reduced-redundancy --delete-removed --cf-invalidate [your-distribution-folder]/* s3://[your-s3-bucket]
Примечание. В macOS вы можете установить этот инструмент с помощью: brew install s3cmd.
Надеюсь, что это поможет.
Вы можете автоматизировать процесс с помощью Lambda. Он позволяет вам создать функцию, которая будет выполнять определенные действия (недействительность объекта в вашем случае) в ответ на определенные события (новый файл на S3).
Дополнительная информация здесь: https://aws.amazon.com/documentation/lambda/
Если вы используете s3cmd sync и используете опцию --cf-invalidate, возможно, вам придется указать --cf-invalidate-default-index в зависимости от вашей установки.
На странице man:
При использовании статического веб-сайта Custom Origin и S3 аннулируйте индексный файл по умолчанию.
Это обеспечит также недействительность вашего индексного документа, скорее всего index.html, который в противном случае будет пропущен независимо от того, обновляется или нет через синхронизацию.
При синхронизации локального каталога с s3 вы можете сделать это:
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
Первая команда - это просто обычная синхронизация, вторая команда разрешает S3 возвращать управление кешем для всех файлов, кроме index.html и robots.txt.
Затем ваш SPA может быть полностью кэширован (кроме index.html).
Реальный вопрос заключается в том, почему вы должны делать все это, чтобы сделать что-то настолько простое, что большинство других провайдеров/решений используют графический интерфейс пользователя и простую точку и щелчок. Именно поэтому я предпочитаю не использовать S3, если мой клиент не требует этого. Garbage.