Jak ustawić domyślny obiekt główny dla podkatalogów w witrynie hostowanej statycznie w Cloudfront? W szczególności chciałbym www.example.com/subdir/index.html
być obsługiwany za każdym razem, gdy poprosi o to użytkownik www.example.com/subdir
. Uwaga: służy to dostarczaniu statycznej witryny internetowej przechowywanej w zasobniku S3. Ponadto chciałbym użyć tożsamości dostępu pochodzenia, aby ograniczyć dostęp do zasobnika S3 tylko do Cloudfront.
Teraz zdaję sobie sprawę, że Cloudfront działa inaczej niż S3 i stany amazon w szczególności :
Zachowanie domyślnych obiektów głównych CloudFront różni się od zachowania dokumentów indeksowych Amazon S3. Po skonfigurowaniu zasobnika Amazon S3 jako witryny internetowej i określeniu dokumentu indeksu Amazon S3 zwraca dokument indeksu, nawet jeśli użytkownik zażąda podkatalogu w zasobniku. (Kopia dokumentu indeksu musi znajdować się w każdym podkatalogu). Aby uzyskać więcej informacji na temat konfigurowania zasobników Amazon S3 jako witryn internetowych i dokumentów indeksowych, zobacz rozdział Hostowanie witryn internetowych na Amazon S3 w podręczniku programisty Amazon Simple Storage Service.
W związku z tym, mimo że Cloudfront pozwala nam określić domyślny obiekt główny, działa to tylko dla, www.example.com
a nie dla www.example.com/subdir
. Aby obejść tę trudność, możemy zmienić nazwę domeny pochodzenia tak, aby wskazywała punkt końcowy witryny internetowej podany przez S3. Działa to świetnie i umożliwia jednolite określanie obiektów głównych. Niestety wydaje się, że nie jest to zgodne z tożsamościami dostępu pochodzenia . W szczególności powyższe linki stanowią:
Zmień na tryb edycji:
Dystrybucje internetowe - kliknij kartę Początki, kliknij źródło, które chcesz edytować, i kliknij Edytuj. Możesz utworzyć tożsamość dostępu do źródła tylko dla źródeł, dla których Typ pochodzenia to S3 Origin.
Zasadniczo, aby ustawić prawidłowy domyślny obiekt główny, używamy punktu końcowego witryny S3, a nie samego zasobnika witryny. Nie jest to zgodne z używaniem tożsamości dostępu pochodzenia. Jako takie, moje pytania sprowadzają się do jednego z nich
Czy można określić domyślny obiekt główny dla wszystkich podkatalogów dla witryny hostowanej statycznie w Cloudfront?
Czy można skonfigurować tożsamość dostępu pochodzenia dla treści udostępnianej z Cloudfront, gdzie źródłem jest punkt końcowy witryny S3, a nie zasobnik S3?
Odpowiedzi:
AKTUALIZACJA: Wygląda na to, że się pomyliłem! Zobacz odpowiedź JBaczuka, która powinna być akceptowaną odpowiedzią w tym wątku.
Niestety, odpowiedź na oba pytania brzmi: nie.
1. Czy można określić domyślny obiekt główny dla wszystkich podkatalogów w witrynie hostowanej statycznie w Cloudfront?
Nie. Jak stwierdzono w dokumentacji AWS CloudFront ...
2. Czy można skonfigurować tożsamość dostępu pochodzenia dla treści udostępnianej z Cloudfront, gdzie źródłem jest punkt końcowy witryny S3, a nie zasobnik S3?
Nie bezpośrednio. Twoje opcje początkowe w CloudFront to zasobniki S3 lub własny serwer.
Jednak to ta druga opcja otwiera kilka interesujących możliwości. To prawdopodobnie podważa cel tego, co próbujesz zrobić, ale możesz skonfigurować własny serwer, którego jedynym zadaniem jest być serwerem pochodzenia CloudFront.
Gdy nadejdzie żądanie dotyczące http://d111111abcdef8.cloudfront.net/install/ , CloudFront przekaże to żądanie do Twojego serwera pochodzenia, prosząc o
/install
. Możesz dowolnie konfigurować serwer pochodzenia, w tym do obsługiindex.html
w tym przypadku.Możesz też napisać małą aplikację internetową, która po prostu odbiera to połączenie i i tak pobiera je bezpośrednio z S3.
Ale zdaję sobie sprawę, że skonfigurowanie własnego serwera i martwienie się o jego skalowanie może zniweczyć cel tego, co próbujesz zrobić.
źródło
Istnieje JEST sposób to zrobić. Zamiast kierować go do swojego zasobnika, wybierając go z listy rozwijanej (www.example.com.s3.amazonaws.com), wskaż statyczną domenę swojego zasobnika (np. Www.example.com.s3-website-us -west-2.amazonaws.com):
Dzięki wątku z tego forum AWS
źródło
HTTPS
?Aktywacja hostingu S3 oznacza, że musisz otworzyć wiadro na świat. W moim przypadku musiałem zachować prywatność zasobnika i użyć funkcji tożsamości pochodzenia, aby ograniczyć dostęp tylko do Cloudfront. Jak zasugerował @Juissi, funkcja Lambda może naprawić przekierowania:
Po opublikowaniu funkcji przejdź do dystrybucji w chmurze w konsoli AWS. Idź do
Behaviors
, następnie wybierzOrigin Request
poniżejLambda Function Associations
i na koniec wklej ARN do nowej funkcji.źródło
Jest jeszcze jeden sposób na pobranie domyślnego pliku udostępnianego w podkatalogu, na przykład
example.com/subdir/
. Możesz faktycznie (programowo) przechowywać plik z kluczemsubdir/
w wiadrze. Ten plik nie pojawi się w konsoli zarządzania S3, ale faktycznie istnieje i CloudFront go obsłuży.źródło
Obejściem tego problemu jest użycie lambda @ edge do ponownego zapisywania żądań. Wystarczy ustawić lambdę dla zdarzenia żądania przeglądarki w dystrybucji CloudFront i przepisać wszystko, co kończy się na „/” i nie jest równe „/” z domyślnym dokumentem głównym, np. Index.html.
źródło
Istnieje "oficjalny" przewodnik opublikowany na blogu AWS, który zaleca skonfigurowanie funkcji Lambda @ Edge uruchamianej przez Twoją dystrybucję CloudFront:
Postępuj zgodnie z powyższym przewodnikiem, aby zobaczyć wszystkie kroki wymagane do skonfigurowania tego, w tym wiadro S3, dystrybucję CloudFront i tworzenie funkcji Lambda @ Edge .
źródło
Inną alternatywą dla używania lambda @ edge jest użycie stron błędów CloudFront. Skonfiguruj niestandardową odpowiedź na błąd, aby wysłać wszystkie 403 do określonego pliku. Następnie dodaj javascript do tego pliku, aby dołączyć index.html do adresów URL kończących się na /. Przykładowy kod:
źródło
Wiem, że to stare pytanie, ale sam się z tym zmagałem. Ostatecznie moim celem było mniej ustawienie domyślnego pliku w katalogu, a bardziej uzyskanie końcowego wyniku pliku, który był obsługiwany bez
.html
na końcuSkończyło się na usunięciu
.html
z nazwy pliku i programowo / ręcznie ustawiłem typ MIME natext/html
. Nie jest to tradycyjny sposób, ale wydaje się działać i spełnia moje wymagania dotyczące ładnych adresów URL, nie rezygnując z zalet cloudformation. Ustawienie typu mime jest denerwujące, ale moim zdaniem niewielka cena za korzyściźródło