Rozmieszczanie w usłudze Amazon S3 Cloudfront Najlepsze praktyki

Nasz obecny plan witryny to korzystanie z usługi Cloudfront Amazon jako CDN dla plików zasobów, takich jak CSS, JavaScript i obrazy oraz innych plików statycznych.Rozmieszczanie w usłudze Amazon S3 Cloudfront Najlepsze praktyki

Obecnie mamy 1 wiadro w S3, które zawiera wszystkie te pliki statyczne. Pliki są podzielone na różne foldery w zależności od tego, czym są, "Skrypty" to pliki JS, "Obrazy" to Obrazy itp. Yadda yadda yadda.

Nie zdawałem sobie sprawy z tego, że po wdrożeniu segmentu z S3 do dystrybucji Cloudfront, każda kolejna aktualizacja do tego zasobnika nie zostanie ponownie wdrożona w tej samej dystrybucji. Wygląda na to, że musisz ponownie wdrożyć wiadro do innej instancji Cloudfront za każdym razem, gdy masz statyczną aktualizację pliku.

Jest to dobre dla obrazów, ponieważ możemy z łatwością upewnić się, że w przypadku zmiany obrazu, po prostu tworzymy nowy obraz. Ale trudno to zrobić dla CSS i JS.

Tak, że dostaje mi Dobrych Praktyk pytania:

Czy to najlepszym rozwiązaniem jest stworzenie innej dystrybucji CloudFront dla każdego wdrożenia produkcyjnego? Problem polega na tym, że powoduje problemy z rekordami CNAME.
Czy najlepszą praktyką jest NIE magazynowanie CSS i JS w Cloudfront ze względu na charakter tych plików i ich łatwą modyfikację? Wygląda na to, że odpowiedź brzmi NIE, ponieważ taki jest cel CDN.
Czy jest jakaś inna metoda z Cloudfront, o której nie wiem?

Źródło

2011-07-14 Mike Richards

Witam, czy możesz mi powiedzieć, w jaki sposób wdrożyłeś swoje css do CDN? Jak wysłałeś pliki css, js do swojego CDN? Czy używasz capistrano? – tcgumus

skorzystaj z cloudflare, to nic nie kosztuje: D – rocketspacer

Możesz składać wnioski o unieważnienie do CloudFront.

http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

Zamiast łyżką S3, choć używamy nasz własny serwer jako niestandardowego pochodzenia. Mamy .htaccess alias style_*.css do , a my wprowadzamy czas modyfikacji pliku dla style.css w kodzie HTML. Ponieważ CloudFront widzi zupełnie inny adres URL, pobierze nową wersję.

(Uwaga: Niektóre CDN niech to zrobić poprzez ciąg kwerendy, ale CloudFront ignoruje wszystkie dane ciąg kwerendy do buforowania, stąd rozwiązanie .htaccess.)

edit: CloudFront może być (opcjonalnie) skonfigurowany do korzystania ciągi zapytań teraz.

Źródło

2011-07-14 17:48:08 ceejayoz

Obie są dobrymi rozwiązaniami, ale myślę, że twoja druga jest idealna. Przed CDN dodaliśmy "? V = 2.0.x" (bez względu na numer wersji) do wszystkich adresów URL zasobów dla pomijania pamięci podręcznej, ale jeśli zmienimy to na "stylesheet-v2.0.x.css" z CloudFront za pomocą naszego serwer jako pochodzenie, myślę, że będzie działać świetnie. Dzięki! –

Cieszę się, że mogę pomóc! Zostaliśmy ugryzieni przez CF, upuszczając ciągi zapytań kilka razy, zanim się zmęczyliśmy. :-) – ceejayoz

Unieważnienie ma ograniczenia co do liczby plików, które mogą być przetwarzane jednocześnie i może być wolne, więc drugie rozwiązanie jest zdecydowanie lepsze. –

CloudFront zaczął obsługiwać ciągi zapytań, których można użyć do unieważnienia pamięci podręcznej. http://aws.typepad.com/aws/2012/05/amazon-cloudfront-support-for-dynamic-content.html

Źródło

2012-06-05 05:20:26

jak, dokładnie używasz tego, aby unieważnić pamięć podręczną dla konkretnego pliku?Być może jest to w tym miejscu, ale nie jest to zbyt jasne. – gMale

Po aktywowaniu łańcuchów zapytań chmura w chmurze zachodzi w zasobie dla każdej kombinacji parametrów. więc możesz dołączyć wersję. img.jpg? version = 1 i? version = 2 po więcej szczegółów zajrzyj do instrukcji http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html – Dukeatcoding

Rozmieszczanie w usłudze Amazon S3 Cloudfront Najlepsze praktyki

Odpowiedz

Powiązane problemy