GWT 응용 프로그램을 파란색/녹색 배포와 함께 배포 할 수 있습니까?

Question

Martin Fowler의 Blue/Green Deployment 문서를 읽고 정말 좋아합니다. 기본적으로 두 가지 프로덕션 클래스 환경 즉 "파란색"LIVE 환경과 "녹색"LIVE 환경이 있다는 개념입니다. 주어진 시간에 "실제"라이브 환경으로 간주되는 환경은 1 개뿐입니다. 따라서 어떤 환경 사용자가 라우팅되는지를 결정하는이 두 라이브 환경 앞에 라우팅/스위치 메커니즘 (아마도 중개 웹 응용 프로그램 또는 수정 된 소프트웨어 부하 분산 장치)을 설치합니다. 여기서는 웹 응용 프로그램을 말합니다.

그래서 모든 사용자가 녹색 라이브 환경 (예 : http://green.example.com/myapp)으로 연결됩니다. 그런 다음 Green LIVE에 배포하는 대신 새로운 제작 변경 사항을 푸시 할 준비가되면 Blue LIVE에 배포하고 일부 작은 (~ 10 %) 사용자 비율을 Blue LIVE로 라우팅합니다. 일반적인 전략은 라우터가 IP 주소 나 쿠키를 사용하여 사용자를 Blue 또는 Green으로 라우팅해야하는지 여부를 결정하는 것입니다.

프로덕션 변경 사항 (Blue LIVE에 적용)에 버그 버그/문제가 없다고 확신하면 모든 트래픽을 Blue LIVE http://blue.example.com/myapp으로 리디렉션하도록 라우터를 다시 구성하십시오.

이제 내 질문 위에 :

나는 GWT 응용 프로그램을 설계하고이 파란색/녹색 스위치 패턴을 구현하고 싶습니다. 문제는 GWT 애플리케이션이 클라이언트 측이고 Spring, Struts, JSP, 서블릿 애플리케이션이 사용하는 일반적인 서버 측 웹 애플리케이션 아키텍처를 따르지 않는다는 것입니다.

그래서 물어볼 : 어떻게 내가 파란색/녹색 "라우터"뒤에있는 사용자에게 동일한 GWT 애플 리케이션의 두 가지 버전을 제공하는 2 Tomcat 인스턴스 (블루 Tomcat과 그린 Tomcat)을 가질 수 있을까요? "라우터"로, 나는 아마 http://router.example.com/myapp-router에 중간 웹 애플 리케이션에 대해 이야기하고 있습니다. 기본 아키텍처의

green.example.com:8080/opt/tomcat/webapps/myapp.war/ --> Green Tomcat 
    myModule/ 
     mymodule.nocache.js 
     mymodule.cache.html } typical GWT app WAR structure... 
    hosts/      this is currently the "real" LIVE 
     index.html    environment where 90% traffic is routed to 
    css/ 
     main.css 
    WEB-INF/ 
     web.xml 
     lib/ 
     classes/ 

blue.example.com:8080/opt/tomcat/webapps/myapp.war/ --> Blue Tomcat 
    myModule/ 
     mymodule.nocache.js 
     mymodule.cache.html } typical GWT app WAR structure... 
    hosts/      new production changes have been deployed here 
     index.html    and 10% of users are routed here 
    css/ 
     main.css 
    WEB-INF/ 
     web.xml 
     lib/ 
     classes/ 

router.example.com:8080/opt/tomcat/webapps/myapp-router.war/ --> Router 
    WEB-INF/ 
     web.xml 
     lib/   } simple headless WAR that inspects HTTP Requests and 
     classes/   determines which environment to redirect user to 

:

시각적으로, 여기에 문제의 문제는 클라이언트가 router.example.com/myapp-router에 요청을 할 것이며, 라우터가 blue.example.com/myapp 또는 green.example.com/myapp 중 하나에게 요청을 전달 할 것입니다. GWT 앱이 클라이언트에 다운로드되면 GWT (나는 RequestFactory을 사용하고 있습니다)가 blue 또는 green과 통신하는 것을 궁극적으로 알게됩니다.

나는 이것이 가능한가? 특별한 설정/코드/라이브러리/기술 등이 있습니까?이 작업을하기 위해 활용해야합니까? 생각 나지 않는 모든주의 사항이나 함정? 미리 감사드립니다!

Answer 1

배포 전략에 관계없이 blue-green, canary (차이점에 대한 설명은 Canary release strategy vs. Blue/Green, 기타 질문 참조) 또는 단일 서버 업그레이드와 같은 배포 준비가 필요합니다. 성공적인 업그레이드에 대한 단일 클라이언트의 브라우저 수준보기는 동일합니다. 각 요청에 이전 버전이 표시되고 배포가 발생하며 각 요청에 새 버전이 표시됩니다. 마찬가지로 실패한 업그레이드 및 롤백에 대한 단일 클라이언트의 브라우저 수준보기는 동일합니다.

몇 년 전에 GWT 앱을 사용했을 때 GWT가 서버에서 호환되지 않는 새 버전을 발견했을 때 예외를 잡아 내고 브라우저를 새로 고치는 메시지를 사용자에게 표시했습니다. 이 기사에서는 좀 더 자세히 설명합니다 : http://codebetter.com/kylebaley/2012/01/06/deploying-a-new-version-of-a-gwt-app-2/ Google App Engine을 사용하는 경우 GAE의 Channel API를 사용하여 새 버전의 앱이 출시되었음을 감지 한 다음 사용자에게 새로 고침을 요청할 수 있습니다.그러나 어떤 전략을 따르더라도 모든 배포 프로세스에 적용됩니다.