Nick,
I've used the profiles and they work well. After the Maven plugin runs you end up with a zip file that has karaf and all its dependencies self-contained. As Guillaume notes the Karaf is slimmed down by removing those services. But if one is compiling and zipping the whole Karaf container with dependencies then installs as features really aren't needed. It also will make black box testing of the resulting artifacts that much easier. If you look, for example, at the zip file that's created you can see how small they are even with dependencies. https://github.com/Ranx0r0x/Panda-Vault/tree/master/sample%20zip I really think this could be huge if it gets standardized and standard integration Karaf appliances get created. I'd certainly hop on board and help develop those. Brad From: Nick Baker [mailto:[email protected]] Sent: Thursday, January 12, 2017 6:45 AM To: user <[email protected]> Subject: Re: Levels of Containerization - focus on Docker and Karaf Thanks Guillaume! This is perfect for our microservice/containerized Karaf. I'll give this a try and see if we can get our features in startup. We've had issues in the past here. -Nick Baker _____ From: Guillaume Nodet <[email protected] <mailto:[email protected]> > Sent: Thursday, January 12, 2017 5:55:24 AM To: user Subject: Re: Levels of Containerization - focus on Docker and Karaf Fwiw, starting with Karaf 4.x, you can build custom distributions which are mostly static, and that more closely map to micro-services / docker images. The "static" images are called this way because you they kinda remove all the OSGi dynamism, i.e. no feature service, no deploy folder, read-only config admin, all bundles being installed at startup time from etc/startup.properties. This can be easily done by using the karaf maven plugin and configuring startupFeatures and referencing the static kar, as shown in: https://github.com/apache/karaf/blob/master/demos/profiles/static/pom.xml 2017-01-11 21:07 GMT+01:00 CodeCola <[email protected] <mailto:[email protected]> >: Not a question but a request for comments. With a focus on Java. Container technology has traditionally been messy with dependencies and no easy failsafe way until Docker came along to really pack ALL dependencies (including the JVM) together in one ready-to-ship image that was faster, more comfortable, and easier to understand than other container and code shipping methods out there. The spectrum from (Classical) Java EE Containers (e.g. Tomcat, Jetty) --> Java Application Servers that are containerized (Karaf, Wildfly, etc), Application Delivery Containers (Docker) and Virtualization (VMWare, Hyper-V) etc. offers a different level of isolation with different goals (abstraction, isolation and delivery). What are the choices, how should they play together, should they be used in conjunction with each other as they offer different kinds of Containerization? <http://karaf.922171.n3.nabble.com/file/n4049162/Levels_of_Containerization. png> -- View this message in context: http://karaf.922171.n3.nabble.com/Levels-of-Containerization-focus-on-Docker -and-Karaf-tp4049162.html Sent from the Karaf - User mailing list archive at Nabble.com. -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] <mailto:[email protected]> Web: http://fusesource.com <http://fusesource.com/> Blog: http://gnodet.blogspot.com/
