Google App Engine обслуживает старые версии статических файлов - PullRequest
0 голосов
/ 01 июля 2018

У меня есть приложение для фляги, которое я развертываю в Google App Engine.

Я вносил изменения в сценарии js и css в этом приложении и развертывал обновленный репозиторий в gae. Однако, когда я перезагружаю URL *.appspot.com после развертывания, файлы js и css, загруженные в мой браузер, не являются последними версиями.

Я не уверен, как решить эту проблему. Я не знаю, является ли это проблемой кэширования в моем браузере, проблемой с моим файлом app.yaml или чем-то другим.

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

enter image description here

Вот мой app.yaml:

runtime: python27
api_version: 1
threadsafe: true

libraries:
- name: ssl
  version: 2.7.11

handlers:
- url: /.*
  script: app.app

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

Спасибо!

UDPATE:

Я добавил в свой файл app.yaml по предложению @GAEfan и ссылку на страницу @Dave W. Smith, так что теперь это выглядит следующим образом:

runtime: python27
api_version: 1
threadsafe: true

libraries:
- name: ssl
  version: 2.7.11

handlers:
- url: /.*
  script: app.app
- url: /static
  static_dir: static
  expiration: '10s'

Однако проблема сохраняется. Теперь я ожидаю, что это может иметь какое-то отношение к другому предложению @Dave W. Smith, что «старые экземпляры обслуживают запросы до тех пор, пока они не умрут».

Вот еще один скриншот с платформы GCP, показывающий, что запущено несколько экземпляров моего приложения, по одному от каждой новой команды развертывания:

Multiple versions/instances of my app running on google app engine

Последняя версия является версией по умолчанию, и на снимке экрана показано, что 100% распределения трафика приходится на эту версию. Должен ли я удалять старые версии приложения при каждом развертывании? Если это так, можно ли это сделать с помощью gcloud cli? Можно ли как-то сохранить эти старые версии и просто обеспечить, чтобы статические файлы были обязательно доставлены из последней версии?

Еще раз спасибо.

Ответы [ 3 ]

0 голосов
/ 01 июля 2018

Да, похоже на проблему с кешированием. Читать это: https://cloud.google.com/appengine/docs/standard/python/config/appref#static_cache_expiration

Вы можете проверить, установив небольшое время кэширования для ваших статических файлов, например:

- url: /static
  static_dir: static/
  expiration: '10s'

Или, еще более гранулированный:

- url: /static/css
  static_dir: static/css/
  expiration: '10s'

- url: /static/js
  static_dir: static/js/
  expiration: '5m'

Или глобально:

default_expiration: '2s'

Затем, когда вы будете удовлетворены вашими статическими файлами, установите время кэширования намного выше, чтобы ускорить работу вашего сайта и сэкономить время сервера.

0 голосов
/ 20 ноября 2018

Как указывает GAEfan , документы для стандартной среды Pyhton утверждают, что оба параметра срок действия статического кэша , отдельный элемент expiration и элемент верхнего уровня default_expiration, ответственны за определение «времени истечения [того], которое будет отправлено в заголовках ответа HTTP Cache-Control и Expires». Это означает, что «файлы, вероятно, будут кэшироваться браузером пользователя, а также промежуточными прокси-серверами, такими как интернет-провайдеры».

Проблема здесь в том, что «повторное развертывание новой версии приложения не сбрасывает все кэши». Поэтому, если установить default_expiration, например, на 15 дней, но внести изменения в файл CSS или JS и повторно развернуть приложение, нет гарантии, что эти файлы будут автоматически обслуживаться из-за активных кэшей, особенно из-за для промежуточного кэширования прокси-серверов, которые могут включать в себя серверы Google Cloud - что, по-видимому, имеет место, так как доступ к your-project-name.appspot.com также обслуживает устаревшие файлы.

В той же документации, ссылка на которую приведена выше, указано, что «если вы когда-либо планируете модифицировать статический файл, он должен иметь короткий (менее одного часа) срок действия. В большинстве случаев подходит 10-минутное время истечения по умолчанию». Это то, что нужно подумать о до того, как установит срок действия статического кэша. Но для тех, кто, как и я, не знал всего этого заранее и уже был пойман этой проблемой, я нашел решение.

Несмотря на то, что в документации указано, что очистить промежуточные прокси-серверы невозможно, можно удалить хотя бы кеш Google Cloud.

Чтобы сделать это , перейдите в Облачная консоль Google и откройте свой проект. В левом меню гамбургера перейдите в «Хранилище» -> «Браузер». Там вы должны найти хотя бы один Bucket: your-project-name.appspot.com. В столбце «Жизненный цикл» нажмите на ссылку с именем your-project-name.appspot.com. Удалите все существующие правила, поскольку они могут конфликтовать с тем, которое вы создадите сейчас.

Создайте новое правило, нажав кнопку «Добавить правило». Для условий объекта выберите only параметр 'Newer version' и установите для него значение 1. Не забудьте нажать кнопку "Continue". Для действия выберите «Удалить» и нажмите кнопку «Продолжить». Сохраните ваше новое правило.

Это новое правило вступит в силу до 24 часов, но по крайней мере для моего проекта это заняло всего несколько минут. После того, как он запущен и работает, версия файлов, обслуживаемых вашим приложением под your-project-name.appspot.com , всегда будет последней развернутой , что решит проблему. Кроме того, если вы регулярно редактируете свои статические файлы, вы должны удалить любой элемент expiration из обработчиков, связанных с этими статическими файлами, и элемент default_expiration из файла app.yaml, что поможет избежать непреднамеренного кэширования другими серверами.

0 голосов
/ 01 июля 2018

Если это ваш app.yaml, вы можете подумать , что у вас есть статические файлы, но они обслуживаются приложением. Чтобы сделать эту статичность действительно статичной, вам понадобится немного больше в нашем app.yaml. Смотри https://cloud.google.com/appengine/docs/standard/python/getting-started/serving-static-files

То, что вы, вероятно, видите, если только вы не повышаете версию для командной строки, это старые экземпляры, обслуживающие запросы до тех пор, пока они не прекратятся.

...