Могут ли приложения GWT быть развернуты с помощью сине-зеленого развертывания?

Question

Я прочитал статью Мартина Фаулера " Blue/Green Deployment", и мне она очень понравилась. По сути, это концепция, согласно которой у вас есть 2 среды производственного класса: "голубая" среда LIVE и "зеленая" среда LIVE. В любой момент времени у вас есть только одна среда, которая считается "настоящей" LIVE-средой. Таким образом, вы помещаете какой-то механизм маршрутизации / коммутации (возможно, промежуточное веб-приложение или модифицированный программный балансировщик нагрузки) перед этими двумя LIVE-средами, который определяет, в какую среду пользователи направляются (мы здесь говорим о веб-приложениях).

Таким образом, все ваши пользователи перенаправляются, скажем, в среду Green LIVE на http://green.example.com/myapp, Затем, когда вы будете готовы выпустить некоторые новые производственные изменения, вместо того, чтобы развертывать их в Green LIVE, вы развернете их в Blue LIVE и начнете перенаправлять небольшой (~10%) процент ваших пользователей в Blue LIVE. Типичные стратегии - заставить маршрутизатор использовать IP-адреса или файлы cookie, чтобы определить, нужно ли маршрутизировать пользователя в синий или зеленый цвет.

Когда вы уверены, что в ваших производственных изменениях нет ошибок / проблем (примененных в Blue LIVE), вы перенастраиваете маршрутизатор, чтобы теперь весь трафик перенаправлялся в Blue LIVE в http://blue.example.com/myapp,

Теперь на мой вопрос:

Я занимаюсь разработкой приложения GWT и хотел бы реализовать этот синий / зеленый шаблон переключения. Проблема заключается в том, что приложения GWT являются клиентскими и не соответствуют обычной серверной архитектуре веб-приложений, которую используют приложения Spring, Struts, JSP и сервлет.

Поэтому я спрашиваю: как я мог иметь 2 экземпляра Tomcat (Blue Tomcat и Green Tomcat), обслуживающих две разные версии одного и того же приложения GWT для пользователей из-за сине-зеленого "маршрутизатора"? Под "роутером" я, вероятно, говорю о промежуточном веб-приложении на 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 (я использую RequestFactory здесь) в конечном итоге будет знать, как общаться с blue или же green как только приложение GWT загружено на клиент.

Поэтому я спрашиваю: это возможно? Существуют ли какие-либо специальные конфигурации / код / ​​библиотеки / методы и т. Д., Которые мне нужно будет использовать, чтобы сделать эту работу? Какие-нибудь предостережения или подводные камни, о которых я не думаю? Заранее спасибо!

Answer 1

Те же приготовления к развертыванию необходимы независимо от стратегии развертывания: сине-зеленый, канарейка (см. Другой вопрос: стратегия выпуска Canary или 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, чтобы обнаружить, что была выпущена новая версия вашего приложения, и затем попросить пользователя обновить. Но опять же, какой бы стратегией вы ни руководствовались, она применима к любому процессу развертывания.