Новые подходы автоматизации Wildfly

    Доброго времени суток хаброжители.
    Достаточное количество времени назад я писал о первых шагах в автоматизации Wildfly, но прогресс не стоит на месте и пришло время взглянуть на новые подходы.
    Добро пожаловать под кат


    Проект Wildfly к моему большому удовольствию, не стоит на месте, а активно развивается. Работая с ним достаточное количество времени (уже года 4 !), удалось обуздать и наладить процессы.

    Важной находкой является в первую очередь является отличный модуль для ansible — jboss (да-да, он может работать и с jboss ). Модуль официально представлен на страничке RedHat раздела Ansible и дает достаточно удобный функционал для управлениями деплоем
    Инфраструктура у нас построена полностью на ansible, что позволило без проблем интегрировать данный модуль в имеющиеся пайпы работы с окружениями.
    Достаточно красивый на мой взгляд пример функциональности:
    - name: APP deployment
      jboss:
        src: "DIR_WITH_EAR/application_file.ear" #ear/war/jar файл для деплоя
        deploy_path: 'wildfly_path/deployments' #Директория для деплоя
        deployment: "application_file_version.ear" #Версия приложения - возможно изменение при деплое
    

    В чем неотвратимое удобство в данном случае?
    Необходимый файл для деплоя необходимо положить непосредственно только в одну директорию и в дальнейшем из нее можно деплоить в несколько application servers — это экономит время на копирование, скачивание и так же экономит место, необходимое под файл.

    Так же не стоит забывать, что конфигурации wildfly сервера представлены в файлах xml вида:

    1. standalone.xml
    2. standalone.conf


    Такой формат взаимодействия с конфигурацией отлично ложится на шаблоны через jinja templates.

    Кроме этого, создание юзера и его пароля, кроме того, что отлично автоматизируется через add-user.sh, имеют отличное свойство добавляться копированием хэша, что позволяет на одной машине при наличии возможности переносить созданного юзера добавлением строк в application-users.properties
    Таким образом, использование Wildfly отлично сочетается с использованием Ansible, позволяя держать все окружение в формате yml кода.

    Так же, на данный момент, аналогичные модули можно найти в других configuration management тулзах, в частности puppet
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 11

      0
      А чем он принципиально отличается от простого копирования?
        –1
        принципиальное отличие в том, что можно ear положить в одну директорию для хоть 10 wf и дальше ansible задеплоит во все необходимые сервера
        с учетом, что например бывает сложно что-то отправить на прод, это облегчает процесс деплоя
        Так же использование ansible помогает делать проверки разные, задача часто строится не только из копирования, но так же из добавления хост зависимых переменных например, проверок и тд, что может привести к сложному bash\python скрипту, в случае с ansible может быть немного проще кмк
          0
          Я не про Ansible в целом. А про смысл конкретного модуля
            –1
            на мой взгляд это более удобно, использовать данный модуль с его подходом использования единой директории, ну и это позволяет использовать общий воркфло для всего деплоя
          0
          Ничем, КГ/АМ.
          0
          *
            0
            А что мешало реализовать использовать модуль copy? Просто скопировали файл куда надо, а потом ждём пока задеплоится. А для раздеплоя модуль file. Или вообще не проверять деплой в ансибл, а делать это через лог\консоль.
              –1
              например при 10 имеющихся wf будет занято место в 10 раз больше с модулем copy
              Так же надо тогда следить за нагрузкой на сервере, если модуль делает все шаг за шагом, то после copy придется описывать в скрипте логику старта — часто именно процесс деплоя дает высокую нагрузку на CPU, которая в дальнейшем не будет такой и создавать сервер с большим количеством CPU исключительно для процесса деплоя невыгодно.
              в случае если делать копирование а потом лезть в разные консоли, остается много ручного труда, либо всю эту обработку необходимо описывать каким либо скриптом, что избыточно в данном моменте на мой взгляд.
              на данный момент у меня на сервере 36 WF инстансов работает, таких серверов несколько, ansible является единой точкой деплоя без каких либо сторонних костылей, что облегчает управление и поддержку приложения
                –1
                например при 10 имеющихся wf будет занято место в 10 раз больше с модулем copy

                Вот код можете в нём показать, что вы имеете ввиду? Место будет занято столько же, вот код модуля copy подтверждающий это, вы ошиблись или как то сложно мысль свою доносите.

                Так же надо тогда следить за нагрузкой на сервере, если модуль делает все шаг за шагом, то после copy придется описывать в скрипте логику старта — часто именно процесс деплоя дает высокую нагрузку на CPU, которая в дальнейшем не будет такой и создавать сервер с большим количеством CPU исключительно для процесса деплоя невыгодно.

                В таком случае, исходя из кода обоих модулей, необходимо всегда следить за нагрузкой.

                на данный момент у меня на сервере 36 WF инстансов работает, таких серверов несколько, ansible является единой точкой деплоя без каких либо сторонних костылей, что облегчает управление и поддержку приложения

                Это замечательно, жаль что вы им пользоваться не умеете, и ничего не понимаете, что делаете.
                  0
                  я вообще про это
                  os.remove(os.path.join(deploy_path, "%s.deployed" % deployment))
                  но на самом деле это один из подходов, жаль, что такое решение проблемы вызвало столько негатива у вас
                    0
                    я вообще про это
                    os.remove(os.path.join(deploy_path, "%s.deployed" % deployment))

                    Как это относится хоть к какому то комментарию под вашим мусором, который вы считаете статьёй? И вообще, это раздеплоивание, делаем:

                    file:
                    path: "{{ deployment_file }}.deployed"
                    state: absent

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

                    например при 10 имеющихся wf будет занято место в 10 раз больше с модулем copy

                    Вы писали про экономию места, это голословное заявление, которое вы не можете подтвердить.

                    Так же надо тогда следить за нагрузкой на сервере, если модуль делает все шаг за шагом, то после copy придется описывать в скрипте логику старта

                    Вы писали про контроль нагрузки, ваше решение этого не делает.

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

                    В каком, простите, месте он использует единую директорию?

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

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое