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
