Установка нулевого простоя для приложений Java

Question

Я пытаюсь создать очень легкое решение для нулевого времени простоя для приложений Java. Для простоты подумаем, что у нас есть два сервера. Мое решение заключается в использовании:

1. На «фронте» - какой-то балансировки нагрузки (программное обеспечение) - я имею в виду HAProxy здесь.

2. На «спине» - два сервера, оба запускают Tomcat с развернутым приложением.

Когда мы собираемся развернуть новый релиз

1. отключает один из серверов с HAProxy, так что только один сервер (назовем его сервер A, который работает старый релиз) будет доступный.

2. Разверните новую версию на другом сервере (назовем ее сервером B), запустите тестовые модули (в случае их наличия :-) и включите сервер B с HAProxy, одновременно отключив сервер A.

3. Теперь у нас снова активен только один сервер (сервер B, с новой версией). Разверните новую версию на сервере B и снова включите ее.

Любые советы по улучшению? Как автоматизировать?

Любые готовые решения или мне нужно в конечном итоге выполнить собственные скрипты?

Спасибо!

Answer 1

Подвижное обновление действительно хорошее решение, при условии, что ваш балансировщик нагрузки поддерживает этот вариант (серверное голодание). Другим решением является использование серверов приложений с поддержкой OSGi, компонентов для замены компонентов или всего приложения.

Я бы порекомендовал первый. Контрольная консоль AMS от SpringSource может удалить кластер tcServer (пользовательский tomcat на стероидах), а IIRC выполняет автоматическое обновление (но проверяет документы).

Answer 2

Обратите внимание на технологию OSGi, если вы можете разместить контейнер OSGi, поскольку он обеспечивает хорошую изоляцию и горячее развертывание для пакетов OSGi. Если вы используете фреймворк Spring, вы можете использовать Spring OSGi

Answer 3

LiveRebel обеспечивает функциональность перезапуска перезагрузки, предоставляет API CLI и плагин Hudson/Jenkins для автоматизации.

Answer 4

Я нашел несколько интересных решений из этого article относительно времени простоя нуля. Я хотел бы выделить лишь несколько решений в этой статье.

1. Переключатель/Б: (прокатка механизм обновления + Fallback)

Мы должны иметь набор узлов в режиме стоя. Мы разворачиваем новую версию на эти узлы и мгновенно переключаем трафик на них. Если мы сохраним старые узлы в исходном состоянии, мы можем сделать мгновенный откат. Балансировщик нагрузки обращается к приложению и отвечает за этот переключатель по запросу.

минусам: Если вам нужны X сервера для запуска приложения, йону нужен 2X серверов с этим подходом.

2. Нулевой простои

При таком подходе мы не храним множество машин; скорее, мы задерживаем привязку порта. Совместное приобретение ресурсов задерживается до запуска приложения. Порты переключаются после запуска приложения, а старая версия также работает (без точки доступа) для немедленного возврата в случае необходимости.

3. Параллельное развертывание - Apache Tomcat: (Только для веб-приложений)

Apache Tomcat добавил параллельную функцию развертывания для их выхода версии 7. Они позволяют одновременно запускать две версии приложения и использовать последнюю версию по умолчанию.

4. Отложенная порт связывания:

мы предлагаем здесь является возможность запуска сервера без привязки порта и, по существу, не запуская разъем. Позже будет запущена отдельная команда и привязка соединителя. Версия 2 программного обеспечения может быть развернута, пока версия 1 работает и уже связана. Когда версия 2 запускается позже, мы можем отменить версию 1 и связать версию 2. При таком подходе узел эффективно отключается только на несколько секунд.

5. Advanced Port Binding:

Разбив миф: «Address already in use», * как старый процесс & новый процесс будет связываться с таким же портом. Опция SO_REUSEPORT в режиме ON позволяет двум (или более) процессам связываться с одним и тем же портом. Как только новый процесс связывается с портом, убейте старый процесс.

В SO_REUSEPORT вариант рассмотреть два вопроса:

1. Небольшой глюк между переключением версии приложения: Узел может служить трафик все время, фактически давая нам нулевое время простоя.

2. Улучшенное планирование:

В Резюме:

путем сочетания обоих позднее связывание и порт повторно использовать, можно эффективно достичь нулевого времени простоя. И если мы будем поддерживать резервный процесс, мы также сможем сделать мгновенный откат.

Answer 5

Существует easy-deploy, что делает именно это с контейнерами Docker.

Deploy версия 1

easy-deploy -p 80:80 -v some/path:other/path my-image:1 

Для развертывания новой версии просто запустите команду с обновленным именем тега

easy-deploy -p 80:80 -v some/path:other/path my-image:2 

Раскрытие информации: Я построил этот инструмент. Я построил его именно потому, что не смог найти простого решения этой проблемы.