Re: Is the karaf 4.4.4 docker image arm only?
> Jean-Baptiste Onofré : > yes, the docker image is arm based. I'm adding multi-arch image > support (to have x86 images as well). > I will upload new images soon. Great! Thanks, JB!
Re: Is the karaf 4.4.4 docker image arm only?
> Francois Papon : > It means that your docker image is not immutable and after starting > the Karaf instance, it will download the updated dependencies features > at startup right? Correct! :-) > It's not the common design for docker image and I think it's better to > have a custom Karaf distribution and build a new docker image after > each dependencies update. I'm quite sure all docker enthusiasts would think like you do. :-) Me I just fell in love with the simplicity of the idea, which is similar to the elegance of installing from maven with features in regular karaf (which is the main feature, that made me fall in love with karaf in the first place. That, and karaf feature installs taking the hard part out of finding and loading the right bundles). But... these docker images needs an occasional update when the world changes (such as the OSGi version and possibly the JVM version).
Re: Is the karaf 4.4.4 docker image arm only?
Hi, yes, the docker image is arm based. I'm adding multi-arch image support (to have x86 images as well). I will upload new images soon. Regards JB On Mon, Jan 8, 2024 at 7:36 PM Steinar Bang wrote: > > > Jean-Baptiste Onofré : > > > Hi Steinar > > Let me check about the image type. > > Did you find out anything? > > The docker-maven-plugin I've been using (the one created by spotify), > was abandoned a couple of years back: > https://github.com/spotify/docker-maven-plugin > > So I've been trying to to use a docker-maven-plugin that is maintained: > https://github.com/fabric8io/docker-maven-plugin > > I've succeeded in building a sonar-collector docker image using the new > docker-maven-plugin, but I end up with an arm64 image here as well (even > though I'm building and running on amd64): > > https://github.com/fabric8io/docker-maven-plugin/issues/1739#issuecomment-1881260436 >
Re: Is the karaf 4.4.4 docker image arm only?
It means that your docker image is not immutable and after starting the Karaf instance, it will download the updated dependencies features at startup right? It's not the common design for docker image and I think it's better to have a custom Karaf distribution and build a new docker image after each dependencies update. But it's just my opinion for the Karaf docker image usage :) regards, François On 08/01/2024 20:45, Steinar Bang wrote: Francois Papon : Why not using Jib? https://github.com/GoogleContainerTools/jib/tree/master Unless I'm very mistaken that doesn't do what I want to do. Jib looks like it is for containering a Java application? What I'm doing is something different: 1. I start out with a standard karaf image 2. Then I create a Dockerfile that replaces the org.apache.karaf.features.cfg file with a file that a. has the applications feature repository added to featuresRepositories b, adds the application's feature to featuresBoot So I provision the application using maven and use LATEST, which means I don't have to update the image when the application is updated, I just restart the docker image and it pulls the latest version of the app from maven. That is: I will have to update the image when the world has changed too much (what fails right now is that OSGi 6 can't run OSGi 8 applications, and I can see that the Java version I'm building with can be an issue). I'm trying to create a new docker image for sonar-collector right now, but that is the first time in two years (I don't use the docker image myself, but apparently someone else did and ran into trouble recently).
Re: Is the karaf 4.4.4 docker image arm only?
> Francois Papon : > Why not using Jib? > https://github.com/GoogleContainerTools/jib/tree/master Unless I'm very mistaken that doesn't do what I want to do. Jib looks like it is for containering a Java application? What I'm doing is something different: 1. I start out with a standard karaf image 2. Then I create a Dockerfile that replaces the org.apache.karaf.features.cfg file with a file that a. has the applications feature repository added to featuresRepositories b, adds the application's feature to featuresBoot So I provision the application using maven and use LATEST, which means I don't have to update the image when the application is updated, I just restart the docker image and it pulls the latest version of the app from maven. That is: I will have to update the image when the world has changed too much (what fails right now is that OSGi 6 can't run OSGi 8 applications, and I can see that the Java version I'm building with can be an issue). I'm trying to create a new docker image for sonar-collector right now, but that is the first time in two years (I don't use the docker image myself, but apparently someone else did and ran into trouble recently).
Re: Is the karaf 4.4.4 docker image arm only?
Hi, Why not using Jib? https://github.com/GoogleContainerTools/jib/tree/master regards, François On 08/01/2024 19:36, Steinar Bang wrote: Jean-Baptiste Onofré : Hi Steinar Let me check about the image type. Did you find out anything? The docker-maven-plugin I've been using (the one created by spotify), was abandoned a couple of years back: https://github.com/spotify/docker-maven-plugin So I've been trying to to use a docker-maven-plugin that is maintained: https://github.com/fabric8io/docker-maven-plugin I've succeeded in building a sonar-collector docker image using the new docker-maven-plugin, but I end up with an arm64 image here as well (even though I'm building and running on amd64): https://github.com/fabric8io/docker-maven-plugin/issues/1739#issuecomment-1881260436
Re: Is the karaf 4.4.4 docker image arm only?
> Jean-Baptiste Onofré : > Hi Steinar > Let me check about the image type. Did you find out anything? The docker-maven-plugin I've been using (the one created by spotify), was abandoned a couple of years back: https://github.com/spotify/docker-maven-plugin So I've been trying to to use a docker-maven-plugin that is maintained: https://github.com/fabric8io/docker-maven-plugin I've succeeded in building a sonar-collector docker image using the new docker-maven-plugin, but I end up with an arm64 image here as well (even though I'm building and running on amd64): https://github.com/fabric8io/docker-maven-plugin/issues/1739#issuecomment-1881260436
Re: Is the karaf 4.4.4 docker image arm only?
Hi Steinar Let me check about the image type. Regards JB On Fri, Dec 22, 2023 at 5:44 PM Steinar Bang wrote: > > > Steinar Bang : > [snip!] > > Or try out the, completely different, docker-maven-plugin that comes up > > first on google searches? > > https://github.com/fabric8io/docker-maven-plugin > > > I guess try out the new one. > > Not much luck with the new one, so far: > https://github.com/fabric8io/docker-maven-plugin/issues/1739 > > The command it tries to run doesn't seem like one my docker recognizes. > > Does anyone else have a better maven docker plugin to try? >
Re: Is the karaf 4.4.4 docker image arm only?
> Steinar Bang : [snip!] > Or try out the, completely different, docker-maven-plugin that comes up > first on google searches? > https://github.com/fabric8io/docker-maven-plugin > I guess try out the new one. Not much luck with the new one, so far: https://github.com/fabric8io/docker-maven-plugin/issues/1739 The command it tries to run doesn't seem like one my docker recognizes. Does anyone else have a better maven docker plugin to try?
Re: Is the karaf 4.4.4 docker image arm only?
I just noticed that I'm using an archived and dead docker-maven-plugin https://github.com/steinarb/sonar-collector/blob/b0d6cedb35648df11ef1554b9fb8fbe669e94640/docker/pom.xml#L32 https://github.com/spotify/docker-maven-plugin?tab=readme-ov-file Archived on March 21 2022 and last commit from September 14 2021. I wonder what to do about that? Try the latest release of the dead docker-maven-plugin? Nah, that seems to be 1.2.2 (from January 15 2020), which I already have. Or try out the, completely different, docker-maven-plugin that comes up first on google searches? https://github.com/fabric8io/docker-maven-plugin I guess try out the new one.
Re: Is the karaf 4.4.4 docker image arm only?
FWIW The reason that I'm trying to update sonar-collector's docker image is that I discovered that sonar-collector actually has a user, and that user uses the docker image which suddenly stopped working: https://github.com/steinarb/sonar-collector/issues/5 The way I've created the docker image is that I've started with the official docker image and then have just added LATEST of sonar-collector's feature repository to karaf's boot repository list and then have added the PostgreSQL JDBC driver and sonar-collector itself to the list of boot features. The idea was to create one image that always pulled the latest sonar-collector from maven central. That works fine, I guess, until I start building for a newer Java version. I'm currently building and releasing on java 17, and the official karaf 4.4.4 image is running on java 11, so that might be a problem. Curiously the issue above isn't from Java version, it seems to be the OSGi version? My current sonar-collector docker image is based on the 4.2.8 official karaf image, which is OSGi 6 and Java 8. As I said I'm currently building for and with java 17 and OSGi 8. Surprisingly the error message seems to be related to running an OSGi 8 application on OSGi 6. It's surprising, because I would have thought binary incompatibility from using a newer version byte code would have stopped it before that...? Ah well, one step at a time. The current blocker is that when creating a new docker image on top of the official karaf 4.4.4 image, I keep getting arm64 docker images even though I'm running on amd64. And for the curious that has read this far: sonar-collector is a very simple application that is intended as a webhook to be called by sonarqube and/or sonarcloud, and for each call writes a row in a PostgreSQL database table with some key values from that analysis. It is intended for making long term statistics. The sonar-collector was created and used when maintaining a set of applications with, well, not so good numbers, to prove that for each iteration we made those applications slightly better instead of slightly worse. Sonarqube didn't offer an API to read out those statistics, and typing them in was a chore, writing a webhook was the suggestion made by sonarqube, so that's what I did.
Is the karaf 4.4.4 docker image arm only?
I'm trying to build an updated docker image for my sonar-collector project, based on the official karaf 4.4.4 image: https://github.com/steinarb/sonar-collector However even though I'm building the docker image on an amd64 debian 12.4 "bookworm" system, the resulting docker image seems to be an arm64 image: sb@lorenzo:~/workspaces/ws02/sonar-collector/docker$ docker run -p 8101:8101 -p 8181:8181 -e "JDBC_USER=karaf" -e "JDBC_USER=karaf" -d steinarb/sonar-collector:latest WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested af9714a5cf090b509daf70596fa0f7b7828ea92c90e3225a2705ad83ef45bdca sb@lorenzo:~/workspaces/ws02/sonar-collector/docker$ Is the karaf 4.4.4 official image arm64 only? Or is there a different reason I'm ending up with an arm64 image? According to google search results it shouldn't be neccessary to specify the platform if the desired platform is the same as docker is running on...? Thanks! - Steinar
Re: Using Apache Karaf with Docker
>>>>> Jean-Baptiste Onofré : > Both cases work with Docker, maybe case 1 is "more" interesting (but > it depends of your provisioning scenario). @Andrei, as JB hints at there are many ways to dockerize karaf applications. My applications are provisioned by creating karaf features and deploy OSGi bundles and karaf features to a maven repository, and then load the features in karaf. So for docker, what I've done is to start with the standard karaf docker image deployed to dockerhub, and then override the file etc/org.apache.karaf.features.cfg in the karaf installation in the docker image, with a file that loads the LATEST version my feature(s). I also deploy versions of the JDBC Config files of my application, that can have the URL and USERNAME/PASSWORD values set from environment variables, making them easy to set in the deploy. That means that when I deploy my image it can provision from the newest deploy to maven, without me having to build a new docker image. Here's an example of a maven module that builds a docker image on top of the standard karaf docker image: https://github.com/steinarb/sonar-collector/tree/master/docker Caveat emptor! I haven't run this for a while so it may not be working right now (I probably have to update the docker image version to a newer karaf version). FWIW My deployment model is to have a single karaf instance in my VPS, deploying all of my applications as OSGi bundles. Works like a charm for me!
Re: Using Apache Karaf with Docker
Hi Andrei, Both cases work with Docker, maybe case 1 is "more" interesting (but it depends of your provisioning scenario). Regards JB On 13/01/2022 11:19, Andrei Petru Mura wrote: Hi everyone, I have a dilemma which I'll present to you here. Any advice/indications? Case 1. I have a production system in which I have multiple virtual machines. In every such virtual machine I run an Apache Karaf instance. In all this Apache Karaf instances (one per virtual machine) I run multiple applications (deployed as OSGI bundles). Case 2. I have a production system in which I have multiple virtual machines. In every such virtual machine I run an Apache Karaf instance. In all this Apache Karaf instances (one per virtual machine) I run only one application (deployed as OSGI bundles). N.B. The only difference between Case 1 and Case 2 is that in case 1 I have multiple OSGI bundles in Karaf, while in case 2 I have only one OSGI bundle in Karaf (along the libraries). Question: Is it OK for case 1 or case 2 to be dockerized? This means, instead of running multiple VMs, I'll run multiple docker containers. Thanks, Andrei Mura
Using Apache Karaf with Docker
Hi everyone, I have a dilemma which I'll present to you here. Any advice/indications? Case 1. I have a production system in which I have multiple virtual machines. In every such virtual machine I run an Apache Karaf instance. In all this Apache Karaf instances (one per virtual machine) I run multiple applications (deployed as OSGI bundles). Case 2. I have a production system in which I have multiple virtual machines. In every such virtual machine I run an Apache Karaf instance. In all this Apache Karaf instances (one per virtual machine) I run only one application (deployed as OSGI bundles). N.B. The only difference between Case 1 and Case 2 is that in case 1 I have multiple OSGI bundles in Karaf, while in case 2 I have only one OSGI bundle in Karaf (along the libraries). Question: Is it OK for case 1 or case 2 to be dockerized? This means, instead of running multiple VMs, I'll run multiple docker containers. Thanks, Andrei Mura
Re: Karaf in Docker - JVM arguments
Hi, I can be set using JAVA_OPTS in bin/env (or using env variable). Regards JB > Le 9 févr. 2021 à 21:14, Daniel Las a écrit : > > Hi, > > How can I set JVM arguments of custom distribution running in Docker? I mean > GC or memory settings. > > REgards > -- > Daniel Łaś > CTO at Empirica S.A. > +48 695 616181
Karaf in Docker - JVM arguments
Hi, How can I set JVM arguments of custom distribution running in Docker? I mean GC or memory settings. REgards -- Daniel Łaś CTO at Empirica S.A. +48 695 616181
Re: Karaf in docker - JMX access
You are welcome ! Cheers JB > Le 9 févr. 2021 à 20:19, Daniel Las a écrit : > > > Thanks a lot JB, it works now. > > Best regards > > wt., 9 lut 2021 o 16:27 Jean-Baptiste Onofre napisał(a): >> Be careful, by default, JMX is bound to localhost (not 0.0.0.0), so not >> visible outside. >> >> I mean by default, in etc/org.apache.karaf.management.cfg, you have: >> >> rmiRegistryHost = 127.0.0.1 >> rmiServerHost = 127.0.0.1 >> >> Can you try with 0.0.0.0 here instead of localhost ? >> >> Regards >> JB >> >>> Le 9 févr. 2021 à 16:08, Daniel Las a écrit : >>> >>> HI, >>> >>> I started the container using bare 4.3.0 image pulled from Docker hub: >>> >>> docker run -p 1099:1099 -p 4:4 apache/karaf:4.3.0 >>> >>> This is output from Docker ps command: >>> >>> e5492ba6143aapache/karaf:4.3.0 >>> "karaf run" 15 seconds ago Up 13 seconds >>> 8101/tcp, 0.0.0.0:1099->1099/tcp, 0.0.0.0:4->4/tcp, 8181/tcp >>> blissful_mahavira >>> >>> When I try to connect from Visual VM, there are errors logged: >>> >>> 14:55:56.962 WARN [RMI TCP Accept-4] RMI TCP Accept-4: accept loop >>> for ServerSocket[addr=0.0.0.0/0.0.0.0,localport=4] throws >>> java.io.IOException: Only connections from clients running on the host >>> where the RMI remote objects have been exported are accepted. >>> at >>> org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) >>> at >>> org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) >>> at >>> org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) >>> at >>> java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown >>> Source) >>> at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown >>> Source) >>> at java.base/java.lang.Thread.run(Unknown Source) >>> >>> I gave the JConsole a try, it fails to connect as well. Every time I try to >>> connect, the above exception is logged. >>> >>> Regards >>> >>> wt., 9 lut 2021 o 14:15 Jean-Baptiste Onofre napisał(a): >>>> And you set both registry and transport ports ? >>>> >>>> It’s seems that the 4 is not bound. >>>> >>>> What’s the service URL you have in etc/org.apache.karaf.management.cfg ? >>>> >>>> Regards >>>> JB >>>> >>>>> Le 9 févr. 2021 à 14:01, Daniel Las a écrit : >>>>> >>>>> Hi, >>>>> >>>>> Yes, I did. >>>>> >>>>> Regards >>>>> >>>>> wt., 9 lut 2021 o 13:59 Jean-Baptiste Onofre >>>>> napisał(a): >>>>>> Hi, >>>>>> >>>>>> Did you bind the JMX ports on docker ? (Like docker run -p 1099:1099 -p >>>>>> 4:4 …) >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>>> Le 9 févr. 2021 à 13:27, Daniel Las a écrit : >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm running a custom distribution based on Karaf 4.2.9 in docker. How >>>>>>> should I configure it to allow JMX access? >>>>>>> >>>>>>> I tried to set host IP in rmiRegistryHost and rmiServerHost in >>>>>>> org.apache.karaf.management.cfg but I can't connect to it from JMX >>>>>>> client. Without it I see errors in log when JMX client attempts to >>>>>>> connect: >>>>>>> >>>>>>> 2021-02-09T12:12:17,275 | WARN | RMI TCP Accept-4 | tcp >>>>>>> | 3 - org.ops4j.pax.logging.pax-logging-api - 1.11.7 >>>>>>> | RMI TCP Accept-4: accept loop for >>>>>>> ServerSocket[addr=0.0.0.0/0.0.0.0,localport=4] throws >>>>>>> java.io.IOException: Only connections from clients running on the host >>>>>>> where the RMI remote objects have been exported are accepted. >>>>>>> at >>>>>>> org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) >>>>>>> ~[?:?] >>>>>>> at >>>>>>> org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) >>>>>>> ~[?:?] >>>>>>> at >>>>>>> org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) >>>>>>> ~[?:?] >>>>>>> at >>>>>>> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown >>>>>>> Source) [?:?] >>>>>>> at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) >>>>>>> [?:?] >>>>>>> at java.lang.Thread.run(Unknown Source) [?:?] >>>>>>> >>>>>>> Best regards >>>>>>> -- >>>>>>> Daniel Łaś >>>>>>> CTO at Empirica S.A. >>>>>>> +48 695 616181 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Daniel Łaś >>>>> CTO at Empirica S.A. >>>>> +48 695 616181 >>>> >>> >>> >>> -- >>> Daniel Łaś >>> CTO at Empirica S.A. >>> +48 695 616181 >> > > > -- > Daniel Łaś > CTO at Empirica S.A. > +48 695 616181
Re: Karaf in docker - JMX access
Thanks a lot JB, it works now. Best regards wt., 9 lut 2021 o 16:27 Jean-Baptiste Onofre napisał(a): > Be careful, by default, JMX is bound to localhost (not 0.0.0.0), so not > visible outside. > > I mean by default, in etc/org.apache.karaf.management.cfg, you have: > > rmiRegistryHost = 127.0.0.1 > rmiServerHost = 127.0.0.1 > > Can you try with 0.0.0.0 here instead of localhost ? > > Regards > JB > > Le 9 févr. 2021 à 16:08, Daniel Las a écrit : > > HI, > > I started the container using bare 4.3.0 image pulled from Docker hub: > > docker run -p 1099:1099 -p 4:4 apache/karaf:4.3.0 > > This is output from Docker ps command: > > e5492ba6143aapache/karaf:4.3.0 > "karaf run" 15 seconds ago Up 13 seconds > 8101/tcp, 0.0.0.0:1099->1099/tcp, 0.0.0.0:4->4/tcp, 8181/tcp > blissful_mahavira > > When I try to connect from Visual VM, there are errors logged: > > 14:55:56.962 WARN [RMI TCP Accept-4] RMI TCP Accept-4: accept > loop for ServerSocket[addr=0.0.0.0/0.0.0.0,localport=4] throws > java.io.IOException: Only connections from clients running on the host > where the RMI remote objects have been exported are accepted. > at > org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) > at > org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) > at > org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) > at > java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown > Source) > at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown > Source) > at java.base/java.lang.Thread.run(Unknown Source) > > I gave the JConsole a try, it fails to connect as well. Every time I try > to connect, the above exception is logged. > > Regards > > wt., 9 lut 2021 o 14:15 Jean-Baptiste Onofre napisał(a): > >> And you set both registry and transport ports ? >> >> It’s seems that the 4 is not bound. >> >> What’s the service URL you have in etc/org.apache.karaf.management.cfg ? >> >> Regards >> JB >> >> Le 9 févr. 2021 à 14:01, Daniel Las a écrit : >> >> Hi, >> >> Yes, I did. >> >> Regards >> >> wt., 9 lut 2021 o 13:59 Jean-Baptiste Onofre >> napisał(a): >> >>> Hi, >>> >>> Did you bind the JMX ports on docker ? (Like docker run -p 1099:1099 -p >>> 4:4 …) >>> >>> Regards >>> JB >>> >>> Le 9 févr. 2021 à 13:27, Daniel Las a écrit : >>> >>> Hi, >>> >>> I'm running a custom distribution based on Karaf 4.2.9 in docker. How >>> should I configure it to allow JMX access? >>> >>> I tried to set host IP in rmiRegistryHost and rmiServerHost >>> in org.apache.karaf.management.cfg but I can't connect to it from JMX >>> client. Without it I see errors in log when JMX client attempts to connect: >>> >>> 2021-02-09T12:12:17,275 | WARN | RMI TCP Accept-4 | tcp >>> | 3 - org.ops4j.pax.logging.pax-logging-api - 1.11.7 | RMI >>> TCP Accept-4: accept loop for ServerSocket[addr= >>> 0.0.0.0/0.0.0.0,localport=4] throws >>> java.io.IOException: Only connections from clients running on the host >>> where the RMI remote objects have been exported are accepted. >>> at >>> org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) >>> ~[?:?] >>> at >>> org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) >>> ~[?:?] >>> at >>> org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) >>> ~[?:?] >>> at >>> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown >>> Source) [?:?] >>> at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) >>> [?:?] >>> at java.lang.Thread.run(Unknown Source) [?:?] >>> >>> Best regards >>> -- >>> Daniel Łaś >>> CTO at Empirica S.A. >>> +48 695 616181 >>> >>> >>> >> >> -- >> Daniel Łaś >> CTO at Empirica S.A. >> +48 695 616181 >> >> >> > > -- > Daniel Łaś > CTO at Empirica S.A. > +48 695 616181 > > > -- Daniel Łaś CTO at Empirica S.A. +48 695 616181
Re: Karaf in docker - JMX access
Be careful, by default, JMX is bound to localhost (not 0.0.0.0), so not visible outside. I mean by default, in etc/org.apache.karaf.management.cfg, you have: rmiRegistryHost = 127.0.0.1 rmiServerHost = 127.0.0.1 Can you try with 0.0.0.0 here instead of localhost ? Regards JB > Le 9 févr. 2021 à 16:08, Daniel Las a écrit : > > HI, > > I started the container using bare 4.3.0 image pulled from Docker hub: > > docker run -p 1099:1099 -p 4:4 apache/karaf:4.3.0 > > This is output from Docker ps command: > > e5492ba6143aapache/karaf:4.3.0 > "karaf run" 15 seconds ago Up 13 seconds > 8101/tcp, 0.0.0.0:1099->1099/tcp, 0.0.0.0:4->4/tcp, 8181/tcp > blissful_mahavira > > When I try to connect from Visual VM, there are errors logged: > > 14:55:56.962 WARN [RMI TCP Accept-4] RMI TCP Accept-4: accept loop > for ServerSocket[addr=0.0.0.0/0.0.0.0,localport=4 > <http://0.0.0.0/0.0.0.0,localport=4>] throws > java.io.IOException: Only connections from clients running on the host where > the RMI remote objects have been exported are accepted. > at > org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) > at > org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) > at > org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) > at > java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown > Source) > at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) > at java.base/java.lang.Thread.run(Unknown Source) > > I gave the JConsole a try, it fails to connect as well. Every time I try to > connect, the above exception is logged. > > Regards > > wt., 9 lut 2021 o 14:15 Jean-Baptiste Onofre <mailto:j...@nanthrax.net>> napisał(a): > And you set both registry and transport ports ? > > It’s seems that the 4 is not bound. > > What’s the service URL you have in etc/org.apache.karaf.management.cfg ? > > Regards > JB > >> Le 9 févr. 2021 à 14:01, Daniel Las > <mailto:daniel@empirica.io>> a écrit : >> >> Hi, >> >> Yes, I did. >> >> Regards >> >> wt., 9 lut 2021 o 13:59 Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> napisał(a): >> Hi, >> >> Did you bind the JMX ports on docker ? (Like docker run -p 1099:1099 -p >> 4:4 …) >> >> Regards >> JB >> >>> Le 9 févr. 2021 à 13:27, Daniel Las >> <mailto:daniel@empirica.io>> a écrit : >>> >>> Hi, >>> >>> I'm running a custom distribution based on Karaf 4.2.9 in docker. How >>> should I configure it to allow JMX access? >>> >>> I tried to set host IP in rmiRegistryHost and rmiServerHost in >>> org.apache.karaf.management.cfg but I can't connect to it from JMX client. >>> Without it I see errors in log when JMX client attempts to connect: >>> >>> 2021-02-09T12:12:17,275 | WARN | RMI TCP Accept-4 | tcp >>> | 3 - org.ops4j.pax.logging.pax-logging-api - 1.11.7 | RMI >>> TCP Accept-4: accept loop for >>> ServerSocket[addr=0.0.0.0/0.0.0.0,localport=4 >>> <http://0.0.0.0/0.0.0.0,localport=4>] throws >>> java.io.IOException: Only connections from clients running on the host >>> where the RMI remote objects have been exported are accepted. >>> at >>> org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) >>> ~[?:?] >>> at >>> org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) >>> ~[?:?] >>> at >>> org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) >>> ~[?:?] >>> at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown >>> Source) [?:?] >>> at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) [?:?] >>> at java.lang.Thread.run(Unknown Source) [?:?] >>> >>> Best regards >>> -- >>> Daniel Łaś >>> CTO at Empirica S.A. >>> +48 695 616181 >> >> >> >> -- >> Daniel Łaś >> CTO at Empirica S.A. >> +48 695 616181 > > > > -- > Daniel Łaś > CTO at Empirica S.A. > +48 695 616181
Re: Karaf in docker - JMX access
HI, I started the container using bare 4.3.0 image pulled from Docker hub: docker run -p 1099:1099 -p 4:4 apache/karaf:4.3.0 This is output from Docker ps command: e5492ba6143aapache/karaf:4.3.0 "karaf run" 15 seconds ago Up 13 seconds 8101/tcp, 0.0.0.0:1099->1099/tcp, 0.0.0.0:4->4/tcp, 8181/tcp blissful_mahavira When I try to connect from Visual VM, there are errors logged: 14:55:56.962 WARN [RMI TCP Accept-4] RMI TCP Accept-4: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,localport=4] throws java.io.IOException: Only connections from clients running on the host where the RMI remote objects have been exported are accepted. at org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) at org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) at org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown Source) at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) I gave the JConsole a try, it fails to connect as well. Every time I try to connect, the above exception is logged. Regards wt., 9 lut 2021 o 14:15 Jean-Baptiste Onofre napisał(a): > And you set both registry and transport ports ? > > It’s seems that the 4 is not bound. > > What’s the service URL you have in etc/org.apache.karaf.management.cfg ? > > Regards > JB > > Le 9 févr. 2021 à 14:01, Daniel Las a écrit : > > Hi, > > Yes, I did. > > Regards > > wt., 9 lut 2021 o 13:59 Jean-Baptiste Onofre napisał(a): > >> Hi, >> >> Did you bind the JMX ports on docker ? (Like docker run -p 1099:1099 -p >> 4:4 …) >> >> Regards >> JB >> >> Le 9 févr. 2021 à 13:27, Daniel Las a écrit : >> >> Hi, >> >> I'm running a custom distribution based on Karaf 4.2.9 in docker. How >> should I configure it to allow JMX access? >> >> I tried to set host IP in rmiRegistryHost and rmiServerHost >> in org.apache.karaf.management.cfg but I can't connect to it from JMX >> client. Without it I see errors in log when JMX client attempts to connect: >> >> 2021-02-09T12:12:17,275 | WARN | RMI TCP Accept-4 | tcp >> | 3 - org.ops4j.pax.logging.pax-logging-api - 1.11.7 | RMI >> TCP Accept-4: accept loop for ServerSocket[addr= >> 0.0.0.0/0.0.0.0,localport=4] throws >> java.io.IOException: Only connections from clients running on the host >> where the RMI remote objects have been exported are accepted. >> at >> org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) >> ~[?:?] >> at >> org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) >> ~[?:?] >> at >> org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) >> ~[?:?] >> at >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown >> Source) [?:?] >> at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) [?:?] >> at java.lang.Thread.run(Unknown Source) [?:?] >> >> Best regards >> -- >> Daniel Łaś >> CTO at Empirica S.A. >> +48 695 616181 >> >> >> > > -- > Daniel Łaś > CTO at Empirica S.A. > +48 695 616181 > > > -- Daniel Łaś CTO at Empirica S.A. +48 695 616181
Re: Karaf in docker - JMX access
And you set both registry and transport ports ? It’s seems that the 4 is not bound. What’s the service URL you have in etc/org.apache.karaf.management.cfg ? Regards JB > Le 9 févr. 2021 à 14:01, Daniel Las a écrit : > > Hi, > > Yes, I did. > > Regards > > wt., 9 lut 2021 o 13:59 Jean-Baptiste Onofre <mailto:j...@nanthrax.net>> napisał(a): > Hi, > > Did you bind the JMX ports on docker ? (Like docker run -p 1099:1099 -p > 4:4 …) > > Regards > JB > >> Le 9 févr. 2021 à 13:27, Daniel Las > <mailto:daniel@empirica.io>> a écrit : >> >> Hi, >> >> I'm running a custom distribution based on Karaf 4.2.9 in docker. How should >> I configure it to allow JMX access? >> >> I tried to set host IP in rmiRegistryHost and rmiServerHost in >> org.apache.karaf.management.cfg but I can't connect to it from JMX client. >> Without it I see errors in log when JMX client attempts to connect: >> >> 2021-02-09T12:12:17,275 | WARN | RMI TCP Accept-4 | tcp >> | 3 - org.ops4j.pax.logging.pax-logging-api - 1.11.7 | RMI TCP >> Accept-4: accept loop for >> ServerSocket[addr=0.0.0.0/0.0.0.0,localport=4 >> <http://0.0.0.0/0.0.0.0,localport=4>] throws >> java.io.IOException: Only connections from clients running on the host where >> the RMI remote objects have been exported are accepted. >> at >> org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) >> ~[?:?] >> at >> org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) >> ~[?:?] >> at >> org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) >> ~[?:?] >> at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown >> Source) [?:?] >> at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) [?:?] >> at java.lang.Thread.run(Unknown Source) [?:?] >> >> Best regards >> -- >> Daniel Łaś >> CTO at Empirica S.A. >> +48 695 616181 > > > > -- > Daniel Łaś > CTO at Empirica S.A. > +48 695 616181
Re: Karaf in docker - JMX access
Hi, Yes, I did. Regards wt., 9 lut 2021 o 13:59 Jean-Baptiste Onofre napisał(a): > Hi, > > Did you bind the JMX ports on docker ? (Like docker run -p 1099:1099 -p > 4:4 …) > > Regards > JB > > Le 9 févr. 2021 à 13:27, Daniel Las a écrit : > > Hi, > > I'm running a custom distribution based on Karaf 4.2.9 in docker. How > should I configure it to allow JMX access? > > I tried to set host IP in rmiRegistryHost and rmiServerHost > in org.apache.karaf.management.cfg but I can't connect to it from JMX > client. Without it I see errors in log when JMX client attempts to connect: > > 2021-02-09T12:12:17,275 | WARN | RMI TCP Accept-4 | tcp >| 3 - org.ops4j.pax.logging.pax-logging-api - 1.11.7 | RMI > TCP Accept-4: accept loop for ServerSocket[addr= > 0.0.0.0/0.0.0.0,localport=4] throws > java.io.IOException: Only connections from clients running on the host > where the RMI remote objects have been exported are accepted. > at > org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) > ~[?:?] > at > org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) > ~[?:?] > at > org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) > ~[?:?] > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown > Source) [?:?] > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) [?:?] > at java.lang.Thread.run(Unknown Source) [?:?] > > Best regards > -- > Daniel Łaś > CTO at Empirica S.A. > +48 695 616181 > > > -- Daniel Łaś CTO at Empirica S.A. +48 695 616181
Re: Karaf in docker - JMX access
Hi, Did you bind the JMX ports on docker ? (Like docker run -p 1099:1099 -p 4:4 …) Regards JB > Le 9 févr. 2021 à 13:27, Daniel Las a écrit : > > Hi, > > I'm running a custom distribution based on Karaf 4.2.9 in docker. How should > I configure it to allow JMX access? > > I tried to set host IP in rmiRegistryHost and rmiServerHost in > org.apache.karaf.management.cfg but I can't connect to it from JMX client. > Without it I see errors in log when JMX client attempts to connect: > > 2021-02-09T12:12:17,275 | WARN | RMI TCP Accept-4 | tcp > | 3 - org.ops4j.pax.logging.pax-logging-api - 1.11.7 | RMI TCP > Accept-4: accept loop for > ServerSocket[addr=0.0.0.0/0.0.0.0,localport=4 > <http://0.0.0.0/0.0.0.0,localport=4>] throws > java.io.IOException: Only connections from clients running on the host where > the RMI remote objects have been exported are accepted. > at > org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) > ~[?:?] > at > org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) > ~[?:?] > at > org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) > ~[?:?] > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown > Source) [?:?] > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) [?:?] > at java.lang.Thread.run(Unknown Source) [?:?] > > Best regards > -- > Daniel Łaś > CTO at Empirica S.A. > +48 695 616181
Karaf in docker - JMX access
Hi, I'm running a custom distribution based on Karaf 4.2.9 in docker. How should I configure it to allow JMX access? I tried to set host IP in rmiRegistryHost and rmiServerHost in org.apache.karaf.management.cfg but I can't connect to it from JMX client. Without it I see errors in log when JMX client attempts to connect: 2021-02-09T12:12:17,275 | WARN | RMI TCP Accept-4 | tcp | 3 - org.ops4j.pax.logging.pax-logging-api - 1.11.7 | RMI TCP Accept-4: accept loop for ServerSocket[addr= 0.0.0.0/0.0.0.0,localport=4] throws java.io.IOException: Only connections from clients running on the host where the RMI remote objects have been exported are accepted. at org.apache.karaf.management.ConnectorServerFactory.checkLocal(ConnectorServerFactory.java:900) ~[?:?] at org.apache.karaf.management.ConnectorServerFactory.access$000(ConnectorServerFactory.java:67) ~[?:?] at org.apache.karaf.management.ConnectorServerFactory$LocalOnlyServerSocket.accept(ConnectorServerFactory.java:646) ~[?:?] at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown Source) [?:?] at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source) [?:?] at java.lang.Thread.run(Unknown Source) [?:?] Best regards -- Daniel Łaś CTO at Empirica S.A. +48 695 616181
Re: Problems running on the karaf 4.2.9 docker image
Hi Steinar, Thanks for the update, it’s what I thought ;) Regards JB > Le 12 sept. 2020 à 12:46, Steinar Bang a écrit : > >> Steinar Bang : >> I saw that myself and just thought of why: I replace the file loading >> boot features with one that adds my application feature. > >> And I've based this file on the boot features file of the karaf 4.2.8 >> distribution. > >> And of course, that won't work! :-) > >> Once I replace the file with same file from the 4.2.9 distro I suspect >> things will start working again. > > Update: Once I had replaced the org.apache.karaf.features.cfg with a > file yanked from the karaf 4.2.9 distro instead of karaf 4.2.8, then the > docker image with my application started working. > >
Re: Problems running on the karaf 4.2.9 docker image
> Steinar Bang : > I saw that myself and just thought of why: I replace the file loading > boot features with one that adds my application feature. > And I've based this file on the boot features file of the karaf 4.2.8 > distribution. > And of course, that won't work! :-) > Once I replace the file with same file from the 4.2.9 distro I suspect > things will start working again. Update: Once I had replaced the org.apache.karaf.features.cfg with a file yanked from the karaf 4.2.9 distro instead of karaf 4.2.8, then the docker image with my application started working.
Re: Problems running on the karaf 4.2.9 docker image
> Jean-Baptiste Onofre : > Hi, > Understood. > Did you see my previous email about that I see 4.2.8 feature in your docker > logs. Is that normal ? I saw that myself and just thought of why: I replace the file loading boot features with one that adds my application feature. And I've based this file on the boot features file of the karaf 4.2.8 distribution. And of course, that won't work! :-) Once I replace the file with same file from the 4.2.9 distro I suspect things will start working again. My bad! Sorry about the noise! :-)
Re: Problems running on the karaf 4.2.9 docker image
Hi, Understood. Did you see my previous email about that I see 4.2.8 feature in your docker logs. Is that normal ? Regards JB > Le 10 sept. 2020 à 13:03, Steinar Bang a écrit : > >> Jean-Baptiste Onofre : > >> Hi Steinar, >> Karaf 4.2.9 image is little bit different from previous as it’s based on >> adoptopenjdk:11-jre-hotspot. > >> The rest is the same. Do you want me to push like the old style (openjdk8 >> based) ? > > No, I've completely converted to Java 11 on the build dev side. > > And I definitely want Java 11 (if you see the link to what failed on > when I ran the app on 4.2.8). :-) > > But there wasn't much to go on in where it stopped... > > The app starts and run fine on karaf 4.2.9 on Java 11 when I run it locally. >
Re: Problems running on the karaf 4.2.9 docker image
> Jean-Baptiste Onofre : > By the way, just did a new test running the image with: > docker run -p 8101:8101 —name test apache/karaf:4.2.9 > And it starts fine, accessing via SSH doesn’t show anything suspicious. > I will fetch your repo to take a look. Note that the docker build isn't in that repo, it's in a branch in my scratch repo, so that the full clone operation is: git clone https://github.com/steinarb/oldalbum.git cd oldalbum git remote add scratch https://github.com/steinarb/scratch.git git checkout oldalbum/make-docker-image-of-oldalbum (I use a separate repository for "junk" and "under work" branches to avoid clutter)
Re: Problems running on the karaf 4.2.9 docker image
> Jean-Baptiste Onofre : > Hi Steinar, > Karaf 4.2.9 image is little bit different from previous as it’s based on > adoptopenjdk:11-jre-hotspot. > The rest is the same. Do you want me to push like the old style (openjdk8 > based) ? No, I've completely converted to Java 11 on the build dev side. And I definitely want Java 11 (if you see the link to what failed on when I ran the app on 4.2.8). :-) But there wasn't much to go on in where it stopped... The app starts and run fine on karaf 4.2.9 on Java 11 when I run it locally.
Re: Problems running on the karaf 4.2.9 docker image (Was: No 4.2.9 karaf docker image?)
By the way, just did a new test running the image with: docker run -p 8101:8101 —name test apache/karaf:4.2.9 And it starts fine, accessing via SSH doesn’t show anything suspicious. I will fetch your repo to take a look. Regards JB > Le 10 sept. 2020 à 05:32, Jean-Baptiste Onofre a écrit : > > Hi Steinar, > > Karaf 4.2.9 image is little bit different from previous as it’s based on > adoptopenjdk:11-jre-hotspot. > > The rest is the same. Do you want me to push like the old style (openjdk8 > based) ? > > How do you start the docker container ? Just a simply docker run ? > > In the log you shared, I see that boot features are 4.2.8 (not 4.2.9). I > suspect you can have kind of refresh stopping bundles (it’s what we see in > the log). > Are you sure about the versions (not mixing 4.2.8 and 4.2.9) ? > > Regards > JB > >> Le 9 sept. 2020 à 22:41, Steinar Bang a écrit : >> >> My app doesn't start on the karaf 4.2.9 image. >> >> Here's the output from "docker logs" from the app running on the 4.2.9 image: >> https://gist.github.com/steinarb/68404e9afe5dc94e3235fe46aefd9959 >> >> When running on the karaf 4.2.9 image it gets much farther: >> https://gist.github.com/steinarb/2d04feb63ef58462eaf6415eacadf145 >> >> Does anyone know what can cause this difference? >> The app runs fine on both karaf 4.2.8 and 4.2.9 locally. >> I'm using Java 11. >> >> The app still eventually fails on the 4.2.8 image as wekk, but before it >> fails it starts running liquibase to create the database, and which it >> never gets around to in the 4.2.9 image. >> >> The reason it fails in 4.2.8 is that I'm guessing the 4.2.8 image is >> built on top of Java 1.8 and I have built my app with java 11: >> https://gist.github.com/steinarb/2d04feb63ef58462eaf6415eacadf145#file-docker_logs-L754 >> >> I have built with Java 11 when I made releases of the app to maven >> central. >> >> Here's the app: >> https://github.com/steinarb/oldalbum >> >
Re: Problems running on the karaf 4.2.9 docker image (Was: No 4.2.9 karaf docker image?)
Hi Steinar, Karaf 4.2.9 image is little bit different from previous as it’s based on adoptopenjdk:11-jre-hotspot. The rest is the same. Do you want me to push like the old style (openjdk8 based) ? How do you start the docker container ? Just a simply docker run ? In the log you shared, I see that boot features are 4.2.8 (not 4.2.9). I suspect you can have kind of refresh stopping bundles (it’s what we see in the log). Are you sure about the versions (not mixing 4.2.8 and 4.2.9) ? Regards JB > Le 9 sept. 2020 à 22:41, Steinar Bang a écrit : > > My app doesn't start on the karaf 4.2.9 image. > > Here's the output from "docker logs" from the app running on the 4.2.9 image: > https://gist.github.com/steinarb/68404e9afe5dc94e3235fe46aefd9959 > > When running on the karaf 4.2.9 image it gets much farther: > https://gist.github.com/steinarb/2d04feb63ef58462eaf6415eacadf145 > > Does anyone know what can cause this difference? > The app runs fine on both karaf 4.2.8 and 4.2.9 locally. > I'm using Java 11. > > The app still eventually fails on the 4.2.8 image as wekk, but before it > fails it starts running liquibase to create the database, and which it > never gets around to in the 4.2.9 image. > > The reason it fails in 4.2.8 is that I'm guessing the 4.2.8 image is > built on top of Java 1.8 and I have built my app with java 11: > https://gist.github.com/steinarb/2d04feb63ef58462eaf6415eacadf145#file-docker_logs-L754 > > I have built with Java 11 when I made releases of the app to maven > central. > > Here's the app: > https://github.com/steinarb/oldalbum >
Problems running on the karaf 4.2.9 docker image (Was: No 4.2.9 karaf docker image?)
My app doesn't start on the karaf 4.2.9 image. Here's the output from "docker logs" from the app running on the 4.2.9 image: https://gist.github.com/steinarb/68404e9afe5dc94e3235fe46aefd9959 When running on the karaf 4.2.9 image it gets much farther: https://gist.github.com/steinarb/2d04feb63ef58462eaf6415eacadf145 Does anyone know what can cause this difference? The app runs fine on both karaf 4.2.8 and 4.2.9 locally. I'm using Java 11. The app still eventually fails on the 4.2.8 image as wekk, but before it fails it starts running liquibase to create the database, and which it never gets around to in the 4.2.9 image. The reason it fails in 4.2.8 is that I'm guessing the 4.2.8 image is built on top of Java 1.8 and I have built my app with java 11: https://gist.github.com/steinarb/2d04feb63ef58462eaf6415eacadf145#file-docker_logs-L754 I have built with Java 11 when I made releases of the app to maven central. Here's the app: https://github.com/steinarb/oldalbum
Re: My first real karaf-based docker image: sonar-collector
> Jean-Baptiste Onofre : > Thanks for sharing ! > I think we can improve the docker script provided by Karaf to do the same > (starting from Karaf official instance). Sounds great! :-) Resolving a feature like at startup and providing the bundles both from dependencies and the reactor build into system directory of the karaf in the container in some way would also be nice. For my particular docker image it makes sense to provision from the latest release on maven central (I don't have to rebuild the image when I make a new release). But for someone creating an image containing stuff not released to maven central or creating an image from a snapshot build, or deploying to a docker instance that's can't reach maven central, then it would be nice to have all of the dependecies inside the image.
Re: My first real karaf-based docker image: sonar-collector
Thanks for sharing ! I think we can improve the docker script provided by Karaf to do the same (starting from Karaf official instance). Regards JB > Le 21 avr. 2020 à 18:36, Steinar Bang a écrit : > > I have created my first real karaf-based docker image: > https://github.com/steinarb/sonar-collector#run-the-sonar-metrics-collector-in-docker > > The sonar-collector is intended as a webhook called by sonar on > completing a build, it will store key sonar measurements as a row in a > database table. > > Sonar has these numbers internally but doesn't have a way to get at > them. At first we typed these numbers manually into a spreadsheet to get > statistics on a set of analyzed programs. But that was tedious, so we > created sonar-collector to capture the numbers instead. > > The docker image is built with maven against a local docker and then > after testing, the image was pushed to docker hub: > https://github.com/steinarb/sonar-collector#building-the-docker-image > > The docker image is a very thin layer on top of the official karaf 4.2.8 > docker image > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/Dockerfile#L1 > > It copies in two files into the image's karaf etc directory: > 1. org.apache.karaf.features.cfg >a. Adds a feature repository for sonar-collector > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L28 >b. Adds two features to the boot features > i. An enviroment variable overloadable DataSourceFactory feature > that defaults to postgresql > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L52 > ii. The sonar-collector-webhook-with-postgresql feature > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L53 > > 2. org.ops4j.datasource-sonar-collector.cfg which is a modified version >of the file generated by pax-jdbc on first start, and the JDBC >driver name and JDBC connection info overridable by system >environment variables > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.ops4j.datasource-sonar-collector.cfg#L2 > > This image will provision itself from maven central (sonar-collector is > released to maven-central) and will always use the latest released > version, so there is no need to build a new docker image if a new > version of sonar-collector is released to maven central. > > Since the database schema is set up by liquibase and the SQL used is > trivial (inserts rows into a single table), it should in theory be > possible to use a different database than PostgreSQL, and I have > provided the possibility to override the database used when doing > "docker run" of the image. > > But using other databases than PostgreSQL is something I haven't > extensively tested. >
Re: My first real karaf-based docker image: sonar-collector
Nice! Great job Steinar! regards, François fpa...@apache.org Le 21/04/2020 à 18:36, Steinar Bang a écrit : > I have created my first real karaf-based docker image: > > https://github.com/steinarb/sonar-collector#run-the-sonar-metrics-collector-in-docker > > The sonar-collector is intended as a webhook called by sonar on > completing a build, it will store key sonar measurements as a row in a > database table. > > Sonar has these numbers internally but doesn't have a way to get at > them. At first we typed these numbers manually into a spreadsheet to get > statistics on a set of analyzed programs. But that was tedious, so we > created sonar-collector to capture the numbers instead. > > The docker image is built with maven against a local docker and then > after testing, the image was pushed to docker hub: > https://github.com/steinarb/sonar-collector#building-the-docker-image > > The docker image is a very thin layer on top of the official karaf 4.2.8 > docker image > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/Dockerfile#L1 > > It copies in two files into the image's karaf etc directory: > 1. org.apache.karaf.features.cfg > a. Adds a feature repository for sonar-collector > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L28 > b. Adds two features to the boot features >i. An enviroment variable overloadable DataSourceFactory feature > that defaults to postgresql > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L52 >ii. The sonar-collector-webhook-with-postgresql feature > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L53 > > 2. org.ops4j.datasource-sonar-collector.cfg which is a modified version > of the file generated by pax-jdbc on first start, and the JDBC > driver name and JDBC connection info overridable by system > environment variables > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.ops4j.datasource-sonar-collector.cfg#L2 > > This image will provision itself from maven central (sonar-collector is > released to maven-central) and will always use the latest released > version, so there is no need to build a new docker image if a new > version of sonar-collector is released to maven central. > > Since the database schema is set up by liquibase and the SQL used is > trivial (inserts rows into a single table), it should in theory be > possible to use a different database than PostgreSQL, and I have > provided the possibility to override the database used when doing > "docker run" of the image. > > But using other databases than PostgreSQL is something I haven't > extensively tested. >
Re: My first real karaf-based docker image: sonar-collector
Cool stuff. Like it! > Steinar Bang hat am 21. April 2020 18:36 geschrieben: > > > I have created my first real karaf-based docker image: > > https://github.com/steinarb/sonar-collector#run-the-sonar-metrics-collector-in-docker > > The sonar-collector is intended as a webhook called by sonar on > completing a build, it will store key sonar measurements as a row in a > database table. > > Sonar has these numbers internally but doesn't have a way to get at > them. At first we typed these numbers manually into a spreadsheet to get > statistics on a set of analyzed programs. But that was tedious, so we > created sonar-collector to capture the numbers instead. > > The docker image is built with maven against a local docker and then > after testing, the image was pushed to docker hub: > https://github.com/steinarb/sonar-collector#building-the-docker-image > > The docker image is a very thin layer on top of the official karaf 4.2.8 > docker image > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/Dockerfile#L1 > > It copies in two files into the image's karaf etc directory: > 1. org.apache.karaf.features.cfg > a. Adds a feature repository for sonar-collector > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L28 > b. Adds two features to the boot features >i. An enviroment variable overloadable DataSourceFactory feature > that defaults to postgresql > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L52 >ii. The sonar-collector-webhook-with-postgresql feature > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L53 > > 2. org.ops4j.datasource-sonar-collector.cfg which is a modified version > of the file generated by pax-jdbc on first start, and the JDBC > driver name and JDBC connection info overridable by system > environment variables > > https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.ops4j.datasource-sonar-collector.cfg#L2 > > This image will provision itself from maven central (sonar-collector is > released to maven-central) and will always use the latest released > version, so there is no need to build a new docker image if a new > version of sonar-collector is released to maven central. > > Since the database schema is set up by liquibase and the SQL used is > trivial (inserts rows into a single table), it should in theory be > possible to use a different database than PostgreSQL, and I have > provided the possibility to override the database used when doing > "docker run" of the image. > > But using other databases than PostgreSQL is something I haven't > extensively tested.
My first real karaf-based docker image: sonar-collector
I have created my first real karaf-based docker image: https://github.com/steinarb/sonar-collector#run-the-sonar-metrics-collector-in-docker The sonar-collector is intended as a webhook called by sonar on completing a build, it will store key sonar measurements as a row in a database table. Sonar has these numbers internally but doesn't have a way to get at them. At first we typed these numbers manually into a spreadsheet to get statistics on a set of analyzed programs. But that was tedious, so we created sonar-collector to capture the numbers instead. The docker image is built with maven against a local docker and then after testing, the image was pushed to docker hub: https://github.com/steinarb/sonar-collector#building-the-docker-image The docker image is a very thin layer on top of the official karaf 4.2.8 docker image https://github.com/steinarb/sonar-collector/blob/master/docker/docker/Dockerfile#L1 It copies in two files into the image's karaf etc directory: 1. org.apache.karaf.features.cfg a. Adds a feature repository for sonar-collector https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L28 b. Adds two features to the boot features i. An enviroment variable overloadable DataSourceFactory feature that defaults to postgresql https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L52 ii. The sonar-collector-webhook-with-postgresql feature https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.apache.karaf.features.cfg#L53 2. org.ops4j.datasource-sonar-collector.cfg which is a modified version of the file generated by pax-jdbc on first start, and the JDBC driver name and JDBC connection info overridable by system environment variables https://github.com/steinarb/sonar-collector/blob/master/docker/docker/org.ops4j.datasource-sonar-collector.cfg#L2 This image will provision itself from maven central (sonar-collector is released to maven-central) and will always use the latest released version, so there is no need to build a new docker image if a new version of sonar-collector is released to maven central. Since the database schema is set up by liquibase and the SQL used is trivial (inserts rows into a single table), it should in theory be possible to use a different database than PostgreSQL, and I have provided the possibility to override the database used when doing "docker run" of the image. But using other databases than PostgreSQL is something I haven't extensively tested.
Re: Failover with Apache Karaf + Cellar + Docker
Yeah, it should work with the docker host filesystem. Regards JB On 19/06/2018 16:40, imranrazakhan wrote: > Ok i will look into it. > > As of now i dont have NFS, so will try to use HOST file system for locking. > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Failover with Apache Karaf + Cellar + Docker
Ok i will look into it. As of now i dont have NFS, so will try to use HOST file system for locking. -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Failover with Apache Karaf + Cellar + Docker
By the way, a possible new feature would be to implement a locking mechanism based on Cellar, leveraging jClouds, Hazelcast, Ignite, Zookeeper, whatever. I already started something with jClouds. Regards JB On 19/06/2018 16:09, Jean-Baptiste Onofré wrote: > Hi, > > you can't do that with Cellar (again, Cellar is active/active). > > For "pure" failover, you have to use the lock mechanism. Your two docker > processes should: > > 1. use a shared filesystem (like NFS) to store the lock > 2. a database lock > > Kubernetes POD could be used with Cellar to discover the cluster nodes, > but not for failover. > > Regards > JB > > On 19/06/2018 16:06, imranrazakhan wrote: >> Ok, thanks for updates. >> >> Please provide details how we can achieve failover behavior(A 'hot' standby >> instance) like mentioned in >> >> >> https://svn.apache.org/repos/asf/karaf/site/production/manual/latest-3.0.x/failover.html >> >> >> in Docker environment? >> >> How karaf support to communicate between two images/pods. >> >> As we can use kubernetes for orchestration of instances but i am not clear >> how to achieve "A 'hot' standby instance" with it. Kubernetes will start and >> stop bundles regardless of statuses of bundles of karaf pods >> >> >> >> -- >> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html >> > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Failover with Apache Karaf + Cellar + Docker
Hi, you can't do that with Cellar (again, Cellar is active/active). For "pure" failover, you have to use the lock mechanism. Your two docker processes should: 1. use a shared filesystem (like NFS) to store the lock 2. a database lock Kubernetes POD could be used with Cellar to discover the cluster nodes, but not for failover. Regards JB On 19/06/2018 16:06, imranrazakhan wrote: > Ok, thanks for updates. > > Please provide details how we can achieve failover behavior(A 'hot' standby > instance) like mentioned in > > > https://svn.apache.org/repos/asf/karaf/site/production/manual/latest-3.0.x/failover.html > > > in Docker environment? > > How karaf support to communicate between two images/pods. > > As we can use kubernetes for orchestration of instances but i am not clear > how to achieve "A 'hot' standby instance" with it. Kubernetes will start and > stop bundles regardless of statuses of bundles of karaf pods > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Failover with Apache Karaf + Cellar + Docker
Ok, thanks for updates. Please provide details how we can achieve failover behavior(A 'hot' standby instance) like mentioned in https://svn.apache.org/repos/asf/karaf/site/production/manual/latest-3.0.x/failover.html in Docker environment? How karaf support to communicate between two images/pods. As we can use kubernetes for orchestration of instances but i am not clear how to achieve "A 'hot' standby instance" with it. Kubernetes will start and stop bundles regardless of statuses of bundles of karaf pods -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Failover with Apache Karaf + Cellar + Docker
Hi Cellar is not an active-passive solution, it's cluster deployment solution. It means that all instances are active, all instances can be part of the same cluster group, and then, you can install features/bundles/configs on this cluster group. For instance, you do: cluster:feature-install clusterGroup1 my-feature my-feature will be installed on all instances members of clusterGroup1. Regards JB On 19/06/2018 15:49, imranrazakhan wrote: > Hi, > > I have two karaf instances with Active-Passive configurations. Following is > deployment details > > 1- One become master and all bundles are with start status. > 2- Second instance is also up but all my developed bundles are with install > status but not running. > 3- Both instance communicate on socket and as soon as first goes down second > instance just change the status of bundles from install to status, due to > which uptime in failover is very minimum. > 4- these bundles dont expose http services so i cant use load balancer. > > I was evaluating Apache Cellar and found i can achieve same behavior with it > by setting karaf.lock.level=50 property in etc/startup.properties. > > But i want to deploy both instances with docker images and locking is only > done through filesystem or DB. > > How Cellar support locking in cloud environment? Please point some blog or > documentations to achieve this behavior in . > > > > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Failover with Apache Karaf + Cellar + Docker
Hi, I have two karaf instances with Active-Passive configurations. Following is deployment details 1- One become master and all bundles are with start status. 2- Second instance is also up but all my developed bundles are with install status but not running. 3- Both instance communicate on socket and as soon as first goes down second instance just change the status of bundles from install to status, due to which uptime in failover is very minimum. 4- these bundles dont expose http services so i cant use load balancer. I was evaluating Apache Cellar and found i can achieve same behavior with it by setting karaf.lock.level=50 property in etc/startup.properties. But i want to deploy both instances with docker images and locking is only done through filesystem or DB. How Cellar support locking in cloud environment? Please point some blog or documentations to achieve this behavior in . -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Karaf in Docker
Hi,
I recently used the following as entry point:
https://github.com/ANierbeck/Karaf-Vertx/blob/master/Vertx-Karaf-Cluster-Docker/src/main/resources/entrypoint.sh
the docker is generated through a maven build:
but that one uses this entry file:
https://github.com/ANierbeck/Karaf-Vertx/blob/master/Vertx-Karaf-Cluster-Docker/pom.xml#L59
that's it, you'll have a constant docker log.
regards, Achim
2017-06-16 17:47 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> Yes, but I tried with kellar.
>
> Let me check with 4.1.1 "vanilla".
>
> Regards
> JB
>
> On 06/16/2017 04:13 PM, Daniel McGreal wrote:
>
>> But your Dockerfile gets the distribution from
>> http://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-
>> karaf-4.1.1.tar.gz <http://www-us.apache.org/dist
>> /karaf/$%7BKARAF_VERSION%7D/apache-karaf-4.1.1.tar.gz> ?
>>
>> On 16 Jun 2017, at 15:12, Jean-Baptiste Onofré <j...@nanthrax.net >> j...@nanthrax.net>> wrote:
>>>
>>> Let me check as I'm using a custom Karaf distribution (kellar).
>>>
>>> I keep you posted.
>>>
>>> Regards
>>> JB
>>>
>>> On 06/16/2017 04:10 PM, Daniel McGreal wrote:
>>>
>>>> Indeed…
>>>> The mkroli Dockerfile is identical, apart from the MAINTAINER line, and
>>>> yet I get an error in some script file, and the container exits when the
>>>> console appears (presumably because it encounters an EOF?)...
>>>> Argent:~ dan$ docker run mkroli/karaf
>>>> __ __
>>>>/ //_/ __ _/ __/
>>>> / ,< / __ `/ ___/ __ `/ /_
>>>> / /| |/ /_/ / / / /_/ / __/
>>>> /_/ |_|\__,_/_/ \__,_/_/
>>>> Apache Karaf (4.1.1)
>>>> Hit '' for a list of available commands
>>>> and '[cmd] --help' for help on a specific command.
>>>> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>>>> Error in initialization script: /opt/karaf/etc/shell.init.script:
>>>> String index out of range: 0
>>>> karaf@root()>
>>>> Argent:~ dan$
>>>> Running in server mode works, but is a bit quiet. Is there a way for it
>>>> to also output something like log:tail when booted?
>>>> docker run mkroli/karaf server
>>>> I’m surprised yours works as-is, though I am finding Docker not to be
>>>> living up anywhere near to its hype.
>>>> Dan.
>>>>
>>>>> On 16 Jun 2017, at 15:04, Jean-Baptiste Onofré <j...@nanthrax.net
>>>>> <mailto:j...@nanthrax.net><mailto:j...@nanthrax.net>> wrote:
>>>>>
>>>>> Hi Dan,
>>>>>
>>>>> docker run kellar
>>>>> __ __
>>>>> / //_/ __ _/ __/
>>>>> / ,< / __ `/ ___/ __ `/ /_
>>>>>/ /| |/ /_/ / / / /_/ / __/
>>>>> /_/ |_|\__,_/_/ \__,_/_/
>>>>>
>>>>> Apache Karaf (4.1.1)
>>>>>
>>>>> Hit '' for a list of available commands
>>>>> and '[cmd] --help' for help on a specific command.
>>>>> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>>>>>
>>>>>
>>>>> What issue do you have ?
>>>>>
>>>>> Do you see the MOTD and then it exits ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 06/16/2017 03:58 PM, Daniel McGreal wrote:
>>>>>
>>>>>> This seems fairly identical to the mkroli Dockerfile. Does docker run
>>>>>> work for you with this file then presumably? For me, it exits as soon as
>>>>>> the console appears.
>>>>>>
>>>>>>> On 16 Jun 2017, at 14:27, Jean-Baptiste Onofré <j...@nanthrax.net
>>>>>>> <mailto:j...@nanthrax.net><mailto:j...@nanthrax.net>> wrote:
>>>>>>>
>>>>>>> Hi Dan,
>>>>>>>
>>>>>>> Here's a dockerfile I'm using starting from the official java image:
>>>>>>>
>>>>>>> FROM java:8-jdk
>>>>>>> ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
>>>>>>>
>>>>>>> ENV KARAF_VERSION=4.1.1
>>>>>>>
>>>>>>> RUN wgethttp://www-us.apache.org/dist/karaf/${KARAF_VERSION}/
Re: Karaf in Docker
Yes, but I tried with kellar.
Let me check with 4.1.1 "vanilla".
Regards
JB
On 06/16/2017 04:13 PM, Daniel McGreal wrote:
But your Dockerfile gets the distribution from
http://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-karaf-4.1.1.tar.gz
<http://www-us.apache.org/dist/karaf/$%7BKARAF_VERSION%7D/apache-karaf-4.1.1.tar.gz> ?
On 16 Jun 2017, at 15:12, Jean-Baptiste Onofré <j...@nanthrax.net
<mailto:j...@nanthrax.net>> wrote:
Let me check as I'm using a custom Karaf distribution (kellar).
I keep you posted.
Regards
JB
On 06/16/2017 04:10 PM, Daniel McGreal wrote:
Indeed…
The mkroli Dockerfile is identical, apart from the MAINTAINER line, and yet I
get an error in some script file, and the container exits when the console
appears (presumably because it encounters an EOF?)...
Argent:~ dan$ docker run mkroli/karaf
__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (4.1.1)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
Error in initialization script: /opt/karaf/etc/shell.init.script: String
index out of range: 0
karaf@root()>
Argent:~ dan$
Running in server mode works, but is a bit quiet. Is there a way for it to
also output something like log:tail when booted?
docker run mkroli/karaf server
I’m surprised yours works as-is, though I am finding Docker not to be living
up anywhere near to its hype.
Dan.
On 16 Jun 2017, at 15:04, Jean-Baptiste Onofré <j...@nanthrax.net
<mailto:j...@nanthrax.net><mailto:j...@nanthrax.net>> wrote:
Hi Dan,
docker run kellar
__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (4.1.1)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
What issue do you have ?
Do you see the MOTD and then it exits ?
Regards
JB
On 06/16/2017 03:58 PM, Daniel McGreal wrote:
This seems fairly identical to the mkroli Dockerfile. Does docker run work
for you with this file then presumably? For me, it exits as soon as the
console appears.
On 16 Jun 2017, at 14:27, Jean-Baptiste Onofré <j...@nanthrax.net
<mailto:j...@nanthrax.net><mailto:j...@nanthrax.net>> wrote:
Hi Dan,
Here's a dockerfile I'm using starting from the official java image:
FROM java:8-jdk
ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
ENV KARAF_VERSION=4.1.1
RUN
wgethttp://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-karaf-${KARAF_VERSION}.tar.gz
<http://www-us.apache.org/dist/karaf/$%7BKARAF_VERSION%7D/apache-karaf-$%7BKARAF_VERSION%7D.tar.gz>;
\
mkdir /opt/karaf; \
tar --strip-components=1 -C /opt/karaf -xzf
apache-karaf-${KARAF_VERSION}.tar.gz; \
rm apache-karaf-${KARAF_VERSION}.tar.gz; \
mkdir /deploy; \
sed -i 's/^\(felix\.fileinstall\.dir\s*=\s*\).*$/\1\/deploy/'
/opt/karaf/etc/org.apache.felix.fileinstall-deploy.cfg
VOLUME ["/deploy"]
EXPOSE 1099 8101 4
ENTRYPOINT ["/opt/karaf/bin/karaf"]
By the way, I'm in the process to create official Apache Karaf images.
Regards
JB
On 06/16/2017 03:12 PM, Daniel McGreal wrote:
Hi Karaf users,
I’m trying to run Karaf in Docker using mkroli/karaf.
docker run mkroli/karaf fails, possibly because the console is running
and it gets an EOF immediately. docker run mkroli/karaf server works, but
is a bit silent for my liking… can I somehow get it to output log:tail?
Best, Dan.
--
Jean-Baptiste Onofré
jbono...@apache.org <mailto:jbono...@apache.org><mailto:jbono...@apache.org>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend -http://www.talend.com <http://www.talend.com/>
--
Jean-Baptiste Onofré
jbono...@apache.org <mailto:jbono...@apache.org><mailto:jbono...@apache.org>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend -http://www.talend.com <http://www.talend.com/>
--
Jean-Baptiste Onofré
jbono...@apache.org <mailto:jbono...@apache.org>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend -http://www.talend.com <http://www.talend.com/>
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf in Docker
But your Dockerfile gets the distribution from
http://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-karaf-4.1.1.tar.gz
<http://www-us.apache.org/dist/karaf/$%7BKARAF_VERSION%7D/apache-karaf-4.1.1.tar.gz>
?
> On 16 Jun 2017, at 15:12, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>
> Let me check as I'm using a custom Karaf distribution (kellar).
>
> I keep you posted.
>
> Regards
> JB
>
> On 06/16/2017 04:10 PM, Daniel McGreal wrote:
>> Indeed…
>> The mkroli Dockerfile is identical, apart from the MAINTAINER line, and yet
>> I get an error in some script file, and the container exits when the console
>> appears (presumably because it encounters an EOF?)...
>> Argent:~ dan$ docker run mkroli/karaf
>> __ __
>>/ //_/ __ _/ __/
>> / ,< / __ `/ ___/ __ `/ /_
>> / /| |/ /_/ / / / /_/ / __/
>> /_/ |_|\__,_/_/ \__,_/_/
>> Apache Karaf (4.1.1)
>> Hit '' for a list of available commands
>> and '[cmd] --help' for help on a specific command.
>> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>> Error in initialization script: /opt/karaf/etc/shell.init.script: String
>> index out of range: 0
>> karaf@root()>
>> Argent:~ dan$
>> Running in server mode works, but is a bit quiet. Is there a way for it to
>> also output something like log:tail when booted?
>> docker run mkroli/karaf server
>> I’m surprised yours works as-is, though I am finding Docker not to be living
>> up anywhere near to its hype.
>> Dan.
>>> On 16 Jun 2017, at 15:04, Jean-Baptiste Onofré <j...@nanthrax.net
>>> <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net
>>> <mailto:j...@nanthrax.net>>> wrote:
>>>
>>> Hi Dan,
>>>
>>> docker run kellar
>>> __ __
>>> / //_/ __ _/ __/
>>> / ,< / __ `/ ___/ __ `/ /_
>>>/ /| |/ /_/ / / / /_/ / __/
>>> /_/ |_|\__,_/_/ \__,_/_/
>>>
>>> Apache Karaf (4.1.1)
>>>
>>> Hit '' for a list of available commands
>>> and '[cmd] --help' for help on a specific command.
>>> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>>>
>>>
>>> What issue do you have ?
>>>
>>> Do you see the MOTD and then it exits ?
>>>
>>> Regards
>>> JB
>>>
>>> On 06/16/2017 03:58 PM, Daniel McGreal wrote:
>>>> This seems fairly identical to the mkroli Dockerfile. Does docker run work
>>>> for you with this file then presumably? For me, it exits as soon as the
>>>> console appears.
>>>>> On 16 Jun 2017, at 14:27, Jean-Baptiste Onofré <j...@nanthrax.net
>>>>> <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net
>>>>> <mailto:j...@nanthrax.net>>> wrote:
>>>>>
>>>>> Hi Dan,
>>>>>
>>>>> Here's a dockerfile I'm using starting from the official java image:
>>>>>
>>>>> FROM java:8-jdk
>>>>> ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
>>>>>
>>>>> ENV KARAF_VERSION=4.1.1
>>>>>
>>>>> RUN wget
>>>>> http://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-karaf-${KARAF_VERSION}.tar.gz
>>>>>
>>>>> <http://www-us.apache.org/dist/karaf/$%7BKARAF_VERSION%7D/apache-karaf-$%7BKARAF_VERSION%7D.tar.gz>;
>>>>> \
>>>>> mkdir /opt/karaf; \
>>>>> tar --strip-components=1 -C /opt/karaf -xzf
>>>>> apache-karaf-${KARAF_VERSION}.tar.gz; \
>>>>> rm apache-karaf-${KARAF_VERSION}.tar.gz; \
>>>>> mkdir /deploy; \
>>>>> sed -i 's/^\(felix\.fileinstall\.dir\s*=\s*\).*$/\1\/deploy/'
>>>>> /opt/karaf/etc/org.apache.felix.fileinstall-deploy.cfg
>>>>>
>>>>> VOLUME ["/deploy"]
>>>>> EXPOSE 1099 8101 4
>>>>> ENTRYPOINT ["/opt/karaf/bin/karaf"]
>>>>>
>>>>> By the way, I'm in the process to create official Apache Karaf images.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 06/16/2017 03:12 PM, Daniel McGreal wrote:
>>>>>> Hi Karaf users,
>>>>>> I’m trying to run Karaf in Docker using mkroli/karaf.
>>>>>> docker run mkroli/karaf fails, possibly because the console is running
>>>>>> and it gets an EOF immediately. docker run mkroli/karaf server works,
>>>>>> but is a bit silent for my liking… can I somehow get it to output
>>>>>> log:tail?
>>>>>> Best, Dan.
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbono...@apache.org <mailto:jbono...@apache.org>
>>>>> <mailto:jbono...@apache.org <mailto:jbono...@apache.org>>
>>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org <mailto:jbono...@apache.org>
>>> <mailto:jbono...@apache.org <mailto:jbono...@apache.org>>
>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>> Talend - http://www.talend.com <http://www.talend.com/>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org <mailto:jbono...@apache.org>
> http://blog.nanthrax.net <http://blog.nanthrax.net/>
> Talend - http://www.talend.com <http://www.talend.com/>
Re: Karaf in Docker
Let me check as I'm using a custom Karaf distribution (kellar).
I keep you posted.
Regards
JB
On 06/16/2017 04:10 PM, Daniel McGreal wrote:
Indeed…
The mkroli Dockerfile is identical, apart from the MAINTAINER line, and yet I
get an error in some script file, and the container exits when the console
appears (presumably because it encounters an EOF?)...
Argent:~ dan$ docker run mkroli/karaf
__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (4.1.1)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
Error in initialization script: /opt/karaf/etc/shell.init.script: String index
out of range: 0
karaf@root()>
Argent:~ dan$
Running in server mode works, but is a bit quiet. Is there a way for it to also
output something like log:tail when booted?
docker run mkroli/karaf server
I’m surprised yours works as-is, though I am finding Docker not to be living up
anywhere near to its hype.
Dan.
On 16 Jun 2017, at 15:04, Jean-Baptiste Onofré <j...@nanthrax.net
<mailto:j...@nanthrax.net>> wrote:
Hi Dan,
docker run kellar
__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (4.1.1)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
What issue do you have ?
Do you see the MOTD and then it exits ?
Regards
JB
On 06/16/2017 03:58 PM, Daniel McGreal wrote:
This seems fairly identical to the mkroli Dockerfile. Does docker run work
for you with this file then presumably? For me, it exits as soon as the
console appears.
On 16 Jun 2017, at 14:27, Jean-Baptiste Onofré <j...@nanthrax.net
<mailto:j...@nanthrax.net>> wrote:
Hi Dan,
Here's a dockerfile I'm using starting from the official java image:
FROM java:8-jdk
ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
ENV KARAF_VERSION=4.1.1
RUN wget
http://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-karaf-${KARAF_VERSION}.tar.gz;
\
mkdir /opt/karaf; \
tar --strip-components=1 -C /opt/karaf -xzf
apache-karaf-${KARAF_VERSION}.tar.gz; \
rm apache-karaf-${KARAF_VERSION}.tar.gz; \
mkdir /deploy; \
sed -i 's/^\(felix\.fileinstall\.dir\s*=\s*\).*$/\1\/deploy/'
/opt/karaf/etc/org.apache.felix.fileinstall-deploy.cfg
VOLUME ["/deploy"]
EXPOSE 1099 8101 4
ENTRYPOINT ["/opt/karaf/bin/karaf"]
By the way, I'm in the process to create official Apache Karaf images.
Regards
JB
On 06/16/2017 03:12 PM, Daniel McGreal wrote:
Hi Karaf users,
I’m trying to run Karaf in Docker using mkroli/karaf.
docker run mkroli/karaf fails, possibly because the console is running and
it gets an EOF immediately. docker run mkroli/karaf server works, but is a
bit silent for my liking… can I somehow get it to output log:tail?
Best, Dan.
--
Jean-Baptiste Onofré
jbono...@apache.org <mailto:jbono...@apache.org>
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org <mailto:jbono...@apache.org>
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf in Docker
Indeed…
The mkroli Dockerfile is identical, apart from the MAINTAINER line, and yet I
get an error in some script file, and the container exits when the console
appears (presumably because it encounters an EOF?)...
Argent:~ dan$ docker run mkroli/karaf
__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (4.1.1)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
Error in initialization script: /opt/karaf/etc/shell.init.script: String index
out of range: 0
karaf@root()>
Argent:~ dan$
Running in server mode works, but is a bit quiet. Is there a way for it to also
output something like log:tail when booted?
docker run mkroli/karaf server
I’m surprised yours works as-is, though I am finding Docker not to be living up
anywhere near to its hype.
Dan.
> On 16 Jun 2017, at 15:04, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>
> Hi Dan,
>
> docker run kellar
>__ __
> / //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
>/_/ |_|\__,_/_/ \__,_/_/
>
> Apache Karaf (4.1.1)
>
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>
>
> What issue do you have ?
>
> Do you see the MOTD and then it exits ?
>
> Regards
> JB
>
> On 06/16/2017 03:58 PM, Daniel McGreal wrote:
>> This seems fairly identical to the mkroli Dockerfile. Does docker run work
>> for you with this file then presumably? For me, it exits as soon as the
>> console appears.
>>> On 16 Jun 2017, at 14:27, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>>>
>>> Hi Dan,
>>>
>>> Here's a dockerfile I'm using starting from the official java image:
>>>
>>> FROM java:8-jdk
>>> ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
>>>
>>> ENV KARAF_VERSION=4.1.1
>>>
>>> RUN wget
>>> http://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-karaf-${KARAF_VERSION}.tar.gz;
>>> \
>>>mkdir /opt/karaf; \
>>>tar --strip-components=1 -C /opt/karaf -xzf
>>> apache-karaf-${KARAF_VERSION}.tar.gz; \
>>>rm apache-karaf-${KARAF_VERSION}.tar.gz; \
>>>mkdir /deploy; \
>>>sed -i 's/^\(felix\.fileinstall\.dir\s*=\s*\).*$/\1\/deploy/'
>>> /opt/karaf/etc/org.apache.felix.fileinstall-deploy.cfg
>>>
>>> VOLUME ["/deploy"]
>>> EXPOSE 1099 8101 4
>>> ENTRYPOINT ["/opt/karaf/bin/karaf"]
>>>
>>> By the way, I'm in the process to create official Apache Karaf images.
>>>
>>> Regards
>>> JB
>>>
>>> On 06/16/2017 03:12 PM, Daniel McGreal wrote:
>>>> Hi Karaf users,
>>>> I’m trying to run Karaf in Docker using mkroli/karaf.
>>>> docker run mkroli/karaf fails, possibly because the console is running and
>>>> it gets an EOF immediately. docker run mkroli/karaf server works, but is a
>>>> bit silent for my liking… can I somehow get it to output log:tail?
>>>> Best, Dan.
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Karaf in Docker
Hi Dan,
docker run kellar
__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (4.1.1)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
What issue do you have ?
Do you see the MOTD and then it exits ?
Regards
JB
On 06/16/2017 03:58 PM, Daniel McGreal wrote:
This seems fairly identical to the mkroli Dockerfile. Does docker run work for
you with this file then presumably? For me, it exits as soon as the console
appears.
On 16 Jun 2017, at 14:27, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
Hi Dan,
Here's a dockerfile I'm using starting from the official java image:
FROM java:8-jdk
ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
ENV KARAF_VERSION=4.1.1
RUN wget
http://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-karaf-${KARAF_VERSION}.tar.gz;
\
mkdir /opt/karaf; \
tar --strip-components=1 -C /opt/karaf -xzf
apache-karaf-${KARAF_VERSION}.tar.gz; \
rm apache-karaf-${KARAF_VERSION}.tar.gz; \
mkdir /deploy; \
sed -i 's/^\(felix\.fileinstall\.dir\s*=\s*\).*$/\1\/deploy/'
/opt/karaf/etc/org.apache.felix.fileinstall-deploy.cfg
VOLUME ["/deploy"]
EXPOSE 1099 8101 4
ENTRYPOINT ["/opt/karaf/bin/karaf"]
By the way, I'm in the process to create official Apache Karaf images.
Regards
JB
On 06/16/2017 03:12 PM, Daniel McGreal wrote:
Hi Karaf users,
I’m trying to run Karaf in Docker using mkroli/karaf.
docker run mkroli/karaf fails, possibly because the console is running and it
gets an EOF immediately. docker run mkroli/karaf server works, but is a bit
silent for my liking… can I somehow get it to output log:tail?
Best, Dan.
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf in Docker
This seems fairly identical to the mkroli Dockerfile. Does docker run work for
you with this file then presumably? For me, it exits as soon as the console
appears.
> On 16 Jun 2017, at 14:27, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>
> Hi Dan,
>
> Here's a dockerfile I'm using starting from the official java image:
>
> FROM java:8-jdk
> ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
>
> ENV KARAF_VERSION=4.1.1
>
> RUN wget
> http://www-us.apache.org/dist/karaf/${KARAF_VERSION}/apache-karaf-${KARAF_VERSION}.tar.gz;
> \
>mkdir /opt/karaf; \
>tar --strip-components=1 -C /opt/karaf -xzf
> apache-karaf-${KARAF_VERSION}.tar.gz; \
>rm apache-karaf-${KARAF_VERSION}.tar.gz; \
>mkdir /deploy; \
>sed -i 's/^\(felix\.fileinstall\.dir\s*=\s*\).*$/\1\/deploy/'
> /opt/karaf/etc/org.apache.felix.fileinstall-deploy.cfg
>
> VOLUME ["/deploy"]
> EXPOSE 1099 8101 4
> ENTRYPOINT ["/opt/karaf/bin/karaf"]
>
> By the way, I'm in the process to create official Apache Karaf images.
>
> Regards
> JB
>
> On 06/16/2017 03:12 PM, Daniel McGreal wrote:
>> Hi Karaf users,
>> I’m trying to run Karaf in Docker using mkroli/karaf.
>> docker run mkroli/karaf fails, possibly because the console is running and
>> it gets an EOF immediately. docker run mkroli/karaf server works, but is a
>> bit silent for my liking… can I somehow get it to output log:tail?
>> Best, Dan.
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Karaf in Docker
Hi Karaf users, I’m trying to run Karaf in Docker using mkroli/karaf. docker run mkroli/karaf fails, possibly because the console is running and it gets an EOF immediately. docker run mkroli/karaf server works, but is a bit silent for my liking… can I somehow get it to output log:tail? Best, Dan.
Re: Karaf and Docker
to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com mailto:fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com mailto:fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every
Re: Karaf and Docker
on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could
Re: Karaf and Docker
machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com mailto:fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all
Re: Karaf and Docker
been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com mailto:fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services
Re: Karaf and Docker
of them. It always made me laugh when I was told how super efficient and streamlined it was over any other solution because every fat jar deployed (Maven shade plugin abuse in order to be lazy) was between 500Mb and 1.7Gb. So much for being a micro-service. On Apr 8, 2015 2:55 PM, Achim Nierbeck bcanh...@googlemail.com mailto:bcanh...@googlemail.com wrote: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/__is-docker-eating-javas-lunch.__html http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com mailto:fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable
Re: Karaf and Docker
to plugin whatever filter or modules you need ? Personally I think that what is really needed in OSGi is better tooling, especially for making it a lot simpler to build high quality and minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is quite tedious and possibly error prone. I've built my own Maven plugin on top of the bundle plugin so that it can handle a lot more resources (including JSPs that include taglibs for example) and that also tries to be smarter at generating import-package statements. This makes it easier for OSGi newbies to adopt the technology. I'm also worried that the initial learning curve of OSGi might be putting less experienced developers off and more towards package-the-world solutions such as Docker, which while acceptable for some cases such as continuous integration, could also be dangerous if not maintained properly. Regards, Serge Le 11 avr. 2015 à 19:43, Niels niels...@gmail.com a écrit : Could not agree more Achim. Good fad indicators are high promises which are designed to target the ultimate need of decision makers to deliver software quicker and cheaper. Just rewind 10 years and we will find the exact same promises were made at the start of the SOA hype which are now touted by the microservices believers. At the end of the day nothing will prevent people from doing something really badly. I can see the value of docker but unless one really has all the lifecycle ducks in a row I would not go down the path and containerise the all and sundry. Cheers, Niels On 12 Apr 2015, at 08:28, Ryan Moquin fragility...@gmail.com wrote: I used to work somewhere with other developers who always became very spiritual about whatever the latest cool developer technology or methodology is. Microservices was one of them. It always made me laugh when I was told how super efficient and streamlined it was over any other solution because every fat jar deployed (Maven shade plugin abuse in order to be lazy) was between 500Mb and 1.7Gb. So much for being a micro-service. On Apr 8, 2015 2:55 PM, Achim Nierbeck bcanh...@googlemail.com wrote: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch. html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose
Re: Karaf and Docker
Maybe drawing a timeline of a typical application lifecycle and outlining the challenges at the various stages should paint a pretty good picture. This could then be overlaid with the technology features that support each of those concerns. We'd get to a view that would show the areas where docker provides benefits and where OSGi plays its strengths. End of the day OSGi covers the lifecycle of interdependent application components and docker is more or less a means to speed up deployment of a configured compute resource. Nothing wrong with docker but using it purposeful seems a bit of a challenge to a lot of folks out there. Cheers, Niels
Re: Karaf and Docker
to be lazy) was between 500Mb and 1.7Gb. So much for being a micro-service. On Apr 8, 2015 2:55 PM, Achim Nierbeck bcanh...@googlemail.com wrote: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch. html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute
Re: Karaf and Docker
people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch. html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing
Re: Karaf and Docker
will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing and virtualization in general already setup this kind of approach? When a VM or a container has a problem, it may indeed be more simple to launch a new one, reconfigure your application to use it and kill the old one
Re: Karaf and Docker
everything directly listen to ports without any security but be able to plugin whatever filter or modules you need ? Personally I think that what is really needed in OSGi is better tooling, especially for making it a lot simpler to build high quality and minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is quite tedious and possibly error prone. I've built my own Maven plugin on top of the bundle plugin so that it can handle a lot more resources (including JSPs that include taglibs for example) and that also tries to be smarter at generating import-package statements. This makes it easier for OSGi newbies to adopt the technology. I'm also worried that the initial learning curve of OSGi might be putting less experienced developers off and more towards package-the-world solutions such as Docker, which while acceptable for some cases such as continuous integration, could also be dangerous if not maintained properly. Regards, Serge Le 11 avr. 2015 à 19:43, Niels niels...@gmail.com a écrit : Could not agree more Achim. Good fad indicators are high promises which are designed to target the ultimate need of decision makers to deliver software quicker and cheaper. Just rewind 10 years and we will find the exact same promises were made at the start of the SOA hype which are now touted by the microservices believers. At the end of the day nothing will prevent people from doing something really badly. I can see the value of docker but unless one really has all the lifecycle ducks in a row I would not go down the path and containerise the all and sundry. Cheers, Niels On 12 Apr 2015, at 08:28, Ryan Moquin fragility...@gmail.com wrote: I used to work somewhere with other developers who always became very spiritual about whatever the latest cool developer technology or methodology is. Microservices was one of them. It always made me laugh when I was told how super efficient and streamlined it was over any other solution because every fat jar deployed (Maven shade plugin abuse in order to be lazy) was between 500Mb and 1.7Gb. So much for being a micro-service. On Apr 8, 2015 2:55 PM, Achim Nierbeck bcanh...@googlemail.com wrote: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf
Re: Karaf and Docker
regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient
Re: Karaf and Docker
the other stuff ? Or maybe you want to wire things a little differently ? Not have everything directly listen to ports without any security but be able to plugin whatever filter or modules you need ? Personally I think that what is really needed in OSGi is better tooling, especially for making it a lot simpler to build high quality and minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is quite tedious and possibly error prone. I've built my own Maven plugin on top of the bundle plugin so that it can handle a lot more resources (including JSPs that include taglibs for example) and that also tries to be smarter at generating import-package statements. This makes it easier for OSGi newbies to adopt the technology. I'm also worried that the initial learning curve of OSGi might be putting less experienced developers off and more towards package-the-world solutions such as Docker, which while acceptable for some cases such as continuous integration, could also be dangerous if not maintained properly. Regards, Serge Le 11 avr. 2015 à 19:43, Niels niels...@gmail.com a écrit : Could not agree more Achim. Good fad indicators are high promises which are designed to target the ultimate need of decision makers to deliver software quicker and cheaper. Just rewind 10 years and we will find the exact same promises were made at the start of the SOA hype which are now touted by the microservices believers. At the end of the day nothing will prevent people from doing something really badly. I can see the value of docker but unless one really has all the lifecycle ducks in a row I would not go down the path and containerise the all and sundry. Cheers, Niels On 12 Apr 2015, at 08:28, Ryan Moquin fragility...@gmail.com wrote: I used to work somewhere with other developers who always became very spiritual about whatever the latest cool developer technology or methodology is. Microservices was one of them. It always made me laugh when I was told how super efficient and streamlined it was over any other solution because every fat jar deployed (Maven shade plugin abuse in order to be lazy) was between 500Mb and 1.7Gb. So much for being a micro-service. On Apr 8, 2015 2:55 PM, Achim Nierbeck bcanh...@googlemail.com wrote: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part
Re: Karaf and Docker
, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing and virtualization in general already setup this kind of approach? When a VM or a container has a problem, it may indeed be more simple to launch a new one, reconfigure your application to use it and kill the old one. But this is not new at all. And there are some little things to deal with, like reconfiguration. Docker works the same, at its level. And even if you can create new containers, the less procedures you have in production environments, the better it is. So, having applications
Re: Karaf and Docker
big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing and virtualization in general already setup this kind of approach? When a VM or a container has a problem, it may indeed be more simple to launch a new one, reconfigure your application to use it and kill the old one. But this is not new at all. And there are some little things to deal with, like reconfiguration. Docker works the same, at its level. And even if you can create new containers, the less procedures you have in production environments, the better it is. So, having applications with 99,99% uptime will always
Re: Karaf and Docker
part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing and virtualization in general already setup this kind of approach? When a VM or a container has a problem, it may indeed be more simple to launch a new one, reconfigure your application to use it and kill the old one. But this is not new at all. And there are some little things to deal with, like reconfiguration
Re: Karaf and Docker
Hi Charlie, I completely agree with you. I'm glad that there are others that have the same opinion. I'm fine using Docker. I don't want to see great technologies go away because developers can use something like Docker as a way to get away with write crap code. On Apr 8, 2015 4:45 PM, Charlie Mordant cmorda...@gmail.com wrote: My 2 cents on this: On one side, you've the way to build real modular application the right way, you just have to have a brain to do this, and its going simpler and simpler with Karaf, bnd, and all Ops4j work. On the other side, you can mimic a nearly modular architecture, lowering the problem on the infrastructure side. * You'll never be able to build real modular application, you'll never be able to have multiple version of the same product together, you'll never be able to hotswitch your services (or you'll use kubernete, chef or another provisioning tool, but it will always be harder than using OSGI itself). * You'll also never be able to upgrade your app, just replacing an older by a newer (so no automatic provision by Nexus listening). * Your apps will always be as crappy as the previous one: no api/impl package distinction, no intra vm services (and http ones like spring boot add a non negligible overhead). * All your 'microservices' will be 20mo sized (embedding tomcat and spring-beans/context/boot has a cost). As an addition, all the configuration will be duplicated (and slightly different) in all that services. So, the choice is in your hands: coding well and really modular or coding crappy and maintaining a hard-to-maintain infrastructure. Real Microservices architecture is here with Karaf/Camel, not with Spring-boot and Docker. I hope people won't be cheated on the commercial and hype on these wrong solution. I'm not against docker, I use this to provision ldap, ELK, Mail servers, etc... They're just not suited for micro services (and for Spring boot, I consider it always be better than JavaEE, but far from OSGI). 2015-04-08 20:54 GMT+02:00 Achim Nierbeck bcanh...@googlemail.com: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image
Re: Karaf and Docker
Exactly, my point being that even though it's not easy to update things at runtime, I don't want Docker to stop us from trying to achieve that goal and keep innovating. On Apr 8, 2015 11:35 AM, Frank Lyaruu fr...@dexels.com wrote: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing and virtualization in general already setup this kind of approach? When a VM or a container has a problem, it may indeed be more simple to launch a new one, reconfigure your application to use it and kill the old one. But this is not new at all. And there are some little things to deal with, like reconfiguration. Docker works the same, at its level. And even if you can create new containers, the less procedures you have in production environments, the better it is. So, having applications with 99,99% uptime will always be better. BTW, Docker also has some limitations (with systems services as an example). So, it comes with its own problems. And I do not expect embedded systems to use Docker (at least, for the moment). To summer it up, I would say OSGi brings modularity to Java applications
Re: Karaf and Docker
I used to work somewhere with other developers who always became very spiritual about whatever the latest cool developer technology or methodology is. Microservices was one of them. It always made me laugh when I was told how super efficient and streamlined it was over any other solution because every fat jar deployed (Maven shade plugin abuse in order to be lazy) was between 500Mb and 1.7Gb. So much for being a micro-service. On Apr 8, 2015 2:55 PM, Achim Nierbeck bcanh...@googlemail.com wrote: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I
Re: Karaf and Docker
Could not agree more Achim. Good fad indicators are high promises which are designed to target the ultimate need of decision makers to deliver software quicker and cheaper. Just rewind 10 years and we will find the exact same promises were made at the start of the SOA hype which are now touted by the microservices believers. At the end of the day nothing will prevent people from doing something really badly. I can see the value of docker but unless one really has all the lifecycle ducks in a row I would not go down the path and containerise the all and sundry. Cheers, Niels On 12 Apr 2015, at 08:28, Ryan Moquin fragility...@gmail.com wrote: I used to work somewhere with other developers who always became very spiritual about whatever the latest cool developer technology or methodology is. Microservices was one of them. It always made me laugh when I was told how super efficient and streamlined it was over any other solution because every fat jar deployed (Maven shade plugin abuse in order to be lazy) was between 500Mb and 1.7Gb. So much for being a micro-service. On Apr 8, 2015 2:55 PM, Achim Nierbeck bcanh...@googlemail.com wrote: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies
Re: Karaf and Docker
That's been my view, it's something that can be used to make deployments a little easier, not as a I don't have to try to write decent, non-monolithic code anymore. A lot of others are vocally expressing this sort of opinion. It actually feels like a this sort of thing happens a lot. A new technology comes along, makes it easy to get a turd of a piece of software up and running, magically everything goes out the window until the fad passes. I saw someone describe this sort of phenomena in a great way, wish I could find it to quote him. I certainly have no problem if others want to use the latest fad, I don't like how people push the newest fad on everyone rather than let people decide for themselves. On Apr 8, 2015 11:12 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: I see your point. But IMHO, I don't see anything new with Docker, just a easier or more convenient way to do what you do with Solaris Zone, Linux jail/xen, and vm like VirtualBox and vmWare ;) So, Docker itself doesn't provide an application container: it provides an system container. Of course, you can always start a Docker image with just a JVM for your application, for instance bootstrapping Jetty, etc. Or you can just bootstrap an application container (like Karaf ;)), ready to host your applications. My $0.02. Regards JB On 04/08/2015 04:58 PM, Ryan Moquin wrote: I actually pop by your blob periodically to see if you have posted anything new. Your blog post on Karaf and Docker is initially what made me want to look into and understand how Docker could benefit Karaf. As I've been reading other sources, I'm becoming less optimistic about how Docker benefits Karaf. As Vincent mentioned, cloud computing and virtualization are already using a similar approach. I guess I'm wondering why we need to add yet another virtualization container on top of another. Ryan On Wed, Apr 8, 2015 at 10:12 AM, Jean-Baptiste Onofré j...@nanthrax.net mailto:j...@nanthrax.net wrote: Hi Ryan, I invite you to read my blog about Karaf and Docker: http://blog.nanthrax.net/2014/__12/apache-karaf-christmas-__ gifts-docker-io-profiles-and-__decanter/ http://blog.nanthrax.net/2014/12/apache-karaf- christmas-gifts-docker-io-profiles-and-decanter/ and the Karaf Docker proposal: http://karaf.922171.n3.nabble.__com/DISCUSSION-Karaf-docker- __io-td4038470.html http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf- docker-io-td4038470.html Regards JB On 04/08/2015 02:31 PM, Ryan Moquin wrote: Hi, I've been reading up on Docker and trying to understand what all the fuss is about (I'm still not sure for several reasons, but I digress). I was wondering how Docker might influence Karaf in the future as well as how Docker fits in with OSGi and Karaf in general. Specifically my questions are: 1. It seems like the hype of Docker is causing people to shy away from the dynamic nature of OSGi, such as being able to update bundles in a running Karaf container. Is the use of Docker and Karaf boiling down to creating a static Karaf image and anytime you want to upgrade anything, you throw away the instance and replace it with a newly built instance? It feels inefficient. It also feels like it really complicates everything. Unless you are developing on Linux, development using Docker containers is really slow. Dealing with setting up docker containers to test things out locally also seems like a lot of overhead. If you don't test locally with Docker, then can you be sure that deploying in a Docker container will work properly? 2. In regards to the first question, and the fact that people indicate they think Docker will become the standard, will Karaf be dumbed down in the future due to the static nature of Docker? Meaning, if Docker *does* becomes the de factor standard for deploying everything, it feels like developers would be discouraged from using a lot of the run-time benefits OSGi offers. I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. Am I wrong? This is just my initial thoughts and questions. I wanted to see what other people thought and how other people view Docker
Re: Karaf and Docker
Very interesting thread guys :) Actually I recently started a project integrating Karaf with ElasticSearch and for me it was a little like what you guys are describing in this thread. ES, at least in the early versions is quite monolithic and it would clearly benefit from a framework such as OSGi. For example, the clustering technology is quite interesting but why can't it be reused without all the other stuff ? Or maybe you want to wire things a little differently ? Not have everything directly listen to ports without any security but be able to plugin whatever filter or modules you need ? Personally I think that what is really needed in OSGi is better tooling, especially for making it a lot simpler to build high quality and minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is quite tedious and possibly error prone. I've built my own Maven plugin on top of the bundle plugin so that it can handle a lot more resources (including JSPs that include taglibs for example) and that also tries to be smarter at generating import-package statements. This makes it easier for OSGi newbies to adopt the technology. I'm also worried that the initial learning curve of OSGi might be putting less experienced developers off and more towards package-the-world solutions such as Docker, which while acceptable for some cases such as continuous integration, could also be dangerous if not maintained properly. Regards, Serge Le 11 avr. 2015 à 19:43, Niels niels...@gmail.com a écrit : Could not agree more Achim. Good fad indicators are high promises which are designed to target the ultimate need of decision makers to deliver software quicker and cheaper. Just rewind 10 years and we will find the exact same promises were made at the start of the SOA hype which are now touted by the microservices believers. At the end of the day nothing will prevent people from doing something really badly. I can see the value of docker but unless one really has all the lifecycle ducks in a row I would not go down the path and containerise the all and sundry. Cheers, Niels On 12 Apr 2015, at 08:28, Ryan Moquin fragility...@gmail.com wrote: I used to work somewhere with other developers who always became very spiritual about whatever the latest cool developer technology or methodology is. Microservices was one of them. It always made me laugh when I was told how super efficient and streamlined it was over any other solution because every fat jar deployed (Maven shade plugin abuse in order to be lazy) was between 500Mb and 1.7Gb. So much for being a micro-service. On Apr 8, 2015 2:55 PM, Achim Nierbeck bcanh...@googlemail.com wrote: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker
Re: Karaf and Docker
I think it makes sense to leverage profiles in the docker feature that I started and proposed: for me it's a great addition of the Karaf instances. The Karaf Docker feature can bootstrap an image including a Karaf profile. My $0.02 Regards JB On 04/08/2015 04:24 PM, Guillaume Nodet wrote: All the tooling to build karaf distributions is now available in master, including the use of profiles, kars, features. This code has been extracted from the maven plugin so that it does not depend on maven at all : all downloads are performed as done from inside karaf with the features service. This tooling can create dynamic or completely static distributions (with all bundles being referenced and no need for the features service provisioning, a read-only config admin, no file install, etc...). I haven't brought back the pure docker side yet, i.e. build the docker image by extracting the distribution on top of a java based docker image, but I still have the original code, so it's just a matter of getting back to working on it. 2015-04-08 16:12 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net mailto:j...@nanthrax.net: Hi Ryan, I invite you to read my blog about Karaf and Docker: http://blog.nanthrax.net/2014/__12/apache-karaf-christmas-__gifts-docker-io-profiles-and-__decanter/ http://blog.nanthrax.net/2014/12/apache-karaf-christmas-gifts-docker-io-profiles-and-decanter/ and the Karaf Docker proposal: http://karaf.922171.n3.nabble.__com/DISCUSSION-Karaf-docker-__io-td4038470.html http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-docker-io-td4038470.html Regards JB On 04/08/2015 02:31 PM, Ryan Moquin wrote: Hi, I've been reading up on Docker and trying to understand what all the fuss is about (I'm still not sure for several reasons, but I digress). I was wondering how Docker might influence Karaf in the future as well as how Docker fits in with OSGi and Karaf in general. Specifically my questions are: 1. It seems like the hype of Docker is causing people to shy away from the dynamic nature of OSGi, such as being able to update bundles in a running Karaf container. Is the use of Docker and Karaf boiling down to creating a static Karaf image and anytime you want to upgrade anything, you throw away the instance and replace it with a newly built instance? It feels inefficient. It also feels like it really complicates everything. Unless you are developing on Linux, development using Docker containers is really slow. Dealing with setting up docker containers to test things out locally also seems like a lot of overhead. If you don't test locally with Docker, then can you be sure that deploying in a Docker container will work properly? 2. In regards to the first question, and the fact that people indicate they think Docker will become the standard, will Karaf be dumbed down in the future due to the static nature of Docker? Meaning, if Docker *does* becomes the de factor standard for deploying everything, it feels like developers would be discouraged from using a lot of the run-time benefits OSGi offers. I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. Am I wrong? This is just my initial thoughts and questions. I wanted to see what other people thought and how other people view Docker and Karaf being used or how it is being used. Ryan -- Jean-Baptiste Onofré jbono...@apache.org mailto:jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf and Docker
I actually pop by your blob periodically to see if you have posted anything new. Your blog post on Karaf and Docker is initially what made me want to look into and understand how Docker could benefit Karaf. As I've been reading other sources, I'm becoming less optimistic about how Docker benefits Karaf. As Vincent mentioned, cloud computing and virtualization are already using a similar approach. I guess I'm wondering why we need to add yet another virtualization container on top of another. Ryan On Wed, Apr 8, 2015 at 10:12 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Ryan, I invite you to read my blog about Karaf and Docker: http://blog.nanthrax.net/2014/12/apache-karaf-christmas- gifts-docker-io-profiles-and-decanter/ and the Karaf Docker proposal: http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-docker- io-td4038470.html Regards JB On 04/08/2015 02:31 PM, Ryan Moquin wrote: Hi, I've been reading up on Docker and trying to understand what all the fuss is about (I'm still not sure for several reasons, but I digress). I was wondering how Docker might influence Karaf in the future as well as how Docker fits in with OSGi and Karaf in general. Specifically my questions are: 1. It seems like the hype of Docker is causing people to shy away from the dynamic nature of OSGi, such as being able to update bundles in a running Karaf container. Is the use of Docker and Karaf boiling down to creating a static Karaf image and anytime you want to upgrade anything, you throw away the instance and replace it with a newly built instance? It feels inefficient. It also feels like it really complicates everything. Unless you are developing on Linux, development using Docker containers is really slow. Dealing with setting up docker containers to test things out locally also seems like a lot of overhead. If you don't test locally with Docker, then can you be sure that deploying in a Docker container will work properly? 2. In regards to the first question, and the fact that people indicate they think Docker will become the standard, will Karaf be dumbed down in the future due to the static nature of Docker? Meaning, if Docker *does* becomes the de factor standard for deploying everything, it feels like developers would be discouraged from using a lot of the run-time benefits OSGi offers. I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. Am I wrong? This is just my initial thoughts and questions. I wanted to see what other people thought and how other people view Docker and Karaf being used or how it is being used. Ryan -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf and Docker
Hi Ryan, I invite you to read my blog about Karaf and Docker: http://blog.nanthrax.net/2014/12/apache-karaf-christmas-gifts-docker-io-profiles-and-decanter/ and the Karaf Docker proposal: http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-docker-io-td4038470.html Regards JB On 04/08/2015 02:31 PM, Ryan Moquin wrote: Hi, I've been reading up on Docker and trying to understand what all the fuss is about (I'm still not sure for several reasons, but I digress). I was wondering how Docker might influence Karaf in the future as well as how Docker fits in with OSGi and Karaf in general. Specifically my questions are: 1. It seems like the hype of Docker is causing people to shy away from the dynamic nature of OSGi, such as being able to update bundles in a running Karaf container. Is the use of Docker and Karaf boiling down to creating a static Karaf image and anytime you want to upgrade anything, you throw away the instance and replace it with a newly built instance? It feels inefficient. It also feels like it really complicates everything. Unless you are developing on Linux, development using Docker containers is really slow. Dealing with setting up docker containers to test things out locally also seems like a lot of overhead. If you don't test locally with Docker, then can you be sure that deploying in a Docker container will work properly? 2. In regards to the first question, and the fact that people indicate they think Docker will become the standard, will Karaf be dumbed down in the future due to the static nature of Docker? Meaning, if Docker *does* becomes the de factor standard for deploying everything, it feels like developers would be discouraged from using a lot of the run-time benefits OSGi offers. I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. Am I wrong? This is just my initial thoughts and questions. I wanted to see what other people thought and how other people view Docker and Karaf being used or how it is being used. Ryan -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Karaf and Docker
Hi, I've been reading up on Docker and trying to understand what all the fuss is about (I'm still not sure for several reasons, but I digress). I was wondering how Docker might influence Karaf in the future as well as how Docker fits in with OSGi and Karaf in general. Specifically my questions are: 1. It seems like the hype of Docker is causing people to shy away from the dynamic nature of OSGi, such as being able to update bundles in a running Karaf container. Is the use of Docker and Karaf boiling down to creating a static Karaf image and anytime you want to upgrade anything, you throw away the instance and replace it with a newly built instance? It feels inefficient. It also feels like it really complicates everything. Unless you are developing on Linux, development using Docker containers is really slow. Dealing with setting up docker containers to test things out locally also seems like a lot of overhead. If you don't test locally with Docker, then can you be sure that deploying in a Docker container will work properly? 2. In regards to the first question, and the fact that people indicate they think Docker will become the standard, will Karaf be dumbed down in the future due to the static nature of Docker? Meaning, if Docker *does* becomes the de factor standard for deploying everything, it feels like developers would be discouraged from using a lot of the run-time benefits OSGi offers. I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. Am I wrong? This is just my initial thoughts and questions. I wanted to see what other people thought and how other people view Docker and Karaf being used or how it is being used. Ryan
Re: Karaf and Docker
Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing and virtualization in general already setup this kind of approach? When a VM or a container has a problem, it may indeed be more simple to launch a new one, reconfigure your application to use it and kill the old one. But this is not new at all. And there are some little things to deal with, like reconfiguration. Docker works the same, at its level. And even if you can create new containers, the less procedures you have in production environments, the better it is. So, having applications with 99,99% uptime will always be better. BTW, Docker also has some limitations (with systems services as an example). So, it comes with its own problems. And I do not expect embedded systems to use Docker (at least, for the moment). To summer it up, I would say OSGi brings modularity to Java applications. And that Docker brings modularity to deployments. That's not the same. My 2 cents, Vincent. -- Vincent Zurczak Linagora: www.linagora.com http://www.linagora.com/ Twitter https://twitter.com/VincentZurczak Vincent Zurczak @ LinkedIn http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7 My Skype ID callto://vincent.zurczak My English blog http://vzurczak.wordpress.com
Re: Karaf and Docker
I see your point. But IMHO, I don't see anything new with Docker, just a easier or more convenient way to do what you do with Solaris Zone, Linux jail/xen, and vm like VirtualBox and vmWare ;) So, Docker itself doesn't provide an application container: it provides an system container. Of course, you can always start a Docker image with just a JVM for your application, for instance bootstrapping Jetty, etc. Or you can just bootstrap an application container (like Karaf ;)), ready to host your applications. My $0.02. Regards JB On 04/08/2015 04:58 PM, Ryan Moquin wrote: I actually pop by your blob periodically to see if you have posted anything new. Your blog post on Karaf and Docker is initially what made me want to look into and understand how Docker could benefit Karaf. As I've been reading other sources, I'm becoming less optimistic about how Docker benefits Karaf. As Vincent mentioned, cloud computing and virtualization are already using a similar approach. I guess I'm wondering why we need to add yet another virtualization container on top of another. Ryan On Wed, Apr 8, 2015 at 10:12 AM, Jean-Baptiste Onofré j...@nanthrax.net mailto:j...@nanthrax.net wrote: Hi Ryan, I invite you to read my blog about Karaf and Docker: http://blog.nanthrax.net/2014/__12/apache-karaf-christmas-__gifts-docker-io-profiles-and-__decanter/ http://blog.nanthrax.net/2014/12/apache-karaf-christmas-gifts-docker-io-profiles-and-decanter/ and the Karaf Docker proposal: http://karaf.922171.n3.nabble.__com/DISCUSSION-Karaf-docker-__io-td4038470.html http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-docker-io-td4038470.html Regards JB On 04/08/2015 02:31 PM, Ryan Moquin wrote: Hi, I've been reading up on Docker and trying to understand what all the fuss is about (I'm still not sure for several reasons, but I digress). I was wondering how Docker might influence Karaf in the future as well as how Docker fits in with OSGi and Karaf in general. Specifically my questions are: 1. It seems like the hype of Docker is causing people to shy away from the dynamic nature of OSGi, such as being able to update bundles in a running Karaf container. Is the use of Docker and Karaf boiling down to creating a static Karaf image and anytime you want to upgrade anything, you throw away the instance and replace it with a newly built instance? It feels inefficient. It also feels like it really complicates everything. Unless you are developing on Linux, development using Docker containers is really slow. Dealing with setting up docker containers to test things out locally also seems like a lot of overhead. If you don't test locally with Docker, then can you be sure that deploying in a Docker container will work properly? 2. In regards to the first question, and the fact that people indicate they think Docker will become the standard, will Karaf be dumbed down in the future due to the static nature of Docker? Meaning, if Docker *does* becomes the de factor standard for deploying everything, it feels like developers would be discouraged from using a lot of the run-time benefits OSGi offers. I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. Am I wrong? This is just my initial thoughts and questions. I wanted to see what other people thought and how other people view Docker and Karaf being used or how it is being used. Ryan -- Jean-Baptiste Onofré jbono...@apache.org mailto:jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf and Docker
Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing and virtualization in general already setup this kind of approach? When a VM or a container has a problem, it may indeed be more simple to launch a new one, reconfigure your application to use it and kill the old one. But this is not new at all. And there are some little things to deal with, like reconfiguration. Docker works the same, at its level. And even if you can create new containers, the less procedures you have in production environments, the better it is. So, having applications with 99,99% uptime will always be better. BTW, Docker also has some limitations (with systems services as an example). So, it comes with its own problems. And I do not expect embedded systems to use Docker (at least, for the moment). To summer it up, I would say OSGi brings modularity to Java applications. And that Docker brings modularity to deployments. That's not the same. My 2 cents, Vincent. -- Vincent Zurczak Linagora: www.linagora.com [image: Twitter] https://twitter.com/VincentZurczak [image: Vincent Zurczak @ LinkedIn] http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7 [image: My Skype ID] callto://vincent.zurczak [image: My English blog] http://vzurczak.wordpress.com
Re: Karaf and Docker
All the tooling to build karaf distributions is now available in master, including the use of profiles, kars, features. This code has been extracted from the maven plugin so that it does not depend on maven at all : all downloads are performed as done from inside karaf with the features service. This tooling can create dynamic or completely static distributions (with all bundles being referenced and no need for the features service provisioning, a read-only config admin, no file install, etc...). I haven't brought back the pure docker side yet, i.e. build the docker image by extracting the distribution on top of a java based docker image, but I still have the original code, so it's just a matter of getting back to working on it. 2015-04-08 16:12 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: Hi Ryan, I invite you to read my blog about Karaf and Docker: http://blog.nanthrax.net/2014/12/apache-karaf-christmas- gifts-docker-io-profiles-and-decanter/ and the Karaf Docker proposal: http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-docker- io-td4038470.html Regards JB On 04/08/2015 02:31 PM, Ryan Moquin wrote: Hi, I've been reading up on Docker and trying to understand what all the fuss is about (I'm still not sure for several reasons, but I digress). I was wondering how Docker might influence Karaf in the future as well as how Docker fits in with OSGi and Karaf in general. Specifically my questions are: 1. It seems like the hype of Docker is causing people to shy away from the dynamic nature of OSGi, such as being able to update bundles in a running Karaf container. Is the use of Docker and Karaf boiling down to creating a static Karaf image and anytime you want to upgrade anything, you throw away the instance and replace it with a newly built instance? It feels inefficient. It also feels like it really complicates everything. Unless you are developing on Linux, development using Docker containers is really slow. Dealing with setting up docker containers to test things out locally also seems like a lot of overhead. If you don't test locally with Docker, then can you be sure that deploying in a Docker container will work properly? 2. In regards to the first question, and the fact that people indicate they think Docker will become the standard, will Karaf be dumbed down in the future due to the static nature of Docker? Meaning, if Docker *does* becomes the de factor standard for deploying everything, it feels like developers would be discouraged from using a lot of the run-time benefits OSGi offers. I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. Am I wrong? This is just my initial thoughts and questions. I wanted to see what other people thought and how other people view Docker and Karaf being used or how it is being used. Ryan -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf and Docker
I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM
Re: Karaf and Docker
I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes a trend, then it feels that many of the nice features of Karaf will become discouraged and I can't see them being furthered in Karaf at that point. I love Karaf and everything it offers. I'm just a little concerned about how Docker is being pushed and the mindset that seems to evolving around it. The point is, I'm hoping that because Docker is immutable, that it doesn't cause all software development to shoot to be immutable. Hopefully that makes sense. :) Lots of new technologies allow developers to know less about software development and to write sloppier code because they can get away with it. While building things faster and minimizing redundant or error prone tasks is great. I guess I'm a little concerned about how Docker can be misused and the effect it could have. Hopefully that makes sense :) I have no problem embracing Docker as a container to run Karaf in, I'm just hoping Docker doesn't become a liability or stifler to Karaf. These of course are only my opinion of the research I've been doing on and off. I may be completely off the mark or misinterpreting things. Ryan On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I don't know if we can really compare Karaf and Docker. I use OSGi to build modular applications. My bundles are Java modules that I can assemble in one way or another. And I use Karaf to create a custom distribution of my OSGi applications. It is a developer thing. Now, I use Docker to execute applications in an isolated container on a machine. Even on VM, running Docker can simplify support and debug for applications. The fact we can isolate things is very helpful for that. And it is convenient to maximize the usage of VM resources. I do not see how one could replace the other. BTW, I already run Karaf in Docker containers. And one of our OSGi applications (which runs in Karaf) can create and interact with Docker containers. So, you can make both of them together when you need. Le 08/04/2015 14:31, Ryan Moquin a écrit : I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. May I say that cloud computing and virtualization in general already setup this kind of approach? When a VM or a container has a problem, it may indeed be more simple to launch a new one, reconfigure your application to use it and kill the old one. But this is not new at all. And there are some little things to deal with, like reconfiguration. Docker works the same, at its level. And even if you can create new containers, the less procedures you have in production environments, the better it is. So, having applications with 99,99% uptime will always be better. BTW, Docker also has some limitations (with systems services as an example). So, it comes with its own problems. And I do not expect embedded systems to use Docker (at least, for the moment). To summer it up, I would say OSGi brings modularity to Java applications. And that Docker brings modularity to deployments. That's not the same. My 2 cents, Vincent. -- Vincent Zurczak Linagora: www.linagora.com [image: Twitter] https://twitter.com/VincentZurczak [image: Vincent Zurczak
Re: Karaf and Docker
Hi, I totally agree with JB. We use docker to start our karaf containers. In addition with boot features we can setup karaf container with just one simple command. Deploying new karaf runtimes to our customers has become much easier this way. And if you have a look at fabric8 / openshift you will see, that even cloud hosters go in that direction. Regards, Marco Am 08.04.2015 um 17:10 schrieb Jean-Baptiste Onofré: I see your point. But IMHO, I don't see anything new with Docker, just a easier or more convenient way to do what you do with Solaris Zone, Linux jail/xen, and vm like VirtualBox and vmWare ;) So, Docker itself doesn't provide an application container: it provides an system container. Of course, you can always start a Docker image with just a JVM for your application, for instance bootstrapping Jetty, etc. Or you can just bootstrap an application container (like Karaf ;)), ready to host your applications. My $0.02. Regards JB On 04/08/2015 04:58 PM, Ryan Moquin wrote: I actually pop by your blob periodically to see if you have posted anything new. Your blog post on Karaf and Docker is initially what made me want to look into and understand how Docker could benefit Karaf. As I've been reading other sources, I'm becoming less optimistic about how Docker benefits Karaf. As Vincent mentioned, cloud computing and virtualization are already using a similar approach. I guess I'm wondering why we need to add yet another virtualization container on top of another. Ryan On Wed, Apr 8, 2015 at 10:12 AM, Jean-Baptiste Onofré j...@nanthrax.net mailto:j...@nanthrax.net wrote: Hi Ryan, I invite you to read my blog about Karaf and Docker: http://blog.nanthrax.net/2014/__12/apache-karaf-christmas-__gifts-docker-io-profiles-and-__decanter/ http://blog.nanthrax.net/2014/12/apache-karaf-christmas-gifts-docker-io-profiles-and-decanter/ and the Karaf Docker proposal: http://karaf.922171.n3.nabble.__com/DISCUSSION-Karaf-docker-__io-td4038470.html http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-docker-io-td4038470.html Regards JB On 04/08/2015 02:31 PM, Ryan Moquin wrote: Hi, I've been reading up on Docker and trying to understand what all the fuss is about (I'm still not sure for several reasons, but I digress). I was wondering how Docker might influence Karaf in the future as well as how Docker fits in with OSGi and Karaf in general. Specifically my questions are: 1. It seems like the hype of Docker is causing people to shy away from the dynamic nature of OSGi, such as being able to update bundles in a running Karaf container. Is the use of Docker and Karaf boiling down to creating a static Karaf image and anytime you want to upgrade anything, you throw away the instance and replace it with a newly built instance? It feels inefficient. It also feels like it really complicates everything. Unless you are developing on Linux, development using Docker containers is really slow. Dealing with setting up docker containers to test things out locally also seems like a lot of overhead. If you don't test locally with Docker, then can you be sure that deploying in a Docker container will work properly? 2. In regards to the first question, and the fact that people indicate they think Docker will become the standard, will Karaf be dumbed down in the future due to the static nature of Docker? Meaning, if Docker *does* becomes the de factor standard for deploying everything, it feels like developers would be discouraged from using a lot of the run-time benefits OSGi offers. I kind of feel like the big push of Docker in the development community in general (as a whole, not talking about the Karaf developer community), will potentially cause a lack of innovation and improvements in the deploying of applications. Docker could become a crutch. If an application is slowly leaking memory over a 24 hour period, why fix it? When it crashes, just replace it with a new instance. Am I wrong? This is just my initial thoughts and questions. I wanted to see what other people thought and how other people view Docker and Karaf being used or how it is being used. Ryan -- Jean-Baptiste Onofré jbono...@apache.org mailto:jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- ++ Business-Software aus einer Hand ++ ++ Internet, Warenwirtschaft, Linux, Virtualisierung ++ http://www.intersales.de http://www.eisxen.org http://www.tarantella-partner.de http://www.medisales.de http://www.eisfair.net interSales AG
Re: Karaf and Docker
My 2 cents on this: On one side, you've the way to build real modular application the right way, you just have to have a brain to do this, and its going simpler and simpler with Karaf, bnd, and all Ops4j work. On the other side, you can mimic a nearly modular architecture, lowering the problem on the infrastructure side. * You'll never be able to build real modular application, you'll never be able to have multiple version of the same product together, you'll never be able to hotswitch your services (or you'll use kubernete, chef or another provisioning tool, but it will always be harder than using OSGI itself). * You'll also never be able to upgrade your app, just replacing an older by a newer (so no automatic provision by Nexus listening). * Your apps will always be as crappy as the previous one: no api/impl package distinction, no intra vm services (and http ones like spring boot add a non negligible overhead). * All your 'microservices' will be 20mo sized (embedding tomcat and spring-beans/context/boot has a cost). As an addition, all the configuration will be duplicated (and slightly different) in all that services. So, the choice is in your hands: coding well and really modular or coding crappy and maintaining a hard-to-maintain infrastructure. Real Microservices architecture is here with Karaf/Camel, not with Spring-boot and Docker. I hope people won't be cheated on the commercial and hype on these wrong solution. I'm not against docker, I use this to provision ldap, ELK, Mail servers, etc... They're just not suited for micro services (and for Spring boot, I consider it always be better than JavaEE, but far from OSGI). 2015-04-08 20:54 GMT+02:00 Achim Nierbeck bcanh...@googlemail.com: I'm very ambivalent regarding this topic. On one hand I see a lot of move to Docker as heading for the holy grail on fixing all the issues we had in the past. #FAIL On the other hand I see some benefits of it, but still haven't found the concrete use-case where it did top a bar-metal or bare virtualized machine. It's absolutely true that it does have some benefits for easier deployment of Infrastructure but I also see a lot of failures in usage of Docker. Just to mention one, where did the init daemon go, it's been there for a reason in linux OS's and now we run applications on top of the system without it ... I don't feel comfortable with that, especially if you don't have a JVM as process running which starts spawning other processes (one might remember the zombie processes). In the end there are mostly more slopy/lazy people around[1] trying to get something going, that's why Docker will be sufficient enough, while the dynamic and re-configurable service oriented software architecture will be on the decrease. One just needs to follow that Microservice hype. Docker/SpringBoot are just part of this mantra :D In the end people will just split their Monolithic rubbish up to different small Monolithic piles of rubbish, but in case one of them is failing, they'll end up with one big failing pile of rubbish. Besides this rant, I think building a custom Karaf with your application on top, distributable as Docker image. Or as I did for a showcase building a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a good combination. As long as it's possible to configure the services inside this docker image from the outside. regards, Achim [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html 2015-04-08 17:34 GMT+02:00 Frank Lyaruu fr...@dexels.com: I agree, I do feel that vibe from time to time, mostly due to the 'containers should be immutable' mantra. In my opinion, if you can get away with it, make it as dynamic as you want, but I guess we all know that building an application that can be reconfigured + updated on the fly is not easy at all. Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, with quite a different approach: I explore monitoring the Docker API to discover services, and inject those services as OSGi configuration data: http://www.codemonkey.nl/discovery/ I think OSGi and Docker can complement each other very nicely. regards, Frank On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin fragility...@gmail.com wrote: Don't get me wrong, I don't mean that Docker and Karaf are interchangeable. I mean that it feels like, from quite a few things I read, that the trend may be to have a docker image built as part of every CI build. The purpose being that deployments should be fully immutable and if changes need to be made, then a new Docker image should be generated and deployed. One particular conversation that I felt really expressed this type of development track is this one: https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk Fabric8 used to be fully built on Karaf but has changed the approach to support other runtimes. Nothing is wrong with that, but if that pattern becomes
