카나리아 릴리스 전략 vs. 블루 / 그린

카나리아 릴리스에 대한 나의 이해 는 고정 세션이 켜져있는 프로덕션 노드 하위 집합에 대한 부분 릴리스라는 것입니다. 이렇게하면 나쁜 버그를 공개 할 경우 영향을받는 사용자 / 고객의 수를 제어하고 최소화 할 수 있습니다.

블루 / 그린 릴리스에 대한 나의 이해 는 미러링 된 프로덕션 환경 ( "파란색"및 "녹색")이 2 개 있고 변경 사항을 파란색 또는 녹색의 모든 노드에 한 번에 푸시 한 다음 네트워킹 마법을 사용하여 제어한다는 것입니다. 사용자가 DNS를 통해 라우팅되는 환경

따라서 시작하기 전에 지금까지 말한 내용이 잘못된 경우 나를 바로 잡는 것으로 시작하십시오!

내가 어느 정도 궤도에 있다고 가정하면 두 가지 전략에 대한 몇 가지 질문이 있습니다.

• 파란색 / 녹색보다 카나리아가 선호되는 시나리오가 있습니까?
• 배포 모델이 두 전략을 동시에 구현할 수있는 시나리오가 있습니까?

청록색 방출은 더 간단하고 빠릅니다.

테스트 환경에서 새 버전을 테스트하고 새 버전이 프로덕션에서 올바르게 작동 할 것이라고 확신하는 경우 청록색 릴리스를 수행 할 수 있습니다 . 항상 기능 토글을 사용 하면 새 버전이 기능 토글을 뒤집을 때까지 이전 버전과 똑같이 작동하므로 새 버전에 대한 자신감을 높일 수있는 좋은 방법입니다. 테스트 할 것이 적고 중단 될 수있는 서비스가 적기 때문에 애플리케이션을 독립적으로 릴리스 가능한 소규모 서비스로 분할하는 것은 또 다른 문제입니다.

당신 은 새 버전은 생산에서 제대로 작동하는지 완전히 특정하지 않으면 카나리아 버전을한다. 철저한 테스터 라하더라도 인터넷은 크고 복잡한 곳이며 항상 예기치 않은 문제가 발생합니다. 기능 토글을 사용하더라도 잘못 구현 될 수 있습니다.

배포 자동화에는 노력이 필요하므로 대부분의 조직은 매번 하나의 전략 또는 다른 전략을 사용하도록 계획합니다.

따라서 확신을 가질 수있는 관행에 전념한다면 블루-그린 배포를 수행하십시오. 그렇지 않으면 카나리아를 보내십시오.

청록색의 본질은 한 번에 배포하는 것이고 카나리아 배포의 본질은 점진적으로 배포하는 것이므로 단일 사용자 풀을 고려할 때 두 가지를 동시에 수행하는 것으로 설명 할 프로세스를 생각할 수 없습니다. 예를 들어 서로 다른 지역 데이터 센터를 사용하는 경우와 같이 여러 독립적 인 사용자 풀이있는 경우 각 데이터 센터 내에서 청녹색을 수행하고 데이터 센터에서 카나리아를 수행 할 수 있습니다. 데이터 센터 내에서 카나리아 배포가 필요하지 않더라도 데이터 센터 전체에서 필요하지 않을 것입니다.

이 주제에 대한 자세한 에세이를 여기에 작성했습니다. http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

제 생각에 차이점은 새로운 '그린'버전이 실제 사용자에게 노출되는지 여부입니다. 그렇다면 카나리아라고 부를 것입니다. Canary를 구현하는 일반적인 방법은 특정 사용자의 스마트 라우팅을 새 버전에 추가하는 일반 블루 / 그린입니다. 자세한 비교를 위해 게시물 읽기

파란색 / 녹색 :

카나리아:

이 두 용어는 서로 매우 비슷해 보이지만 미묘한 차이가 있습니다. 하나는 기능 릴리스를 신뢰하고 다른 하나는 릴리스 방식을 신뢰합니다.

카나리아

1. 카나리아 릴리스는 전체 인프라에 배포하기 전에 일부 사용자에게 변경 사항을 천천히 배포하여 프로덕션에 새 소프트웨어 버전을 도입 할 위험을 줄이는 기술입니다.

2. 새 버전이 어떻게 작동 할 것인지에 대한 아이디어를 얻으려고합니다 (다른 앱, CPU, 메모리, 디스크 사용량 등과 통합).

파란색 / 녹색 :

1. 다운 타임없이 배포 할 수있는 예측 가능한 릴리스에 관한 것입니다.
2. 실패시 쉽게 롤백합니다.
3. 완전히 자동화 된 배포 프로세스

다음은 인라인 정의입니다.

• Blue-Green 배포 -새 버전의 애플리케이션을 배포 할 때 두 번째 환경이 생성됩니다. 새 환경이 테스트되면 이전 버전을 대신합니다. 그런 다음 이전 환경을 끌 수 있습니다.

   

• A / B 테스트 -두 버전의 애플리케이션이 동시에 실행 중입니다. 요청의 일부가 각각에 전달됩니다. 그런 다음 개발자는 버전을 비교할 수 있습니다.  
• 카나리아 릴리스 -새 버전의 마이크로 서비스가 이전 버전과 함께 시작됩니다. 그러면 새 버전이 요청의 일부를 취할 수 있으며 팀은이 새 버전이 전체 시스템과 상호 작용하는 방식을 테스트 할 수 있습니다.

좋은 정의 시작. "배포"와 "릴리스 (기능)"에서 "릴리스"정의를 분할하면 전략에 대한 결정을 내리는데도 도움이된다고 생각합니다.

배포 (바이너리)

제품을 (생산) 시스템에 이진 배포하는 작업입니다.

릴리스 (기능)

사용자 (그룹)의 기능 가용성을 관리하는 작업입니다.

왜? 일반적으로 "출시"할 때 두 가지 우려 사항이 있습니다. 1) 버그 / 이전 버전과의 호환성 / etc 2) 새로운 기능의 유효성 / 사용 가능성 확인

그런 다음 Canary 또는 Blue / green 또는 회색 / 혼합 모드 전략을 선택하기 전에 스스로에게 물어보십시오. 새 버전을 출시 / 배포 할 때 어떤 문제가 있습니까? 그런 다음 우려 사항을 알고있는 경우에만 전략을 선택하십시오.

또한 더 복잡한 배포 / 릴리스 전략을 수행 할 수 있습니다. 예를 들어, 일부 클라우드 / 인프라에서는 여러 프로덕션 서버를 보유하고 제품의 다른 서버 및 버전에 대해 서로 다른 비율로로드를 릴레이하고 모든 사용자에게 릴리스 / 배포를 확장하기 전에 건전성을 모니터링 할 수 있습니다.

기능 신고

사용자 (그룹)에 대해 어떤 기능을 사용할 수 있는지 (불가) "구성"(콜드 또는 핫)하는 작업

또한 "기능 플래그 지정"과 같은 작업을 수행하는 경우 먼저 배포하고, 이전 버전과의 호환성 / 버그 관점에서 릴리스의 건전성을 측정하고, 다른 사용자에게 새로운 기능을 점진적으로 릴리스하거나, 그 반대로 (기능 및 / 또는 롤백 기능 및 / 또는 바이너리를 축소하거나 ). 기능 플래그 지정을 통해 바이너리 배포에서 기능 가용성을 분리 할 수 ​​있으며 "배포 / 롤백"보다 훨씬 더 세밀한 의사 결정을 내릴 수 있습니다.