CloudFront를 사용한 블루 / 그린 배포


16

CloudFront로 Blue / Green 배포를 수행하는 방법을 찾고 있습니다.

누구나 하나의 CloudFront 배포에서 다른 CloudFront 배포로 이동할 수있는 좋은 솔루션이 있습니까, 아니면 누구나 배포를 만든 다음 다시 만지지 않습니까?

My CloudFront 배포는 정적 콘텐츠 (자바 스크립트 등)에 대한 하나의 S3 오리진 과 AWS ELB를 가리키는 사용자 지정 오리진으로 구성됩니다.

CloudFront에 대한 변경 사항 없음

정상적인 상황에서는 CloudFront 배포를 전혀 변경하지 않습니다. S3에서 정적 컨텐츠 파일 이름을 변경하여 S3 오리진에서 정적 컨텐츠를 버전 화하고 ELB (Elastic Load Balancer)에서 EC2 인스턴스로 롤링 배포를 수행합니다. 그러나 CloudFront 배포 자체를 테스트하고 변경해야하거나 새로운 환경에서 새로운 ELB를 가리켜 야 할 정도로 환경을 충분히 변경해야 할 때가 있습니다.

2 개의 CloudFront 배포

내가 시도한 첫 번째 옵션은 현재 환경 또는 A 환경과 새 환경 또는 B 환경에 대한 두 개의 별도 CloudFront 웹 배포 를 갖는 것입니다. www.domain.com Route53 레코드에 대해 두 개의 레코드를 추가 한 Route53 가중 라우팅 정책 을 사용하려고했습니다 . 하나는 가중치가 1 인 CloudFront Distribution A를 가리키고 다른 하나는 가중치가 0 인 CloudFront Distribution B를 가리 킵니다. 배포 A에서 배포 B로 이동하려는 경우 가중치를 변경하는 것이 좋습니다 . 그러나 한 번에 하나의 CloudFront 배포 만 www.domain.com CNAME (대체 도메인 이름)을 등록하거나 다음 오류가 발생합니다.

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)

하나의 CloudFront 배포

두 번째 옵션은 하나의 CloudFront 웹 배포를 유지하는 것입니다. 내 A 및 B 환경을 모두 가리키는 S3 및 사용자 지정 오리진이 있고 한 환경에서 다른 환경으로 이동하려는 경우 다른 원점을 가리 키도록 CloudFront 캐시 동작 을 업데이트합니다 . 이러한 업데이트는 15-60 분이 걸리고 업데이트 진행 상황에 대한 가시성이 없으며 변경의 특성에 따라 CloudFront Invalidation 으로 후속 조치를 취해야 캐시 된 콘텐츠를 제공하지 않기 때문에 이는 매우 지저분 합니다. 새로운 콘텐츠와 함께 이전 환경에서

조언 해 주셔서 감사합니다!


해결책을 찾았습니까? 우리는 프로젝트와 같은 방식으로 문제를 해결하고 있습니다. 프로젝트에서 수동으로 Cloudfront Endpoint를 변경합니다.
Dmytriy Voloshyn

1
불행히도 아니요-좋은 것이 없다고 생각합니다. 모범 사례는 하나의 cloudfront 배포를 사용하고 s3 버킷의 모든 콘텐츠 버전을 지정하고 동적 콘텐츠를 가리키는 오리진에 route53 가중 dns 레코드를 사용하는 것입니다. 그런 다음 route53을 업데이트하여 동적 콘텐츠를 변경하면 클라우드 프론트를 만질 필요가 없습니다. 우리는 dev와 qa에 대해 별도의 cloudfront 배포를 유지합니다. 예 : stackoverflow.com/questions/9130555/…
Peter M

답변:


9

두 개의 Cloudfront 배포

AWS는 동일한 AWS 계정에서 와일드 카드 대체 CNAME간에 겹침을 허용하므로 다음과 같은 방식으로 두 개의 클라우드 프론트 배포간에 전환 할 수 있습니다.

  • Prod 배포를위한 대체 CNAME으로 www.domain.com 사용 1
  • Prod 배포 2를위한 대체 CNAME으로 * .domain.com 사용
  • CNAME DNS www.domain.com을 배포 1 또는 배포 2 (*. cloudfront.net)로 지정하십시오.
  • 더 이상 콘텐츠를 제공하지 않으려는 배포에서 대체 CNAME을 제거하십시오.

그러나 두 개의 서로 다른 배포 DNS (*. cloudfront.net)는 동일한 에지 노드를 가리킬 수 있습니다. 즉, 콘텐츠가 제공되는 방식은 cloudfront.net CNAME을 서비스하는 에지 노드와 일치시킨 다음 일치하는 것입니다. 호스트 이름. 이 경우 두 배포판 모두 같은 가장자리 노드를 사용하는 경우 (예 :로 확인 가능 dig) 컷이 깨끗하지 않습니다.

예를 들어 두 배포 모두 하나 이상의 에지 노드를 공유하는 경우 Alt CNAME이있는 배포 1 www.domain.com은 모든 에지 노드의 배포 1 구성에서 CNAME이 제거 될 때까지보다 일반적인 * .domain.com이있는 배포 2보다 우선합니다. . 따라서 전환 기간 동안 한 요청에서 검색된 버전이 다른 요청과 다를 수 있습니다.


CloudFront에서 연장 된 변경 확산 시간으로 인해 실제로 이것이 유일한 옵션입니다.
CloudWalker

감사합니다-이것은 매우 흥미로운 답변입니다. 나는 이런 식으로 그렇게 생각하지 않았습니다. 한 배포에서 다른 배포로 삭감 되었기 때문에 올바른 것으로 표시 할 것입니다. 그러나 확산 시간이 길어지고 전환 중에 잘못된 콘텐츠를 제공 할 위험을 피해야하므로 제 경우에는 사용할 수 없습니다 . @CloudWalker에 다른 옵션이 없다는 데 동의합니다.
피터 M

3

여기 게임에서 약간 늦었지만 이것을 찾는 다른 사람들을 위해. 나는 이것이 lambda @ edge를 사용하여 수행 할 수 있다고 생각합니다. A / B 테스트와 유사합니다. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . 사용자가 URL을 요청할 때 트리거되는 람다 함수를 구현할 수 있습니다. 다른 출처 또는 URL 접두사에서 파랑 / 녹색 컨텐츠를 제공하도록 선택하십시오. 쿠키 값에 따라 제공 될 배포가 결정됩니다. 첫 번째 요청이 도착하면 (쿠키 없음) 쿠키가 임의로 95 % 파랑 5 % 녹색으로 설정됩니다.


1

엉덩이에서 촬영할 때 클라우드 전면 배포판에서 원점을 전환하는 데 얼마나 걸립니까? 1) ELB 뒤에 새 코드를 배치하고 예열하십시오. 2) 기존 ELB 뒤에 오래된 코드를 제거하고 기존 원점을 제거하면서이 ELB를 클라우드 프론트 분배에 새 출처로 추가하십시오.

CloudFront 업데이트 또는 DNS 업데이트와 관련된 지연을 피하기 위해 오토 스케일 그룹을 ELB 뒤에서 교체 할 수 있습니다. 1) 새 ASG에 새 코드를 배포하고 예열합니다. 2)이 새 ASG에 기존 ELB를 등록합니다. 3) ELB에서 기존 ASG를 등록 취소합니다. 4) 일단 컷 오버하면 오래된 ASG를 해제합니다.


0

나는 또한이 주제에 대해 연구하고 해결 방법을 가지고 있습니다 (아래 참조).

배경:

CloudFront를 사용하려면 배포 구성의 CNAME이 전체 계정에서 고유해야합니다. 따라서 DNS를 통해 다른 배포판으로 블루 / 그린을 제어하면 작동하지 않습니다. 와일드 카드를 사용하는 해킹이 있지만 올바른 파일이 제공된다는 보장은 없습니다. DNS 및 CloudFront를 통한 청 / 녹색 제어는 불가능합니다.

또한 CloudFront (CNAME 포함)에서 구성을 변경하면 변경 사항이 엣지 서버로 전파되는 동안 15-60 분 동안 대기하게됩니다. 또한 이상적인 설정은 아닙니다.

해결 방법 :

단일 페이지 앱의 경우이 구성을 통해 트릭을 수행 할 수 있습니다.

  • 앱 URL : app.mydomain.com/app
  • S3 구조 :
    • 앱 / (라이브 사이트)
    • app2 / (실제 사이트가 아님)

이제 버킷을 사용하여 파일을 제공하도록 CloudFront를 구성하십시오. 이 시점에서 캐시 설정이 모두 완료됩니다. CloudFront는 영원히 걸리므로 S3 객체에서 CacheControl 헤더를 설정하십시오. index.html의 경우 5 분, 그 밖의 모든 것을 1 일로 사용합니다. 전환시기가되면 S3 디렉토리 이름을 바꾸십시오. 5 분 이내에 앱은 모든 의도와 목적으로 작동합니다.

이미 실행중인 앱의 경우 코드에 빌드 버전이 빌드되고 앱 루트에 빌드 구성 json 파일이 있습니다. 그런 다음 앱은 때때로 json 파일을 요청하고, 버전이 오래된 경우 버전을 확인하여 새로 고침을 요청합니다.

한계

담그기 테스트는 잘 수행 할 수 없습니다. 필자는 필요에 따라 index.html의 TTL을 몇 시간 또는 며칠로 늘려서 로컬 캐시가 만료되면 클라이언트가 새 버전을 얻을 수 있다고 생각합니다.


0

에서 이 블로그에 게시 : AB는 AWS 문서의 코드로 해제 작업 에지 @ 람다를 통해 테스트 저자 구현을 (당신은 여기에 자신의 예를 볼 수 있습니다 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- examples.html ).

기본적으로 두 가지 다른 출처를 가리키는 단일 Cloudfront 배포를 생성합니다. 그런 다음 Lambda @ Edge를 사용하여 트래픽을 오리진 (쿠키를 통해)으로 전달할 수 있으며 Lambda를 통해 트래픽에 가중치를 부여하거나 뒤집는 등 다른 것을 구현할 수도 있습니다. .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.