지속적 통합 - 블루-그린 배포

CI/CD와 Docker 를 결합하여 서비스 구성

 

Vagrant, Docker, 배포 파이프라인, 

형상관리(puppet,chef,ansible), 

서비스 검색(etcd,registrator, confd, consul), 

proxy service(nginx vs haproxy), 

CI/CD(jenkins), 

blue/green 배포, 

클러스터링(k8s,swarm, mesos), 

컨설과 watches, 젠킨스 등을 이용한 자가 치유 시스템, 

로깅(filebeat+ELK, metric) 

 

각 프로그램별 상세한 정보는 따로 보아야하지먄 중요한건 이런 여러가지 프로그램을 연결해서 사용하는 방법

 

모든 예제를 vagrant+ansible+docker 로 제공하기 때문에 실습환경을 바로 만들 수가 있습니다.

 

 

 

Using Blue-Green Deployment to Reduce Downtime and Risk

블루 그린 배포 전략은 새버전의 서버그룹을 모두 배포 완료한 후에, 로드밸런서에서 트래픽을 구버전에서 새버전으로 일시에 바꾸는 방식

 

blue-green 배포 전략은 가능한 동일하게 구성된 두 벌의 운영 환경을 구성하여 이 문제를 해결한다. 예를 들어 위 그림에서 현재 파란색의 환경이 실제 운영중이라고 생각해 보자. 새로운 버전의 소프트웨어 릴리즈를 준비하고 있다면 최종 테스트는 초록색 환경에서 이루어질 것이다. 초록색 환경에서 소프트웨어가 문제없이 잘 동작한다면, 인입되는 모든 요청이 초록색 환경으로 가도록 라우터 설정을 변경한다. 그러면 파란색 환경은 이제 노는 상태가 된다.

 

이 접근법의 장점은 hot-standby 환경을 구성하는 것과 기본 개념이 동일하다는 것이다. 따라서, 매 배포 시마다 재해 복구 절차를 테스트하는 것과 동일한 효과를 가진다.

 

• Blue-Green Deployment with Cloud Foundry Example
• • Step 1: Push an App
  • Step 2: Update App and Push
  • Step 3: Map Original Route to Green
  • Step 4: Unmap Route to Blue
  • Step 5: Remove Temporary Route to Green
• Implementations

 

 

 

 

그림 https://sdtimes.com/cloud/google-open-source-platform-spinnaker-1-0/

 

 

 

 

 

• blue-green 스위치가 작동하기 위해서는
• • 현재의 “blue” 환경의 엔트리 가중치는 255 가 되어야 하고
  • 새로운 “green” 환경은 가중치 0이 되어야 한다.
  • 그러면 단순하게 가중치에 의해서 트래픽이 blue 에서 green 으로 swap 된다.
• 이 방법의 유일한 단점은 DNS 변경 전파에 약간의 시간이 걸린다는 것이다.
• • 그래서 넌 사용자가 perceive 할 시기를 컨트롤 할 수 없다.
• 장점은 거의 zero-downtime 이라는 것이다.

 

https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html

Using Blue-Green Deployment to Reduce Downtime and Risk | Cloud Foundry Docs