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