Изменение путей миграции CDN

Question

Я пытаюсь перенести CDN из rackspace в aws.

В первом, все отображается в отдельные контейнеры через CNAME записей так:

container1 = CNAME = container1.cdndomain 
container2 = CNAME = container2.cdndomain 
container3 = CNAME = container3.cdndomain 

Когда мы создали АМС, все, я прочитал, сказал, чтобы настроить один (только) CloudFront, с различными ковшами. Вот что я сделал.

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

Я бы предпочел не пропустить тысячи строк кода и конфигурационных файлов и изменить все текущие URL-адреса (например, вручную изменить container1.cdndomain на cdndomain/container1).

Но я не могу найти способ переназначить

this: http://bgimgs.cdndomain/image 

Чтобы это AWS на основе партнерства

here: http://cdndomain/bucket/image 

Мы используем Zerigo для DNS и интерфейс будет принимать этот путь CNAME:

container.domain = CNAME = cdndomain/bucket 

, но aws не направляет это на правильный ковш.

Я попробовал .htaccess Раствора

RewriteEngine On 
RewriteCond %{HTTP_HOST} ^container1\.cdndomain(.*)$ [NC] 
RewriteRule ^(.*)$ http:\/\/cdndomain/container1/$1 [L,R=301] 

Но это не работает, либо.

Любые идеи?

Answer 1

Я не знаю, откуда пришел совет, чтобы использовать только одно распространение CloudFront с несколькими ведрами S3. Конечно, вы можете, но если это не соответствует вашим потребностям, нет причин, почему вы должны.

Просто создайте несколько распределений.

Если вы уже обращаетесь к ним с разными именами хостов, они представляют собой разные коллекции объектов, я не могу думать о какой-либо причине, такой совет будет применим в вашем случае. Единственная причина, по которой вам стоит подумать, что вы бы использовали только один дистрибутив CloudFront с несколькими ведрами, состояла бы в том, чтобы хранить весь контент (из разных ведер) за одним именем хоста или за несколькими именами хостов с теми же путями, используемыми для каждого имени хоста (взломать браузеры быстрее загружать ресурсы - это убедить браузер, что все активы идут с разных хостов, поэтому браузер будет открывать больше параллельных подключений).

В вашем случае это не похоже на то, что вам нужно вообще. Распределения сами по себе свободны. Задача решена.

Что касается DNS, другой поставщик может принять эту конфигурацию, но это не значит, что это действует конфигурации. Это не так. Вы не можете изменять пути с помощью DNS.

Относительно .htaccess, S3 не обрабатывает .htaccess. Если вы создавали их на своем веб-сервере, это тоже было бы нехорошо, так как веб-сервер не видел запросы, чтобы перенаправить их.