Blue / Green dağıtımlarını yapmanın bir yolunu arıyorum. CloudFront.
Herkes bir CloudFront dağıtımından diğerine geçmek için iyi bir çözüm sunuyor mu yoksa herkes kendi dağıtımını yaratıyor mu?
CloudFront dağıtımım bir S3'ten oluşur Menşei Statik içerik (javascript, vb.) ve AWS ELB'ye işaret eden özel bir kaynak için.
CloudFront için hiçbir değişiklik
Normal şartlar altında, CloudFront dağıtımımızda hiçbir değişiklik yapmıyoruz. S3'deki statik içeriklerimizi S3'teki statik içerik dosyalarının ismini değiştirerek ve Elastik Yük Dengeleyici (ELB) altında EC2 örneklerine yuvarlanan dağıtımlar yaparak uygularız. Bununla birlikte, CloudFront dağıtımının kendisinde test etmemiz ve değişiklik yapmamız gerektiğinde veya yeni bir çevrede yeni bir ELB'ye işaret etmemiz gereken çevremizde yeterince önemli değişiklikler yaptığımız zamanlar vardır.
İki CloudFront Dağılımı
Denediğim ilk seçenek, iki ayrı CloudFront'a sahip olmaktı. Web Dağılımlarıbiri benimki, ya da A, çevre için ve benim yeni ya da B ortamım için. Bir Route53 kullanmaya teşebbüs ettim ağırlıklı yönlendirme politikası www.domain.com Route53 kaydım için iki kayıt ekledim, biri CloudFront Distribution A'yı 1 ve diğeri de CloudFront Distribution B'yi 0 kilo ile işaret ediyordu. Plan I A dağıtımından B dağıtımına geçmek istiyorum. Ancak, bir seferde yalnızca bir CloudFront dağıtımı www.domain.com adresine sahip olabilir. Alternatif Alan Adları (CNAME) kayıtlı veya aşağıdaki hatayı alıyorsunuz:
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ğılımı
İkinci seçenek, bir CloudFront web dağıtımını tutmaktır.
Hem A hem de B ortamlarına işaret eden S3 ve özel kökenler var ve sonra CloudFront'u güncelliyorum Önbellek Davranışı Bir çevreden diğerine geçmek istediğimde diğer kökene işaret etmek. Bu son derece dağınıktır, çünkü bu güncellemeler 15-60 dakika sürer, güncellemenin ilerleyişinde bir görünürlük yoktur ve değişimin niteliğine bağlı olarak bunu takip etmeniz gerekebilir. CloudFront Geçersizleştirme Bu nedenle, eski içerikten önbelleğe alınmış içeriği yeni içerikle birlikte sunmuyorsunuz.
Tavsiyen için teşekkürler!
İki Cloudfront Dağılımı
AWS, aynı AWS hesabındaki joker alternatif CNAME'ler arasında çakışmaya izin verdiğinden, iki bulut bölgesi dağılımı arasında aşağıdaki şekilde geçiş yapabilirsiniz:
- Prod dağıtım için alternatif CNAME olarak www.domain.com kullanın 1
- Prod dağıtımı 2 için Alternatif CNAME olarak * .domain.com kullanın
- CNAME DNS www.domain.com adresinizi dağıtım 1 veya dağıtım 2'ye (* .cloudfront.net) yönlendirin.
- İçeriğe artık sunmak istemediğiniz dağıtımın alternatif CNAME'sini kaldırın.
Bununla birlikte, iki farklı dağıtım DNS'si (* .cloudfront.net), aynı kenar düğümlerine işaret edebilir, bu da içeriğinizin sunulma şeklinin, cloudfront.net CNAME öğesinin onu sunan Edge düğümlerine eşleştirmesi ve ardından eşleşmesidir. hostname. Bu durumda, her iki dağıtımınız da aynı kenar düğümlerini kullanıyorsa (örn.
dig) Kesim temiz olmayacaktır.
Örneğin. Her iki dağıtım da bir veya daha fazla kenar düğümünü paylaşıyorsa, Dağıtım 1 Alt CNAME www.domain.com ile dağıtıldığında, dağıtımın 2 yerine daha genel * .domain.com ile öncelik verilir.
CNAME, tüm kenar düğümlerinde dağıtım 1 yapılandırmasından kaldırılana kadar. Bu nedenle, bir talepten alınan versiyon, geçiş döneminde diğerlerinden farklı olabilir.
Kalpten çekim yapmak, kökeni bir bulut ön dağılımı arasında değiştirmek ne kadar sürer? 1) ELB'nin arkasına yeni bir kod dağıtın, ısıtın 2) eski ELB'yi geride bırakarak eski kodu 3) kaldırdığınızda eski ELB'nin arkasındaki eski kodu yırtarak bu ELB'yi bulut ön dağıtımınıza yeni bir kaynak olarak ekleyin.
CloudFront güncellemeleri veya DNS güncellemeleriyle ilişkili gecikmelerden kurtulmak için, otomatik ölçeklendirme grubunu ELB'nizin arkasına takabilirsiniz. 1) yeni ASG'ye yeni kodu dağıtın, ısıtın 2) mevcut ELB'nizi bu yeni ASG 3'e kaydedin. Eski ASG'yi ELB 4'ten ayırın, eski ASG'yi yırtıp atın.
Burada oyunda biraz geç, ama bunu isteyen 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ı bir URL istediğinde tetiklenen bir lambda işlevi uygulayabilirsiniz. Farklı kökenlerden veya URL öneki mavi / yeşil içeriği sunmayı seçin. Hangi dağıtımın sunulacağını bir çerez değeri belirler. İlk istek geldiğinde (çerez yok), çerez rasgele% 95 mavi% 5 yeşil olarak belirir.
Ayrıca bu konuyla ilgili araştırmalar yapıyorum ve bir çalışma var (aşağıya bakınız).
Arka fon:
CloudFront, dağıtım yapılandırmasında CNAME'nin tüm hesabınızın genelinde benzersiz olmasını gerektirir. Bu nedenle, farklı dağıtımlar için DNS aracılığıyla mavi / yeşilin kontrol edilmesi işe yaramayacaktır. Bu, vahşi kartları kullanacak şekilde etrafta dolaşan bir korsanlık var, ancak bu, doğru dosyaların sunulduğuna dair bir garanti vermiyor. DNS ve CloudFront aracılığıyla mavi / yeşilin kontrol edilmesi mümkün değildir.
Dahası, CloudFront'daki (CNAME dahil) herhangi bir yapılandırmanın değiştirilmesi, değişikliklerin kenar sunucularına iletilirken 15-60 dakika beklemesine neden olur. Ayrıca, ideal bir kurulum değil.
Etrafında çalışın:
Tek sayfa uygulaması için, hile yapabilecek bu yapılandırma:
- Uygulama URL'si: app.mydomain.com/app
- S3 Yapısı:
- app / (canlı siteniz)
- app2 / (o kadar canlı siteniz değil)
Şimdi, CloudFront'u, dosyaları sunmak için kepçenizi kullanacak şekilde yapılandırın. Bu noktada, hepsi size önbellek ayarları geliyor. CloudFront sonsuza kadar sürdüğü için, S3 nesnelerine CacheControl üstbilgisini ayarlayın. İndex.html için 5 dakika, diğer her şey, 1 gün kullanıyoruz.
Geçiş zamanı geldiğinde, S3 dizin isimlerini değiştiriniz. 5 dakika içinde, uygulama tüm amaç ve amaçlar için canlı olacak.
Zaten çalışan uygulamalar için, kodun içerisine derlenmiş bir derleme sürümüne ve uygulamanın kökü üzerinde bir yapılandırma yapılandırması json dosyasına sahibiz. Ardından, uygulama zaman zaman json dosyasını isteyecek, sürümü güncel değilse güncel bir yenileme isteyecektir.
Sınırlamalar
Testleri çok iyi ememezsiniz. İndeks.html'nin TTL değerini birkaç saat veya güne (ihtiyacınıza bağlı olarak) yükseltmek mümkündür; bu, istemcilerin yerel önbelleklerinin süresi dolduğunda yeni sürümler almasını sağlar.
İçinde bu blog yazısı yazar, AWS belgelerinde koddan çalışan Lambda @ Edge aracılığıyla a-b testi uygular (burada örneklerini görebilirsiniz: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html).
Temel olarak yaptığınız şey, iki farklı kökene işaret eden tek bir Cloudfront dağılımı yaratmanızdır. Ardından, trafiği kaynağınıza (Cookies aracılığıyla) yönlendirmek için Lambda @ Edge'i kullanabilirsiniz ve elbette Lambda aracılığıyla trafiği ağırlıklandırmak veya çevirmek gibi başka şeyler de uygulayabilirsiniz. Ayrıca daha fazla kaynak ve mantık eklemek de kolaydır. .