karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Johnson" <bradj...@redhat.com>
Subject RE: Levels of Containerization - focus on Docker and Karaf
Date Thu, 12 Jan 2017 19:10:53 GMT
Agreed about the testing.  One problem with much of the Camel documentation is it shows the
use of Processors/Exchanges instead of just POJOs.  For the most part that sort of unit testing
is simple if one isn’t using Processor/Exchanges.  The CDI makes it even easier yet.  But
PAX and Camel Blueprint Test Support can be slow and fiddly. 

 

Since Jetty is a simple web server it is commonly included in Karaf/application stacks. Its
concerns are orthogonal to those of OSGi/Felix (or Equinox)/Karaf.  OSGi based application
servers like Glassfish use it for the web server/webservices.  I think Jetty is about 10MB
soaking wet.

 

I’m not sure what dependency issues you ran into.  One of the great benefits to having the
classloader isolation in OSGi is that you can run different versions of the same library without
stepping on one another. 

 

Obviously Docker/Kubernettes, etc. are not at odds with Karaf and exist at different levels.
 Spinning up multiple Docker containers for single services seems (A) heavy on processes,
(B) heavu on configuration of URI/ports, and (c) potentially requires separate security set
up for each..  Since Camel routing for received webservice calls is so simple it makes it
a relatively easy proposition. So using the Karaf instance for multiple services isn’t just
about the classloader isolation.

 

But all that depends on the use case and it’s hard to make any sweeping generalizations.
 At some point that becomes as much art as science.

 

Testing though is the biggest issue.  With the static profiles it should be easy to run a
Karaf instance, exercise it as a black box against some test stubs and verify basic operations.

 

I wish they’d redo that Camel documentation to move the information about Procssor/Exhange
to the equivalent of an Appendix. 

 

 

From: Elliot Metsger [mailto:emetsger@gmail.com] 
Sent: Thursday, January 12, 2017 11:32 AM
To: user@karaf.apache.org
Subject: Re: Levels of Containerization - focus on Docker and Karaf

 

Hi,

 

I'm involved in a project [1] that is based on Karaf and Camel.  We recently produced a milestone
that involved a working demonstration of the code base using Docker [2].  This was one of
our first forays into this technology stack, so we not only came away with some impressions
of the stack but also noted some of the same questions you ask with regard to the various
containerization choices.

 

Fundamentally, we noted that that properly testing our code to work in an OSGI container is
challenging and time consuming (we used Pax Exam [3]); we would spend more time fiddling around
with the test fixtures than actually writing tests and fixing any bugs they illuminated. 


 

Secondarily, we struggled at times to find and resolve any conflicts in our Maven dependency
tree related to using an OSGI bundle instead of a dependency's non-OSGI counterpart.  We also
struggled with some of the nuances of running Karaf and Camel, including discovering bugs
in each of these frameworks or their components.

 

All of that being said, the result is something we are very pleased with.  In order to produce
our milestone demo, we containerized all of our services, which included two different instances
of Karaf, an RDF triple store (Java web application server), the Fedora 4 linked data repository
[4] (Java web application server), and other services (also a Java web application server).
 The exercise of producing this Dockerized milestone was very illuminating; we worked out
some additional architectural issues and other bugs that our integration tests by themselves
didn't do (and later added additional ITs to cover these discovered issues).

 

Personally, my observation is that there seems to be a lot of overlap in containerization
technologies, but it seems the levels of abstraction differ with different tradeoffs.  For
example, if you desire classloader isolation, you could use a single instance of Karaf running
multiple services, or you could simply spin up a Docker container for each service, running
each service in a traditional web app container.  You'd have to decide if embracing Karaf
and OSGI way of doing things is better than working with "heavy" Docker containers and traditional,
stable, well-understood Java application servers like Jetty.

 

Good discussion, I've enjoyed reading this thread!

 

[1] https://github.com/fcrepo4-labs/fcrepo-api-x

[2] https://github.com/fcrepo4-labs/fcrepo-api-x-demo

[3] https://ops4j1.jira.com/wiki/x/PwA8Aw

[4] https://github.com/fcrepo4/fcrepo4

 

On Wed, Jan 11, 2017 at 3:07 PM, CodeCola <prasenjit@rogers.com <mailto:prasenjit@rogers.com>
> wrote:

Not a question but a request for comments. With a focus on Java.

Container technology has traditionally been messy with dependencies and no
easy failsafe way until Docker came along to really pack ALL dependencies
(including the JVM) together in one ready-to-ship image that was faster,
more comfortable, and easier to understand than other container and code
shipping methods out there. The spectrum from (Classical) Java EE Containers
(e.g. Tomcat, Jetty) --> Java Application Servers that are containerized
(Karaf, Wildfly, etc), Application Delivery Containers (Docker) and
Virtualization (VMWare, Hyper-V) etc. offers a different level of isolation
with different goals (abstraction, isolation and delivery).

What are the choices, how should they play together, should they be used in
conjunction with each other as they offer different kinds of
Containerization?

<http://karaf.922171.n3.nabble.com/file/n4049162/Levels_of_Containerization.png>



--
View this message in context: http://karaf.922171.n3.nabble.com/Levels-of-Containerization-focus-on-Docker-and-Karaf-tp4049162.html
Sent from the Karaf - User mailing list archive at Nabble.com.

 


Mime
View raw message