CloudFront ile Mavi / Yeşil dağıtımlar

CloudFront ile Mavi / Yeşil dağıtımları yapmanın bir yolunu arıyorum .

Herkesin bir CloudFront dağıtımından diğerine geçmek için iyi bir çözümü var mı veya herkes sadece dağıtımlarını oluşturuyor ve bir daha asla ona dokunmuyor mu?

My CloudFront dağıtımı, statik içerik için bir S3 kaynağından (javascript, vb.) Ve bir AWS ELB'ye işaret eden özel bir kaynaktan oluşur.

CloudFront'da Değişiklik Yok

Normal şartlar altında CloudFront dağıtımımızda hiçbir değişiklik yapmayız. S3'teki statik içerik dosyalarının adını değiştirerek statik içeriğimizi S3 kökenine uyarlıyoruz ve Elastik Yük Dengeleyici (ELB) altındaki EC2 örneklerine yuvarlanan dağıtımlar yapıyoruz. Bununla birlikte, CloudFront dağıtımının kendisini test etmemiz ve değişiklikler yapmamız gerektiğinde veya çevremizde yeni bir ortamda yeni bir ELB'ye işaret etmemiz gereken yeterince önemli değişikliklere sahip olduğumuz zamanlar vardır.

İki CloudFront Dağılımı

Denediğim ilk seçenek , biri mevcut veya A, ortamım ve diğeri yeni veya B ortamım için olmak üzere iki ayrı CloudFront Web Dağıtımı'na sahip olmaktı . Www.domain.com Route53 kaydım için biri 1 ağırlığında CloudFront Dağıtım A'ya, diğeri 0 ağırlığında CloudFront Dağıtım B'ye işaret eden iki kayıt eklediğim bir Route53 ağırlıklı yönlendirme politikası kullanmaya çalıştım . planı, A dağıtımından B dağıtımına geçmek istediğimde ağırlıkları değiştirmek olacaktır. Ancak, aynı anda yalnızca bir CloudFront dağıtımında www.domain.com Alternatif Etki Alanı Adları (CNAME) kayıtlı olabilir veya aşağıdaki hatayı alabilirsiniz:

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)

Bir CloudFront Dağıtımı

İkinci seçenek, bir CloudFront web dağıtımını korumaktır. S3 ve hem A hem de B ortamlarımı gösteren özel kökenleri var ve sonra bir ortamdan diğerine taşımak istediğinizde diğer köken işaret etmek için CloudFront Önbellek Davranışı güncelleyin . Bu son derece dağınık çünkü bu güncellemeler 15-60 dakika sürüyor, güncellemenin ilerleyişi hakkında bir görünürlük yok ve değişikliğinizin doğasına bağlı olarak, bunu bir CloudFront Geçersiz Kılma ile takip etmeniz gerekebilir, böylece önbelleğe alınmış içerik sunmuyorsunuz yeni içerikle birlikte eski ortamdan.

Tavsiyeniz için teşekkürler!

İki Cloudfront Dağıtımı

AWS, aynı AWS hesabındaki joker karakter alternatif CNAME'leri çakışmasına izin verdiğinden, iki bulutsal dağıtım arasında aşağıdaki şekilde geçiş yapabilirsiniz:

• Prod dağıtımı için Alternatif CNAME olarak www.etkialani.com kullanın 1
• Ürün dağıtımı 2 için Alternatif CNAME olarak * .etkialanı.com'u kullanın
• CNAME DNS www.domain.com adresinizi dağıtım 1 veya dağıtım 2'ye yönlendirin. (* .Cloudfront.net).
• İçeriği sunmak istemediğiniz diğer CNAME dağıtımından kaldırın.

Bununla birlikte, iki farklı dağıtım DNS'si (* .cloudfront.net) aynı kenar düğümlerini gösterebilir, bu da içeriğinizin sunulma şeklinin cloudfront.net CNAME'i hizmet veren Edge düğümleriyle eşleştirmesi ve ardından eşleşmesi anlamına gelir. hostname. Bu durumda, her iki dağıtımınız da aynı kenar düğümlerini kullanıyorsa (örneğin ile kontrol edilebilir dig) kesim temiz olmayacaktır.

Örneğin, her iki dağıtım da bir veya daha fazla kenar düğümünü paylaşıyorsa, Alt CNAME www.domain.com ile dağıtım 1, CNAME tüm kenar düğümlerindeki dağıtım 1 yapılandırmasından kaldırılıncaya kadar daha genel * .domain.com ile dağıtım 2'den öncelikli olacaktır. . Dolayısıyla, bir istekten alınan sürüm, geçiş süresi boyunca diğerinden farklı olabilir.

Burada oyuna biraz geç, ama bunu arayan herkes için. Bunun lambda @ edge kullanılarak yapılabileceğine inanıyorum. A / B testlerine benzer. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . Bir kullanıcı URL istediğinde tetiklenen bir lambda işlevi uygulayabilirsiniz. Mavi / yeşil içeriği farklı kaynaklardan veya URL önekinden sunmayı seçin. Bir çerez değeri hangi dağıtımın sunulacağını belirler. İlk istek geldiğinde (çerez yok) çerez rastgele% 95 mavi% 5 yeşil der.

Kalçadan ateş ederken, bulut ön dağılımı içindeki menşei değiştirmek ne kadar sürer? 1) ELB'nin arkasına yeni kod dağıtın, ısıtın 2) eski ELB'yi kaldırırken bulut ön dağıtımınıza yeni bir kaynak olarak bu ELB'yi ekleyin 3) bir kez kesildiğinde, eski ELB'nin arkasındaki eski kodu yırtın.

CloudFront güncellemeleri veya DNS güncellemeleri ile ilişkili gecikmelerden kurtulmak için ELB'nizin arkasındaki otomatik ölçek grubunu değiştirebilirsiniz. 1) yeni ASG'de yeni kod dağıtın, ısıtın 2) mevcut ELB'nizi bu yeni ASG'ye kaydedin 3) eski ASG'yi ELB'nizden kaldırın 4) bir kez kesildikten sonra eski ASG'yi yıkın.

Ayrıca bu konuyla ilgili araştırma yapıyorum ve bir çözüm buldum (aşağıya bakın).

Arka fon:

CloudFront, dağıtım yapılandırmasındaki CNAME'nin hesabınızın tamamında benzersiz olmasını gerektirir. Bu nedenle, farklı dağıtımlara DNS üzerinden mavi / yeşil kontrolü çalışmaz. Joker kartları kullanacak bir dolandırıcılık var, ancak doğru dosyaların sunulduğunu garanti etmez. DNS ve CloudFront üzerinden mavi / yeşil kontrolü mümkün değildir.

Ayrıca, CloudFront'daki herhangi bir yapılandırmayı (CNAME dahil) değiştirmek, değişiklikler edge sunucularına yayılırken 15-60 dakika beklemeye neden olur. Ayrıca, ideal bir kurulum değil.

Geçici çözüm:

Tek sayfa uygulaması için hile yapabilen bu yapılandırma:

• Uygulama URL'si: app.alan_adim.com/app
• S3 Yapısı:
  • app / (canlı siteniz)
  • app2 / (canlı olmayan siteniz)

Şimdi CloudFront'u dosyaları sunmak için grubunuzu kullanacak şekilde yapılandırın. Bu noktada, her şey önbellek ayarlarına gelir. CloudFront sonsuza kadar sürdüğünden, S3 nesnelerimizde CacheControl başlığını ayarlayın. İndex.html için 5 dakika, her şey 1 gün kullanıyoruz. Geçiş zamanı geldiğinde, S3 dizin adlarını değiştirin. 5 dakika içinde, uygulama tüm niyet ve amaçlar için canlı olacak.

Halihazırda çalışan uygulamalar için, kodun içine yerleşik derleme sürümü ve uygulamanın kökünde bir derleme config json dosyası bulunur. Sonra uygulama zaman zaman json dosyasını isteyecek, güncelliğini yitirmişse, yenilemeyi istemek için sürümü kontrol edecektir.

Sınırlamalar

Islatma testlerini çok iyi yapamazsınız. Index.html'nin TTL'sini birkaç saat veya güne (ihtiyacınıza bağlı olarak) arttırmanın mümkün olduğunu düşünüyorum, bu da istemcilerin yerel önbellek süresi dolduğunda yeni sürümler almasını sağlayacaktır.

Gelen bu blog sonrası : ab AWS belgelerinde kod kapalı çalışma Kenar @ Lambda'ya yoluyla test yazar uygular (burada kendi örnekler görebilirsiniz https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- samples.html ).

Temel olarak, iki farklı kökene işaret eden tek bir Cloudfront dağılımı oluşturursunuz. Ardından Lambda @ Edge'i kullanarak trafiği başlangıç ​​noktasına (Çerezler aracılığıyla) yönlendirmek için kullanabilirsiniz ve elbette Lambda üzerinden trafiği ağırlıklandırmak veya çevirmek gibi başka şeyler de uygulayabilirsiniz. Daha fazla kaynak ve mantık eklemek de kolaydır. .