Я действительно запутался в настройке, которая мне нужна для моего приложения angularjs2.
Это просто SPA-приложение с URL-адресами в режиме html5, и все, что мне нужно, это:
www.mydomain.com/blabla... будет перенаправлен на тот же mydomain, но без wwwmydomain.com/anything/including/path/like/this отдаст s3 (/ cloudfront) index.htmlmydomain.com/path/or/not/path/file_that_ends_with_any_extesnion_like.js будет обслуживать этот файл с s3 (/ cloudfront) если это слишком сложно, я также могу настроить свой веб-сайт, чтобы все объекты были в папке с ресурсами поэтому просит mydomain.com/assets/path/blabla.bla будет обслуживать статический файл из s3 (/ cloudfront)mydomain.com/api/... перенаправит на экземпляр ec2, который содержит мой сервер REST API node.jsОбычно я бы просто использовал 1 экземпляр ec2 с nginx и node.js, а nginx try_files и если это не удается, он дает index.html файл и если URL /api/.. он перенаправляет запрос на api, который находится на том же ec2
Проблема с этой настройкой заключается в том, что она плохо масштабируется и ее сложно поддерживать, если у вас более 1 экземпляра ec2.
Я много искал в Google, но не могу найти ни одного руководства или сообщения в блоге о том, как настроить что-то вроде того, что я описал в облаке AWS.
Заранее спасибо :)
запросы к www.mydomain.com/blabla ... будут перенаправлены на тот же mydomain, но без www
Это делается путем создания пустой корзины в S3 с именем www.example.com, настроив его для перенаправления всех запросов на другое имя хоста (example.com) и указав на него DNS.
Если вы хотите, чтобы он поддерживал перенаправление запросов https на стороне www, вы создаете второй дистрибутив CloudFront для имени хоста www, указывающий на конечную точку веб-сайта для корзины, и указываете DNS на CloudFront.
запросы к mydomain.com/anything/including/path/like/this предоставят s3 (/ cloudfront) index.html
Настроить example.com ведро (с вашим контентом, а не пустое, о котором говорилось выше) для статического хостинга веб-сайтов, и установите имя индексного документа на index.html в параметрах конфигурации хостинга статических веб-сайтов корзины. Как описано в документации S3, когда для сегмента включена функция хостинга веб-сайта S3, указанная страница индекса из соответствующего места в сегменте будет автоматически возвращаться S3 везде, где это возможно, в соответствии со следующими правилами:
Если запрошенный путь /foo/bar/ (с косой чертой в конце), то S3 ищет объект с ключом foo/bar/index.html и возвращает его, оставляя адресную строку браузера без изменений.
Если запрошенный путь /foo/bar (без косой черты) и foo/bar/index.html существует, то S3 возвращает перенаправление на /foo/bar/, что приводит к поведению, описанному выше, после конечного / появляется в адресной строке браузера. (Это перенаправление для добавления конечной косой черты - стандартное поведение веб-сервера; в противном случае относительные ссылки на странице индекса будут указывать на неправильный каталог).
Вместо того, чтобы выбирать сегмент из раскрывающегося списка в CloudFront, при настройке источника CloudFront необходимо ввести имя хоста конечной точки веб-сайта для сегмента. В противном случае функции веб-сайта, такие как индексные документы, не будут включены:
Важный
Не выбирайте название своей корзины из списка, например example.com.s3.amazonaws.com.
http://docs.aws.amazon.com/gettingstarted/latest/swh/getting-started-create-cfdist.html
Следующий выпуск:
запросы к mydomain.com/path/or/not/path/file_that_ends_with_any_extesnion_like.js будут обслуживать этот файл из s3 (/ cloudfront), если это слишком сложно, я также могу настроить свой веб-сайт, чтобы все объекты были в папке с ресурсами, поэтому запросы к mydomain.com/assets/path/blabla.bla будут обслуживать статический файл из s3 (/ cloudfront)
Вы можете настроить CloudFront на выбор «источника» (серверной системы), которому будет отправлен запрос, с использованием поведения кеша, каждое из которых соответствует шаблону пути. Похоже, в этом случае вы хотите, чтобы ваше поведение кеша по умолчанию указывало на корзину, которая будет отправлять туда все запросы, если не соответствует другому поведению кеша.
и, наконец, что не менее важно, запросы к mydomain.com/api / ... будут перенаправлены на экземпляр ec2, который содержит мой сервер REST API node.js
Предположительно, вы на самом деле не имеете в виду «перенаправление», но вместо этого имеете в виду «пересылку» или «прокси» (то же самое) запросы к экземпляру EC2.
Объявите экземпляр EC2 как другой источник в раздаче CloudFront для своего сайта. Создание нового поведения кеша, соответствующего шаблону пути /api/* который использует этот источник, и CloudFront отправит эти запросы в ваш экземпляр EC2.
Убедитесь, что ваш код на EC2 возвращает соответствующий Cache-Control: заголовки в ответах API, чтобы CloudFront кэшировал их на соответствующее время или не кэшировал вообще, если вы вернетесь Cache-Control: no-cache.
Обратите внимание, что в шаблонах пути поведения кеша отсутствие ведущей косой черты подразумевается, поэтому api/* эквивалентно /api/*.
Также обратите внимание, что CloudFront имеет параметр, называемый «исходный путь», атрибут источника, который иногда путают с «шаблоном пути», который является атрибутом поведения кеша. Оставьте поле «Путь к источнику» пустым, потому что оно не связано с путями, которые вы хотите отправить в конкретный источник.