Подключение Google CDN к CDN не создает таких ключевых ошибок

Я загрузил изображения в ведро хранилища Google и не пытаюсь настроить работу CDN с помощью балансировщика нагрузки.

Состояние хранилища: права доступа к сегменту: средство просмотра объектов хранилища - средство чтения назначается всем пользователям, средство чтения сегмента устаревшего хранилища назначается всем пользователям

Статус файла: установлен общий доступ к общедоступной ссылке и есть общедоступная ссылка.

Балансировщик нагрузки: укажите путь / creatives / * в имени хоста.

но я всегда получаю это сообщение:

 <Error>
 <Code>NoSuchKey</Code>
 <Message>The specified key does not exist.</Message>
 </Error>

что я замечаю, так это то, что как только я создаю путь / creatives / *, появляется другой путь build / * прямо к серверной службе группы автоматического масштабирования

мне здесь не хватает каких-то настроек?


google-cloud-storage
person Meta_data    schedule 04.11.2017    source источник
comment
Эта ошибка не имеет ничего общего с разрешением. Эта ошибка возникает, когда URL-адрес объекта, к которому вы пытаетесь получить доступ, не соответствует ни одному URL-адресу объекта в ведре Google. Если у вас установлен gsutil, запустите ls или cat, чтобы отобразить содержимое объекта, например gsutil ls gs://objectUrl, и проверьте, присутствует ли объект в корзине или сейчас. В основном проблема связана с созданием неправильного URL-адреса объекта.   -  person Yogesh Patil    schedule 06.11.2017
comment
Спасибо, я сам написал ответ, поскольку он был скрыт в журналах, как вы упомянули. просто не совсем понял, что режим принудительного статического веб-сайта, который Google CDN предоставляет по умолчанию   -  person Meta_data    schedule 12.11.2017

Ответы (2)


arrow_upward
5
arrow_downward

Итак, я обнаружил, что Google CDN + Google http Load balancer работает не так, как другие CDN.

с обычным CDN вы можете направить источник на свой HTTP-адрес корзины и работать со структурой /. например: URL корзины Google CDN: googleapi.storage.com/my-bucket Структура папки: /1/1.jpg

Обычный источник CDN будет указывать на googleapi.storage.com/my-bucket, и вы получите новую конечную точку службы для CDN, например my-bucket.fastly.cdonservice.com, и этот вызов будет работать: my-bucket.fastly. cdonservice.com/1/1.jpg

но в облаке Google вы настраиваете путь, который подключен к службе CDN, которую вы создали в серверной части. Итак, в этом большая разница, допустим, вы создали это правило пути. host: www.googlecdnnonexplainedfeautres.com путь: / images / * service: yourbackendservice (подключен к корзине, которую вы хотите кэшировать)

так что вы можете предположить, что это должно работать: www.googlecdnnonexplainedfeautres.com/images/1/1.jpg.

но НЕТ ... после рытья журналов вы найдете 404 в ведре, потому что Google будет искать этот путь в ведре:

googleapi.storage.com/my-bucket/images/1/1.jpg.

подождите, откуда взялись изображения? я думал, что это крючок. Никакой Google не воспринимает это как статический корень веб-сайта (то, что вы можете включать и выключать на S3), поэтому здесь это обязательно.

так как это должно работать?

измените структуру папок, чтобы она была такой:

URL корзины Google CDN: googleapi.storage.com/my-bucket

Структура папки: images / 1 / 1.jpg

и теперь тебе хорошо.

Эта ссылка должна работать сейчас:

www.googlecdnnonexplainedfeautres.com/images/1/1.jpg.

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

ну и конечно .. разрешения, allUsers, чтение и т.д ..

Наслаждайтесь!

person Meta_data    schedule 12.11.2017
comment
Большое спасибо! Вы только что закончили пару часов NoSuchKey безумия - person dbramwell; 23.10.2020
comment
Спасибо, Meta_data - это действительно безумие, на то, чтобы понять, почему было потрачено ›1 час, @google действительно должен задокументировать это и выделить это! - person Shawn Cao; 30.01.2021
comment
Большое спасибо, Google действительно должен это задокументировать. - person cheekujha; 11.06.2021

arrow_upward
1
arrow_downward

Вы можете использовать перезапись URL для решения этой проблемы.

Возможно, этого не было еще в 2017 году, но вариант есть как минимум с 2021 года.

Объяснение:

По умолчанию lb передает весь путь после хоста в облачное хранилище. Это может показаться неправильным, но это разумное значение по умолчанию (как балансировщик нагрузки должен знать, какую часть пути вы хотите включить или исключить?).

Я столкнулся с той же проблемой.

Я подключил mydomain.com/static/* к своей корзине облачного хранилища static-assets.

После посещения mydomain.com/static/static-asset.jpg балансировщик нагрузки запросит облачное хранилище для объекта с ключом static-assets/**static**/static-asset.jpg.

Поскольку фактический ключ объекта - static-assets/static-asset.jpg, это вернет ответ NoSuchKey.

Исправление заключалось в переписывании префикса пути с /static на /.

Один из способов настроить это - через пользовательский интерфейс Cloud Console Load Balancer - мы можем добавить расширенное правило пути, чтобы переписать префикс.

Графический интерфейс облачной консоли с подробными сведениями о правиле пути

Пожалуйста, обрати внимание:

Важно: перезапись добавляется к пути как есть. Перезапись полного пути не поддерживается. Балансировка нагрузки HTTP (S) реализует только перезапись префикса пути. Например, вы можете переписать: host.name/path1/resource1 на host.name/path2/resource1. Вы не можете перезаписать host.name/path1/resource1 на host.name/path1/resource2.

Подробнее о перезаписи URL читайте здесь.

person Govind Rai    schedule 27.04.2021