Внезапное развертывание для приложений Java

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

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

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

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

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

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

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

Кто-нибудь советует, как улучшить? Как автоматизировать?

Какие-либо готовые решения, или я должен закончить свои собственные собственные скрипты?

Спасибо!

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

cons: Если вам нужно X-серверов для запуска вашего приложения, вам понадобится 2X-сервер с этим подходом.

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

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

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

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

4. Задержка привязки порта:

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

5. Расширенное связывание портов:

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

Опция SO_REUSEPORT адресует два вопроса:

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

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

введите описание изображения здесь

В резюме:

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

Ответ 5

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

Развертывание версии 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

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