Karaf and Docker

[Ryan Moquin <fr...@gmail.com>]

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

[Ryan Moquin <fr...@gmail.com>]

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é" <jb...@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é <jb@nanthrax.net
>> <ma...@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é
>>     jbonofre@apache.org <ma...@apache.org>
>>     http://blog.nanthrax.net
>>     Talend - http://www.talend.com
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Karaf and Docker

[Marco Westermann <mw...@intersales.de>]

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é <jb@nanthrax.net
>> <ma...@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é
>>     jbonofre@apache.org <ma...@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 Internet Commerce
Weinsbergstr. 190
50825 Köln

Tel  02 21 - 27 90 50
Fax  02 21 - 27 90 517
Mail isinfo@intersales.de
Mail mw@intersales.de
Web  www.intersales.de

Handelsregister Köln HR B 30904
Ust.-Id.: DE199672015
Finanzamt Köln-Nord. UstID: nicht vergeben
Aufsichtsratsvorsitzender: Michael Hippler
Vorstand: Andrej Radonic, Peter Zander

Re: Karaf and Docker

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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é <jb@nanthrax.net
> <ma...@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é
>     jbonofre@apache.org <ma...@apache.org>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Ryan Moquin <fr...@gmail.com>]

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é <jb...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Karaf and Docker

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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é <jb@nanthrax.net
> <ma...@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é
>     jbonofre@apache.org <ma...@apache.org>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Guillaume Nodet <gn...@apache.org>]

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é <jb...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Karaf and Docker

[Jean-Baptiste Onofré <jb...@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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Ryan Moquin <fr...@gmail.com>]

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 <fr...@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.zurczak@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

[Ryan Moquin <fr...@gmail.com>]

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" <cm...@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 <bc...@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 <fr...@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.zurczak@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>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>
>
> --
> Charlie Mordant
>
> Full OSGI/EE stack made with Karaf:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>

Re: Karaf and Docker

[Charlie Mordant <cm...@gmail.com>]

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 <bc...@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 <fr...@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.zurczak@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>
>>>>
>>>
>>>
>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>


-- 
Charlie Mordant

Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent

Re: Karaf and Docker

[Charlie Mordant <cm...@gmail.com>]

Hi Serge,

Docker learning curve is lower than the maven-Bnd-pg one? This is just
hype, not reality...

Regards,

2015-04-12 8:19 GMT+02:00 Achim Nierbeck <bc...@googlemail.com>:

> Hi Serge,
>
> since you wanted to integrate ES in Karaf, take a look at decanter. About
> the modularization of ES, I'm with you. A colleague of mine just recently
> talked to Shay Banon about this, but right now they aren't in for OSGi, I
> guess we have to push them there a little.
>
> About tooling, yes I think we could need some better tooling here and
> there, but as usual the devs here just scratch their own itches. So if we
> miss things, since we do it just a bit different or don't feel the pain
> we're not going to build those tools ;)
>
> Personally I think the learning curve used to be steeper, but with
> blueprint and DS it turns out to be much simpler. Until people stumble over
> service-trackers in Activators ;)
>
> The thing about Docker is, it's a nice tool and does help here and there,
> for showcases, POCs and such. In the end people will use
> it as the hammer for every issue they have.
>
> regards, Achim
>
>
> 2015-04-12 3:52 GMT+02:00 Serge Huber <sh...@jahia.com>:
>
>> 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 <ni...@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 <fr...@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" <bc...@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 <fr...@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.zurczak@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
>>>>>>
>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>> <linkedin_16.png>
>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>> <http://vzurczak.wordpress.com>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>> & Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>


-- 
Charlie Mordant

Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent

Re: Karaf and Docker

[Achim Nierbeck <bc...@googlemail.com>]

Hi Serge,

since you wanted to integrate ES in Karaf, take a look at decanter. About
the modularization of ES, I'm with you. A colleague of mine just recently
talked to Shay Banon about this, but right now they aren't in for OSGi, I
guess we have to push them there a little.

About tooling, yes I think we could need some better tooling here and
there, but as usual the devs here just scratch their own itches. So if we
miss things, since we do it just a bit different or don't feel the pain
we're not going to build those tools ;)

Personally I think the learning curve used to be steeper, but with
blueprint and DS it turns out to be much simpler. Until people stumble over
service-trackers in Activators ;)

The thing about Docker is, it's a nice tool and does help here and there,
for showcases, POCs and such. In the end people will use
it as the hammer for every issue they have.

regards, Achim


2015-04-12 3:52 GMT+02:00 Serge Huber <sh...@jahia.com>:

> 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 <ni...@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 <fr...@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" <bc...@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 <fr...@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.zurczak@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
>>>>>
>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>> <linkedin_16.png>
>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> <skype_16.png>
>>>>> <callto://vincent.zurczak> <wordpress_16.png>
>>>>> <http://vzurczak.wordpress.com>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[Achim Nierbeck <bc...@googlemail.com>]

Hi Serge,

I think there are some drawbacks with Microservices which you run into over
time, that to my personal opinion have already been addressed with OSGi.
As a short list of what I presented at the JavaLand conference last month:
- operations overhead (Java, ruby, node.js, python ... what else)
- dev-ops skills are required
- implicit interfaces - changes in syntax/semantics
- complexity of distributed systems
- asynchronity
- Testability challenges

Most of those are addressable with the right modularity and within the same
JVM when using OSGi.
If one takes those experiences to a "bigger" level, between different
Servers, you end up with Microservices in a manageable way.
In the end those Microservices applications are just as modular as OSGi
services, just as one Application on each different instance.

just my 2 cents.

Regards, Achim

P.S. I still need to move those slides to slideshare ... :D


2015-04-13 21:49 GMT+02:00 Serge Huber <sh...@jahia.com>:

> Interesting discussion indeed.
>
> I'm currently at ApacheCon US and I've taken a few opportunities to
> promote Apache Karaf which surprisingly few people know about. But again
> what I was describing earlier is really a frequent feedback : is modularity
> worth the trouble when I can built "micro-services" that are actually
> running in docker containers ? Although I am convinced that the two are not
> in opposition, I think it would be great to have a killer use case to
> demonstrate what the benefits of using Karaf would be.
>
> I'm really looking forward to meeting Jean-Baptiste in person ! I love
> Karaf and I hope to be able to exchange with him a few experiences around
> it.
>
> Regards,
>   Serge
>
> - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
> Acacias, Switzerland
> twitter: @sergehuber <https://twitter.com/sergehuber>
>
> <http://jahiaone.com/register>
> JahiaOne <http://www.jahiaone.com/>, our international user conference is
> back! June 10-12 in Paris - Grab your tickets now
> <http://www.jahiaone.com/>!
>
> Jahia is a leading open source User eXperience Platform (UXP) vendor,
> relentlessly working at transforming a siloed industry into a user-driven
> one, beyond technology constraints - http://www.jahia.com
>
>
> On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck <bc...@googlemail.com>
> wrote:
>
>> Hey,
>>
>> yes I fully agree, also with the Spring-Boot stuff.
>> as already stated on the other thread, I think there are certain cases
>> where Docker images are useful.
>> For a POC, for CI I think a Docker Image is useful. In the end if you
>> want to run it in Production I rather have the Ansible setup.
>>
>> regards, Achim
>>
>>
>> 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>
>>> Hi Ed,
>>>
>>> I can't agree more ;)
>>> I fully agree about your points.
>>>
>>> I quite have the same view on Spring Boot ;)
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 04/13/2015 04:32 PM, Ed Welch wrote:
>>>
>>>> I've really enjoyed following this thread, and I have to say, as a
>>>> Docker skeptic surrounded by people who want to bash my brains in with
>>>> docker images, it's nice to hear some feedback from people who seem to have
>>>> a healthy dose of skepticism like I do...
>>>>
>>>> So rather than rehash all the things I agree with that have been said
>>>> so far, I wanted to comment a few things I hadn't seen:
>>>>
>>>> The biggest discussion point I bring up with my peers regarding docker
>>>> that I've been using to kind of hold the floodgates back:  Who is
>>>> responsible for updates to the underlying docker image OS?  Our
>>>> organization is fairly segmented, we have a linux operations group, we have
>>>> a development group.  If our development group deploys 50 docker images,
>>>> all with a variety of distros inside them, different versions of
>>>> everything... What happens if there is a big vulnerability found
>>>> (think/remember bash).  Is our linux team now on the hook to learn docker
>>>> and handle digging through dozens to hundreds of potentially very different
>>>> docker images ( which would make you want to force standardization of your
>>>> docker images on a particular distro at a minimum ), or does the dev team
>>>> now own this responsibility?  This is a hard question for our company to
>>>> answer...
>>>>
>>>> My other comment, is actually regarding what I think is the most
>>>> fantastic use case I've seen for docker, which was written up by Roland
>>>> Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/
>>>> Using docker as part of your automated integration tests is a really
>>>> neat idea, especially if you work on a project that has to maintain support
>>>> for piles of application servers, operating systems, and versions of java.
>>>> I think there is some real opportunity here as was previously mentioned, to
>>>> build a docker image that sets up the OS, java, and karaf, and then at test
>>>> time you deploy your app and run your tests.  With this kind of model you
>>>> can just keep adding new docker images to your test suite and retire old
>>>> ones when you finally drop support for something ( *cough* java 6 *cough*)
>>>>
>>>> Good discussion, really have enjoyed reading!
>>>>
>>>> Ed
>>>>
>>>>
>>>> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <fr...@gmail.com>
>>>> wrote:
>>>>
>>>>  I guess the barrier to be able to write code has been lowered enough
>>>>> that
>>>>> more people are able to do it, probably for the money.  That goes hand
>>>>> in
>>>>> hand with the whole Docker thing where it feels there is an expectation
>>>>> that everything should be easy to do rather than accept that like any
>>>>> profession, you have to learn in order to become good.  Nothing wrong
>>>>> with
>>>>> asking questions, but I feel quality of code will probably continue to
>>>>> decline with tools being the crutch.
>>>>>
>>>>> Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
>>>>> software, I just wanted to make sure that things like Docker weren't
>>>>> going
>>>>> to cause it to be dumbed down.  Obviously like any growing technology,
>>>>> modularity has some rough spots to iron out, but that doesn't mean we
>>>>> should give up.  Developers can do what they want, I would like to
>>>>> continue
>>>>> to choose what fits my requirements best out of the technologies that
>>>>> are
>>>>> available.
>>>>>
>>>>> Ryan
>>>>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com>
>>>>> wrote:
>>>>>
>>>>>  I can't agree more ... and some questions on stackoverflow or this
>>>>>> mailinglist just reflect that ...
>>>>>> "please solve my issue for me, cause I forgot to use my brain today"
>>>>>> :D
>>>>>>
>>>>>> regards, Achim
>>>>>>
>>>>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>>>
>>>>>>  Serge,
>>>>>>>
>>>>>>> Package the world applications were able to be built easily before
>>>>>>> Docker
>>>>>>> was around.  Docker is simply a different way of deploying an
>>>>>>> application
>>>>>>> virtually.
>>>>>>>
>>>>>>> In my experience, developers who "package the world" with their code
>>>>>>> are
>>>>>>> usually either biased against modularity or just don't feel like
>>>>>>> putting
>>>>>>> forth the effort.  Many technologies in use today take effort to
>>>>>>> figure
>>>>>>> out.  A lot of developers seem to feel that any technology that
>>>>>>> requires
>>>>>>> effort above the maven shade plugin or using shell scripts to dump
>>>>>>> all
>>>>>>> their jars to a server isn't worth their time.
>>>>>>>
>>>>>>> Developers that care about the quality of the code or applications
>>>>>>> they
>>>>>>> produce won't be deterred from a technology they believe will help
>>>>>>> them
>>>>>>> make better applications just because it takes a little bit of
>>>>>>> effort.  How
>>>>>>> did less experienced developers manage to survive when the only real
>>>>>>> choices for writing software was assembly, c or c++?
>>>>>>>
>>>>>>> Ryan
>>>>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>>>>>>>
>>>>>>>  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 <ni...@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 <fr...@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" <bc...@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 <
>>>>>>>>>> fragility2.0@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.zurczak@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
>>>>>>>>>>>>
>>>>>>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>>>>>>>> <linkedin_16.png>
>>>>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>>>>>>>> <http://vzurczak.wordpress.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Apache Member
>>>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>> Committer & Project Lead
>>>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>>>
>>>>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Apache Member
>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>> Committer &
>>>>>> Project Lead
>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>
>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi James,

no problem at all ! It was more than cool to share our thoughts and views.

Regards
JB

On 04/18/2015 05:47 PM, James Carman wrote:
> Serge,
>
> We had some pretty good discussions during JB's talk (hope we didn't
> hijack it too much, JB).  I don't think this topic really has anything
> to do with Docker, necessarily.  Docker is merely a tool people employ
> to implement a deployment strategy.  I think it basically boils down to
> the notion that in the "cloud era", it's simpler and cheaper to spin up
> a new node configured the way you want.  Cloud-enabled applications need
> to be "cloneable" in this way already, so you kind of get this benefit
> for free.
>
> This doesn't mean we can't use OSGi to piece together these nodes.  OSGi
> isn't only about being able to runtime-refresh your modules.  There are
> many other benefits of the OSGi programming model that make it suitable
> for building statically-configured applications as well.
>
> Just my $0.02
>
> James
>
> On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <shuber@jahia.com
> <ma...@jahia.com>> wrote:
>
>     Interesting discussion indeed.
>
>     I'm currently at ApacheCon US and I've taken a few opportunities to
>     promote Apache Karaf which surprisingly few people know about. But
>     again what I was describing earlier is really a frequent feedback :
>     is modularity worth the trouble when I can built "micro-services"
>     that are actually running in docker containers ? Although I am
>     convinced that the two are not in opposition, I think it would be
>     great to have a killer use case to demonstrate what the benefits of
>     using Karaf would be.
>
>     I'm really looking forward to meeting Jean-Baptiste in person ! I
>     love Karaf and I hope to be able to exchange with him a few
>     experiences around it.
>
>     Regards,
>        Serge
>
>     - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
>     CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
>     Acacias, Switzerland
>     twitter: @sergehuber <https://twitter.com/sergehuber>
>
>     <http://jahiaone.com/register>
>     JahiaOne <http://www.jahiaone.com/>, our international user
>     conference is back! June 10-12 in Paris - Grab your tickets now
>     <http://www.jahiaone.com/>!
>
>     Jahia is a leading open source User eXperience Platform (UXP)
>     vendor, relentlessly working at transforming a siloed industry into
>     a user-driven one, beyond technology constraints -
>     http://www.jahia.com <http://www.jahia.com/>
>
>
>     On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck
>     <bcanhome@googlemail.com <ma...@googlemail.com>> wrote:
>
>         Hey,
>
>         yes I fully agree, also with the Spring-Boot stuff.
>         as already stated on the other thread, I think there are certain
>         cases where Docker images are useful.
>         For a POC, for CI I think a Docker Image is useful. In the end
>         if you want to run it in Production I rather have the Ansible
>         setup.
>
>         regards, Achim
>
>
>         2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net
>         <ma...@nanthrax.net>>:
>
>             Hi Ed,
>
>             I can't agree more ;)
>             I fully agree about your points.
>
>             I quite have the same view on Spring Boot ;)
>
>             Regards
>             JB
>
>
>             On 04/13/2015 04:32 PM, Ed Welch wrote:
>
>                 I've really enjoyed following this thread, and I have to
>                 say, as a Docker skeptic surrounded by people who want
>                 to bash my brains in with docker images, it's nice to
>                 hear some feedback from people who seem to have a
>                 healthy dose of skepticism like I do...
>
>                 So rather than rehash all the things I agree with that
>                 have been said so far, I wanted to comment a few things
>                 I hadn't seen:
>
>                 The biggest discussion point I bring up with my peers
>                 regarding docker that I've been using to kind of hold
>                 the floodgates back:  Who is responsible for updates to
>                 the underlying docker image OS?  Our organization is
>                 fairly segmented, we have a linux operations group, we
>                 have a development group.  If our development group
>                 deploys 50 docker images, all with a variety of distros
>                 inside them, different versions of everything... What
>                 happens if there is a big vulnerability found
>                 (think/remember bash).  Is our linux team now on the
>                 hook to learn docker and handle digging through dozens
>                 to hundreds of potentially very different docker images
>                 ( which would make you want to force standardization of
>                 your docker images on a particular distro at a minimum
>                 ), or does the dev team now own this responsibility?
>                 This is a hard question for our company to answer...
>
>                 My other comment, is actually regarding what I think is
>                 the most fantastic use case I've seen for docker, which
>                 was written up by Roland Huss on his blog:
>                 https://ro14nd.de/Jolokia-__Docker-Image/
>                 <https://ro14nd.de/Jolokia-Docker-Image/>
>                 Using docker as part of your automated integration tests
>                 is a really neat idea, especially if you work on a
>                 project that has to maintain support for piles of
>                 application servers, operating systems, and versions of
>                 java.  I think there is some real opportunity here as
>                 was previously mentioned, to build a docker image that
>                 sets up the OS, java, and karaf, and then at test time
>                 you deploy your app and run your tests.  With this kind
>                 of model you can just keep adding new docker images to
>                 your test suite and retire old ones when you finally
>                 drop support for something ( *cough* java 6 *cough*)
>
>                 Good discussion, really have enjoyed reading!
>
>                 Ed
>
>
>                 On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin
>                 <fragility2.0@gmail.com <ma...@gmail.com>>
>                 wrote:
>
>                     I guess the barrier to be able to write code has
>                     been lowered enough that
>                     more people are able to do it, probably for the
>                     money.  That goes hand in
>                     hand with the whole Docker thing where it feels
>                     there is an expectation
>                     that everything should be easy to do rather than
>                     accept that like any
>                     profession, you have to learn in order to become
>                     good.  Nothing wrong with
>                     asking questions, but I feel quality of code will
>                     probably continue to
>                     decline with tools being the crutch.
>
>                     Anyhow, thanks for everyone's input.  Karaf is a
>                     fantastic piece of
>                     software, I just wanted to make sure that things
>                     like Docker weren't going
>                     to cause it to be dumbed down.  Obviously like any
>                     growing technology,
>                     modularity has some rough spots to iron out, but
>                     that doesn't mean we
>                     should give up.  Developers can do what they want, I
>                     would like to continue
>                     to choose what fits my requirements best out of the
>                     technologies that are
>                     available.
>
>                     Ryan
>                     On Apr 13, 2015 2:37 AM, "Achim Nierbeck"
>                     <bcanhome@googlemail.com
>                     <ma...@googlemail.com>> wrote:
>
>                         I can't agree more ... and some questions on
>                         stackoverflow or this
>                         mailinglist just reflect that ...
>                         "please solve my issue for me, cause I forgot to
>                         use my brain today" :D
>
>                         regards, Achim
>
>                         2015-04-13 0:44 GMT+02:00 Ryan Moquin
>                         <fragility2.0@gmail.com
>                         <ma...@gmail.com>>:
>
>                             Serge,
>
>                             Package the world applications were able to
>                             be built easily before Docker
>                             was around.  Docker is simply a different
>                             way of deploying an application
>                             virtually.
>
>                             In my experience, developers who "package
>                             the world" with their code are
>                             usually either biased against modularity or
>                             just don't feel like putting
>                             forth the effort.  Many technologies in use
>                             today take effort to figure
>                             out.  A lot of developers seem to feel that
>                             any technology that requires
>                             effort above the maven shade plugin or using
>                             shell scripts to dump all
>                             their jars to a server isn't worth their time.
>
>                             Developers that care about the quality of
>                             the code or applications they
>                             produce won't be deterred from a technology
>                             they believe will help them
>                             make better applications just because it
>                             takes a little bit of effort.  How
>                             did less experienced developers manage to
>                             survive when the only real
>                             choices for writing software was assembly, c
>                             or c++?
>
>                             Ryan
>                             On Apr 11, 2015 9:53 PM, "Serge Huber"
>                             <shuber@jahia.com <ma...@jahia.com>>
>                             wrote:
>
>                                 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
>                                 <nielsbne@gmail.com
>                                 <ma...@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
>                                 <fragility2.0@gmail.com
>                                 <ma...@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"
>                                 <bcanhome@googlemail.com
>                                 <ma...@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 <frank@dexels.com
>                                     <ma...@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/
>                                         <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
>                                         <fragility2.0@gmail.com
>                                         <ma...@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
>                                             <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.zurczak@linagora.com
>                                             <ma...@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
>                                                 <http://www.linagora.com>
>
>                                                 <twitter_16.png>
>                                                 <https://twitter.com/__VincentZurczak
>                                                 <https://twitter.com/VincentZurczak>>
>                                                 <linkedin_16.png>
>                                                 <http://fr.linkedin.com/pub/__vincent-zurczak/18/b35/6a7
>                                                 <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>>
>                                                 <skype_16.png>
>                                                 <callto://vincent.zurczak>
>                                                 <wordpress_16.png>
>                                                 <http://vzurczak.wordpress.com__>
>
>
>
>
>
>
>                                     --
>
>                                     Apache Member
>                                     Apache Karaf
>                                     <http://karaf.apache.org/> Committer
>                                     & PMC
>                                     OPS4J Pax Web
>                                     <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>                                     <http://wiki.ops4j.org/display/paxweb/Pax+Web/>>
>                                     Committer & Project Lead
>                                     blog <http://notizblog.nierbeck.de/__>
>                                     Co-Author of Apache Karaf Cookbook
>                                     <http://bit.ly/1ps9rkS>
>
>                                     Software Architect / Project Manager
>                                     / Scrum Master
>
>
>
>
>                         --
>
>                         Apache Member
>                         Apache Karaf <http://karaf.apache.org/>
>                         Committer & PMC
>                         OPS4J Pax Web
>                         <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>                         <http://wiki.ops4j.org/display/paxweb/Pax+Web/>>
>                         Committer &
>                         Project Lead
>                         blog <http://notizblog.nierbeck.de/__>
>                         Co-Author of Apache Karaf Cookbook
>                         <http://bit.ly/1ps9rkS>
>
>                         Software Architect / Project Manager / Scrum Master
>
>
>
>
>
>             --
>             Jean-Baptiste Onofré
>             jbonofre@apache.org <ma...@apache.org>
>             http://blog.nanthrax.net
>             Talend - http://www.talend.com
>
>
>
>
>         --
>
>         Apache Member
>         Apache Karaf <http://karaf.apache.org/> Committer & PMC
>         OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>         Committer & Project Lead
>         blog <http://notizblog.nierbeck.de/>
>         Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
>         Software Architect / Project Manager / Scrum Master
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Niels <ni...@gmail.com>]

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

[Achim Nierbeck <bc...@googlemail.com>]

Hi Ryan,

for the update of a karaf cluster solution I'd suggest to look into cellar.
And while at it, if you have a complex solution to update. A "feature"
oriented application with dynamic switches to enable certain features
might be the best solution. Especially if you just enable that feature on
certain nodes. Attach some monitors (like Decanter) to your
application and if everything works as expected enable the feature
throughout the cluster.

regards, Achim



2015-04-19 18:04 GMT+02:00 Ryan Moquin <fr...@gmail.com>:

> Also, one reason I think the ability to hot update karaf in production is
> that if you have a lot of servers it can take a long time to vring each one
> down, reinstall a whole docker package and bring it back up.
>
> Also, one thing I never understood about the whole "updating a production
> server is risky and is safer to redeploy entirely" is that you can always
> get a good idea on the success of an update by performing it on test
> servers that are running the same version as production.
>
> On Sun, Apr 19, 2015, 3:50 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi Christian,
>>
>> We should extend the view to more than single artifacts provisioning.
>> Provisioning also covers both application and container configuration.
>> It's where we bring lot of value as all can be dynamic.
>>
>> More over, you are right about micro-service, but right now, IMHO, lot
>> of people doesn't do micro-services as they bring a lot of overhead on
>> top of the actual service in their application. Karaf and OSGi, if done
>> correctly, provides a more clean way and lightweight way to provide
>> micro-services.
>>
>> Regards
>> JB
>>
>> On 04/19/2015 08:12 AM, Christian Schneider wrote:
>> > I really like the deployment of bundles into a running instance at
>> > development time. For example it allows to debug through my bundle, do a
>> > fix and redeploy the single bundle while the debugger stays open. That
>> > really speeds up the development process.
>> >
>> > At production time though I never saw that for a single application that
>> > deployment at runtime was used. Typically a certain set of bundles is
>> > tested together and released together. So I think in this case docker is
>> > a nice fit as we can pack karaf together with this set of bundles into
>> > an image. This can then be deployed as a simple singular unit which is
>> > good for admins. Rolling back then is also easy as you can just install
>> > the previous image.
>> >
>> > There is one case where runtime deployment makes a lot of sense. This is
>> > the case of an integration server where you deploy lots of small
>> > integrations. Each of these has its own lifecycle and it would not make
>> > sense to build a container for each of them.
>> >
>> > Then there is a case in between represented by the micro services hype
>> > (not in the sense of OSGi Services). There you have an application that
>> > is built from individual modules that each have their own lifecycle and
>> > dependencies. For this case you could use one container and runtime
>> > deployment but you could also create one container for each. I recently
>> > helped to port an application from spring/tomcat to OSGi. The
>> > application was already design to have modules with different
>> > lifecycles. In tomcat this was represented as one war per module /
>> > "microservice". The problem in OSGi was that the application was not
>> > modularized in an OSGi way. So for example there was no semantic
>> > versioning. Some of the bundles had to be installed in one single
>> > version over all the modules. If versions were mixed the wiring of
>> > module A could change when a new version of module B was installed. For
>> > this case having separate containers can help.
>> >
>> > So the picture I painted shows that there is no one size fits all
>> > solution and I think docker can be a good match for some of the use
>> > cases in deployment.
>> >
>> > Christian
>> >
>> > Am 19.04.2015 um 02:44 schrieb Serge Huber:
>> >> James, I don't think JB cared. He was probably more than happy to have
>> >> a discussion than to have to simply walk through slides without any
>> >> feedback. At least that's how I prefer it.
>> >>
>> >> Personally I think that OSGi is really a great way to make sure that
>> >> people get into the good practice about thinking about the full
>> >> lifecycle of code, not just developing it and starting it, but also
>> >> shutting it down, and what happens when dependencies are not present
>> >> or shutdown.
>> >>
>> >> In that regard I've seen that in our team since we switched to OSGi,
>> >> although it took a little investment in terms of getting used to it,
>> >> people are a lot more productive because they can focus on the module
>> >> they are building without having to restart the whole container. This
>> >> is a huge improvement over Docker type of deployments where rebuilding
>> >> and restarting a container can take a lot longer to test a single
>> change.
>> >>
>> >> I believe that OSGi is also more than proven since it has been around
>> >> for a long time, and it is defined by a standard body that is quite
>> >> significant. I just wish it would get adopted more, and hopefully
>> >> Karaf will help with this effort.
>> >>
>> >> Not to make me say that Docker or Spring Boot or the Play Framework
>> >> don't have their merits, but I think that it is not enough to look at
>> >> the time to get started, it is also important to look at the TMDT (an
>> >> acronym I just made up : Total Maintenance and Deployment Time :)).
>> >>
>> >> cheers,
>> >>   Serge...
>> >>
>> >> - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
>> >> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
>> >> Acacias, Switzerland
>> >> twitter: @sergehuber <https://twitter.com/sergehuber>
>> >>
>> >> <http://jahiaone.com/register>
>> >> JahiaOne <http://www.jahiaone.com/>, our international user conference
>> >> is back! June 10-12 in Paris - Grab your tickets now
>> >> <http://www.jahiaone.com/>!
>> >>
>> >> Jahia is a leading open source User eXperience Platform (UXP) vendor,
>> >> relentlessly working at transforming a siloed industry into a
>> >> user-driven one, beyond technology constraints - http://www.jahia.com
>> >> <http://www.jahia.com/>
>> >>
>> >>
>> >> On Sat, Apr 18, 2015 at 10:47 AM, James Carman
>> >> <james@carmanconsulting.com <ma...@carmanconsulting.com>>
>> wrote:
>> >>
>> >>     Serge,
>> >>
>> >>     We had some pretty good discussions during JB's talk (hope we
>> >>     didn't hijack it too much, JB).  I don't think this topic really
>> >>     has anything to do with Docker, necessarily.  Docker is merely a
>> >>     tool people employ to implement a deployment strategy.  I think it
>> >>     basically boils down to the notion that in the "cloud era", it's
>> >>     simpler and cheaper to spin up a new node configured the way you
>> >>     want.  Cloud-enabled applications need to be "cloneable" in this
>> >>     way already, so you kind of get this benefit for free.
>> >>
>> >>     This doesn't mean we can't use OSGi to piece together these
>> >>     nodes.  OSGi isn't only about being able to runtime-refresh your
>> >>     modules.  There are many other benefits of the OSGi programming
>> >>     model that make it suitable for building statically-configured
>> >>     applications as well.
>> >>
>> >>     Just my $0.02
>> >>
>> >>     James
>> >>
>> >>     On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <shuber@jahia.com
>> >>     <ma...@jahia.com>> wrote:
>> >>
>> >>         Interesting discussion indeed.
>> >>
>> >>         I'm currently at ApacheCon US and I've taken a few
>> >>         opportunities to promote Apache Karaf which surprisingly few
>> >>         people know about. But again what I was describing earlier is
>> >>         really a frequent feedback : is modularity worth the trouble
>> >>         when I can built "micro-services" that are actually running in
>> >>         docker containers ? Although I am convinced that the two are
>> >>         not in opposition, I think it would be great to have a killer
>> >>         use case to demonstrate what the benefits of using Karaf would
>> be.
>> >>
>> >>         I'm really looking forward to meeting Jean-Baptiste in person
>> >>         ! I love Karaf and I hope to be able to exchange with him a
>> >>         few experiences around it.
>> >>
>> >>         Regards,
>> >>           Serge
>> >>
>> >>         - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
>> >>         CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes,
>> >>         1227 Acacias, Switzerland
>> >>         twitter: @sergehuber <https://twitter.com/sergehuber>
>> >>
>> >>         <http://jahiaone.com/register>
>> >>         JahiaOne <http://www.jahiaone.com/>, our international user
>> >>         conference is back! June 10-12 in Paris - Grab your tickets
>> >>         now <http://www.jahiaone.com/>!
>> >>
>> >>         Jahia is a leading open source User eXperience Platform (UXP)
>> >>         vendor, relentlessly working at transforming a siloed industry
>> >>         into a user-driven one, beyond technology constraints -
>> >>         http://www.jahia.com <http://www.jahia.com/>
>> >>
>> >>
>> >>         On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck
>> >>         <bcanhome@googlemail.com <ma...@googlemail.com>>
>> wrote:
>> >>
>> >>             Hey,
>> >>
>> >>             yes I fully agree, also with the Spring-Boot stuff.
>> >>             as already stated on the other thread, I think there are
>> >>             certain cases where Docker images are useful.
>> >>             For a POC, for CI I think a Docker Image is useful. In the
>> >>             end if you want to run it in Production I rather have the
>> >>             Ansible setup.
>> >>
>> >>             regards, Achim
>> >>
>> >>
>> >>             2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré
>> >>             <jb@nanthrax.net <ma...@nanthrax.net>>:
>> >>
>> >>                 Hi Ed,
>> >>
>> >>                 I can't agree more ;)
>> >>                 I fully agree about your points.
>> >>
>> >>                 I quite have the same view on Spring Boot ;)
>> >>
>> >>                 Regards
>> >>                 JB
>> >>
>> >>
>> >>                 On 04/13/2015 04:32 PM, Ed Welch wrote:
>> >>
>> >>                     I've really enjoyed following this thread, and I
>> >>                     have to say, as a Docker skeptic surrounded by
>> >>                     people who want to bash my brains in with docker
>> >>                     images, it's nice to hear some feedback from
>> >>                     people who seem to have a healthy dose of
>> >>                     skepticism like I do...
>> >>
>> >>                     So rather than rehash all the things I agree with
>> >>                     that have been said so far, I wanted to comment a
>> >>                     few things I hadn't seen:
>> >>
>> >>                     The biggest discussion point I bring up with my
>> >>                     peers regarding docker that I've been using to
>> >>                     kind of hold the floodgates back:  Who is
>> >>                     responsible for updates to the underlying docker
>> >>                     image OS?  Our organization is fairly segmented,
>> >>                     we have a linux operations group, we have a
>> >>                     development group.  If our development group
>> >>                     deploys 50 docker images, all with a variety of
>> >>                     distros inside them, different versions of
>> >>                     everything... What happens if there is a big
>> >>                     vulnerability found (think/remember bash). Is our
>> >>                     linux team now on the hook to learn docker and
>> >>                     handle digging through dozens to hundreds of
>> >>                     potentially very different docker images ( which
>> >>                     would make you want to force standardization of
>> >>                     your docker images on a particular distro at a
>> >>                     minimum ), or does the dev team now own this
>> >>                     responsibility?  This is a hard question for our
>> >>                     company to answer...
>> >>
>> >>                     My other comment, is actually regarding what I
>> >>                     think is the most fantastic use case I've seen for
>> >>                     docker, which was written up by Roland Huss on his
>> >>                     blog: https://ro14nd.de/Jolokia-Docker-Image/
>> >>                     Using docker as part of your automated integration
>> >>                     tests is a really neat idea, especially if you
>> >>                     work on a project that has to maintain support for
>> >>                     piles of application servers, operating systems,
>> >>                     and versions of java.  I think there is some real
>> >>                     opportunity here as was previously mentioned, to
>> >>                     build a docker image that sets up the OS, java,
>> >>                     and karaf, and then at test time you deploy your
>> >>                     app and run your tests. With this kind of model
>> >>                     you can just keep adding new docker images to your
>> >>                     test suite and retire old ones when you finally
>> >>                     drop support for something ( *cough* java 6
>> *cough*)
>> >>
>> >>                     Good discussion, really have enjoyed reading!
>> >>
>> >>                     Ed
>> >>
>> >>
>> >>                     On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin
>> >>                     <fragility2.0@gmail.com
>> >>                     <ma...@gmail.com>> wrote:
>> >>
>> >>                         I guess the barrier to be able to write code
>> >>                         has been lowered enough that
>> >>                         more people are able to do it, probably for
>> >>                         the money.  That goes hand in
>> >>                         hand with the whole Docker thing where it
>> >>                         feels there is an expectation
>> >>                         that everything should be easy to do rather
>> >>                         than accept that like any
>> >>                         profession, you have to learn in order to
>> >>                         become good.  Nothing wrong with
>> >>                         asking questions, but I feel quality of code
>> >>                         will probably continue to
>> >>                         decline with tools being the crutch.
>> >>
>> >>                         Anyhow, thanks for everyone's input. Karaf is
>> >>                         a fantastic piece of
>> >>                         software, I just wanted to make sure that
>> >>                         things like Docker weren't going
>> >>                         to cause it to be dumbed down. Obviously like
>> >>                         any growing technology,
>> >>                         modularity has some rough spots to iron out,
>> >>                         but that doesn't mean we
>> >>                         should give up. Developers can do what they
>> >>                         want, I would like to continue
>> >>                         to choose what fits my requirements best out
>> >>                         of the technologies that are
>> >>                         available.
>> >>
>> >>                         Ryan
>> >>                         On Apr 13, 2015 2:37 AM, "Achim Nierbeck"
>> >>                         <bcanhome@googlemail.com
>> >>                         <ma...@googlemail.com>> wrote:
>> >>
>> >>                             I can't agree more ... and some questions
>> >>                             on stackoverflow or this
>> >>                             mailinglist just reflect that ...
>> >>                             "please solve my issue for me, cause I
>> >>                             forgot to use my brain today" :D
>> >>
>> >>                             regards, Achim
>> >>
>> >>                             2015-04-13 0:44 GMT+02:00 Ryan Moquin
>> >>                             <fragility2.0@gmail.com
>> >>                             <ma...@gmail.com>>:
>> >>
>> >>                                 Serge,
>> >>
>> >>                                 Package the world applications were
>> >>                                 able to be built easily before Docker
>> >>                                 was around. Docker is simply a
>> >>                                 different way of deploying an
>> application
>> >>                                 virtually.
>> >>
>> >>                                 In my experience, developers who
>> >>                                 "package the world" with their code are
>> >>                                 usually either biased against
>> >>                                 modularity or just don't feel like
>> putting
>> >>                                 forth the effort. Many technologies in
>> >>                                 use today take effort to figure
>> >>                                 out.  A lot of developers seem to feel
>> >>                                 that any technology that requires
>> >>                                 effort above the maven shade plugin or
>> >>                                 using shell scripts to dump all
>> >>                                 their jars to a server isn't worth
>> >>                                 their time.
>> >>
>> >>                                 Developers that care about the quality
>> >>                                 of the code or applications they
>> >>                                 produce won't be deterred from a
>> >>                                 technology they believe will help them
>> >>                                 make better applications just because
>> >>                                 it takes a little bit of effort.  How
>> >>                                 did less experienced developers manage
>> >>                                 to survive when the only real
>> >>                                 choices for writing software was
>> >>                                 assembly, c or c++?
>> >>
>> >>                                 Ryan
>> >>                                 On Apr 11, 2015 9:53 PM, "Serge Huber"
>> >>                                 <shuber@jahia.com
>> >>                                 <ma...@jahia.com>> wrote:
>> >>
>> >>                                     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
>> >>                                     <nielsbne@gmail.com
>> >>                                     <ma...@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 <fragility2.0@gmail.com
>> >>                                     <ma...@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" <bcanhome@googlemail.com
>> >>                                     <ma...@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 <frank@dexels.com
>> >>                                         <ma...@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
>> >>                                             <fragility2.0@gmail.com
>> >>                                             <mailto:
>> fragility2.0@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
>> >>                                                 <
>> https://groups.google.com/forum/m/#%21topic/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.zurczak@linagora.com
>> >>                                                 <mailto:
>> vincent.zurczak@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
>> >>
>
>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[Ryan Moquin <fr...@gmail.com>]

Also, one reason I think the ability to hot update karaf in production is
that if you have a lot of servers it can take a long time to vring each one
down, reinstall a whole docker package and bring it back up.

Also, one thing I never understood about the whole "updating a production
server is risky and is safer to redeploy entirely" is that you can always
get a good idea on the success of an update by performing it on test
servers that are running the same version as production.

On Sun, Apr 19, 2015, 3:50 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Hi Christian,
>
> We should extend the view to more than single artifacts provisioning.
> Provisioning also covers both application and container configuration.
> It's where we bring lot of value as all can be dynamic.
>
> More over, you are right about micro-service, but right now, IMHO, lot
> of people doesn't do micro-services as they bring a lot of overhead on
> top of the actual service in their application. Karaf and OSGi, if done
> correctly, provides a more clean way and lightweight way to provide
> micro-services.
>
> Regards
> JB
>
> On 04/19/2015 08:12 AM, Christian Schneider wrote:
> > I really like the deployment of bundles into a running instance at
> > development time. For example it allows to debug through my bundle, do a
> > fix and redeploy the single bundle while the debugger stays open. That
> > really speeds up the development process.
> >
> > At production time though I never saw that for a single application that
> > deployment at runtime was used. Typically a certain set of bundles is
> > tested together and released together. So I think in this case docker is
> > a nice fit as we can pack karaf together with this set of bundles into
> > an image. This can then be deployed as a simple singular unit which is
> > good for admins. Rolling back then is also easy as you can just install
> > the previous image.
> >
> > There is one case where runtime deployment makes a lot of sense. This is
> > the case of an integration server where you deploy lots of small
> > integrations. Each of these has its own lifecycle and it would not make
> > sense to build a container for each of them.
> >
> > Then there is a case in between represented by the micro services hype
> > (not in the sense of OSGi Services). There you have an application that
> > is built from individual modules that each have their own lifecycle and
> > dependencies. For this case you could use one container and runtime
> > deployment but you could also create one container for each. I recently
> > helped to port an application from spring/tomcat to OSGi. The
> > application was already design to have modules with different
> > lifecycles. In tomcat this was represented as one war per module /
> > "microservice". The problem in OSGi was that the application was not
> > modularized in an OSGi way. So for example there was no semantic
> > versioning. Some of the bundles had to be installed in one single
> > version over all the modules. If versions were mixed the wiring of
> > module A could change when a new version of module B was installed. For
> > this case having separate containers can help.
> >
> > So the picture I painted shows that there is no one size fits all
> > solution and I think docker can be a good match for some of the use
> > cases in deployment.
> >
> > Christian
> >
> > Am 19.04.2015 um 02:44 schrieb Serge Huber:
> >> James, I don't think JB cared. He was probably more than happy to have
> >> a discussion than to have to simply walk through slides without any
> >> feedback. At least that's how I prefer it.
> >>
> >> Personally I think that OSGi is really a great way to make sure that
> >> people get into the good practice about thinking about the full
> >> lifecycle of code, not just developing it and starting it, but also
> >> shutting it down, and what happens when dependencies are not present
> >> or shutdown.
> >>
> >> In that regard I've seen that in our team since we switched to OSGi,
> >> although it took a little investment in terms of getting used to it,
> >> people are a lot more productive because they can focus on the module
> >> they are building without having to restart the whole container. This
> >> is a huge improvement over Docker type of deployments where rebuilding
> >> and restarting a container can take a lot longer to test a single
> change.
> >>
> >> I believe that OSGi is also more than proven since it has been around
> >> for a long time, and it is defined by a standard body that is quite
> >> significant. I just wish it would get adopted more, and hopefully
> >> Karaf will help with this effort.
> >>
> >> Not to make me say that Docker or Spring Boot or the Play Framework
> >> don't have their merits, but I think that it is not enough to look at
> >> the time to get started, it is also important to look at the TMDT (an
> >> acronym I just made up : Total Maintenance and Deployment Time :)).
> >>
> >> cheers,
> >>   Serge...
> >>
> >> - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
> >> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
> >> Acacias, Switzerland
> >> twitter: @sergehuber <https://twitter.com/sergehuber>
> >>
> >> <http://jahiaone.com/register>
> >> JahiaOne <http://www.jahiaone.com/>, our international user conference
> >> is back! June 10-12 in Paris - Grab your tickets now
> >> <http://www.jahiaone.com/>!
> >>
> >> Jahia is a leading open source User eXperience Platform (UXP) vendor,
> >> relentlessly working at transforming a siloed industry into a
> >> user-driven one, beyond technology constraints - http://www.jahia.com
> >> <http://www.jahia.com/>
> >>
> >>
> >> On Sat, Apr 18, 2015 at 10:47 AM, James Carman
> >> <james@carmanconsulting.com <ma...@carmanconsulting.com>> wrote:
> >>
> >>     Serge,
> >>
> >>     We had some pretty good discussions during JB's talk (hope we
> >>     didn't hijack it too much, JB).  I don't think this topic really
> >>     has anything to do with Docker, necessarily.  Docker is merely a
> >>     tool people employ to implement a deployment strategy.  I think it
> >>     basically boils down to the notion that in the "cloud era", it's
> >>     simpler and cheaper to spin up a new node configured the way you
> >>     want.  Cloud-enabled applications need to be "cloneable" in this
> >>     way already, so you kind of get this benefit for free.
> >>
> >>     This doesn't mean we can't use OSGi to piece together these
> >>     nodes.  OSGi isn't only about being able to runtime-refresh your
> >>     modules.  There are many other benefits of the OSGi programming
> >>     model that make it suitable for building statically-configured
> >>     applications as well.
> >>
> >>     Just my $0.02
> >>
> >>     James
> >>
> >>     On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <shuber@jahia.com
> >>     <ma...@jahia.com>> wrote:
> >>
> >>         Interesting discussion indeed.
> >>
> >>         I'm currently at ApacheCon US and I've taken a few
> >>         opportunities to promote Apache Karaf which surprisingly few
> >>         people know about. But again what I was describing earlier is
> >>         really a frequent feedback : is modularity worth the trouble
> >>         when I can built "micro-services" that are actually running in
> >>         docker containers ? Although I am convinced that the two are
> >>         not in opposition, I think it would be great to have a killer
> >>         use case to demonstrate what the benefits of using Karaf would
> be.
> >>
> >>         I'm really looking forward to meeting Jean-Baptiste in person
> >>         ! I love Karaf and I hope to be able to exchange with him a
> >>         few experiences around it.
> >>
> >>         Regards,
> >>           Serge
> >>
> >>         - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
> >>         CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes,
> >>         1227 Acacias, Switzerland
> >>         twitter: @sergehuber <https://twitter.com/sergehuber>
> >>
> >>         <http://jahiaone.com/register>
> >>         JahiaOne <http://www.jahiaone.com/>, our international user
> >>         conference is back! June 10-12 in Paris - Grab your tickets
> >>         now <http://www.jahiaone.com/>!
> >>
> >>         Jahia is a leading open source User eXperience Platform (UXP)
> >>         vendor, relentlessly working at transforming a siloed industry
> >>         into a user-driven one, beyond technology constraints -
> >>         http://www.jahia.com <http://www.jahia.com/>
> >>
> >>
> >>         On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck
> >>         <bcanhome@googlemail.com <ma...@googlemail.com>>
> wrote:
> >>
> >>             Hey,
> >>
> >>             yes I fully agree, also with the Spring-Boot stuff.
> >>             as already stated on the other thread, I think there are
> >>             certain cases where Docker images are useful.
> >>             For a POC, for CI I think a Docker Image is useful. In the
> >>             end if you want to run it in Production I rather have the
> >>             Ansible setup.
> >>
> >>             regards, Achim
> >>
> >>
> >>             2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré
> >>             <jb@nanthrax.net <ma...@nanthrax.net>>:
> >>
> >>                 Hi Ed,
> >>
> >>                 I can't agree more ;)
> >>                 I fully agree about your points.
> >>
> >>                 I quite have the same view on Spring Boot ;)
> >>
> >>                 Regards
> >>                 JB
> >>
> >>
> >>                 On 04/13/2015 04:32 PM, Ed Welch wrote:
> >>
> >>                     I've really enjoyed following this thread, and I
> >>                     have to say, as a Docker skeptic surrounded by
> >>                     people who want to bash my brains in with docker
> >>                     images, it's nice to hear some feedback from
> >>                     people who seem to have a healthy dose of
> >>                     skepticism like I do...
> >>
> >>                     So rather than rehash all the things I agree with
> >>                     that have been said so far, I wanted to comment a
> >>                     few things I hadn't seen:
> >>
> >>                     The biggest discussion point I bring up with my
> >>                     peers regarding docker that I've been using to
> >>                     kind of hold the floodgates back:  Who is
> >>                     responsible for updates to the underlying docker
> >>                     image OS?  Our organization is fairly segmented,
> >>                     we have a linux operations group, we have a
> >>                     development group.  If our development group
> >>                     deploys 50 docker images, all with a variety of
> >>                     distros inside them, different versions of
> >>                     everything... What happens if there is a big
> >>                     vulnerability found (think/remember bash). Is our
> >>                     linux team now on the hook to learn docker and
> >>                     handle digging through dozens to hundreds of
> >>                     potentially very different docker images ( which
> >>                     would make you want to force standardization of
> >>                     your docker images on a particular distro at a
> >>                     minimum ), or does the dev team now own this
> >>                     responsibility?  This is a hard question for our
> >>                     company to answer...
> >>
> >>                     My other comment, is actually regarding what I
> >>                     think is the most fantastic use case I've seen for
> >>                     docker, which was written up by Roland Huss on his
> >>                     blog: https://ro14nd.de/Jolokia-Docker-Image/
> >>                     Using docker as part of your automated integration
> >>                     tests is a really neat idea, especially if you
> >>                     work on a project that has to maintain support for
> >>                     piles of application servers, operating systems,
> >>                     and versions of java.  I think there is some real
> >>                     opportunity here as was previously mentioned, to
> >>                     build a docker image that sets up the OS, java,
> >>                     and karaf, and then at test time you deploy your
> >>                     app and run your tests. With this kind of model
> >>                     you can just keep adding new docker images to your
> >>                     test suite and retire old ones when you finally
> >>                     drop support for something ( *cough* java 6 *cough*)
> >>
> >>                     Good discussion, really have enjoyed reading!
> >>
> >>                     Ed
> >>
> >>
> >>                     On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin
> >>                     <fragility2.0@gmail.com
> >>                     <ma...@gmail.com>> wrote:
> >>
> >>                         I guess the barrier to be able to write code
> >>                         has been lowered enough that
> >>                         more people are able to do it, probably for
> >>                         the money.  That goes hand in
> >>                         hand with the whole Docker thing where it
> >>                         feels there is an expectation
> >>                         that everything should be easy to do rather
> >>                         than accept that like any
> >>                         profession, you have to learn in order to
> >>                         become good.  Nothing wrong with
> >>                         asking questions, but I feel quality of code
> >>                         will probably continue to
> >>                         decline with tools being the crutch.
> >>
> >>                         Anyhow, thanks for everyone's input. Karaf is
> >>                         a fantastic piece of
> >>                         software, I just wanted to make sure that
> >>                         things like Docker weren't going
> >>                         to cause it to be dumbed down. Obviously like
> >>                         any growing technology,
> >>                         modularity has some rough spots to iron out,
> >>                         but that doesn't mean we
> >>                         should give up. Developers can do what they
> >>                         want, I would like to continue
> >>                         to choose what fits my requirements best out
> >>                         of the technologies that are
> >>                         available.
> >>
> >>                         Ryan
> >>                         On Apr 13, 2015 2:37 AM, "Achim Nierbeck"
> >>                         <bcanhome@googlemail.com
> >>                         <ma...@googlemail.com>> wrote:
> >>
> >>                             I can't agree more ... and some questions
> >>                             on stackoverflow or this
> >>                             mailinglist just reflect that ...
> >>                             "please solve my issue for me, cause I
> >>                             forgot to use my brain today" :D
> >>
> >>                             regards, Achim
> >>
> >>                             2015-04-13 0:44 GMT+02:00 Ryan Moquin
> >>                             <fragility2.0@gmail.com
> >>                             <ma...@gmail.com>>:
> >>
> >>                                 Serge,
> >>
> >>                                 Package the world applications were
> >>                                 able to be built easily before Docker
> >>                                 was around. Docker is simply a
> >>                                 different way of deploying an
> application
> >>                                 virtually.
> >>
> >>                                 In my experience, developers who
> >>                                 "package the world" with their code are
> >>                                 usually either biased against
> >>                                 modularity or just don't feel like
> putting
> >>                                 forth the effort. Many technologies in
> >>                                 use today take effort to figure
> >>                                 out.  A lot of developers seem to feel
> >>                                 that any technology that requires
> >>                                 effort above the maven shade plugin or
> >>                                 using shell scripts to dump all
> >>                                 their jars to a server isn't worth
> >>                                 their time.
> >>
> >>                                 Developers that care about the quality
> >>                                 of the code or applications they
> >>                                 produce won't be deterred from a
> >>                                 technology they believe will help them
> >>                                 make better applications just because
> >>                                 it takes a little bit of effort.  How
> >>                                 did less experienced developers manage
> >>                                 to survive when the only real
> >>                                 choices for writing software was
> >>                                 assembly, c or c++?
> >>
> >>                                 Ryan
> >>                                 On Apr 11, 2015 9:53 PM, "Serge Huber"
> >>                                 <shuber@jahia.com
> >>                                 <ma...@jahia.com>> wrote:
> >>
> >>                                     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
> >>                                     <nielsbne@gmail.com
> >>                                     <ma...@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 <fragility2.0@gmail.com
> >>                                     <ma...@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" <bcanhome@googlemail.com
> >>                                     <ma...@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 <frank@dexels.com
> >>                                         <ma...@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
> >>                                             <fragility2.0@gmail.com
> >>                                             <mailto:
> fragility2.0@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
> >>                                                 <
> https://groups.google.com/forum/m/#%21topic/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.zurczak@linagora.com
> >>                                                 <mailto:
> vincent.zurczak@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
> >>

Re: Karaf and Docker

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Christian,

We should extend the view to more than single artifacts provisioning. 
Provisioning also covers both application and container configuration.
It's where we bring lot of value as all can be dynamic.

More over, you are right about micro-service, but right now, IMHO, lot 
of people doesn't do micro-services as they bring a lot of overhead on 
top of the actual service in their application. Karaf and OSGi, if done 
correctly, provides a more clean way and lightweight way to provide 
micro-services.

Regards
JB

On 04/19/2015 08:12 AM, Christian Schneider wrote:
> I really like the deployment of bundles into a running instance at
> development time. For example it allows to debug through my bundle, do a
> fix and redeploy the single bundle while the debugger stays open. That
> really speeds up the development process.
>
> At production time though I never saw that for a single application that
> deployment at runtime was used. Typically a certain set of bundles is
> tested together and released together. So I think in this case docker is
> a nice fit as we can pack karaf together with this set of bundles into
> an image. This can then be deployed as a simple singular unit which is
> good for admins. Rolling back then is also easy as you can just install
> the previous image.
>
> There is one case where runtime deployment makes a lot of sense. This is
> the case of an integration server where you deploy lots of small
> integrations. Each of these has its own lifecycle and it would not make
> sense to build a container for each of them.
>
> Then there is a case in between represented by the micro services hype
> (not in the sense of OSGi Services). There you have an application that
> is built from individual modules that each have their own lifecycle and
> dependencies. For this case you could use one container and runtime
> deployment but you could also create one container for each. I recently
> helped to port an application from spring/tomcat to OSGi. The
> application was already design to have modules with different
> lifecycles. In tomcat this was represented as one war per module /
> "microservice". The problem in OSGi was that the application was not
> modularized in an OSGi way. So for example there was no semantic
> versioning. Some of the bundles had to be installed in one single
> version over all the modules. If versions were mixed the wiring of
> module A could change when a new version of module B was installed. For
> this case having separate containers can help.
>
> So the picture I painted shows that there is no one size fits all
> solution and I think docker can be a good match for some of the use
> cases in deployment.
>
> Christian
>
> Am 19.04.2015 um 02:44 schrieb Serge Huber:
>> James, I don't think JB cared. He was probably more than happy to have
>> a discussion than to have to simply walk through slides without any
>> feedback. At least that's how I prefer it.
>>
>> Personally I think that OSGi is really a great way to make sure that
>> people get into the good practice about thinking about the full
>> lifecycle of code, not just developing it and starting it, but also
>> shutting it down, and what happens when dependencies are not present
>> or shutdown.
>>
>> In that regard I've seen that in our team since we switched to OSGi,
>> although it took a little investment in terms of getting used to it,
>> people are a lot more productive because they can focus on the module
>> they are building without having to restart the whole container. This
>> is a huge improvement over Docker type of deployments where rebuilding
>> and restarting a container can take a lot longer to test a single change.
>>
>> I believe that OSGi is also more than proven since it has been around
>> for a long time, and it is defined by a standard body that is quite
>> significant. I just wish it would get adopted more, and hopefully
>> Karaf will help with this effort.
>>
>> Not to make me say that Docker or Spring Boot or the Play Framework
>> don't have their merits, but I think that it is not enough to look at
>> the time to get started, it is also important to look at the TMDT (an
>> acronym I just made up : Total Maintenance and Deployment Time :)).
>>
>> cheers,
>>   Serge...
>>
>> - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
>> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
>> Acacias, Switzerland
>> twitter: @sergehuber <https://twitter.com/sergehuber>
>>
>> <http://jahiaone.com/register>
>> JahiaOne <http://www.jahiaone.com/>, our international user conference
>> is back! June 10-12 in Paris - Grab your tickets now
>> <http://www.jahiaone.com/>!
>>
>> Jahia is a leading open source User eXperience Platform (UXP) vendor,
>> relentlessly working at transforming a siloed industry into a
>> user-driven one, beyond technology constraints - http://www.jahia.com
>> <http://www.jahia.com/>
>>
>>
>> On Sat, Apr 18, 2015 at 10:47 AM, James Carman
>> <james@carmanconsulting.com <ma...@carmanconsulting.com>> wrote:
>>
>>     Serge,
>>
>>     We had some pretty good discussions during JB's talk (hope we
>>     didn't hijack it too much, JB).  I don't think this topic really
>>     has anything to do with Docker, necessarily.  Docker is merely a
>>     tool people employ to implement a deployment strategy.  I think it
>>     basically boils down to the notion that in the "cloud era", it's
>>     simpler and cheaper to spin up a new node configured the way you
>>     want.  Cloud-enabled applications need to be "cloneable" in this
>>     way already, so you kind of get this benefit for free.
>>
>>     This doesn't mean we can't use OSGi to piece together these
>>     nodes.  OSGi isn't only about being able to runtime-refresh your
>>     modules.  There are many other benefits of the OSGi programming
>>     model that make it suitable for building statically-configured
>>     applications as well.
>>
>>     Just my $0.02
>>
>>     James
>>
>>     On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <shuber@jahia.com
>>     <ma...@jahia.com>> wrote:
>>
>>         Interesting discussion indeed.
>>
>>         I'm currently at ApacheCon US and I've taken a few
>>         opportunities to promote Apache Karaf which surprisingly few
>>         people know about. But again what I was describing earlier is
>>         really a frequent feedback : is modularity worth the trouble
>>         when I can built "micro-services" that are actually running in
>>         docker containers ? Although I am convinced that the two are
>>         not in opposition, I think it would be great to have a killer
>>         use case to demonstrate what the benefits of using Karaf would be.
>>
>>         I'm really looking forward to meeting Jean-Baptiste in person
>>         ! I love Karaf and I hope to be able to exchange with him a
>>         few experiences around it.
>>
>>         Regards,
>>           Serge
>>
>>         - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
>>         CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes,
>>         1227 Acacias, Switzerland
>>         twitter: @sergehuber <https://twitter.com/sergehuber>
>>
>>         <http://jahiaone.com/register>
>>         JahiaOne <http://www.jahiaone.com/>, our international user
>>         conference is back! June 10-12 in Paris - Grab your tickets
>>         now <http://www.jahiaone.com/>!
>>
>>         Jahia is a leading open source User eXperience Platform (UXP)
>>         vendor, relentlessly working at transforming a siloed industry
>>         into a user-driven one, beyond technology constraints -
>>         http://www.jahia.com <http://www.jahia.com/>
>>
>>
>>         On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck
>>         <bcanhome@googlemail.com <ma...@googlemail.com>> wrote:
>>
>>             Hey,
>>
>>             yes I fully agree, also with the Spring-Boot stuff.
>>             as already stated on the other thread, I think there are
>>             certain cases where Docker images are useful.
>>             For a POC, for CI I think a Docker Image is useful. In the
>>             end if you want to run it in Production I rather have the
>>             Ansible setup.
>>
>>             regards, Achim
>>
>>
>>             2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré
>>             <jb@nanthrax.net <ma...@nanthrax.net>>:
>>
>>                 Hi Ed,
>>
>>                 I can't agree more ;)
>>                 I fully agree about your points.
>>
>>                 I quite have the same view on Spring Boot ;)
>>
>>                 Regards
>>                 JB
>>
>>
>>                 On 04/13/2015 04:32 PM, Ed Welch wrote:
>>
>>                     I've really enjoyed following this thread, and I
>>                     have to say, as a Docker skeptic surrounded by
>>                     people who want to bash my brains in with docker
>>                     images, it's nice to hear some feedback from
>>                     people who seem to have a healthy dose of
>>                     skepticism like I do...
>>
>>                     So rather than rehash all the things I agree with
>>                     that have been said so far, I wanted to comment a
>>                     few things I hadn't seen:
>>
>>                     The biggest discussion point I bring up with my
>>                     peers regarding docker that I've been using to
>>                     kind of hold the floodgates back:  Who is
>>                     responsible for updates to the underlying docker
>>                     image OS?  Our organization is fairly segmented,
>>                     we have a linux operations group, we have a
>>                     development group.  If our development group
>>                     deploys 50 docker images, all with a variety of
>>                     distros inside them, different versions of
>>                     everything... What happens if there is a big
>>                     vulnerability found (think/remember bash). Is our
>>                     linux team now on the hook to learn docker and
>>                     handle digging through dozens to hundreds of
>>                     potentially very different docker images ( which
>>                     would make you want to force standardization of
>>                     your docker images on a particular distro at a
>>                     minimum ), or does the dev team now own this
>>                     responsibility?  This is a hard question for our
>>                     company to answer...
>>
>>                     My other comment, is actually regarding what I
>>                     think is the most fantastic use case I've seen for
>>                     docker, which was written up by Roland Huss on his
>>                     blog: https://ro14nd.de/Jolokia-Docker-Image/
>>                     Using docker as part of your automated integration
>>                     tests is a really neat idea, especially if you
>>                     work on a project that has to maintain support for
>>                     piles of application servers, operating systems,
>>                     and versions of java.  I think there is some real
>>                     opportunity here as was previously mentioned, to
>>                     build a docker image that sets up the OS, java,
>>                     and karaf, and then at test time you deploy your
>>                     app and run your tests. With this kind of model
>>                     you can just keep adding new docker images to your
>>                     test suite and retire old ones when you finally
>>                     drop support for something ( *cough* java 6 *cough*)
>>
>>                     Good discussion, really have enjoyed reading!
>>
>>                     Ed
>>
>>
>>                     On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin
>>                     <fragility2.0@gmail.com
>>                     <ma...@gmail.com>> wrote:
>>
>>                         I guess the barrier to be able to write code
>>                         has been lowered enough that
>>                         more people are able to do it, probably for
>>                         the money.  That goes hand in
>>                         hand with the whole Docker thing where it
>>                         feels there is an expectation
>>                         that everything should be easy to do rather
>>                         than accept that like any
>>                         profession, you have to learn in order to
>>                         become good.  Nothing wrong with
>>                         asking questions, but I feel quality of code
>>                         will probably continue to
>>                         decline with tools being the crutch.
>>
>>                         Anyhow, thanks for everyone's input. Karaf is
>>                         a fantastic piece of
>>                         software, I just wanted to make sure that
>>                         things like Docker weren't going
>>                         to cause it to be dumbed down. Obviously like
>>                         any growing technology,
>>                         modularity has some rough spots to iron out,
>>                         but that doesn't mean we
>>                         should give up. Developers can do what they
>>                         want, I would like to continue
>>                         to choose what fits my requirements best out
>>                         of the technologies that are
>>                         available.
>>
>>                         Ryan
>>                         On Apr 13, 2015 2:37 AM, "Achim Nierbeck"
>>                         <bcanhome@googlemail.com
>>                         <ma...@googlemail.com>> wrote:
>>
>>                             I can't agree more ... and some questions
>>                             on stackoverflow or this
>>                             mailinglist just reflect that ...
>>                             "please solve my issue for me, cause I
>>                             forgot to use my brain today" :D
>>
>>                             regards, Achim
>>
>>                             2015-04-13 0:44 GMT+02:00 Ryan Moquin
>>                             <fragility2.0@gmail.com
>>                             <ma...@gmail.com>>:
>>
>>                                 Serge,
>>
>>                                 Package the world applications were
>>                                 able to be built easily before Docker
>>                                 was around. Docker is simply a
>>                                 different way of deploying an application
>>                                 virtually.
>>
>>                                 In my experience, developers who
>>                                 "package the world" with their code are
>>                                 usually either biased against
>>                                 modularity or just don't feel like putting
>>                                 forth the effort. Many technologies in
>>                                 use today take effort to figure
>>                                 out.  A lot of developers seem to feel
>>                                 that any technology that requires
>>                                 effort above the maven shade plugin or
>>                                 using shell scripts to dump all
>>                                 their jars to a server isn't worth
>>                                 their time.
>>
>>                                 Developers that care about the quality
>>                                 of the code or applications they
>>                                 produce won't be deterred from a
>>                                 technology they believe will help them
>>                                 make better applications just because
>>                                 it takes a little bit of effort.  How
>>                                 did less experienced developers manage
>>                                 to survive when the only real
>>                                 choices for writing software was
>>                                 assembly, c or c++?
>>
>>                                 Ryan
>>                                 On Apr 11, 2015 9:53 PM, "Serge Huber"
>>                                 <shuber@jahia.com
>>                                 <ma...@jahia.com>> wrote:
>>
>>                                     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
>>                                     <nielsbne@gmail.com
>>                                     <ma...@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 <fragility2.0@gmail.com
>>                                     <ma...@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" <bcanhome@googlemail.com
>>                                     <ma...@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 <frank@dexels.com
>>                                         <ma...@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
>>                                             <fragility2.0@gmail.com
>>                                             <ma...@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
>>                                                 <https://groups.google.com/forum/m/#%21topic/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.zurczak@linagora.com
>>                                                 <ma...@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
>>                                                     <http://www.linagora.com>
>>
>>                                                     <twitter_16.png>
>>                                                     <https://twitter.com/VincentZurczak>
>>                                                     <linkedin_16.png>
>>                                                     <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>                                                     <skype_16.png>
>>                                                     <callto://vincent.zurczak>
>>                                                     <wordpress_16.png>
>>                                                     <http://vzurczak.wordpress.com>
>>
>>
>>
>>
>>
>>
>>                                         --
>>
>>                                         Apache Member
>>                                         Apache Karaf
>>                                         <http://karaf.apache.org/>
>>                                         Committer & PMC
>>                                         OPS4J Pax Web
>>                                         <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>                                         Committer & Project Lead
>>                                         blog
>>                                         <http://notizblog.nierbeck.de/>
>>                                         Co-Author of Apache Karaf
>>                                         Cookbook <http://bit.ly/1ps9rkS>
>>
>>                                         Software Architect / Project
>>                                         Manager / Scrum Master
>>
>>
>>
>>
>>                             --
>>
>>                             Apache Member
>>                             Apache Karaf <http://karaf.apache.org/>
>>                             Committer & PMC
>>                             OPS4J Pax Web
>>                             <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>                             Committer &
>>                             Project Lead
>>                             blog <http://notizblog.nierbeck.de/>
>>                             Co-Author of Apache Karaf Cookbook
>>                             <http://bit.ly/1ps9rkS>
>>
>>                             Software Architect / Project Manager /
>>                             Scrum Master
>>
>>
>>
>>
>>
>>                 --
>>                 Jean-Baptiste Onofré
>>                 jbonofre@apache.org <ma...@apache.org>
>>                 http://blog.nanthrax.net
>>                 Talend - http://www.talend.com
>>
>>
>>
>>
>>             --
>>
>>             Apache Member
>>             Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>             OPS4J Pax Web
>>             <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>             & Project Lead
>>             blog <http://notizblog.nierbeck.de/>
>>             Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>>             Software Architect / Project Manager / Scrum Master
>>
>>
>>
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Achim Nierbeck <bc...@googlemail.com>]

Hi Christian,

I agree concerning the microservice hype and that you have to differ
between development and runtime time.
OTH. I've already seen it working in production to replace a single bundle
due to bug-fixing a critical bug.
So I disagree about that you only deploy a single server setup and replace
that. It is actually much more complex and
therefore requires an appropriate deployment strategy.

regards, Achim

2015-04-19 8:12 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:

>  I really like the deployment of bundles into a running instance at
> development time. For example it allows to debug through my bundle, do a
> fix and redeploy the single bundle while the debugger stays open. That
> really speeds up the development process.
>
> At production time though I never saw that for a single application that
> deployment at runtime was used. Typically a certain set of bundles is
> tested together and released together. So I think in this case docker is a
> nice fit as we can pack karaf together with this set of bundles into an
> image. This can then be deployed as a simple singular unit which is good
> for admins. Rolling back then is also easy as you can just install the
> previous image.
>
> There is one case where runtime deployment makes a lot of sense. This is
> the case of an integration server where you deploy lots of small
> integrations. Each of these has its own lifecycle and it would not make
> sense to build a container for each of them.
>
> Then there is a case in between represented by the micro services hype
> (not in the sense of OSGi Services). There you have an application that is
> built from individual modules that each have their own lifecycle and
> dependencies. For this case you could use one container and runtime
> deployment but you could also create one container for each. I recently
> helped to port an application from spring/tomcat to OSGi. The application
> was already design to have modules with different lifecycles. In tomcat
> this was represented as one war per module / "microservice". The problem in
> OSGi was that the application was not modularized in an OSGi way. So for
> example there was no semantic versioning. Some of the bundles had to be
> installed in one single version over all the modules. If versions were
> mixed the wiring of module A could change when a new version of module B
> was installed. For this case having separate containers can help.
>
> So the picture I painted shows that there is no one size fits all solution
> and I think docker can be a good match for some of the use cases in
> deployment.
>
> Christian
>
> Am 19.04.2015 um 02:44 schrieb Serge Huber:
>
> James, I don't think JB cared. He was probably more than happy to have a
> discussion than to have to simply walk through slides without any feedback.
> At least that's how I prefer it.
>
>  Personally I think that OSGi is really a great way to make sure that
> people get into the good practice about thinking about the full lifecycle
> of code, not just developing it and starting it, but also shutting it down,
> and what happens when dependencies are not present or shutdown.
>
>  In that regard I've seen that in our team since we switched to OSGi,
> although it took a little investment in terms of getting used to it, people
> are a lot more productive because they can focus on the module they are
> building without having to restart the whole container. This is a huge
> improvement over Docker type of deployments where rebuilding and restarting
> a container can take a lot longer to test a single change.
>
>  I believe that OSGi is also more than proven since it has been around
> for a long time, and it is defined by a standard body that is quite
> significant. I just wish it would get adopted more, and hopefully Karaf
> will help with this effort.
>
>  Not to make me say that Docker or Spring Boot or the Play Framework
> don't have their merits, but I think that it is not enough to look at the
> time to get started, it is also important to look at the TMDT (an acronym I
> just made up : Total Maintenance and Deployment Time :)).
>
>  cheers,
>   Serge...
>
>     - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
> Acacias, Switzerland
> twitter: @sergehuber <https://twitter.com/sergehuber>
>
>  <http://jahiaone.com/register>
> JahiaOne <http://www.jahiaone.com/>, our international user conference is
> back! June 10-12 in Paris - Grab your tickets now
> <http://www.jahiaone.com/>!
>
>  Jahia is a leading open source User eXperience Platform (UXP) vendor,
> relentlessly working at transforming a siloed industry into a user-driven
> one, beyond technology constraints - http://www.jahia.com
>
>
> On Sat, Apr 18, 2015 at 10:47 AM, James Carman <james@carmanconsulting.com
> > wrote:
>
>> Serge,
>>
>>  We had some pretty good discussions during JB's talk (hope we didn't
>> hijack it too much, JB).  I don't think this topic really has anything to
>> do with Docker, necessarily.  Docker is merely a tool people employ to
>> implement a deployment strategy.  I think it basically boils down to the
>> notion that in the "cloud era", it's simpler and cheaper to spin up a new
>> node configured the way you want.  Cloud-enabled applications need to be
>> "cloneable" in this way already, so you kind of get this benefit for free.
>>
>>  This doesn't mean we can't use OSGi to piece together these nodes.
>> OSGi isn't only about being able to runtime-refresh your modules.  There
>> are many other benefits of the OSGi programming model that make it suitable
>> for building statically-configured applications as well.
>>
>>  Just my $0.02
>>
>>  James
>>
>> On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <sh...@jahia.com> wrote:
>>
>>> Interesting discussion indeed.
>>>
>>>  I'm currently at ApacheCon US and I've taken a few opportunities to
>>> promote Apache Karaf which surprisingly few people know about. But again
>>> what I was describing earlier is really a frequent feedback : is modularity
>>> worth the trouble when I can built "micro-services" that are actually
>>> running in docker containers ? Although I am convinced that the two are not
>>> in opposition, I think it would be great to have a killer use case to
>>> demonstrate what the benefits of using Karaf would be.
>>>
>>>  I'm really looking forward to meeting Jean-Baptiste in person ! I love
>>> Karaf and I hope to be able to exchange with him a few experiences around
>>> it.
>>>
>>>  Regards,
>>>   Serge
>>>
>>>     - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
>>> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
>>> Acacias, Switzerland
>>> twitter: @sergehuber <https://twitter.com/sergehuber>
>>>
>>>  <http://jahiaone.com/register>
>>> JahiaOne <http://www.jahiaone.com/>, our international user conference
>>> is back! June 10-12 in Paris - Grab your tickets now
>>> <http://www.jahiaone.com/>!
>>>
>>>  Jahia is a leading open source User eXperience Platform (UXP) vendor,
>>> relentlessly working at transforming a siloed industry into a user-driven
>>> one, beyond technology constraints - http://www.jahia.com
>>>
>>>
>>> On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck <bcanhome@googlemail.com
>>> > wrote:
>>>
>>>> Hey,
>>>>
>>>>  yes I fully agree, also with the Spring-Boot stuff.
>>>> as already stated on the other thread, I think there are certain cases
>>>> where Docker images are useful.
>>>> For a POC, for CI I think a Docker Image is useful. In the end if you
>>>> want to run it in Production I rather have the Ansible setup.
>>>>
>>>>  regards, Achim
>>>>
>>>>
>>>> 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>>
>>>>> Hi Ed,
>>>>>
>>>>> I can't agree more ;)
>>>>> I fully agree about your points.
>>>>>
>>>>> I quite have the same view on Spring Boot ;)
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 04/13/2015 04:32 PM, Ed Welch wrote:
>>>>>
>>>>>> I've really enjoyed following this thread, and I have to say, as a
>>>>>> Docker skeptic surrounded by people who want to bash my brains in with
>>>>>> docker images, it's nice to hear some feedback from people who seem to have
>>>>>> a healthy dose of skepticism like I do...
>>>>>>
>>>>>> So rather than rehash all the things I agree with that have been said
>>>>>> so far, I wanted to comment a few things I hadn't seen:
>>>>>>
>>>>>> The biggest discussion point I bring up with my peers regarding
>>>>>> docker that I've been using to kind of hold the floodgates back:  Who is
>>>>>> responsible for updates to the underlying docker image OS?  Our
>>>>>> organization is fairly segmented, we have a linux operations group, we have
>>>>>> a development group.  If our development group deploys 50 docker images,
>>>>>> all with a variety of distros inside them, different versions of
>>>>>> everything... What happens if there is a big vulnerability found
>>>>>> (think/remember bash).  Is our linux team now on the hook to learn docker
>>>>>> and handle digging through dozens to hundreds of potentially very different
>>>>>> docker images ( which would make you want to force standardization of your
>>>>>> docker images on a particular distro at a minimum ), or does the dev team
>>>>>> now own this responsibility?  This is a hard question for our company to
>>>>>> answer...
>>>>>>
>>>>>> My other comment, is actually regarding what I think is the most
>>>>>> fantastic use case I've seen for docker, which was written up by Roland
>>>>>> Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/
>>>>>> Using docker as part of your automated integration tests is a really
>>>>>> neat idea, especially if you work on a project that has to maintain support
>>>>>> for piles of application servers, operating systems, and versions of java.
>>>>>> I think there is some real opportunity here as was previously mentioned, to
>>>>>> build a docker image that sets up the OS, java, and karaf, and then at test
>>>>>> time you deploy your app and run your tests.  With this kind of model you
>>>>>> can just keep adding new docker images to your test suite and retire old
>>>>>> ones when you finally drop support for something ( *cough* java 6 *cough*)
>>>>>>
>>>>>> Good discussion, really have enjoyed reading!
>>>>>>
>>>>>> Ed
>>>>>>
>>>>>>
>>>>>> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <
>>>>>> fragility2.0@gmail.com> wrote:
>>>>>>
>>>>>>  I guess the barrier to be able to write code has been lowered enough
>>>>>>> that
>>>>>>> more people are able to do it, probably for the money.  That goes
>>>>>>> hand in
>>>>>>> hand with the whole Docker thing where it feels there is an
>>>>>>> expectation
>>>>>>> that everything should be easy to do rather than accept that like any
>>>>>>> profession, you have to learn in order to become good.  Nothing
>>>>>>> wrong with
>>>>>>> asking questions, but I feel quality of code will probably continue
>>>>>>> to
>>>>>>> decline with tools being the crutch.
>>>>>>>
>>>>>>> Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
>>>>>>> software, I just wanted to make sure that things like Docker weren't
>>>>>>> going
>>>>>>> to cause it to be dumbed down.  Obviously like any growing
>>>>>>> technology,
>>>>>>> modularity has some rough spots to iron out, but that doesn't mean we
>>>>>>> should give up.  Developers can do what they want, I would like to
>>>>>>> continue
>>>>>>> to choose what fits my requirements best out of the technologies
>>>>>>> that are
>>>>>>> available.
>>>>>>>
>>>>>>> Ryan
>>>>>>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>  I can't agree more ... and some questions on stackoverflow or this
>>>>>>>> mailinglist just reflect that ...
>>>>>>>> "please solve my issue for me, cause I forgot to use my brain
>>>>>>>> today" :D
>>>>>>>>
>>>>>>>> regards, Achim
>>>>>>>>
>>>>>>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>>>>>
>>>>>>>>  Serge,
>>>>>>>>>
>>>>>>>>> Package the world applications were able to be built easily before
>>>>>>>>> Docker
>>>>>>>>> was around.  Docker is simply a different way of deploying an
>>>>>>>>> application
>>>>>>>>> virtually.
>>>>>>>>>
>>>>>>>>> In my experience, developers who "package the world" with their
>>>>>>>>> code are
>>>>>>>>> usually either biased against modularity or just don't feel like
>>>>>>>>> putting
>>>>>>>>> forth the effort.  Many technologies in use today take effort to
>>>>>>>>> figure
>>>>>>>>> out.  A lot of developers seem to feel that any technology that
>>>>>>>>> requires
>>>>>>>>> effort above the maven shade plugin or using shell scripts to dump
>>>>>>>>> all
>>>>>>>>> their jars to a server isn't worth their time.
>>>>>>>>>
>>>>>>>>> Developers that care about the quality of the code or applications
>>>>>>>>> they
>>>>>>>>> produce won't be deterred from a technology they believe will help
>>>>>>>>> them
>>>>>>>>> make better applications just because it takes a little bit of
>>>>>>>>> effort.  How
>>>>>>>>> did less experienced developers manage to survive when the only
>>>>>>>>> real
>>>>>>>>> choices for writing software was assembly, c or c++?
>>>>>>>>>
>>>>>>>>> Ryan
>>>>>>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>>>>>>>>>
>>>>>>>>>  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 <ni...@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 <fr...@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" <bcanhome@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 <
>>>>>>>>>>>> fragility2.0@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.zurczak@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>>>>>>>>>> <linkedin_16.png>
>>>>>>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>>>>>>>>>> <http://vzurczak.wordpress.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Apache Member
>>>>>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>>>> Committer & Project Lead
>>>>>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>>>>>
>>>>>>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Apache Member
>>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>> Committer &
>>>>>>>> Project Lead
>>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>>
>>>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>   --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>>
>>>> Apache Member
>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>> Committer & Project Lead
>>>> blog <http://notizblog.nierbeck.de/>
>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>
>>>>  Software Architect / Project Manager / Scrum Master
>>>>
>>>>
>>>
>>
>
>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[Christian Schneider <ch...@die-schneider.net>]

I really like the deployment of bundles into a running instance at 
development time. For example it allows to debug through my bundle, do a 
fix and redeploy the single bundle while the debugger stays open. That 
really speeds up the development process.

At production time though I never saw that for a single application that 
deployment at runtime was used. Typically a certain set of bundles is 
tested together and released together. So I think in this case docker is 
a nice fit as we can pack karaf together with this set of bundles into 
an image. This can then be deployed as a simple singular unit which is 
good for admins. Rolling back then is also easy as you can just install 
the previous image.

There is one case where runtime deployment makes a lot of sense. This is 
the case of an integration server where you deploy lots of small 
integrations. Each of these has its own lifecycle and it would not make 
sense to build a container for each of them.

Then there is a case in between represented by the micro services hype 
(not in the sense of OSGi Services). There you have an application that 
is built from individual modules that each have their own lifecycle and 
dependencies. For this case you could use one container and runtime 
deployment but you could also create one container for each. I recently 
helped to port an application from spring/tomcat to OSGi. The 
application was already design to have modules with different 
lifecycles. In tomcat this was represented as one war per module / 
"microservice". The problem in OSGi was that the application was not 
modularized in an OSGi way. So for example there was no semantic 
versioning. Some of the bundles had to be installed in one single 
version over all the modules. If versions were mixed the wiring of 
module A could change when a new version of module B was installed. For 
this case having separate containers can help.

So the picture I painted shows that there is no one size fits all 
solution and I think docker can be a good match for some of the use 
cases in deployment.

Christian

Am 19.04.2015 um 02:44 schrieb Serge Huber:
> James, I don't think JB cared. He was probably more than happy to have 
> a discussion than to have to simply walk through slides without any 
> feedback. At least that's how I prefer it.
>
> Personally I think that OSGi is really a great way to make sure that 
> people get into the good practice about thinking about the full 
> lifecycle of code, not just developing it and starting it, but also 
> shutting it down, and what happens when dependencies are not present 
> or shutdown.
>
> In that regard I've seen that in our team since we switched to OSGi, 
> although it took a little investment in terms of getting used to it, 
> people are a lot more productive because they can focus on the module 
> they are building without having to restart the whole container. This 
> is a huge improvement over Docker type of deployments where rebuilding 
> and restarting a container can take a lot longer to test a single change.
>
> I believe that OSGi is also more than proven since it has been around 
> for a long time, and it is defined by a standard body that is quite 
> significant. I just wish it would get adopted more, and hopefully 
> Karaf will help with this effort.
>
> Not to make me say that Docker or Spring Boot or the Play Framework 
> don't have their merits, but I think that it is not enough to look at 
> the time to get started, it is also important to look at the TMDT (an 
> acronym I just made up : Total Maintenance and Deployment Time :)).
>
> cheers,
>   Serge...
>
> - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227 
> Acacias, Switzerland
> twitter: @sergehuber <https://twitter.com/sergehuber>
>
> <http://jahiaone.com/register>
> JahiaOne <http://www.jahiaone.com/>, our international user conference 
> is back! June 10-12 in Paris - Grab your tickets now 
> <http://www.jahiaone.com/>!
>
> Jahia is a leading open source User eXperience Platform (UXP) vendor, 
> relentlessly working at transforming a siloed industry into a 
> user-driven one, beyond technology constraints - http://www.jahia.com 
> <http://www.jahia.com/>
>
>
> On Sat, Apr 18, 2015 at 10:47 AM, James Carman 
> <james@carmanconsulting.com <ma...@carmanconsulting.com>> wrote:
>
>     Serge,
>
>     We had some pretty good discussions during JB's talk (hope we
>     didn't hijack it too much, JB).  I don't think this topic really
>     has anything to do with Docker, necessarily.  Docker is merely a
>     tool people employ to implement a deployment strategy.  I think it
>     basically boils down to the notion that in the "cloud era", it's
>     simpler and cheaper to spin up a new node configured the way you
>     want.  Cloud-enabled applications need to be "cloneable" in this
>     way already, so you kind of get this benefit for free.
>
>     This doesn't mean we can't use OSGi to piece together these
>     nodes.  OSGi isn't only about being able to runtime-refresh your
>     modules.  There are many other benefits of the OSGi programming
>     model that make it suitable for building statically-configured
>     applications as well.
>
>     Just my $0.02
>
>     James
>
>     On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <shuber@jahia.com
>     <ma...@jahia.com>> wrote:
>
>         Interesting discussion indeed.
>
>         I'm currently at ApacheCon US and I've taken a few
>         opportunities to promote Apache Karaf which surprisingly few
>         people know about. But again what I was describing earlier is
>         really a frequent feedback : is modularity worth the trouble
>         when I can built "micro-services" that are actually running in
>         docker containers ? Although I am convinced that the two are
>         not in opposition, I think it would be great to have a killer
>         use case to demonstrate what the benefits of using Karaf would be.
>
>         I'm really looking forward to meeting Jean-Baptiste in person
>         ! I love Karaf and I hope to be able to exchange with him a
>         few experiences around it.
>
>         Regards,
>           Serge
>
>         - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
>         CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes,
>         1227 Acacias, Switzerland
>         twitter: @sergehuber <https://twitter.com/sergehuber>
>
>         <http://jahiaone.com/register>
>         JahiaOne <http://www.jahiaone.com/>, our international user
>         conference is back! June 10-12 in Paris - Grab your tickets
>         now <http://www.jahiaone.com/>!
>
>         Jahia is a leading open source User eXperience Platform (UXP)
>         vendor, relentlessly working at transforming a siloed industry
>         into a user-driven one, beyond technology constraints -
>         http://www.jahia.com <http://www.jahia.com/>
>
>
>         On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck
>         <bcanhome@googlemail.com <ma...@googlemail.com>> wrote:
>
>             Hey,
>
>             yes I fully agree, also with the Spring-Boot stuff.
>             as already stated on the other thread, I think there are
>             certain cases where Docker images are useful.
>             For a POC, for CI I think a Docker Image is useful. In the
>             end if you want to run it in Production I rather have the
>             Ansible setup.
>
>             regards, Achim
>
>
>             2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré
>             <jb@nanthrax.net <ma...@nanthrax.net>>:
>
>                 Hi Ed,
>
>                 I can't agree more ;)
>                 I fully agree about your points.
>
>                 I quite have the same view on Spring Boot ;)
>
>                 Regards
>                 JB
>
>
>                 On 04/13/2015 04:32 PM, Ed Welch wrote:
>
>                     I've really enjoyed following this thread, and I
>                     have to say, as a Docker skeptic surrounded by
>                     people who want to bash my brains in with docker
>                     images, it's nice to hear some feedback from
>                     people who seem to have a healthy dose of
>                     skepticism like I do...
>
>                     So rather than rehash all the things I agree with
>                     that have been said so far, I wanted to comment a
>                     few things I hadn't seen:
>
>                     The biggest discussion point I bring up with my
>                     peers regarding docker that I've been using to
>                     kind of hold the floodgates back:  Who is
>                     responsible for updates to the underlying docker
>                     image OS?  Our organization is fairly segmented,
>                     we have a linux operations group, we have a
>                     development group.  If our development group
>                     deploys 50 docker images, all with a variety of
>                     distros inside them, different versions of
>                     everything... What happens if there is a big
>                     vulnerability found (think/remember bash). Is our
>                     linux team now on the hook to learn docker and
>                     handle digging through dozens to hundreds of
>                     potentially very different docker images ( which
>                     would make you want to force standardization of
>                     your docker images on a particular distro at a
>                     minimum ), or does the dev team now own this
>                     responsibility?  This is a hard question for our
>                     company to answer...
>
>                     My other comment, is actually regarding what I
>                     think is the most fantastic use case I've seen for
>                     docker, which was written up by Roland Huss on his
>                     blog: https://ro14nd.de/Jolokia-Docker-Image/
>                     Using docker as part of your automated integration
>                     tests is a really neat idea, especially if you
>                     work on a project that has to maintain support for
>                     piles of application servers, operating systems,
>                     and versions of java.  I think there is some real
>                     opportunity here as was previously mentioned, to
>                     build a docker image that sets up the OS, java,
>                     and karaf, and then at test time you deploy your
>                     app and run your tests. With this kind of model
>                     you can just keep adding new docker images to your
>                     test suite and retire old ones when you finally
>                     drop support for something ( *cough* java 6 *cough*)
>
>                     Good discussion, really have enjoyed reading!
>
>                     Ed
>
>
>                     On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin
>                     <fragility2.0@gmail.com
>                     <ma...@gmail.com>> wrote:
>
>                         I guess the barrier to be able to write code
>                         has been lowered enough that
>                         more people are able to do it, probably for
>                         the money.  That goes hand in
>                         hand with the whole Docker thing where it
>                         feels there is an expectation
>                         that everything should be easy to do rather
>                         than accept that like any
>                         profession, you have to learn in order to
>                         become good.  Nothing wrong with
>                         asking questions, but I feel quality of code
>                         will probably continue to
>                         decline with tools being the crutch.
>
>                         Anyhow, thanks for everyone's input. Karaf is
>                         a fantastic piece of
>                         software, I just wanted to make sure that
>                         things like Docker weren't going
>                         to cause it to be dumbed down. Obviously like
>                         any growing technology,
>                         modularity has some rough spots to iron out,
>                         but that doesn't mean we
>                         should give up. Developers can do what they
>                         want, I would like to continue
>                         to choose what fits my requirements best out
>                         of the technologies that are
>                         available.
>
>                         Ryan
>                         On Apr 13, 2015 2:37 AM, "Achim Nierbeck"
>                         <bcanhome@googlemail.com
>                         <ma...@googlemail.com>> wrote:
>
>                             I can't agree more ... and some questions
>                             on stackoverflow or this
>                             mailinglist just reflect that ...
>                             "please solve my issue for me, cause I
>                             forgot to use my brain today" :D
>
>                             regards, Achim
>
>                             2015-04-13 0:44 GMT+02:00 Ryan Moquin
>                             <fragility2.0@gmail.com
>                             <ma...@gmail.com>>:
>
>                                 Serge,
>
>                                 Package the world applications were
>                                 able to be built easily before Docker
>                                 was around. Docker is simply a
>                                 different way of deploying an application
>                                 virtually.
>
>                                 In my experience, developers who
>                                 "package the world" with their code are
>                                 usually either biased against
>                                 modularity or just don't feel like putting
>                                 forth the effort. Many technologies in
>                                 use today take effort to figure
>                                 out.  A lot of developers seem to feel
>                                 that any technology that requires
>                                 effort above the maven shade plugin or
>                                 using shell scripts to dump all
>                                 their jars to a server isn't worth
>                                 their time.
>
>                                 Developers that care about the quality
>                                 of the code or applications they
>                                 produce won't be deterred from a
>                                 technology they believe will help them
>                                 make better applications just because
>                                 it takes a little bit of effort.  How
>                                 did less experienced developers manage
>                                 to survive when the only real
>                                 choices for writing software was
>                                 assembly, c or c++?
>
>                                 Ryan
>                                 On Apr 11, 2015 9:53 PM, "Serge Huber"
>                                 <shuber@jahia.com
>                                 <ma...@jahia.com>> wrote:
>
>                                     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
>                                     <nielsbne@gmail.com
>                                     <ma...@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 <fragility2.0@gmail.com
>                                     <ma...@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" <bcanhome@googlemail.com
>                                     <ma...@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 <frank@dexels.com
>                                         <ma...@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
>                                             <fragility2.0@gmail.com
>                                             <ma...@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
>                                                 <https://groups.google.com/forum/m/#%21topic/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.zurczak@linagora.com
>                                                 <ma...@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
>                                                     <http://www.linagora.com>
>
>                                                     <twitter_16.png>
>                                                     <https://twitter.com/VincentZurczak>
>                                                     <linkedin_16.png>
>                                                     <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>                                                     <skype_16.png>
>                                                     <callto://vincent.zurczak>
>                                                     <wordpress_16.png>
>                                                     <http://vzurczak.wordpress.com>
>
>
>
>
>
>
>                                         --
>
>                                         Apache Member
>                                         Apache Karaf
>                                         <http://karaf.apache.org/>
>                                         Committer & PMC
>                                         OPS4J Pax Web
>                                         <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>                                         Committer & Project Lead
>                                         blog
>                                         <http://notizblog.nierbeck.de/>
>                                         Co-Author of Apache Karaf
>                                         Cookbook <http://bit.ly/1ps9rkS>
>
>                                         Software Architect / Project
>                                         Manager / Scrum Master
>
>
>
>
>                             --
>
>                             Apache Member
>                             Apache Karaf <http://karaf.apache.org/>
>                             Committer & PMC
>                             OPS4J Pax Web
>                             <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>                             Committer &
>                             Project Lead
>                             blog <http://notizblog.nierbeck.de/>
>                             Co-Author of Apache Karaf Cookbook
>                             <http://bit.ly/1ps9rkS>
>
>                             Software Architect / Project Manager /
>                             Scrum Master
>
>
>
>
>
>                 -- 
>                 Jean-Baptiste Onofré
>                 jbonofre@apache.org <ma...@apache.org>
>                 http://blog.nanthrax.net
>                 Talend - http://www.talend.com
>
>
>
>
>             -- 
>
>             Apache Member
>             Apache Karaf <http://karaf.apache.org/> Committer & PMC
>             OPS4J Pax Web
>             <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>             & Project Lead
>             blog <http://notizblog.nierbeck.de/>
>             Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
>             Software Architect / Project Manager / Scrum Master
>
>
>
>

Re: Karaf and Docker

[Serge Huber <sh...@jahia.com>]

James, I don't think JB cared. He was probably more than happy to have a
discussion than to have to simply walk through slides without any feedback.
At least that's how I prefer it.

Personally I think that OSGi is really a great way to make sure that people
get into the good practice about thinking about the full lifecycle of code,
not just developing it and starting it, but also shutting it down, and what
happens when dependencies are not present or shutdown.

In that regard I've seen that in our team since we switched to OSGi,
although it took a little investment in terms of getting used to it, people
are a lot more productive because they can focus on the module they are
building without having to restart the whole container. This is a huge
improvement over Docker type of deployments where rebuilding and restarting
a container can take a lot longer to test a single change.

I believe that OSGi is also more than proven since it has been around for a
long time, and it is defined by a standard body that is quite significant.
I just wish it would get adopted more, and hopefully Karaf will help with
this effort.

Not to make me say that Docker or Spring Boot or the Play Framework don't
have their merits, but I think that it is not enough to look at the time to
get started, it is also important to look at the TMDT (an acronym I just
made up : Total Maintenance and Deployment Time :)).

cheers,
  Serge...

- -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227 Acacias,
Switzerland
twitter: @sergehuber <https://twitter.com/sergehuber>

<http://jahiaone.com/register>
JahiaOne <http://www.jahiaone.com/>, our international user conference is
back! June 10-12 in Paris - Grab your tickets now <http://www.jahiaone.com/>
!

Jahia is a leading open source User eXperience Platform (UXP) vendor,
relentlessly working at transforming a siloed industry into a user-driven
one, beyond technology constraints - http://www.jahia.com


On Sat, Apr 18, 2015 at 10:47 AM, James Carman <ja...@carmanconsulting.com>
wrote:

> Serge,
>
> We had some pretty good discussions during JB's talk (hope we didn't
> hijack it too much, JB).  I don't think this topic really has anything to
> do with Docker, necessarily.  Docker is merely a tool people employ to
> implement a deployment strategy.  I think it basically boils down to the
> notion that in the "cloud era", it's simpler and cheaper to spin up a new
> node configured the way you want.  Cloud-enabled applications need to be
> "cloneable" in this way already, so you kind of get this benefit for free.
>
> This doesn't mean we can't use OSGi to piece together these nodes.  OSGi
> isn't only about being able to runtime-refresh your modules.  There are
> many other benefits of the OSGi programming model that make it suitable for
> building statically-configured applications as well.
>
> Just my $0.02
>
> James
>
> On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <sh...@jahia.com> wrote:
>
>> Interesting discussion indeed.
>>
>> I'm currently at ApacheCon US and I've taken a few opportunities to
>> promote Apache Karaf which surprisingly few people know about. But again
>> what I was describing earlier is really a frequent feedback : is modularity
>> worth the trouble when I can built "micro-services" that are actually
>> running in docker containers ? Although I am convinced that the two are not
>> in opposition, I think it would be great to have a killer use case to
>> demonstrate what the benefits of using Karaf would be.
>>
>> I'm really looking forward to meeting Jean-Baptiste in person ! I love
>> Karaf and I hope to be able to exchange with him a few experiences around
>> it.
>>
>> Regards,
>>   Serge
>>
>> - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
>> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
>> Acacias, Switzerland
>> twitter: @sergehuber <https://twitter.com/sergehuber>
>>
>> <http://jahiaone.com/register>
>> JahiaOne <http://www.jahiaone.com/>, our international user conference
>> is back! June 10-12 in Paris - Grab your tickets now
>> <http://www.jahiaone.com/>!
>>
>> Jahia is a leading open source User eXperience Platform (UXP) vendor,
>> relentlessly working at transforming a siloed industry into a user-driven
>> one, beyond technology constraints - http://www.jahia.com
>>
>>
>> On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck <bc...@googlemail.com>
>> wrote:
>>
>>> Hey,
>>>
>>> yes I fully agree, also with the Spring-Boot stuff.
>>> as already stated on the other thread, I think there are certain cases
>>> where Docker images are useful.
>>> For a POC, for CI I think a Docker Image is useful. In the end if you
>>> want to run it in Production I rather have the Ansible setup.
>>>
>>> regards, Achim
>>>
>>>
>>> 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>
>>>> Hi Ed,
>>>>
>>>> I can't agree more ;)
>>>> I fully agree about your points.
>>>>
>>>> I quite have the same view on Spring Boot ;)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 04/13/2015 04:32 PM, Ed Welch wrote:
>>>>
>>>>> I've really enjoyed following this thread, and I have to say, as a
>>>>> Docker skeptic surrounded by people who want to bash my brains in with
>>>>> docker images, it's nice to hear some feedback from people who seem to have
>>>>> a healthy dose of skepticism like I do...
>>>>>
>>>>> So rather than rehash all the things I agree with that have been said
>>>>> so far, I wanted to comment a few things I hadn't seen:
>>>>>
>>>>> The biggest discussion point I bring up with my peers regarding docker
>>>>> that I've been using to kind of hold the floodgates back:  Who is
>>>>> responsible for updates to the underlying docker image OS?  Our
>>>>> organization is fairly segmented, we have a linux operations group, we have
>>>>> a development group.  If our development group deploys 50 docker images,
>>>>> all with a variety of distros inside them, different versions of
>>>>> everything... What happens if there is a big vulnerability found
>>>>> (think/remember bash).  Is our linux team now on the hook to learn docker
>>>>> and handle digging through dozens to hundreds of potentially very different
>>>>> docker images ( which would make you want to force standardization of your
>>>>> docker images on a particular distro at a minimum ), or does the dev team
>>>>> now own this responsibility?  This is a hard question for our company to
>>>>> answer...
>>>>>
>>>>> My other comment, is actually regarding what I think is the most
>>>>> fantastic use case I've seen for docker, which was written up by Roland
>>>>> Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/
>>>>> Using docker as part of your automated integration tests is a really
>>>>> neat idea, especially if you work on a project that has to maintain support
>>>>> for piles of application servers, operating systems, and versions of java.
>>>>> I think there is some real opportunity here as was previously mentioned, to
>>>>> build a docker image that sets up the OS, java, and karaf, and then at test
>>>>> time you deploy your app and run your tests.  With this kind of model you
>>>>> can just keep adding new docker images to your test suite and retire old
>>>>> ones when you finally drop support for something ( *cough* java 6 *cough*)
>>>>>
>>>>> Good discussion, really have enjoyed reading!
>>>>>
>>>>> Ed
>>>>>
>>>>>
>>>>> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <
>>>>> fragility2.0@gmail.com> wrote:
>>>>>
>>>>>  I guess the barrier to be able to write code has been lowered enough
>>>>>> that
>>>>>> more people are able to do it, probably for the money.  That goes
>>>>>> hand in
>>>>>> hand with the whole Docker thing where it feels there is an
>>>>>> expectation
>>>>>> that everything should be easy to do rather than accept that like any
>>>>>> profession, you have to learn in order to become good.  Nothing wrong
>>>>>> with
>>>>>> asking questions, but I feel quality of code will probably continue to
>>>>>> decline with tools being the crutch.
>>>>>>
>>>>>> Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
>>>>>> software, I just wanted to make sure that things like Docker weren't
>>>>>> going
>>>>>> to cause it to be dumbed down.  Obviously like any growing technology,
>>>>>> modularity has some rough spots to iron out, but that doesn't mean we
>>>>>> should give up.  Developers can do what they want, I would like to
>>>>>> continue
>>>>>> to choose what fits my requirements best out of the technologies that
>>>>>> are
>>>>>> available.
>>>>>>
>>>>>> Ryan
>>>>>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com>
>>>>>> wrote:
>>>>>>
>>>>>>  I can't agree more ... and some questions on stackoverflow or this
>>>>>>> mailinglist just reflect that ...
>>>>>>> "please solve my issue for me, cause I forgot to use my brain today"
>>>>>>> :D
>>>>>>>
>>>>>>> regards, Achim
>>>>>>>
>>>>>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>>>>
>>>>>>>  Serge,
>>>>>>>>
>>>>>>>> Package the world applications were able to be built easily before
>>>>>>>> Docker
>>>>>>>> was around.  Docker is simply a different way of deploying an
>>>>>>>> application
>>>>>>>> virtually.
>>>>>>>>
>>>>>>>> In my experience, developers who "package the world" with their
>>>>>>>> code are
>>>>>>>> usually either biased against modularity or just don't feel like
>>>>>>>> putting
>>>>>>>> forth the effort.  Many technologies in use today take effort to
>>>>>>>> figure
>>>>>>>> out.  A lot of developers seem to feel that any technology that
>>>>>>>> requires
>>>>>>>> effort above the maven shade plugin or using shell scripts to dump
>>>>>>>> all
>>>>>>>> their jars to a server isn't worth their time.
>>>>>>>>
>>>>>>>> Developers that care about the quality of the code or applications
>>>>>>>> they
>>>>>>>> produce won't be deterred from a technology they believe will help
>>>>>>>> them
>>>>>>>> make better applications just because it takes a little bit of
>>>>>>>> effort.  How
>>>>>>>> did less experienced developers manage to survive when the only real
>>>>>>>> choices for writing software was assembly, c or c++?
>>>>>>>>
>>>>>>>> Ryan
>>>>>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>>>>>>>>
>>>>>>>>  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 <ni...@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 <fr...@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" <bc...@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 <
>>>>>>>>>>> fragility2.0@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.zurczak@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
>>>>>>>>>>>>>
>>>>>>>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>>>>>>>>> <linkedin_16.png>
>>>>>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>>>>>>>>> <http://vzurczak.wordpress.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Apache Member
>>>>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>>> Committer & Project Lead
>>>>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>>>>
>>>>>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Apache Member
>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>> Committer &
>>>>>>> Project Lead
>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>
>>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>> & Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>>
>

Re: Karaf and Docker

[James Carman <ja...@carmanconsulting.com>]

Serge,

We had some pretty good discussions during JB's talk (hope we didn't hijack
it too much, JB).  I don't think this topic really has anything to do with
Docker, necessarily.  Docker is merely a tool people employ to implement a
deployment strategy.  I think it basically boils down to the notion that in
the "cloud era", it's simpler and cheaper to spin up a new node configured
the way you want.  Cloud-enabled applications need to be "cloneable" in
this way already, so you kind of get this benefit for free.

This doesn't mean we can't use OSGi to piece together these nodes.  OSGi
isn't only about being able to runtime-refresh your modules.  There are
many other benefits of the OSGi programming model that make it suitable for
building statically-configured applications as well.

Just my $0.02

James

On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <sh...@jahia.com> wrote:

> Interesting discussion indeed.
>
> I'm currently at ApacheCon US and I've taken a few opportunities to
> promote Apache Karaf which surprisingly few people know about. But again
> what I was describing earlier is really a frequent feedback : is modularity
> worth the trouble when I can built "micro-services" that are actually
> running in docker containers ? Although I am convinced that the two are not
> in opposition, I think it would be great to have a killer use case to
> demonstrate what the benefits of using Karaf would be.
>
> I'm really looking forward to meeting Jean-Baptiste in person ! I love
> Karaf and I hope to be able to exchange with him a few experiences around
> it.
>
> Regards,
>   Serge
>
> - -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
> Acacias, Switzerland
> twitter: @sergehuber <https://twitter.com/sergehuber>
>
> <http://jahiaone.com/register>
> JahiaOne <http://www.jahiaone.com/>, our international user conference is
> back! June 10-12 in Paris - Grab your tickets now
> <http://www.jahiaone.com/>!
>
> Jahia is a leading open source User eXperience Platform (UXP) vendor,
> relentlessly working at transforming a siloed industry into a user-driven
> one, beyond technology constraints - http://www.jahia.com
>
>
> On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck <bc...@googlemail.com>
> wrote:
>
>> Hey,
>>
>> yes I fully agree, also with the Spring-Boot stuff.
>> as already stated on the other thread, I think there are certain cases
>> where Docker images are useful.
>> For a POC, for CI I think a Docker Image is useful. In the end if you
>> want to run it in Production I rather have the Ansible setup.
>>
>> regards, Achim
>>
>>
>> 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>
>>> Hi Ed,
>>>
>>> I can't agree more ;)
>>> I fully agree about your points.
>>>
>>> I quite have the same view on Spring Boot ;)
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 04/13/2015 04:32 PM, Ed Welch wrote:
>>>
>>>> I've really enjoyed following this thread, and I have to say, as a
>>>> Docker skeptic surrounded by people who want to bash my brains in with
>>>> docker images, it's nice to hear some feedback from people who seem to have
>>>> a healthy dose of skepticism like I do...
>>>>
>>>> So rather than rehash all the things I agree with that have been said
>>>> so far, I wanted to comment a few things I hadn't seen:
>>>>
>>>> The biggest discussion point I bring up with my peers regarding docker
>>>> that I've been using to kind of hold the floodgates back:  Who is
>>>> responsible for updates to the underlying docker image OS?  Our
>>>> organization is fairly segmented, we have a linux operations group, we have
>>>> a development group.  If our development group deploys 50 docker images,
>>>> all with a variety of distros inside them, different versions of
>>>> everything... What happens if there is a big vulnerability found
>>>> (think/remember bash).  Is our linux team now on the hook to learn docker
>>>> and handle digging through dozens to hundreds of potentially very different
>>>> docker images ( which would make you want to force standardization of your
>>>> docker images on a particular distro at a minimum ), or does the dev team
>>>> now own this responsibility?  This is a hard question for our company to
>>>> answer...
>>>>
>>>> My other comment, is actually regarding what I think is the most
>>>> fantastic use case I've seen for docker, which was written up by Roland
>>>> Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/
>>>> Using docker as part of your automated integration tests is a really
>>>> neat idea, especially if you work on a project that has to maintain support
>>>> for piles of application servers, operating systems, and versions of java.
>>>> I think there is some real opportunity here as was previously mentioned, to
>>>> build a docker image that sets up the OS, java, and karaf, and then at test
>>>> time you deploy your app and run your tests.  With this kind of model you
>>>> can just keep adding new docker images to your test suite and retire old
>>>> ones when you finally drop support for something ( *cough* java 6 *cough*)
>>>>
>>>> Good discussion, really have enjoyed reading!
>>>>
>>>> Ed
>>>>
>>>>
>>>> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <fr...@gmail.com>
>>>> wrote:
>>>>
>>>>  I guess the barrier to be able to write code has been lowered enough
>>>>> that
>>>>> more people are able to do it, probably for the money.  That goes hand
>>>>> in
>>>>> hand with the whole Docker thing where it feels there is an expectation
>>>>> that everything should be easy to do rather than accept that like any
>>>>> profession, you have to learn in order to become good.  Nothing wrong
>>>>> with
>>>>> asking questions, but I feel quality of code will probably continue to
>>>>> decline with tools being the crutch.
>>>>>
>>>>> Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
>>>>> software, I just wanted to make sure that things like Docker weren't
>>>>> going
>>>>> to cause it to be dumbed down.  Obviously like any growing technology,
>>>>> modularity has some rough spots to iron out, but that doesn't mean we
>>>>> should give up.  Developers can do what they want, I would like to
>>>>> continue
>>>>> to choose what fits my requirements best out of the technologies that
>>>>> are
>>>>> available.
>>>>>
>>>>> Ryan
>>>>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com>
>>>>> wrote:
>>>>>
>>>>>  I can't agree more ... and some questions on stackoverflow or this
>>>>>> mailinglist just reflect that ...
>>>>>> "please solve my issue for me, cause I forgot to use my brain today"
>>>>>> :D
>>>>>>
>>>>>> regards, Achim
>>>>>>
>>>>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>>>
>>>>>>  Serge,
>>>>>>>
>>>>>>> Package the world applications were able to be built easily before
>>>>>>> Docker
>>>>>>> was around.  Docker is simply a different way of deploying an
>>>>>>> application
>>>>>>> virtually.
>>>>>>>
>>>>>>> In my experience, developers who "package the world" with their code
>>>>>>> are
>>>>>>> usually either biased against modularity or just don't feel like
>>>>>>> putting
>>>>>>> forth the effort.  Many technologies in use today take effort to
>>>>>>> figure
>>>>>>> out.  A lot of developers seem to feel that any technology that
>>>>>>> requires
>>>>>>> effort above the maven shade plugin or using shell scripts to dump
>>>>>>> all
>>>>>>> their jars to a server isn't worth their time.
>>>>>>>
>>>>>>> Developers that care about the quality of the code or applications
>>>>>>> they
>>>>>>> produce won't be deterred from a technology they believe will help
>>>>>>> them
>>>>>>> make better applications just because it takes a little bit of
>>>>>>> effort.  How
>>>>>>> did less experienced developers manage to survive when the only real
>>>>>>> choices for writing software was assembly, c or c++?
>>>>>>>
>>>>>>> Ryan
>>>>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>>>>>>>
>>>>>>>  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 <ni...@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 <fr...@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" <bc...@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 <
>>>>>>>>>> fragility2.0@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.zurczak@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
>>>>>>>>>>>>
>>>>>>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>>>>>>>> <linkedin_16.png>
>>>>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>>>>>>>> <http://vzurczak.wordpress.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Apache Member
>>>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>> Committer & Project Lead
>>>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>>>
>>>>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Apache Member
>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>> Committer &
>>>>>> Project Lead
>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>
>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>

Re: Karaf and Docker

[Serge Huber <sh...@jahia.com>]

Interesting discussion indeed.

I'm currently at ApacheCon US and I've taken a few opportunities to promote
Apache Karaf which surprisingly few people know about. But again what I was
describing earlier is really a frequent feedback : is modularity worth the
trouble when I can built "micro-services" that are actually running in
docker containers ? Although I am convinced that the two are not in
opposition, I think it would be great to have a killer use case to
demonstrate what the benefits of using Karaf would be.

I'm really looking forward to meeting Jean-Baptiste in person ! I love
Karaf and I hope to be able to exchange with him a few experiences around
it.

Regards,
  Serge

- -- --- -----=[ shuber at jahia dot com ]=---- --- -- -
CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227 Acacias,
Switzerland
twitter: @sergehuber <https://twitter.com/sergehuber>

<http://jahiaone.com/register>
JahiaOne <http://www.jahiaone.com/>, our international user conference is
back! June 10-12 in Paris - Grab your tickets now <http://www.jahiaone.com/>
!

Jahia is a leading open source User eXperience Platform (UXP) vendor,
relentlessly working at transforming a siloed industry into a user-driven
one, beyond technology constraints - http://www.jahia.com


On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck <bc...@googlemail.com>
wrote:

> Hey,
>
> yes I fully agree, also with the Spring-Boot stuff.
> as already stated on the other thread, I think there are certain cases
> where Docker images are useful.
> For a POC, for CI I think a Docker Image is useful. In the end if you want
> to run it in Production I rather have the Ansible setup.
>
> regards, Achim
>
>
> 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
>> Hi Ed,
>>
>> I can't agree more ;)
>> I fully agree about your points.
>>
>> I quite have the same view on Spring Boot ;)
>>
>> Regards
>> JB
>>
>>
>> On 04/13/2015 04:32 PM, Ed Welch wrote:
>>
>>> I've really enjoyed following this thread, and I have to say, as a
>>> Docker skeptic surrounded by people who want to bash my brains in with
>>> docker images, it's nice to hear some feedback from people who seem to have
>>> a healthy dose of skepticism like I do...
>>>
>>> So rather than rehash all the things I agree with that have been said so
>>> far, I wanted to comment a few things I hadn't seen:
>>>
>>> The biggest discussion point I bring up with my peers regarding docker
>>> that I've been using to kind of hold the floodgates back:  Who is
>>> responsible for updates to the underlying docker image OS?  Our
>>> organization is fairly segmented, we have a linux operations group, we have
>>> a development group.  If our development group deploys 50 docker images,
>>> all with a variety of distros inside them, different versions of
>>> everything... What happens if there is a big vulnerability found
>>> (think/remember bash).  Is our linux team now on the hook to learn docker
>>> and handle digging through dozens to hundreds of potentially very different
>>> docker images ( which would make you want to force standardization of your
>>> docker images on a particular distro at a minimum ), or does the dev team
>>> now own this responsibility?  This is a hard question for our company to
>>> answer...
>>>
>>> My other comment, is actually regarding what I think is the most
>>> fantastic use case I've seen for docker, which was written up by Roland
>>> Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/
>>> Using docker as part of your automated integration tests is a really
>>> neat idea, especially if you work on a project that has to maintain support
>>> for piles of application servers, operating systems, and versions of java.
>>> I think there is some real opportunity here as was previously mentioned, to
>>> build a docker image that sets up the OS, java, and karaf, and then at test
>>> time you deploy your app and run your tests.  With this kind of model you
>>> can just keep adding new docker images to your test suite and retire old
>>> ones when you finally drop support for something ( *cough* java 6 *cough*)
>>>
>>> Good discussion, really have enjoyed reading!
>>>
>>> Ed
>>>
>>>
>>> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <fr...@gmail.com>
>>> wrote:
>>>
>>>  I guess the barrier to be able to write code has been lowered enough
>>>> that
>>>> more people are able to do it, probably for the money.  That goes hand
>>>> in
>>>> hand with the whole Docker thing where it feels there is an expectation
>>>> that everything should be easy to do rather than accept that like any
>>>> profession, you have to learn in order to become good.  Nothing wrong
>>>> with
>>>> asking questions, but I feel quality of code will probably continue to
>>>> decline with tools being the crutch.
>>>>
>>>> Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
>>>> software, I just wanted to make sure that things like Docker weren't
>>>> going
>>>> to cause it to be dumbed down.  Obviously like any growing technology,
>>>> modularity has some rough spots to iron out, but that doesn't mean we
>>>> should give up.  Developers can do what they want, I would like to
>>>> continue
>>>> to choose what fits my requirements best out of the technologies that
>>>> are
>>>> available.
>>>>
>>>> Ryan
>>>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com>
>>>> wrote:
>>>>
>>>>  I can't agree more ... and some questions on stackoverflow or this
>>>>> mailinglist just reflect that ...
>>>>> "please solve my issue for me, cause I forgot to use my brain today" :D
>>>>>
>>>>> regards, Achim
>>>>>
>>>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>>
>>>>>  Serge,
>>>>>>
>>>>>> Package the world applications were able to be built easily before
>>>>>> Docker
>>>>>> was around.  Docker is simply a different way of deploying an
>>>>>> application
>>>>>> virtually.
>>>>>>
>>>>>> In my experience, developers who "package the world" with their code
>>>>>> are
>>>>>> usually either biased against modularity or just don't feel like
>>>>>> putting
>>>>>> forth the effort.  Many technologies in use today take effort to
>>>>>> figure
>>>>>> out.  A lot of developers seem to feel that any technology that
>>>>>> requires
>>>>>> effort above the maven shade plugin or using shell scripts to dump all
>>>>>> their jars to a server isn't worth their time.
>>>>>>
>>>>>> Developers that care about the quality of the code or applications
>>>>>> they
>>>>>> produce won't be deterred from a technology they believe will help
>>>>>> them
>>>>>> make better applications just because it takes a little bit of
>>>>>> effort.  How
>>>>>> did less experienced developers manage to survive when the only real
>>>>>> choices for writing software was assembly, c or c++?
>>>>>>
>>>>>> Ryan
>>>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>>>>>>
>>>>>>  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 <ni...@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 <fr...@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" <bc...@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 <
>>>>>>>>> fragility2.0@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.zurczak@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
>>>>>>>>>>>
>>>>>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>>>>>>> <linkedin_16.png>
>>>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>>>>>>> <http://vzurczak.wordpress.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Apache Member
>>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>> Committer & Project Lead
>>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>>
>>>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Apache Member
>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>> Committer &
>>>>> Project Lead
>>>>> blog <http://notizblog.nierbeck.de/>
>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>
>>>>> Software Architect / Project Manager / Scrum Master
>>>>>
>>>>>
>>>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: Karaf and Docker

[Achim Nierbeck <bc...@googlemail.com>]

Hey,

yes I fully agree, also with the Spring-Boot stuff.
as already stated on the other thread, I think there are certain cases
where Docker images are useful.
For a POC, for CI I think a Docker Image is useful. In the end if you want
to run it in Production I rather have the Ansible setup.

regards, Achim


2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:

> Hi Ed,
>
> I can't agree more ;)
> I fully agree about your points.
>
> I quite have the same view on Spring Boot ;)
>
> Regards
> JB
>
>
> On 04/13/2015 04:32 PM, Ed Welch wrote:
>
>> I've really enjoyed following this thread, and I have to say, as a Docker
>> skeptic surrounded by people who want to bash my brains in with docker
>> images, it's nice to hear some feedback from people who seem to have a
>> healthy dose of skepticism like I do...
>>
>> So rather than rehash all the things I agree with that have been said so
>> far, I wanted to comment a few things I hadn't seen:
>>
>> The biggest discussion point I bring up with my peers regarding docker
>> that I've been using to kind of hold the floodgates back:  Who is
>> responsible for updates to the underlying docker image OS?  Our
>> organization is fairly segmented, we have a linux operations group, we have
>> a development group.  If our development group deploys 50 docker images,
>> all with a variety of distros inside them, different versions of
>> everything... What happens if there is a big vulnerability found
>> (think/remember bash).  Is our linux team now on the hook to learn docker
>> and handle digging through dozens to hundreds of potentially very different
>> docker images ( which would make you want to force standardization of your
>> docker images on a particular distro at a minimum ), or does the dev team
>> now own this responsibility?  This is a hard question for our company to
>> answer...
>>
>> My other comment, is actually regarding what I think is the most
>> fantastic use case I've seen for docker, which was written up by Roland
>> Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/
>> Using docker as part of your automated integration tests is a really neat
>> idea, especially if you work on a project that has to maintain support for
>> piles of application servers, operating systems, and versions of java.  I
>> think there is some real opportunity here as was previously mentioned, to
>> build a docker image that sets up the OS, java, and karaf, and then at test
>> time you deploy your app and run your tests.  With this kind of model you
>> can just keep adding new docker images to your test suite and retire old
>> ones when you finally drop support for something ( *cough* java 6 *cough*)
>>
>> Good discussion, really have enjoyed reading!
>>
>> Ed
>>
>>
>> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <fr...@gmail.com>
>> wrote:
>>
>>  I guess the barrier to be able to write code has been lowered enough that
>>> more people are able to do it, probably for the money.  That goes hand in
>>> hand with the whole Docker thing where it feels there is an expectation
>>> that everything should be easy to do rather than accept that like any
>>> profession, you have to learn in order to become good.  Nothing wrong
>>> with
>>> asking questions, but I feel quality of code will probably continue to
>>> decline with tools being the crutch.
>>>
>>> Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
>>> software, I just wanted to make sure that things like Docker weren't
>>> going
>>> to cause it to be dumbed down.  Obviously like any growing technology,
>>> modularity has some rough spots to iron out, but that doesn't mean we
>>> should give up.  Developers can do what they want, I would like to
>>> continue
>>> to choose what fits my requirements best out of the technologies that are
>>> available.
>>>
>>> Ryan
>>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com>
>>> wrote:
>>>
>>>  I can't agree more ... and some questions on stackoverflow or this
>>>> mailinglist just reflect that ...
>>>> "please solve my issue for me, cause I forgot to use my brain today" :D
>>>>
>>>> regards, Achim
>>>>
>>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>
>>>>  Serge,
>>>>>
>>>>> Package the world applications were able to be built easily before
>>>>> Docker
>>>>> was around.  Docker is simply a different way of deploying an
>>>>> application
>>>>> virtually.
>>>>>
>>>>> In my experience, developers who "package the world" with their code
>>>>> are
>>>>> usually either biased against modularity or just don't feel like
>>>>> putting
>>>>> forth the effort.  Many technologies in use today take effort to figure
>>>>> out.  A lot of developers seem to feel that any technology that
>>>>> requires
>>>>> effort above the maven shade plugin or using shell scripts to dump all
>>>>> their jars to a server isn't worth their time.
>>>>>
>>>>> Developers that care about the quality of the code or applications they
>>>>> produce won't be deterred from a technology they believe will help them
>>>>> make better applications just because it takes a little bit of
>>>>> effort.  How
>>>>> did less experienced developers manage to survive when the only real
>>>>> choices for writing software was assembly, c or c++?
>>>>>
>>>>> Ryan
>>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>>>>>
>>>>>  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 <ni...@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 <fr...@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" <bc...@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 <fragility2.0@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.zurczak@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
>>>>>>>>>>
>>>>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>>>>>> <linkedin_16.png>
>>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>>>>>> <http://vzurczak.wordpress.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Apache Member
>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>> Committer & Project Lead
>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>
>>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>> --
>>>>
>>>> Apache Member
>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>> Committer &
>>>> Project Lead
>>>> blog <http://notizblog.nierbeck.de/>
>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>
>>>> Software Architect / Project Manager / Scrum Master
>>>>
>>>>
>>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Ed,

I can't agree more ;)
I fully agree about your points.

I quite have the same view on Spring Boot ;)

Regards
JB

On 04/13/2015 04:32 PM, Ed Welch wrote:
> I've really enjoyed following this thread, and I have to say, as a Docker skeptic surrounded by people who want to bash my brains in with docker images, it's nice to hear some feedback from people who seem to have a healthy dose of skepticism like I do...
>
> So rather than rehash all the things I agree with that have been said so far, I wanted to comment a few things I hadn't seen:
>
> The biggest discussion point I bring up with my peers regarding docker that I've been using to kind of hold the floodgates back:  Who is responsible for updates to the underlying docker image OS?  Our organization is fairly segmented, we have a linux operations group, we have a development group.  If our development group deploys 50 docker images, all with a variety of distros inside them, different versions of everything... What happens if there is a big vulnerability found (think/remember bash).  Is our linux team now on the hook to learn docker and handle digging through dozens to hundreds of potentially very different docker images ( which would make you want to force standardization of your docker images on a particular distro at a minimum ), or does the dev team now own this responsibility?  This is a hard question for our company to answer...
>
> My other comment, is actually regarding what I think is the most fantastic use case I've seen for docker, which was written up by Roland Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/
> Using docker as part of your automated integration tests is a really neat idea, especially if you work on a project that has to maintain support for piles of application servers, operating systems, and versions of java.  I think there is some real opportunity here as was previously mentioned, to build a docker image that sets up the OS, java, and karaf, and then at test time you deploy your app and run your tests.  With this kind of model you can just keep adding new docker images to your test suite and retire old ones when you finally drop support for something ( *cough* java 6 *cough*)
>
> Good discussion, really have enjoyed reading!
>
> Ed
>
>
> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <fr...@gmail.com> wrote:
>
>> I guess the barrier to be able to write code has been lowered enough that
>> more people are able to do it, probably for the money.  That goes hand in
>> hand with the whole Docker thing where it feels there is an expectation
>> that everything should be easy to do rather than accept that like any
>> profession, you have to learn in order to become good.  Nothing wrong with
>> asking questions, but I feel quality of code will probably continue to
>> decline with tools being the crutch.
>>
>> Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
>> software, I just wanted to make sure that things like Docker weren't going
>> to cause it to be dumbed down.  Obviously like any growing technology,
>> modularity has some rough spots to iron out, but that doesn't mean we
>> should give up.  Developers can do what they want, I would like to continue
>> to choose what fits my requirements best out of the technologies that are
>> available.
>>
>> Ryan
>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com> wrote:
>>
>>> I can't agree more ... and some questions on stackoverflow or this
>>> mailinglist just reflect that ...
>>> "please solve my issue for me, cause I forgot to use my brain today" :D
>>>
>>> regards, Achim
>>>
>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>
>>>> Serge,
>>>>
>>>> Package the world applications were able to be built easily before Docker
>>>> was around.  Docker is simply a different way of deploying an application
>>>> virtually.
>>>>
>>>> In my experience, developers who "package the world" with their code are
>>>> usually either biased against modularity or just don't feel like putting
>>>> forth the effort.  Many technologies in use today take effort to figure
>>>> out.  A lot of developers seem to feel that any technology that requires
>>>> effort above the maven shade plugin or using shell scripts to dump all
>>>> their jars to a server isn't worth their time.
>>>>
>>>> Developers that care about the quality of the code or applications they
>>>> produce won't be deterred from a technology they believe will help them
>>>> make better applications just because it takes a little bit of effort.  How
>>>> did less experienced developers manage to survive when the only real
>>>> choices for writing software was assembly, c or c++?
>>>>
>>>> Ryan
>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>>>>
>>>>> 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 <ni...@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 <fr...@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" <bc...@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 <fr...@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.zurczak@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
>>>>>>>>>
>>>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>>>>> <linkedin_16.png>
>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>>>>> <http://vzurczak.wordpress.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Apache Member
>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>> Committer & Project Lead
>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>
>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>
>>>>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>>> Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Ed Welch <ed...@edjusted.com>]

I've really enjoyed following this thread, and I have to say, as a Docker skeptic surrounded by people who want to bash my brains in with docker images, it's nice to hear some feedback from people who seem to have a healthy dose of skepticism like I do...

So rather than rehash all the things I agree with that have been said so far, I wanted to comment a few things I hadn't seen:

The biggest discussion point I bring up with my peers regarding docker that I've been using to kind of hold the floodgates back:  Who is responsible for updates to the underlying docker image OS?  Our organization is fairly segmented, we have a linux operations group, we have a development group.  If our development group deploys 50 docker images, all with a variety of distros inside them, different versions of everything... What happens if there is a big vulnerability found (think/remember bash).  Is our linux team now on the hook to learn docker and handle digging through dozens to hundreds of potentially very different docker images ( which would make you want to force standardization of your docker images on a particular distro at a minimum ), or does the dev team now own this responsibility?  This is a hard question for our company to answer...

My other comment, is actually regarding what I think is the most fantastic use case I've seen for docker, which was written up by Roland Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/ 
Using docker as part of your automated integration tests is a really neat idea, especially if you work on a project that has to maintain support for piles of application servers, operating systems, and versions of java.  I think there is some real opportunity here as was previously mentioned, to build a docker image that sets up the OS, java, and karaf, and then at test time you deploy your app and run your tests.  With this kind of model you can just keep adding new docker images to your test suite and retire old ones when you finally drop support for something ( *cough* java 6 *cough*)

Good discussion, really have enjoyed reading!

Ed


On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <fr...@gmail.com> wrote:

> I guess the barrier to be able to write code has been lowered enough that
> more people are able to do it, probably for the money.  That goes hand in
> hand with the whole Docker thing where it feels there is an expectation
> that everything should be easy to do rather than accept that like any
> profession, you have to learn in order to become good.  Nothing wrong with
> asking questions, but I feel quality of code will probably continue to
> decline with tools being the crutch.
> 
> Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
> software, I just wanted to make sure that things like Docker weren't going
> to cause it to be dumbed down.  Obviously like any growing technology,
> modularity has some rough spots to iron out, but that doesn't mean we
> should give up.  Developers can do what they want, I would like to continue
> to choose what fits my requirements best out of the technologies that are
> available.
> 
> Ryan
> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com> wrote:
> 
> > I can't agree more ... and some questions on stackoverflow or this
> > mailinglist just reflect that ...
> > "please solve my issue for me, cause I forgot to use my brain today" :D
> >
> > regards, Achim
> >
> > 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
> >
> >> Serge,
> >>
> >> Package the world applications were able to be built easily before Docker
> >> was around.  Docker is simply a different way of deploying an application
> >> virtually.
> >>
> >> In my experience, developers who "package the world" with their code are
> >> usually either biased against modularity or just don't feel like putting
> >> forth the effort.  Many technologies in use today take effort to figure
> >> out.  A lot of developers seem to feel that any technology that requires
> >> effort above the maven shade plugin or using shell scripts to dump all
> >> their jars to a server isn't worth their time.
> >>
> >> Developers that care about the quality of the code or applications they
> >> produce won't be deterred from a technology they believe will help them
> >> make better applications just because it takes a little bit of effort.  How
> >> did less experienced developers manage to survive when the only real
> >> choices for writing software was assembly, c or c++?
> >>
> >> Ryan
> >> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
> >>
> >>> 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 <ni...@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 <fr...@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" <bc...@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 <fr...@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.zurczak@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
> >>>>>>>
> >>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
> >>>>>>> <linkedin_16.png>
> >>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
> >>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
> >>>>>>> <http://vzurczak.wordpress.com>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Apache Member
> >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> >>>> Committer & Project Lead
> >>>> blog <http://notizblog.nierbeck.de/>
> >>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> >>>>
> >>>> Software Architect / Project Manager / Scrum Master
> >>>>
> >>>>
> >
> >
> > --
> >
> > Apache Member
> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> > Project Lead
> > blog <http://notizblog.nierbeck.de/>
> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> >
> > Software Architect / Project Manager / Scrum Master
> >
> >

Re: Karaf and Docker

[Ryan Moquin <fr...@gmail.com>]

I guess the barrier to be able to write code has been lowered enough that
more people are able to do it, probably for the money.  That goes hand in
hand with the whole Docker thing where it feels there is an expectation
that everything should be easy to do rather than accept that like any
profession, you have to learn in order to become good.  Nothing wrong with
asking questions, but I feel quality of code will probably continue to
decline with tools being the crutch.

Anyhow, thanks for everyone's input.  Karaf is a fantastic piece of
software, I just wanted to make sure that things like Docker weren't going
to cause it to be dumbed down.  Obviously like any growing technology,
modularity has some rough spots to iron out, but that doesn't mean we
should give up.  Developers can do what they want, I would like to continue
to choose what fits my requirements best out of the technologies that are
available.

Ryan
On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bc...@googlemail.com> wrote:

> I can't agree more ... and some questions on stackoverflow or this
> mailinglist just reflect that ...
> "please solve my issue for me, cause I forgot to use my brain today" :D
>
> regards, Achim
>
> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>
>> Serge,
>>
>> Package the world applications were able to be built easily before Docker
>> was around.  Docker is simply a different way of deploying an application
>> virtually.
>>
>> In my experience, developers who "package the world" with their code are
>> usually either biased against modularity or just don't feel like putting
>> forth the effort.  Many technologies in use today take effort to figure
>> out.  A lot of developers seem to feel that any technology that requires
>> effort above the maven shade plugin or using shell scripts to dump all
>> their jars to a server isn't worth their time.
>>
>> Developers that care about the quality of the code or applications they
>> produce won't be deterred from a technology they believe will help them
>> make better applications just because it takes a little bit of effort.  How
>> did less experienced developers manage to survive when the only real
>> choices for writing software was assembly, c or c++?
>>
>> Ryan
>> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>>
>>> 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 <ni...@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 <fr...@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" <bc...@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 <fr...@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.zurczak@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
>>>>>>>
>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>>> <linkedin_16.png>
>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>>> <http://vzurczak.wordpress.com>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Apache Member
>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>> Committer & Project Lead
>>>> blog <http://notizblog.nierbeck.de/>
>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>
>>>> Software Architect / Project Manager / Scrum Master
>>>>
>>>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: Karaf and Docker

[Achim Nierbeck <bc...@googlemail.com>]

I can't agree more ... and some questions on stackoverflow or this
mailinglist just reflect that ...
"please solve my issue for me, cause I forgot to use my brain today" :D

regards, Achim

2015-04-13 0:44 GMT+02:00 Ryan Moquin <fr...@gmail.com>:

> Serge,
>
> Package the world applications were able to be built easily before Docker
> was around.  Docker is simply a different way of deploying an application
> virtually.
>
> In my experience, developers who "package the world" with their code are
> usually either biased against modularity or just don't feel like putting
> forth the effort.  Many technologies in use today take effort to figure
> out.  A lot of developers seem to feel that any technology that requires
> effort above the maven shade plugin or using shell scripts to dump all
> their jars to a server isn't worth their time.
>
> Developers that care about the quality of the code or applications they
> produce won't be deterred from a technology they believe will help them
> make better applications just because it takes a little bit of effort.  How
> did less experienced developers manage to survive when the only real
> choices for writing software was assembly, c or c++?
>
> Ryan
> On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:
>
>> 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 <ni...@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 <fr...@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" <bc...@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 <fr...@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.zurczak@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
>>>>>>
>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>>> <linkedin_16.png>
>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7>
>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png>
>>>>>> <http://vzurczak.wordpress.com>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>> & Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[Ryan Moquin <fr...@gmail.com>]

Serge,

Package the world applications were able to be built easily before Docker
was around.  Docker is simply a different way of deploying an application
virtually.

In my experience, developers who "package the world" with their code are
usually either biased against modularity or just don't feel like putting
forth the effort.  Many technologies in use today take effort to figure
out.  A lot of developers seem to feel that any technology that requires
effort above the maven shade plugin or using shell scripts to dump all
their jars to a server isn't worth their time.

Developers that care about the quality of the code or applications they
produce won't be deterred from a technology they believe will help them
make better applications just because it takes a little bit of effort.  How
did less experienced developers manage to survive when the only real
choices for writing software was assembly, c or c++?

Ryan
On Apr 11, 2015 9:53 PM, "Serge Huber" <sh...@jahia.com> wrote:

> 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 <ni...@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 <fr...@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" <bc...@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 <fr...@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.zurczak@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
>>>>>
>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak>
>>>>> <linkedin_16.png>
>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> <skype_16.png>
>>>>> <callto://vincent.zurczak> <wordpress_16.png>
>>>>> <http://vzurczak.wordpress.com>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>

Re: Karaf and Docker

[Serge Huber <sh...@jahia.com>]

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 <ni...@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 <fr...@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" <bc...@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 <fr...@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 <vi...@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
>>>>>> 
>>>>>> <twitter_16.png> <linkedin_16.png> <skype_16.png> <wordpress_16.png>
>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>> 
>>> Software Architect / Project Manager / Scrum Master 

Re: Karaf and Docker

[Niels <ni...@gmail.com>]

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 <fr...@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" <bc...@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 <fr...@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 <vi...@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
>>>>> 
>>>>> <twitter_16.png> <linkedin_16.png> <skype_16.png> <wordpress_16.png>
>> 
>> 
>> 
>> -- 
>> 
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>> 
>> Software Architect / Project Manager / Scrum Master 

Re: Karaf and Docker

[Ryan Moquin <fr...@gmail.com>]

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" <bc...@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 <fr...@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.zurczak@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>
>>>>
>>>
>>>
>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: Karaf and Docker

[Achim Nierbeck <bc...@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 <fr...@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.zurczak@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>
>>>
>>
>>
>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[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 <fr...@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.zurczak@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

[Ryan Moquin <fr...@gmail.com>]

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.zurczak@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

[Vincent Zurczak <vi...@linagora.com>]

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>