카나리아 릴리스에 대한 나의 이해 는 고정 세션이 켜져있는 프로덕션 노드 하위 집합에 대한 부분 릴리스라는 것입니다. 이렇게하면 나쁜 버그를 공개 할 경우 영향을받는 사용자 / 고객의 수를 제어하고 최소화 할 수 있습니다.
블루 / 그린 릴리스에 대한 나의 이해 는 미러링 된 프로덕션 환경 ( “파란색”및 “녹색”)이 2 개 있고 변경 사항을 파란색 또는 녹색의 모든 노드에 한 번에 푸시 한 다음 네트워킹 마법을 사용하여 제어한다는 것입니다. 사용자가 DNS를 통해 라우팅되는 환경
따라서 시작하기 전에 지금까지 말한 내용이 잘못된 경우 나를 바로 잡는 것으로 시작하십시오!
내가 어느 정도 궤도에 있다고 가정하면 두 가지 전략에 대한 몇 가지 질문이 있습니다.
- 파란색 / 녹색보다 카나리아가 선호되는 시나리오가 있습니까?
- 배포 모델이 두 전략을 동시에 구현할 수있는 시나리오가 있습니까?
답변
청록색 방출은 더 간단하고 빠릅니다.
테스트 환경에서 새 버전을 테스트하고 새 버전이 프로덕션에서 올바르게 작동 할 것이라고 확신하는 경우 청록색 릴리스를 수행 할 수 있습니다 . 항상 기능 토글을 사용 하면 새 버전이 기능 토글을 뒤집을 때까지 이전 버전과 똑같이 작동하므로 새 버전에 대한 자신감을 높일 수있는 좋은 방법입니다. 테스트 할 것이 적고 중단 될 수있는 서비스가 적기 때문에 애플리케이션을 독립적으로 릴리스 가능한 소규모 서비스로 분할하는 것은 또 다른 문제입니다.
당신 은 새 버전은 생산에서 제대로 작동하는지 완전히 특정하지 않으면 카나리아 버전을한다. 철저한 테스터 라하더라도 인터넷은 크고 복잡한 곳이며 항상 예기치 않은 문제가 발생합니다. 기능 토글을 사용하더라도 잘못 구현 될 수 있습니다.
배포 자동화에는 노력이 필요하므로 대부분의 조직은 매번 하나의 전략 또는 다른 전략을 사용하도록 계획합니다.
따라서 확신을 가질 수있는 관행에 전념한다면 블루-그린 배포를 수행하십시오. 그렇지 않으면 카나리아를 보내십시오.
청록색의 본질은 한 번에 배포하는 것이고 카나리아 배포의 본질은 점진적으로 배포하는 것이므로 단일 사용자 풀을 고려할 때 두 가지를 동시에 수행하는 것으로 설명 할 프로세스를 생각할 수 없습니다. 예를 들어 서로 다른 지역 데이터 센터를 사용하는 경우와 같이 여러 독립적 인 사용자 풀이있는 경우 각 데이터 센터 내에서 청녹색을 수행하고 데이터 센터에서 카나리아를 수행 할 수 있습니다. 데이터 센터 내에서 카나리아 배포가 필요하지 않더라도 데이터 센터 전체에서 필요하지 않을 것입니다.
답변
이 주제에 대한 자세한 에세이를 여기에 작성했습니다. http://blog.itaysk.com/2017/11/20/deployment-strategies-defined
제 생각에 차이점은 새로운 ‘그린’버전이 실제 사용자에게 노출되는지 여부입니다. 그렇다면 카나리아라고 부를 것입니다. Canary를 구현하는 일반적인 방법은 특정 사용자의 스마트 라우팅을 새 버전에 추가하는 일반 블루 / 그린입니다. 자세한 비교를 위해 게시물 읽기
파란색 / 녹색 :
카나리아:
답변
이 두 용어는 서로 매우 비슷해 보이지만 미묘한 차이가 있습니다. 하나는 기능 릴리스를 신뢰하고 다른 하나는 릴리스 방식을 신뢰합니다.
카나리아
-
카나리아 릴리스는 전체 인프라에 배포하기 전에 일부 사용자에게 변경 사항을 천천히 배포하여 프로덕션에 새 소프트웨어 버전을 도입 할 위험을 줄이는 기술입니다.
-
새 버전이 어떻게 작동 할 것인지에 대한 아이디어를 얻으려고합니다 (다른 앱, CPU, 메모리, 디스크 사용량 등과 통합).
파란색 / 녹색 :
- 다운 타임없이 배포 할 수있는 예측 가능한 릴리스에 관한 것입니다.
- 실패시 쉽게 롤백합니다.
- 완전히 자동화 된 배포 프로세스
답변
다음은 인라인 정의입니다.
-
Blue-Green 배포 -새 버전의 애플리케이션을 배포 할 때 두 번째 환경이 생성됩니다. 새 환경이 테스트되면 이전 버전을 대신합니다. 그런 다음 이전 환경을 끌 수 있습니다.
- A / B 테스트 -두 버전의 애플리케이션이 동시에 실행 중입니다. 요청의 일부가 각각에 전달됩니다. 그런 다음 개발자는 버전을 비교할 수 있습니다.
- 카나리아 릴리스 -새 버전의 마이크로 서비스가 이전 버전과 함께 시작됩니다. 그러면 새 버전이 요청의 일부를 취할 수 있으며 팀은이 새 버전이 전체 시스템과 상호 작용하는 방식을 테스트 할 수 있습니다.
답변
좋은 정의 시작. “배포”와 “릴리스 (기능)”에서 “릴리스”정의를 분할하면 전략에 대한 결정을 내리는데도 도움이된다고 생각합니다.
배포 (바이너리)
제품을 (생산) 시스템에 이진 배포하는 작업입니다.
릴리스 (기능)
사용자 (그룹)의 기능 가용성을 관리하는 작업입니다.
왜? 일반적으로 “출시”할 때 두 가지 우려 사항이 있습니다. 1) 버그 / 이전 버전과의 호환성 / etc 2) 새로운 기능의 유효성 / 사용 가능성 확인
그런 다음 Canary 또는 Blue / green 또는 회색 / 혼합 모드 전략을 선택하기 전에 스스로에게 물어보십시오. 새 버전을 출시 / 배포 할 때 어떤 문제가 있습니까? 그런 다음 우려 사항을 알고있는 경우에만 전략을 선택하십시오.
또한 더 복잡한 배포 / 릴리스 전략을 수행 할 수 있습니다. 예를 들어, 일부 클라우드 / 인프라에서는 여러 프로덕션 서버를 보유하고 제품의 다른 서버 및 버전에 대해 서로 다른 비율로로드를 릴레이하고 모든 사용자에게 릴리스 / 배포를 확장하기 전에 건전성을 모니터링 할 수 있습니다.
기능 신고
사용자 (그룹)에 대해 어떤 기능을 사용할 수 있는지 (불가) “구성”(콜드 또는 핫)하는 작업
또한 “기능 플래그 지정”과 같은 작업을 수행하는 경우 먼저 배포하고, 이전 버전과의 호환성 / 버그 관점에서 릴리스의 건전성을 측정하고, 다른 사용자에게 새로운 기능을 점진적으로 릴리스하거나, 그 반대로 (기능 및 / 또는 롤백 기능 및 / 또는 바이너리를 축소하거나 ). 기능 플래그 지정을 통해 바이너리 배포에서 기능 가용성을 분리 할 수 있으며 “배포 / 롤백”보다 훨씬 더 세밀한 의사 결정을 내릴 수 있습니다.
답변
