Я пытаюсь создать очень легкое решение для нулевого времени простоя для приложений Java. Для простоты подумаем, что у нас есть два сервера. Мое решение состоит в том, чтобы использовать:
На "фронте" - некоторый балансировщик (программное обеспечение) - я думаю о HAProxy здесь.
На "обратной стороне" - два сервера, оба запускают Tomcat с развернутым приложением.
Когда мы собираемся развернуть новую версию
Мы отключили один из серверов с HAProxy, так что будет доступен только один сервер (пусть его вызывает сервер A, который работает с старой версией).
Разверните новую версию на другом сервере (позвоните на сервер B), запустите тесты производственных модулей (в случае их наличия:-) и включите сервер B с HAProxy, одновременно отключив сервер A.
Теперь у нас снова активен только один сервер (сервер B с новой версией). Разверните новую версию на сервере B и снова включите ее.
Кто-нибудь советует, как улучшить? Как автоматизировать?
Какие-либо готовые решения, или я должен закончить свои собственные собственные скрипты?
Спасибо!
Подвижное обновление действительно хорошее решение, если ваш балансировщик нагрузки поддерживает эту опцию (голодание сервера). Еще одно решение - использовать серверы приложений с поддержкой OSGi, компоненты горячей замены или все ваше приложение.
Я бы порекомендовал первый. Контрольная консоль SpringSource AMS может удалить кластер из tcServer (пользовательский tomcat на стероидах), а IIRC выполняет автоматическое обновление (но проверяет документы).
Посмотрите на технологию OSGi, если вы можете разместить контейнер OSGi, поскольку он обеспечивает хорошую изоляцию и горячее развертывание для пакетов OSGi. Если вы используете фреймворк Spring, вы можете использовать Spring OSGi
LiveRebel обеспечивает функциональность для перезапуска перезагрузки, предоставляет API CLI и плагин Hudson/Jenkins для автоматизации.
Я нашел несколько интересных решений из этой статьи относительно нулевого времени простоя. Я хотел бы выделить лишь несколько решений в этой статье.
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 может обслуживать трафик все время, эффективно давая нам нулевое время простоя.
Улучшенное планирование:
В резюме:
Объединив как последнее связывание, так и повторное использование порта, мы можем эффективно достичь нулевого времени простоя. И если мы будем поддерживать резервный процесс, мы также сможем выполнить мгновенный откат.
Существует 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
Раскрытие: я построил этот инструмент. Я построил его именно потому, что не нашел простого решения этой проблемы.