Best practise for deploying my app with Karaf

[PJR69 <pe...@insta.fi>]

I'm working on an application that has roughly 6-8 OSGi-bundles written by
us. Then we have around 40-50 OSGi-bundles as dependencies from our bundles.

Our application environment will be internal network with no internet
access. The Karaf-instances hosting the application will be running in quite
restricted virtual machines that access database(s) and offer
JMS/RMI/SOAP-endpoints for the clients. I don't think we will be able to
setup any maven repositories.

We do need to update the application from time to time and the application
is pretty mission critical, needs to be running with 99.999+ availability.

Currently I'm thinking that to update the application we would use parallel
Karaf-instances. Something like "APPv1" as the initial child instance; and
if we need to make some update/fix, we would create a new instance, like
"APPv2" and then deploy all the new stuff there, bring it into production
(with different endpoint addresses so it can co-exist for a short while with
the APPv1) and then change all clients to use the new version and then
shutdown and destroy the old version.

So, what would be the best practise to deploy this application?

My thoughts:
- The quick'n'dirty way would be to just copy all jar-files to the
Deploy-folder of Karaf. This doesn't feel very manageable wrt versioning and
packaging. We need to be very exact wrt versions. Prolly works ok for
development.
- Create a KAR-file and make one "feature" of the application and include
all dependencies inside the KAR-file.
- Create a single jar-file and embed all dependencies into it.

Currently the KAR-file feels like a way to go. But how about the concept of
"feature", it feels like some "extension" into Karaf and not really an
"application". But is it just semantics; would a feature from a KAR-file be
as "real" of an application as any other application deployed as plain
jar-files? Would our app lose any services/functionality of Karaf/OSGi if it
would be deployed as a "feature" from KAR-file?

All comments/ideas are highly appreciated.



--
View this message in context: http://karaf.922171.n3.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp4026544.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Best practise for deploying my app with Karaf

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Just an update, about "dependencies": if the bundle is flagged with 
dependency=true in the features XML, the kar deployer can use an already 
installed bundle.

A Maven repository manager (like Archiva) is a good approach, but a 
simple Maven structure in a directory (that you populated with mvn 
deploy:deploy-file for instance) works as well.

Regards
JB

On 10/23/2012 01:09 PM, Christian Schneider wrote:
> When you install a kar file it is added as an additional repository for
> karaf and the features are started.
> So there is not much difference between a kar file and a company maven
> repo when looking at how the application starts up.
>
> The only downside to a kar file is if you have several applications with
> shared dependencies. As you typically pack all dependencies into the kar
> file you would
> have a lot of duplication. As long as you only deploy one application it
> should be no issue.
>
> A feature is the right way to define an application in karaf. It is not
> only for karaf extensions.
>
> If you have the option you should still consider to setup a maven
> repository manager and deploy from there. I think it is a great way to
> connect your development process which ends in the maven repo to the
> deployment which starts there.
>
> About having a second container where you do the upgrades and then
> switch. I think this is exactly the way to go for mission critical
> applications.
>
> Christian
>
> On 10/23/2012 12:46 PM, PJR69 wrote:
>> I'm working on an application that has roughly 6-8 OSGi-bundles
>> written by
>> us. Then we have around 40-50 OSGi-bundles as dependencies from our
>> bundles.
>>
>> Our application environment will be internal network with no internet
>> access. The Karaf-instances hosting the application will be running in
>> quite
>> restricted virtual machines that access database(s) and offer
>> JMS/RMI/SOAP-endpoints for the clients. I don't think we will be able to
>> setup any maven repositories.
>>
>> We do need to update the application from time to time and the
>> application
>> is pretty mission critical, needs to be running with 99.999+
>> availability.
>>
>> Currently I'm thinking that to update the application we would use
>> parallel
>> Karaf-instances. Something like "APPv1" as the initial child instance;
>> and
>> if we need to make some update/fix, we would create a new instance, like
>> "APPv2" and then deploy all the new stuff there, bring it into production
>> (with different endpoint addresses so it can co-exist for a short
>> while with
>> the APPv1) and then change all clients to use the new version and then
>> shutdown and destroy the old version.
>>
>> So, what would be the best practise to deploy this application?
>>
>> My thoughts:
>> - The quick'n'dirty way would be to just copy all jar-files to the
>> Deploy-folder of Karaf. This doesn't feel very manageable wrt
>> versioning and
>> packaging. We need to be very exact wrt versions. Prolly works ok for
>> development.
>> - Create a KAR-file and make one "feature" of the application and include
>> all dependencies inside the KAR-file.
>> - Create a single jar-file and embed all dependencies into it.
>>
>> Currently the KAR-file feels like a way to go. But how about the
>> concept of
>> "feature", it feels like some "extension" into Karaf and not really an
>> "application". But is it just semantics; would a feature from a
>> KAR-file be
>> as "real" of an application as any other application deployed as plain
>> jar-files? Would our app lose any services/functionality of Karaf/OSGi
>> if it
>> would be deployed as a "feature" from KAR-file?
>>
>> All comments/ideas are highly appreciated.
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp4026544.html
>>
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Best practise for deploying my app with Karaf

[PJR69 <pe...@insta.fi>]

Thank you for good comments!

I just noticed that there is a page about making Custom Distributions on the Karaf-website, so I'm thinking that it might actually also be a reasonable way to go. This way we could package the whole app as a single "sw appliance" to be deployed into a virtual machine for integration testing and production.

- Petri

________________________________
From: Christian Schneider [via Karaf] [mailto:ml-node+s922171n4026546h64@n3.nabble.com]
Sent: 23. lokakuuta 2012 14:10
To: Riipinen Petri
Subject: Re: Best practise for deploying my app with Karaf

When you install a kar file it is added as an additional repository for
karaf and the features are started.
So there is not much difference between a kar file and a company maven
repo when looking at how the application starts up.

The only downside to a kar file is if you have several applications with
shared dependencies. As you typically pack all dependencies into the kar
file you would
have a lot of duplication. As long as you only deploy one application it
should be no issue.

A feature is the right way to define an application in karaf. It is not
only for karaf extensions.

If you have the option you should still consider to setup a maven
repository manager and deploy from there. I think it is a great way to
connect your development process which ends in the maven repo to the
deployment which starts there.

About having a second container where you do the upgrades and then
switch. I think this is exactly the way to go for mission critical
applications.

Christian

On 10/23/2012 12:46 PM, PJR69 wrote:

> I'm working on an application that has roughly 6-8 OSGi-bundles written by
> us. Then we have around 40-50 OSGi-bundles as dependencies from our bundles.
>
> Our application environment will be internal network with no internet
> access. The Karaf-instances hosting the application will be running in quite
> restricted virtual machines that access database(s) and offer
> JMS/RMI/SOAP-endpoints for the clients. I don't think we will be able to
> setup any maven repositories.
>
> We do need to update the application from time to time and the application
> is pretty mission critical, needs to be running with 99.999+ availability.
>
> Currently I'm thinking that to update the application we would use parallel
> Karaf-instances. Something like "APPv1" as the initial child instance; and
> if we need to make some update/fix, we would create a new instance, like
> "APPv2" and then deploy all the new stuff there, bring it into production
> (with different endpoint addresses so it can co-exist for a short while with
> the APPv1) and then change all clients to use the new version and then
> shutdown and destroy the old version.
>
> So, what would be the best practise to deploy this application?
>
> My thoughts:
> - The quick'n'dirty way would be to just copy all jar-files to the
> Deploy-folder of Karaf. This doesn't feel very manageable wrt versioning and
> packaging. We need to be very exact wrt versions. Prolly works ok for
> development.
> - Create a KAR-file and make one "feature" of the application and include
> all dependencies inside the KAR-file.
> - Create a single jar-file and embed all dependencies into it.
>
> Currently the KAR-file feels like a way to go. But how about the concept of
> "feature", it feels like some "extension" into Karaf and not really an
> "application". But is it just semantics; would a feature from a KAR-file be
> as "real" of an application as any other application deployed as plain
> jar-files? Would our app lose any services/functionality of Karaf/OSGi if it
> would be deployed as a "feature" from KAR-file?
>
> All comments/ideas are highly appreciated.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp4026544.html
> Sent from the Karaf - User mailing list archive at Nabble.com.


________________________________
If you reply to this email, your message will be added to the discussion below:
http://karaf.922171.n3.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp4026544p4026546.html
To start a new topic under Karaf - User, email ml-node+s922171n930749h57@n3.nabble.com
To unsubscribe from Karaf - User, click here<http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=930749&code=cGV0cmkucmlpcGluZW5AaW5zdGEuZml8OTMwNzQ5fDU5NTY5OTMzOA==>.
NAML<http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: http://karaf.922171.n3.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp4026544p4026547.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Best practise for deploying my app with Karaf

[Christian Schneider <ch...@die-schneider.net>]

When you install a kar file it is added as an additional repository for 
karaf and the features are started.
So there is not much difference between a kar file and a company maven 
repo when looking at how the application starts up.

The only downside to a kar file is if you have several applications with 
shared dependencies. As you typically pack all dependencies into the kar 
file you would
have a lot of duplication. As long as you only deploy one application it 
should be no issue.

A feature is the right way to define an application in karaf. It is not 
only for karaf extensions.

If you have the option you should still consider to setup a maven 
repository manager and deploy from there. I think it is a great way to 
connect your development process which ends in the maven repo to the 
deployment which starts there.

About having a second container where you do the upgrades and then 
switch. I think this is exactly the way to go for mission critical 
applications.

Christian

On 10/23/2012 12:46 PM, PJR69 wrote:
> I'm working on an application that has roughly 6-8 OSGi-bundles written by
> us. Then we have around 40-50 OSGi-bundles as dependencies from our bundles.
>
> Our application environment will be internal network with no internet
> access. The Karaf-instances hosting the application will be running in quite
> restricted virtual machines that access database(s) and offer
> JMS/RMI/SOAP-endpoints for the clients. I don't think we will be able to
> setup any maven repositories.
>
> We do need to update the application from time to time and the application
> is pretty mission critical, needs to be running with 99.999+ availability.
>
> Currently I'm thinking that to update the application we would use parallel
> Karaf-instances. Something like "APPv1" as the initial child instance; and
> if we need to make some update/fix, we would create a new instance, like
> "APPv2" and then deploy all the new stuff there, bring it into production
> (with different endpoint addresses so it can co-exist for a short while with
> the APPv1) and then change all clients to use the new version and then
> shutdown and destroy the old version.
>
> So, what would be the best practise to deploy this application?
>
> My thoughts:
> - The quick'n'dirty way would be to just copy all jar-files to the
> Deploy-folder of Karaf. This doesn't feel very manageable wrt versioning and
> packaging. We need to be very exact wrt versions. Prolly works ok for
> development.
> - Create a KAR-file and make one "feature" of the application and include
> all dependencies inside the KAR-file.
> - Create a single jar-file and embed all dependencies into it.
>
> Currently the KAR-file feels like a way to go. But how about the concept of
> "feature", it feels like some "extension" into Karaf and not really an
> "application". But is it just semantics; would a feature from a KAR-file be
> as "real" of an application as any other application deployed as plain
> jar-files? Would our app lose any services/functionality of Karaf/OSGi if it
> would be deployed as a "feature" from KAR-file?
>
> All comments/ideas are highly appreciated.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp4026544.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Best practise for deploying my app with Karaf

[Freeman Fang <fr...@gmail.com>]

Hi,

Given what you need, like the multiple instance failover, the service address transparency, I suggest you take a look at Fuse Fabric[1], it should be very helpful for your scenario.

[1]http://fuse.fusesource.org/fabric/

－－－－－－－－－－－－－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042

On 2012-10-23, at 下午6:46, PJR69 wrote:

> I'm working on an application that has roughly 6-8 OSGi-bundles written by
> us. Then we have around 40-50 OSGi-bundles as dependencies from our bundles.
> 
> Our application environment will be internal network with no internet
> access. The Karaf-instances hosting the application will be running in quite
> restricted virtual machines that access database(s) and offer
> JMS/RMI/SOAP-endpoints for the clients. I don't think we will be able to
> setup any maven repositories.
> 
> We do need to update the application from time to time and the application
> is pretty mission critical, needs to be running with 99.999+ availability.
> 
> Currently I'm thinking that to update the application we would use parallel
> Karaf-instances. Something like "APPv1" as the initial child instance; and
> if we need to make some update/fix, we would create a new instance, like
> "APPv2" and then deploy all the new stuff there, bring it into production
> (with different endpoint addresses so it can co-exist for a short while with
> the APPv1) and then change all clients to use the new version and then
> shutdown and destroy the old version.
> 
> So, what would be the best practise to deploy this application?
> 
> My thoughts:
> - The quick'n'dirty way would be to just copy all jar-files to the
> Deploy-folder of Karaf. This doesn't feel very manageable wrt versioning and
> packaging. We need to be very exact wrt versions. Prolly works ok for
> development.
> - Create a KAR-file and make one "feature" of the application and include
> all dependencies inside the KAR-file.
> - Create a single jar-file and embed all dependencies into it.
> 
> Currently the KAR-file feels like a way to go. But how about the concept of
> "feature", it feels like some "extension" into Karaf and not really an
> "application". But is it just semantics; would a feature from a KAR-file be
> as "real" of an application as any other application deployed as plain
> jar-files? Would our app lose any services/functionality of Karaf/OSGi if it
> would be deployed as a "feature" from KAR-file?
> 
> All comments/ideas are highly appreciated.
> 
> 
> 
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp4026544.html
> Sent from the Karaf - User mailing list archive at Nabble.com.