Когда я нажимаю новый сайт, я обновляю Origin ID, чтобы он указывал на новую версию, как показано на скриншоте:
Это, в свою очередь, вызывает изменение статуса с Развернутый к В ходе выполнения на главной консоли CF Distributions. Я так понимаю, что это НЕ инициировать фактическое аннулирование краевых кешей. Означает ли это, что мне нужно дождаться, пока статус снова не изменится на Развернутый прежде чем я смогу вызвать аннулирование? Если так, то это ужасная зависимость для любого автоматического развертывания. Я полагаю, он должен продолжать проверку, пока статус развертывания не покажет завершение, а затем вызовет недействительность.
Вкратце, зачем обновлять CF Путь происхождения так мучительно медленно?
Если есть лучший способ развернуть новый сайт с индексной страницей в S3 / CF, я все слышу :)
Использовать управление версиями активов.
V1 вашего сайта будет ссылаться на /v1/js/app.js, /v1/img/logo.png, и т.д.
Когда вы нажимаете новую версию, она будет ссылаться на /v2/js/app.js, /v2/img/logo.png, и т.д.
Таким образом, клиенты, которым еще нужно обратиться к v1 активы из-за некоторого кэшированного содержимого на их стороне могут это сделать, и аннулирование не будет нарушено. Новые посетители получат все-v2 контент и вас не смутит никакие v1 вещи валяются.
В конце концов, через день вы можете удалить и аннулировать v1, но это не будет срочной задачей.
Конечно, вам не обязательно использовать v1, v2 и т. Д., Используйте git hash, если хотите, дату или что-то еще.
Обновить: Как отметил @ Michael-sqlbot в комментариях, корневой объект возвращаемый для "GET /" является особым случаем, поскольку он не выиграет от управления версиями на основе пути. У вас есть несколько вариантов:
Установите короткий срок действия, скажем, 5 минут для корневого объекта. Таким образом, он автоматически истечет вскоре после того, как вы загрузите новую версию веб-сайта.
Или загрузите новую версию и аннулируйте ее /index.html
- это будет намного быстрее и дешевле, чем обесценивание потенциально тысяч файловых ресурсов.
В обоих случаях будет небольшое перекрытие между загрузкой V2 и истекающей V1. /index.html
со всех CloudFronts, кроме это не имеет значения потому что все активы V1 по-прежнему доступны. Независимо от того, получат ли ваши посетители в этот период файл index.html версии 1 или 2, они все равно получат работоспособный веб-сайт.
Надеюсь, это поможет :)