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

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

---

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

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

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

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

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

---

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

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

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

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

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

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

---

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

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

파란색 / 녹색 :

카나리아:

---

블루 / 그린 및 카나리아 릴리스 모두 더 많은 청중에게 소프트웨어 기능을 출시하기 전에 대상 청중을 대상으로 소프트웨어를 테스트하는 동일한 목적을 해결합니다. 카나리아의 경우 배포는 아래에서 동일한 인프라를 공유 할 수 있지만 블루 / 그린의 경우 전체 인프라가 트래픽 라우팅을 위해 라우터 / DNS / 리버스 프록시와 함께 전면 복제됩니다.

인프라 스크립팅 및 재 작성이 더 쉬운 클라우드 환경에서는 인프라가 자동화와 동기화 될 수 있도록 블루 / 그린 배포가 선호됩니다. 이것은 환경을 재현 할 수있는 능력이 필요할 때 가질 수있는 훌륭한 기능입니다.

더 자세한 비교를 위해 다음 문서를 참조 할 수 있습니다.

BlueGreen 배포 : http://martinfowler.com/bliki/BlueGreenDeployment.html

카나리아 배포 : http://martinfowler.com/bliki/CanaryRelease.html

---

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

카나리아

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

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

파란색 / 녹색 :

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

---

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

배포 (바이너리)

제품을 (프로덕션) 시스템에 바이너리 배포하는 작업입니다.

릴리스 (기능)

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

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

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

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

기능 신고

The action of "configuring" (cold, or even hot) which functionality is (not)available for which (group) of users

If you also do something like "feature flagging" you can deploy first, measure soundness of your release in backwards compatibility/bug perspective, and release new functionality gradually to different users, or vice versa (scale down or even rollback functionality and/or binaries). Feature flagging allows for splitting availability of functionality from deployment of binaries, and gives much more fine-grained decision making then only "deploy/rollback"

---

Here are some inline definition -

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

   

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

참고 URL : https://stackoverflow.com/questions/23746038/canary-release-strategy-vs-blue-green