Достаточное количество времени назад я писал о первых шагах в автоматизации 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 вида:
- standalone.xml
- standalone.conf
Такой формат взаимодействия с конфигурацией отлично ложится на шаблоны через jinja templates.
Кроме этого, создание юзера и его пароля, кроме того, что отлично автоматизируется через add-user.sh, имеют отличное свойство добавляться копированием хэша, что позволяет на одной машине при наличии возможности переносить созданного юзера добавлением строк в application-users.properties
Таким образом, использование Wildfly отлично сочетается с использованием Ansible, позволяя держать все окружение в формате yml кода.
Так же, на данный момент, аналогичные модули можно найти в других configuration management тулзах, в частности puppet
SyrexS
А чем он принципиально отличается от простого копирования?
SicYar Автор
принципиальное отличие в том, что можно ear положить в одну директорию для хоть 10 wf и дальше ansible задеплоит во все необходимые сервера
с учетом, что например бывает сложно что-то отправить на прод, это облегчает процесс деплоя
Так же использование ansible помогает делать проверки разные, задача часто строится не только из копирования, но так же из добавления хост зависимых переменных например, проверок и тд, что может привести к сложному bash\python скрипту, в случае с ansible может быть немного проще кмк
SyrexS
Я не про Ansible в целом. А про смысл конкретного модуля
SicYar Автор
на мой взгляд это более удобно, использовать данный модуль с его подходом использования единой директории, ну и это позволяет использовать общий воркфло для всего деплоя
AlexGluck
Ничем, КГ/АМ.