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