RE: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Brad Johnson
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

RE: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Brad Johnson
Agreed. I think it’s all there but not put together in a holistic fashion. Spring Boot has support for all the different ways of working with bundles – blueprint, DS, etc. To use Nick’s term, an “opinionated” and standard way of bring all those elements together would help with adoption.

Re: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Elliot Metsger
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

RE: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Brad Johnson
That's pretty much it except it doesn't use the Kar file. It pulls a distribution of Karaf that has been slimmed down, installs all the bundles, configuration files, and then zips up the entire Karaf instance with all its dependencies. Unzip it, go to the bin directory, and run the Karaf

Re: How to authorize remote JMX access?

2017-01-12 Thread rsteppac2
jbonofre wrote > in etc/org.apache.karaf.management.cfg, did you try to provide the > docker interface ? No. And I also don't quite understand how that should work, as the IP of the container is not known to the outside world. Anyway, this is what I did... System props:

Re: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread CodeCola
Thanks for a great discussion especially the insights from real world deployments. This is what I understand: *"Static" Karaf Profiles* Docker images should be based on a "static distribution" of Karaf generated from Profiles. Starting from Profiles, one can generate a docker image and push it

Re: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Achim Nierbeck
So in the end it looks like Karaf-Boot with profiles, as I tried some long time ago :) would be the best match to what I've seen so far in this thread. The idea I had at the time would be to actually merge those static profiles with a maven plugin generating the static Karaf assembly via the

Re: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Nick Baker
I do agree that an "opinionated" or "prescriptive" stack would help. It shouldn't prohibit the usage of any Karaf feature of course. New users gravitate to full-stack solutions. Agnostic platforms with lots of options and no predefined stack, while obviously having many merits and longer legs

Re: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Guillaume Nodet
I fully agree. However, I'm not sure if there are any pieces actually missing but some documentation and advertisement ... We could eventually add a bit of tooling, but I'm not even sure that's really needed. Guillaume 2017-01-12 16:46 GMT+01:00 Brad Johnson : > Guillaume,

RE: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Brad Johnson
Nick, I've used the profiles and they work well. After the Maven plugin runs you end up with a zip file that has karaf and all its dependencies self-contained. As Guillaume notes the Karaf is slimmed down by removing those services. But if one is compiling and zipping the whole Karaf

RE: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Brad Johnson
Guillaume, I’d mentioned that in an early post as my preferred way to do microservices and perhaps a good way of doing a Karaf Boot. I’ve worked with the Karaf 4 profiles and they are great. Also used your CDI OSGi service. If we could use the Karaf 4 profiles with the CDI implementation

Re: How to authorize remote JMX access?

2017-01-12 Thread Jean-Baptiste Onofré
Hey Ralf, in etc/org.apache.karaf.management.cfg, did you try to provide the docker interface ? Regards JB On 01/12/2017 03:51 PM, rsteppac2 wrote: jbonofre wrote Did you try to force one (and publish on the docker image) ? Sorry, but I don't get what you mean with this. Ralf -- View

Re: How to authorize remote JMX access?

2017-01-12 Thread rsteppac2
jbonofre wrote > Did you try to force one (and publish on the docker image) ? Sorry, but I don't get what you mean with this. Ralf -- View this message in context: http://karaf.922171.n3.nabble.com/How-to-authorize-remote-JMX-access-tp4049177p4049181.html Sent from the Karaf - User mailing

Re: How to authorize remote JMX access?

2017-01-12 Thread Jean-Baptiste Onofré
Yes, that's probably due to the remote port number of the RMI server. Did you try to force one (and publish on the docker image) ? Regards JB On 01/12/2017 03:47 PM, rsteppac2 wrote: Hi JB, jbonofre wrote you should not use your own MBean server but prefer the Karaf provided one. It

Re: How to authorize remote JMX access?

2017-01-12 Thread rsteppac2
Hi JB, jbonofre wrote > you should not use your own MBean server but prefer the Karaf provided > one. > > It should work smoothly. > > Whyt not using the default Karaf one ? You mean the server running on port 1099 by default? If yes, then that worked for remote access as long as Karaf was

Re: How to authorize remote JMX access?

2017-01-12 Thread Jean-Baptiste Onofré
Hi, you should not use your own MBean server but prefer the Karaf provided one. It should work smoothly. Whyt not using the default Karaf one ? Regards JB On 01/12/2017 03:30 PM, rsteppac2 wrote: I am trying to set up Karaf in a Docker container for remote JMX access. With authentication

How to authorize remote JMX access?

2017-01-12 Thread rsteppac2
I am trying to set up Karaf in a Docker container for remote JMX access. With authentication disabled those properties allow me to connect remotely via jconsole: -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.rmi.port=1097 -Dcom.sun.management.jmxremote.port=1098

Re: karaf boot

2017-01-12 Thread Nick Baker
As of right now, No. We're developing this as an enterprise feature (pay). After it's released later this year we'll likely open some of the core stuff like the Source-to-Image build. There's not a lot of code here. Basically we take some files and config checked into a Git repo and construct

Re: karaf boot

2017-01-12 Thread Jean-Baptiste Onofré
Hi, as mentioned some weeks ago on the mailing list, I have a test case using Mesos and Marathon (with Karaf & Cellar). I didn't have time to complete the blog post, I will. Regards JB On 01/12/2017 01:38 AM, Nick Baker wrote: We're deploying into Kubernetes (OpenShift), but it could be

Re: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Nick Baker
Thanks Guillaume! This is perfect for our microservice/containerized Karaf. I'll give this a try and see if we can get our features in startup. We've had issues in the past here. -Nick Baker From: Guillaume Nodet Sent: Thursday, January

Re: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Guillaume Nodet
Fwiw, starting with Karaf 4.x, you can build custom distributions which are mostly static, and that more closely map to micro-services / docker images. The "static" images are called this way because you they kinda remove all the OSGi dynamism, i.e. no feature service, no deploy folder, read-only

Re: Levels of Containerization - focus on Docker and Karaf

2017-01-12 Thread Vincent Zurczak
Le 12/01/2017 à 00:04, Brad Johnson a écrit : And I suppose you’ll commonly run multiple Karaf instances in single Docker instance. Although it is feasible, I think you do not need Karaf instances when you use Karaf Docker containers. The default instance