No, Ed is saying that in most cases he does indeed update his production
karaf instances; however some components (e.g. Apache Karaf) don't take
well to this and then he has to re-deploy Karaf. So re-deployment is the
exception not the rule.
I think the question is whether it really is easier and cheaper to replace
100% of your production instance rather than 1%, and if so whether this is
enough to make this option "better"? Is "I upgraded Windows from 8.0 to
8.1 and now my built-in microphone no longer works" actually a better
place to be than "I upgraded the Creative drivers and now my built-in
microphone no longer works"?
> I have no hands on experience with most of these technologies, and am
> really looking for information not trolling
. why wouldn't this be
> simpler using docker? Do you update your production karaf instances
> rather than redeploy them? My impression is that you say you basically
> redeploy karaf when a change is needed, using ansible. Would you get more
> or less the same effect rebuilding the appropriate docker container and
> (re)-deploying it?
>
> thanks for any insights
.
>
> david jencks
>
> On Apr 13, 2015, at 10:15 AM, "Ed Welch" <e...@edjusted.com> wrote:
>
>> This is a topic I've spent some time on myself and I like this
>> discussion.
>>
>> Ryan, you have asked a lot of questions I have had, and raised some
>> concerns I have had as well.
>>
>> For what it's worth, here is my current setup:
>>
>> I hand maintain a features.xml file for each of my applications (a
>> cohesive grouping of bundles and dependencies that make up an
>> application). I usually only deploy one, maybe two "applications" into
>> one instance of karaf (and run many instances of karaf on one server).
>>
>> I have not spent much time with the maven plugin for generating
>> features, so I can't comment on it too much. What I usually do is put
>> the features.xml in its own maven submodule along side the other modules
>> in my project, which makes it easy to rebuild it and do a repo-refresh
>> for development.
>>
>> This does require me to maintain dependencies twice which I don't love,
>> but it also keeps me very close with my projects dependencies and
>> transitive dependencies which I think has helped me build better
>> applications, and certainly made me more mindful of "bad" libraries
>> which include layers upon layers of transitive dependencies. (which
>> makes me think of the package-the-world strategy a lot of people use
>> even within maven, which you were discussing in regards to docker in
>> another thread)
>>
>> As far as deployment. I've always kind of considered the features
>> support in karaf a little soft. Mainly the lack of in place upgrade or
>> lack of dependent feature uninstall, the latter being addressed in karaf
>> 4.
>>
>> So what I came up with was a merger of another technology that i've been
>> toying with, Ansible. On my dev box I try to take full advantage of the
>> OSGi modularity and hot swapping capabilities, I install the app from my
>> features file through the console and then use bundle:watch religiously
>> while developing. I run into a few hiccups when using blueprint
>> services and bundle:watch as bundles will hang onto stale references of
>> services and sometimes I have to swap over to the command console and
>> punch in an a restart, refresh, or update by hand. But really this
>> works well, and I find very fast. (I've also started learning and
>> toying with declarative services, which I think would address some of my
>> reference issues)
>>
>> When i move off my machine, I let Ansible take over. I setup ansible to
>> deploy karaf, i often have many karaf deployments on one machine, I
>> favor setting up many standalone instances rather than using the built
>> in karaf instances functionality, as most of the time the karaf
>> instances get their own linux user to provide a nice level of isolation.
>>
>> I always deploy karaf with jolokia, then, using a python module I wrote
>> for ansible, which really just executes simple http calls to jolokia to
>> execute features install commands. I have an ansible .yml file which
>> lists out the feature repo url's and the features I want installed, and
>> ansible then installs them:
>>
>> ##### SOA USER #################################################
>>
>> soa_version: '0.1.11'
>> soa_camel_version: '2.15.1'
>> soa_activemq_version: '5.11.1'
>> soa_infinispan_version: '7.1.1.Final'
>>
>> soa_repos:
>> - { url: 'mvn:org.apache.camel.karaf/apache-camel/{{ soa_camel_version
>> }}/xml/features' }
>> - { url: 'mvn:org.apache.activemq/activemq-karaf/{{
>> soa_activemq_version }}/xml/features' }
>> - { url: 'mvn:org.infinispan/infinispan-core/{{ soa_infinispan_version
>> }}/xml/features' }
>> - { url: 'mvn:com.earthlink.business/soa-feature/{{ soa_version
>> }}/xml/features' }
>>
>> soa_features:
>> - { name: 'webconsole', version: '' }
>> - { name: 'elnk-soa-feature-dev', version: '{{ soa_version }}' }
>>
>> We are on Karaf 3 in our prod environments, which doesn't do dependent
>> feature uninstall, which makes upgrading something like camel a little
>> tricky, so i've been handling upgrades by bringing down karaf, deleting
>> the data/cache dir, bring it back up as if it were a clean install, and
>> then installing the features as mentioned above, ansible does all this
>> for me.
>>
>> I know this isn't very modular, or on the fly, or OSGi. But it's very
>> reliable, guarantees me the app server is the way I expect it, and
>> because they run in clusters, the downtime doesn't hurt anybody. The
>> other thing I don't like is that I have configs in pom files for the
>> app, features file for the feature, and this ansible file for the
>> server. Most of my peers are dumb and this hurts their brain. Maybe
>> i'm just being bullish because I built it... but they just keep telling
>> me that they want to use docker, and that if they used docker they
>> wouldn't have to do any of this... sigh...
>>
>> With the dependent feature uninstall in karaf 4, i may revist this. but
>> to be honest, I really love that I can delete that cache dir and have a
>> clean slate. And for my production environments, this isn't really
>> causing us any problems. I still get plenty of use of live reload and
>> the OSGi benefits both from a nice modular application design, and in my
>> development stages.
>>
>>
>> Would love any feedback, and hope maybe my usage may be interesting or
>> inspiring to anyone.
>>
>> Ed
>
>
