Непрерывное развертывание OSGi-приложения на jenkins
Потратив пару часов, пытаясь понять, как заставить работать непрерывное развертывание в случае приложения на основе OSGi, я наконец задаю свой первый вопрос о стековом потоке, надеясь на некоторые признаки того, что я мог сделать неправильно или пропустить - как-то Я чувствую себя на неправильном пути...
Вот чего я хочу добиться:
собрать несколько пакетов и установить их в репозиторий maven (здесь нет проблем, используя bnd)
Теперь, имея все пакеты, составляющие мое приложение (проходя все тесты и т. д.), я хочу развернуть и запустить приложение, то есть запустить некоторую среду OSGi с использованием этих пакетов.
Запуск не является проблемой - "mvn pax:provision -Dframework=equinox" делает свое дело. Мое приложение запускает причину, поэтому легко проверить через браузер, чтобы увидеть, все ли выглядит хорошо (в дополнение ко всем тестам)
Но теперь, пытаясь быть "непрерывным", в следующий раз, когда я захочу применить эту процедуру, я действительно должен сначала закрыть работающий экземпляр моего приложения (освободив по крайней мере используемый порт). Итак, чтобы перезапустить все, мне сначала нужно как-то закрыть старую установку.
И вот тут начинается мой вопрос: помогает ли мне что-то в этом? Я понимаю, что есть плагин maven-deploy-plugin, но это кажется полезным только при развертывании некоторого файла WAR/EAR в некотором стандартном контейнере приложения (кажется, без необходимости перезапуска).
Мне действительно нужно всего лишь запустить какой-нибудь скрипт, чтобы запустить среду OSGi, а затем, в следующий раз, изящно выключить его, прежде чем я запусту его снова. В tomcat, jetty, jboss и т. П. Есть несколько сценариев shutdown.sh или mvn jetty: инструкции по остановке, но действительно ли я должен сам писать такие сценарии? Именно здесь я думаю, что начинаю идти по неверному пути. Должно быть, у кого-то эти проблемы были до меня и я решил их;)
Я понял, что могу каким-то образом попытаться использовать JMX или использовать консоль telnet для доступа к запущенному экземпляру, чтобы выполнить команду "stop 0", но это кажется неправильным.
Процессы, запущенные из jenkins, должны компилировать / строить / развертывать проекты, но не запускать долго работающие потоки, я думаю, поэтому мне как-то нужно запустить какой-то процесс "снаружи", который я хочу убить первым при следующей попытке снова.
Есть идеи? Может я что-то упустил? Заранее спасибо за любой вклад по этому вопросу!
4 ответа
На мой взгляд, телнет-путь кажется самым чистым.
Однако, если вы хотите проявить творческий подход, вы можете создать простой пакет завершения работы, который вы устанавливаете до того, как будете готовы к повторному развертыванию. Убедитесь, что у вас включено автоматическое развертывание, чтобы пакет был активирован после установки. Когда этот пакет активируется, его задача состоит в том, чтобы аккуратно завершить работу текущего работающего контейнера Equinox.
Я бы по-прежнему предложил подход telnet, так как вам нужно убедиться, что ваш контейнер отключен, прежде чем пытаться выполнить повторное развертывание.
Если вам не нравится ни один из этих подходов, взгляните на Apache Karaf. Вы можете отправлять команды запущенного контейнера. Вы даже можете остановиться, удалить, а затем переустановить все ваши пакеты, даже не останавливая Karaf.
Караф может бегать поверх Apache Felix или Eclipse Equinox.
Может быть, я что-то упустил, но почему вы хотите завершить работу всей платформы OSGi, когда хотите переразвернуть / обновить приложение? Весь смысл OSGi в том, что вы можете обновлять пакеты без необходимости перезагружать всю систему (помните любимый материал "Вам нужно перезапустить Windows, чтобы изменения вступили в силу"?). Более того, перезапуск всей платформы будет скрывать любые ошибки, связанные с освобождением ресурсов в методе stop вашего комплекта, поэтому я определенно рекомендую тестировать, обновляя только комплект (и проверяя журналы и потребление ресурсов после нескольких циклов запуска / остановки!))
Если бы я делал это, я бы запустил каркас OSGi только один раз полностью независимо от maven, а затем использовал бы один из многих возможных способов развертывания и обновления в нем пакета без перезапуска каркаса.
Например: * вы можете настроить систему таким образом, чтобы обновленная версия пакета всегда помещалась в определенное место на диске, а затем использовать консоль OSGi /telnet/ независимо от того, какой инструмент администратора поставляется с платформой OSGi, которую вы выбрали для вызова "Обновить ".
или вы можете использовать какой-нибудь инструмент, который может подключиться к работающему экземпляру фреймворка и обновить пакет. Например, для Eclipse есть плагин от ProSyst, который делает именно это.
или вы можете использовать какое-либо реальное программное обеспечение для удаленного управления, которое может помочь вам протестировать удаленное развертывание на нескольких целевых объектах одновременно, а также непосредственно контролировать состояние развертывания. Одна из таких систем, например, mPower Remote Manager
Относительно освобождения порта - если у вас есть проблемы с этим, скорее всего, причина в самом комплекте, и перезапуск платформы OSGi не решит ее, потому что в реальном сценарии fw не должен быть перезапущен после обновления один комплект. Проверьте, останавливаете ли вы все потоки и правильно ли высвобождаете все ресурсы в методе stop() BundleActivator вашего пакета.
После некоторых новых идей и проверки нескольких подходов, я хочу задокументировать то, что мне показалось наиболее подходящим для моего первоначального вопроса о непрерывном развертывании приложения на основе OSGi.
Основная проблема здесь заключалась не в том, чтобы иметь возможность обновлять пакеты в работающем приложении OSGi, просто поместив их в какой-то каталог (например, это можно сделать с помощью org.apache.felix.fileinstall), а в том, чтобы иметь возможность непрерывно развертывать текущий состояние программного обеспечения прямо из SCM - автоматически, через jenkins, точно так же, как это будет выглядеть при развертывании в первый раз.
Для меня решение было довольно простым: на самом деле есть версия демона pax-runner, которую я могу использовать следующим образом:
В конфигурации проекта jenkins, Post-steps, выполнить shell я поместил что-то вроде:
export BUILD_ID=dontKillMe
myproject/etc/scripts/postDeploy.sh &
со скриптом postDeploy, похожим на
#!/bin/bash
cd <myproject>/workspace/skysail.server.ext.osgimonitor/target
cp project.zip /somepath/pax-runner-1.8.5/
cd /somepath/pax-runner-1.8.5/
unzip project.zip
cd project
./rund.sh
с окончательным сценарием rund.sh, аналогичным
java $JAVA_OPTS -cp .:bin/pax-runner-1.8.5.jar org.ops4j.pax.runner.daemon.DaemonLauncher \
--startd --clean scan-composite:file:rund.composite \
--log=DEBUG
rund.composite - это просто файл, ссылающийся на некоторые файлы обеспечения, подобные этому
scan-file:bundledefs/core.setup
scan-file:bundledefs/logging.setup
scan-file:bundledefs/restlet.setup
И, наконец, в качестве примера для этих файлов:
mvn:commons-lang/commons-lang/2.6
mvn:org.codehaus.jackson/jackson-core-lgpl/1.9.5
mvn:org.codehaus.jackson/jackson-mapper-lgpl/1.9.5
mvn:javax.xml.stream/com.springsource.javax.xml.stream/1.0.1
mvn:org.xmlpull/com.springsource.org.xmlpull/1.1.4.c
mvn:com.thoughtworks.xstream/com.springsource.com.thoughtworks.xstream/1.3.1
mvn:org.codehaus.jettison/com.springsource.org.codehaus.jettison/1.0.1
...
При такой настройке всякий раз, когда проект создается jenkins, запускается сценарий после развертывания, и приложение перезапускается в чистом, начальном состоянии.
В bndtools это все автоматизировано... Как только вы сохраняете исходный файл, он создает jar-файл и сообщает платформе, какие пакеты обновлять или устанавливать, когда они новые. Попробуйте, удивительный короткий цикл редактирования-компиляции-сборки-запуска-отладки продолжительностью около 3 секунд.