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é <[email protected]>: > 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 <[email protected]> >> 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" <[email protected]> >>> 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 <[email protected]>: >>>> >>>> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> >>>>>> 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 <[email protected]>: >>>>>>> >>>>>>> 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 <[email protected] >>>>>>>> > >>>>>>>> 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 < >>>>>>>>> [email protected]> 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é > [email protected] > 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
