Автоматическое развертывание приложения с Maven и Wildfly

Привет Хабр! Начать хочу с небольшой статьи мануала, как подружить WildFly с Maven.

Wildfly – Это ребрендинг и развитие JBoss AS7/EAP6 в области как администрирования, так и API для разработчика. Wildfly построен с использованием Java SE 7. Отлично интегрируется с основными Java IDE. Краткая цитата из статьи

Немного официальной информации о 10 версии


  • Реализация сертифицирована на соответствие Full- и Web-профилям Java EE 7. Код WildFly распространяется под лицензией LGPL;
  • В отличие от коммерческого продукта JBoss Enterprise Application Platform, позиционируемого как полностью протестированная и сертифицированная платформа Java EE, WildFly ориентирован, прежде всего, на продвижение технологий. WildFly выступает в роли upstream-проекта для коммерческого продукта JBoss Enterprise. В качестве основной области использования WildFly рассматривается разработка и быстрое внедрение прототипов.

Основные особенности релиза


  • Прекращена поддержка Java 7, что позволило обеспечить более глубокую интеграцию с Java 8 Runtime. Добавлена поддержка текущих снапшотов Java 9;
  • Поставка ActiveMQ Artemis в качестве брокера рассылки сообщений (Java Message Service Broker), совместимого на уровне протокола и заменившего собой HornetQ;
  • Поддержка запуска хост-контроллера при помощи CLI. Новая команда embed-host-controller позволяет редактировать содержимое файлов domain.xml и host.xml без запуска дополнительных процессов или открытия сетевых сокетов;
  • Поддержка JavaScript в http-сервере Undertow.io, позволяющая создавать на языке JavaScript серверные скрипты, которые могут обращаться к CDI Beans и JPA Entity Beans. Указанную возможность удобно использовать для создания внешних обвязок или REST-обработчиков. Отредактированный код JavaScript становится доступен сразу и не требует перезапуска приложения;
  • Поддержка одиночного отказоустойчивого развёртывания приложения («singleton deployment»), при котором в случае использования группы кластеризованных серверов развёртывание будет произведено только на одном узле, но в случае выхода этого узла из строя, приложение будет автоматически перенесено на другой узел;
  • Поддержка одиночного отказоустойчивого брокера рассылки сообщений (Singleton MDB), запускающего доставку только на одном узле, но в случае сбоя использующего для обработки сообщений другой узел;
  • Автоматический выбор размера пула SLSB и MDB, в зависимости от имеющихся системных ресурсов;
  • Средства для миграции устаревших подсистем, таких как jbossweb (AS 7.1), jacorb (WildFly 8) и hornetq (WildFly 9), которые автоматизируют преобразование старых конфигураций в эквиваленты, работающие в WildFly 10;
  • В реализации Hibernate 5 значительно улучшено качество байткода, внесены оптимизации производительности и добавлены улучшения в API.

Хочу рассказать об автоматическом деплое в Wildfly с помощью Maven, а так же рассказать кратко о запускe UI в том же самом контейнере.

Необходимо использовать Maven версии не ниже 3.3.9( использую maven 3.5.0 ), иначе Wildfly Plugin не будет работать.

Версия Wildfly, который на данный момент использую — 10.1.0-Final, версия плагина — 1.2.0.Alpha4

В Pom.XML собираемого приложения необходимо прописать данные для подключения к серверу Wildfly

Пример:

            <plugin>
                <groupId>org.wildfly.plugins</groupId>
                <artifactId>wildfly-maven-plugin</artifactId>
                <configuration>
                    <hostname>${wildfly-hostname}</hostname>
                    <port>${wildfly-port}</port>
                    <username>${wildfly-username}</username>
                    <password>${wildfly-password}</password>
                    <name>${wildfly-name}</name>
                </configuration>
            </plugin>

Так же хорошей практикой может быть вынос настроек в settings.xml либо в pom.xml уровнем выше. Это позволит так же использовать профили при деплое – локальный деплой, деплой на прод.

Область профилей в settings.xml.

        <profile>
            <id>localhost</id>
            <properties>
                <wildfly-hostname>localhost</wildfly-hostname>
                <wildfly-port>9990</wildfly-port>
                <wildfly-username>admin</wildfly-username>
                <wildfly-password>admin</wildfly-password>
                <wildfly-name>core.war</wildfly-name>
            </properties>
        </profile>
        <profile>
            <id>dev</id>
            <properties>
                <wildfly-hostname>Prod_Server</wildfly-hostname>
                <wildfly-port>9990</wildfly-port>
                <wildfly-username>admin</wildfly-username>
                <wildfly-password>admin</wildfly-password>
                <wildfly-name>core-prod_vers.war</wildfly-name>
            </properties>
        </profile>

После всех настроек, с помощью maven, из командной строки, из IDE, из, например, Jenkins (maven plugin), можно будет деплоить war c помощью mvn wildfly:deploy, так же можно использовать mvn wildfly:undeploy и mvn wildfly:redeploy для удаления и передеплоя соответственно. Выбор профиля -Plocalhost позволит запускать с настройками из профиля с id localhost, -Pdev соответственно запускает для прода( все данные в настройках дефолтны или вымышлены).

При верной настройке в WildFly консоле в разделе deployments у Вас появится необходимый war.

Кроме этого, WildFly позволяет запускать UI.

Настройка WildFly для запуска UI:

Проект помещать в корень WildFLy в директорию, которую Вы сами выберете для Вашего UI.
В данном примере я использовал директорию UI.

В файле /PathToWildfly/standalone/configuration/standalone.xml необходимо добавить строки(строки с учетом соседних строк, для облегчения поиска):

<location name="/" handler="welcome-content"/>
<location name="/UI/" handler="UI"/>
    <filter-ref name="server-header"/>
    <filter-ref name="x-powered-by-header"/>

<handlers>
    <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    <file name="UI" path="${jboss.home.dir}/UI/widget/build"/>

После этого WildFLy автоматически подхватывает изменения и по адресу localhost:8080/UI будет доступно ваше приложение.

На данный момент запуск был осуществлен с помощью команды ./standalone.sh -b=0.0.0.0 -bmanagement=0.0.0.0, приложение работает на Linux Oracle в screen.

За время использования были выявлены 2 проблемы:

  1. Иногда перезапуск WildFLy затягивается и долго подтягивается localhost:9990 — консоль.
  2. При запуске из Jenkins на Maven 3.3.9 с тэгом redeploy происходит утекание памяти и приложение удаляет обе версии war и ругается на дубликат. (Воспроизводится не всегда)

Данная связка около 2 месяцев, кроме вышеописанных, проблем не встречал. Всем рулит Jenkins в данном случае, он стартует и mvn wildfly:undeploy mvn wildfly:deploy ( использую такую стратегию, т.к. redeploy не отрабатывает) и доставляет собранный UI в директорию UI, обновление происходит по ночам, полёт нормальный.

Так же тестировал запуск на win хосте, отличий не заметил в работе, все так же стабильно.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 7

    0

    При использовании дикомуха (а ранее jboss as) в production стоит учитывать, что некоторые фиксы не доезжают в него из EAP. Как минимум, с AS7.1/EAP6 такая фигня была, т. к. с некоторого момента все фиксы шли в непубличную версию. А в целом Вполне рабочий инструмент.


    Если хочется более легковесного окружения, но не хочется заморачиваться с ручной настройкой cdi/jax-rs/whatever в embedded jetty/tomcat, то рекомендую посмотреть на wildfly swarm, он позволяет забандлить приложение с необходимыми кусками аппсервера.

      0
      Спасибо за подсказку)
      Да инструмент вполне рабочий, свои косяки конечно есть, но пока мне нравится)
    • UFO just landed and posted this here
        +1
        Ну это в 10 версии особенности, нам для 8 хватает)
          0

          У вас extended или sustaining support на 7 от oracle? То для простых смертных поддержка 7 закончилась почти два с половиной года назад.

          • UFO just landed and posted this here
              0

              То, что у части народа ещё живёт 1.4.2 — я в курсе. Но у них обычно не появляется новый аппсервер, всякие модные JEE6 с EJB3 и прочими подобными радостями. Они живут на каком-нибудь древнем имеющемся WebSphere со своей IBM Classic VM, где всё уже отлито в граните.


              Но мы, надеюсь, здесь говорим не за такой махровый энтерпрайз?


              Если не за него, то вполне можно использовать современную поддерживаемую JRE (и source и target использовать по вкусу).


              Если за махровый энтерпрайз, то откуда там взяться wildfly? Там будет EAP/Fuse с необходимой поддержкой, хождение строем по гайдлайнам и прочие радости.


              У нас сохранилась часть софта, которую предстоит ещё мигрировать с 1.7 на 1.8, но большая часть софта переезжает мягко, не нарушая сна. И рефакторится на использование API из 8 уже в рамках поддержки. Из ощутимых проблем с переездом с 7 на 8 вспоминаются разве что проблемы с loop unroll'ом в ранних 1.8 (и с Apache Lucene/Solr, соответственно) и проблемы с DHE >2k в TLS.

        Only users with full accounts can post comments. Log in, please.