Wdrożenia niebiesko-zielone z CloudFront

Szukam sposobu na wdrożenie niebieski / zielony z CloudFront .

Czy ktoś ma dobre rozwiązanie, aby przejść z jednej dystrybucji CloudFront do drugiej, czy też wszyscy tak naprawdę tworzą swoją dystrybucję i nigdy więcej jej nie dotykają?

Moja dystrybucja CloudFront składa się z jednego źródła S3 dla treści statycznej (javascript itp.) I niestandardowego źródła wskazującego na ELB AWS.

Brak zmian w CloudFront

W normalnych okolicznościach nie wprowadzamy żadnych zmian w naszej dystrybucji CloudFront. Wersję naszej zawartości statycznej tworzymy w źródle S3, zmieniając nazwy plików zawartości statycznej w S3 i wykonujemy cykliczne wdrożenia do instancji EC2 w ramach Elastic Load Balancer (ELB). Są jednak chwile, kiedy musimy przetestować i wprowadzić zmiany w samej dystrybucji CloudFront lub wprowadzić na tyle istotne zmiany w naszym środowisku, że musimy wskazać nowy ELB w nowym środowisku.

Dwie dystrybucje CloudFront

Pierwszą opcją, którą próbowałem, było utworzenie dwóch oddzielnych dystrybucji internetowych CloudFront , jednej dla mojego obecnego środowiska A lub jednej dla mojego nowego środowiska B. Próbowałem użyć zasady routingu ważonej Route53 , w której dodałem dwa rekordy dla mojego rekordu Route53 www.domain.com, jeden wskazuje na CloudFront Distribution A o wadze 1, a drugi wskazuje na CloudFront Distribution B o wadze 0. The planuję zmienić wagi, gdy chcę przejść z dystrybucji A do dystrybucji B. Jednak tylko jedna dystrybucja CloudFront może mieć jednocześnie zarejestrowaną alternatywną nazwę domeny www.domain.com (CNAME) lub pojawi się następujący błąd:

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

Jedna dystrybucja CloudFront

Drugą opcją jest utrzymanie jednej dystrybucji internetowej CloudFront. Mam S3 i niestandardowe źródła wskazujące zarówno na moje środowiska A, jak i B, a następnie aktualizuję zachowanie pamięci podręcznej CloudFront, aby wskazywało na inne źródło, gdy chcę przejść z jednego środowiska do drugiego. Jest to bardzo nieuporządkowane, ponieważ te aktualizacje trwają 15-60 minut, nie ma wglądu w postęp aktualizacji, a w zależności od charakteru zmiany konieczne może być kontynuowanie jej za pomocą Inwalidacji CloudFront, aby nie wyświetlać zawartości pamięci podręcznej ze starego środowiska wraz z nową zawartością.

Dzięki za radę!

Dwie dystrybucje Cloudfront

Ponieważ AWS pozwala na nakładanie się symboli zastępczych CNAME z użyciem symboli zastępczych na tym samym koncie AWS, możesz przełączać się między dwiema dystrybucjami w chmurze w następujący sposób:

• Użyj www.domain.com jako alternatywnej CNAME dla dystrybucji Prod. 1
• Użyj * .domain.com jako alternatywnej CNAME dla dystrybucji Prod 2
• Wskaż DNS CNAME www.domain.com na dystrybucję 1 lub dystrybucję 2. (* .cloudfront.net).
• Usuń alternatywną CNAME z dystrybucji, z której nie chcesz już wyświetlać treści.

Jednak dwa różne DNS-y dystrybucji (* .cloudfront.net) mogą wskazywać na te same węzły brzegowe, co oznacza, że ​​sposób, w jaki twoja treść jest obsługiwana, polega na dopasowaniu CNAME cloudfront.net do obsługujących go węzłów Edge, a następnie dopasowaniu przez nazwa hosta. W takim przypadku, jeśli obie dystrybucje używają tych samych węzłów krawędzi (można to sprawdzić na przykład za pomocą dig), cięcie nie będzie czyste.

np. jeśli obie dystrybucje mają jeden lub więcej węzłów brzegowych, dystrybucja 1 z Alt CNAME www.domain.com będzie miała pierwszeństwo przed dystrybucją 2 z bardziej ogólną * .domain.com, dopóki CNAME nie zostanie usunięty z konfiguracji dystrybucji 1 we wszystkich węzłach brzegowych . Tak więc wersja pobrana z jednego żądania może różnić się od drugiego w okresie przejściowym.

Trochę późno w grze tutaj, ale dla każdego, kto tego szuka. Wierzę, że można to zrobić za pomocą lambda @ edge. Podobne do testów A / B. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . Możesz zaimplementować funkcję lambda wyzwalaną, gdy użytkownik zażąda adresu URL. Wybierz wyświetlanie niebieskiej / zielonej treści z różnych źródeł lub prefiksu adresu URL. Wartość pliku cookie określa, które wdrożenie będzie obsługiwane. Gdy nadejdzie pierwsze żądanie (bez pliku cookie), ustaw plik cookie losowo: 95% niebieski 5% zielony.

Strzelając z biodra, ile czasu zajmuje zmiana źródła w rozkładzie z przodu chmur? 1) wdrożyć nowy kod za ELB, rozgrzać go 2) dodać ten ELB jako nowe źródło do przedniej dystrybucji chmury, jednocześnie usuwając stare źródło 3) po przejściu na nowy, oderwać stary kod za starym ELB.

Aby uniknąć opóźnień związanych z aktualizacjami CloudFront lub aktualizacjami DNS, możesz zamienić grupę automatycznego skalowania za ELB. 1) wdrożyć nowy kod w nowym ASG, rozgrzać go 2) zarejestrować istniejący ELB za pomocą tego nowego ASG 3) wyrejestrować stary ASG ze swojego ELB 4) po przejściu na nowy, oderwać stary ASG.

Robiłem również badania nad tym tematem i obejrzałem (patrz poniżej).

Tło:

CloudFront wymaga, aby CNAME w konfiguracji dystrybucji był unikalny na całym koncie. Tak więc kontrolowanie niebieskiego / zielonego za pośrednictwem DNS do różnych dystrybucji nie będzie działać. Krąży wokół nas włamanie, w którym używa się symboli wieloznacznych, ale nie daje to gwarancji, że prawidłowe pliki są obsługiwane. Kontrolowanie niebieskiego / zielonego za pomocą DNS i CloudFront jest niemożliwe.

Ponadto zmiana dowolnej konfiguracji w CloudFront (w tym CNAME) powoduje 15-60 minut oczekiwania na wprowadzenie zmian do serwerów brzegowych. Również nie jest to idealna konfiguracja.

Obejdź:

W przypadku aplikacji na jednej stronie ta konfiguracja może rozwiązać ten problem:

• Adres URL aplikacji: app.mydomain.com/app
• Struktura S3:
  • app / (twoja strona na żywo)
  • app2 / (Twoja nie tak aktywna strona)

Teraz skonfiguruj CloudFront, aby używał wiadra do obsługi plików. W tym momencie wszystko sprowadza się do ustawień pamięci podręcznej. Ponieważ CloudFront trwa wiecznie, ustaw nagłówek CacheControl na naszych obiektach S3. W przypadku index.html używamy 5 minut, a wszystko inne, 1 dzień. Kiedy przychodzi czas na zmianę, zamień nazwy katalogów S3. W ciągu 5 minut aplikacja będzie dostępna dla wszystkich celów i celów.

W przypadku aplikacji, które są już uruchomione, mamy wersję kompilacji wbudowaną w kod i plik json konfiguracji kompilacji w katalogu głównym aplikacji. Następnie aplikacja od czasu do czasu zażąda pliku json, sprawdź wersję, jeśli jest nieaktualna, poproś o odświeżenie.

Ograniczenia

Nie można bardzo dobrze wykonywać testów nasiąkania. Podejrzewam, że możliwe jest zwiększenie TTL index.html do kilku godzin lub dni (w zależności od potrzeb), co pomogłoby upewnić się, że klienci otrzymają nowe wersje po wygaśnięciu lokalnej pamięci podręcznej.

W tym wpisie na blogu autor wdraża testowanie ab przez Lambda @ Edge działające na podstawie kodu w dokumentacji AWS (ich przykłady można zobaczyć tutaj: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- przykłady.html ).

Zasadniczo tworzysz pojedynczą dystrybucję Cloudfront wskazującą na dwa różne źródła. Następnie możesz użyć Lambda @ Edge, aby skierować ruch do dowolnego źródła (za pomocą plików cookie), i oczywiście możesz implementować inne rzeczy za pośrednictwem Lambda, takie jak ważenie ruchu lub odwracanie go itp. Łatwo jest również dodawać dalsze źródła i logikę .