Автоматизация развертывания

Я смотрел этот вопрос, надеясь, что кто-то придумает умный ответ. Так как они этого не сделали, думаю, я присоединюсь к своим собственным чувствам по этому поводу.

Насколько мне известно, не существует инструмента для автоматизации таких типов развертывания, и я предполагаю, что это связано с тем, что существует так много разных сценариев, с которыми нужно иметь дело. Как минимум, у вас есть:

1. Один сервер разработки, где нужно просто скопировать WAR на место, а затем перезапустить сервер приложений.
2. Один рабочий сервер, где процесс аналогичен, но вы не хотите, чтобы процесс мешал вашим пользователям. Здесь следует учитывать сохранение данных сеанса при перезапусках и планирование перезапуска на время с низким уровнем использования.
3. Небольшой кластер, в котором у вас есть балансировщик нагрузки на многих узлах. Теперь все действительно усложняется. Вы можете использовать различные инструменты LB (HA Proxy, NGINX, Amazon Elastic LB), и если вы заботитесь о своих пользователях, вам необходимо координировать циклический перезапуск серверов приложений. Перенос любых данных сеанса между узлами также вызывает беспокойство.
4. У вас есть большой кластер, состоящий из более мелких кластеров в разных географических регионах. Здесь вы имеете дело с # 3 + любая конфигурация, которую необходимо выполнить для координации между регионами.

Я полагаю, что 1 и 2 было бы проще всего найти общий инструмент, и если бы это были единственные ситуации, с которыми мне нужно было иметь дело, я бы, вероятно, просто развернул Jenkins вместе с приложением. Его можно довольно легко настроить на извлечение из ветки git при возникновении изменений, сборку кода и перезапуск Jetty. Однако к тому времени, когда вы доберетесь до 3 и 4, я думаю, что количество различных задействованных инструментов и необходимость их координации исключают любое стандартное решение. Я не думаю, что это просто проблема в мире Java/Scala, так как я видел отзывы от людей Github о пользовательских инструментах, которые они создали для управления развертывание своего приложения Rails.

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

Вы можете использовать наш продукт BuildMaster, чтобы делать все это. Я заметил, что вы упомянули Puppet, и важно отметить, что этот инструмент предназначен для автоматизации инфраструктуры, а не для развертывания и доставки программного обеспечения.

Работая в сфере DevOps, мы обнаружили, что важно поддерживать ортогональность и синхронизацию развертываний вашего программного обеспечения и инфраструктуры за счет совместной работы в команде (разработчики не являются операционистами, и наоборот).

Чтобы ответить на ваши вопросы:

Развертывание на нескольких серверах

При создании плана автоматического развертывания вы можете указать группу серверов и добавлять/удалять серверы из группы по мере необходимости.

Этап тестирования

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

Развертывание причала

Копирование файла WAR так же просто, как развертывание артефакта на сервере с помощью агента SSH.

тоже смотрел этот вопрос.

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

(И, конечно же, SBT позволяет вам тестировать, предотвращать упаковку, и существует множество инструментов развертывания, которые знакомы с WAR-ами и Jettyies.)

Это типичный сценарий DevOps. Я думаю, что Jenkins поможет удовлетворить первые два требования, добавив пару плагинов с открытым исходным кодом, чтобы получить больший контроль над заданиями, например «Поток сборки CloudBees» и «Параметры узла и метки».

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

Я предлагаю вам обратиться к непрерывной интеграции OpenStack, особенно по вопросам управления проектами и автоматизации инфраструктуры: http://ci.openstack.org/

Для развертывания существует городской код uDeploy, который позволяет вам разработать автоматизированный процесс развертывания в удобном графическом интерфейсе, но пока он является коммерческим (приобретен IBM). На самом деле Дженкинс может сделать то же самое, но ему нужно больше кода и сценариев.