I’m not sure you understand the difference between config admin and a management agent. IMO you are asking for a different management agent than the one Karaf usually uses.
So far I’ve proposed two sorts of environment-variable aware management agents: - property substation into something like property files. This might be appropriate if the configurations needed for OSGI have a lot of stuff that doesn’t need to be configured per-docker-instance - interpreting environment keys into pid + configuration key. This might be appropriate if all the information needed for OSGI should be configured per-docker-instance Obviously there are a lot of other possible approaches. Figuring out how this might interact with the configurator spec proposed for R7 might be a good idea too. Once you’ve decided what you want the management agent to do, writing it and assembling a karaf using it is pretty easy. I’m assuming that whoever does this is going to contribute it to Karaf and that since it’s obviously a good idea it will get included in some form. If I understand Elliot Metsger’s posts correctly karaf already supports the property substitution approach. What specifically do you want different from what’s already working? david jencks > On Jan 13, 2017, at 2:01 PM, Dario Amiri <dariusham...@hotmail.com> wrote: > > You should not have to build a new docker container image for every possible > type of configuration. Just look at any standard docker images in the public > Docker registry. All configuration is driven from the environment variables. > There is a multitude of examples in the public docker registry. > > A new implementation of ConfigurationAdmin sounds like a good way to solve > the problem. However, I don't have the expertise to build and maintain that > on my own. Nor should I because this is an ubiquitous pattern for all > Dockerized applications. Karaf should do this out of the box if it wants to > play well with Docker. > > Zookeeper is great, but what about the coordinates to Zookeeper? Where do I > configure that? We're back to the same problem. Also, Zookeeper is likely too > heavy a solution for some people (me included). > > D > > On 01/13/2017 01:13 PM, Nick Baker wrote: >> Injecting configuration into a containerized app (docker) is considered >> standard practice. The friction here is the level of sophistication in OSGI >> Configuration. >> >> It seems to me what you need isn't some hack to push configurations through >> environment variables, but a new implementation of ConfigurationAdmin, or an >> agent which interacts with CM mirroring configurations in from an external >> system. >> >> In our usage it's common to have a "tenant", think Walmart vs Target. >> Setting the tenant ID as an environment variable then having the >> configurations loaded from Zookeeper or whatever, injected into CM seems >> right. >> >> -Nick >> From: Dario Amiri <dariusham...@hotmail.com> >> <mailto:dariusham...@hotmail.com> >> Sent: Friday, January 13, 2017 3:21:17 PM >> To: user@karaf.apache.org <mailto:user@karaf.apache.org> >> Subject: Re: Levels of Containerization - focus on Docker and Karaf >> >> Let me expand on why this is desirable. Without the ability to set >> configuration through environment variables, I essentially have to create a >> docker image for each deployment. I have a root Dockerfile which assembles >> the main Karaf container image and brings in dependencies such as the JRE, >> then I have a Dockerfile for each deployment environment which builds on top >> of the root image by overriding deployment specific configuration. >> Automation reduces this burden but it is not ideal. >> If I could set the contents of a config file in an environment variable, I >> could just pass the configuration directly to my root karaf docker image >> without having to build on top of it. >> >> Being able to start Karaf as "java -jar karaf.jar" is desirable because it >> makes it easier to use a Karaf based application with PaaS such as Heroku >> and Cloud Foundry. >> D >> >> On 01/13/2017 12:10 PM, Dario Amiri wrote: >>> Ideally, I want to be able to do: >>> java -jar my-karaf.jar >>> And I can override individual configuration files using some environment >>> variable convention. >>> D >>> >>> On 01/13/2017 11:56 AM, Brad Johnson wrote: >>>> Does it have to be an executable jar file or just a standalone executable? >>>> The static profiles actually create and zip up a full >>>> Karaf/felix/dependency/application implementation that when unzipped has >>>> all the standard bin directory items. >>>> >>>> Brad >>>> >>>> From: Dario Amiri [mailto:dariusham...@hotmail.com >>>> <mailto:dariusham...@hotmail.com>] >>>> Sent: Friday, January 13, 2017 1:28 PM >>>> To: user@karaf.apache.org <mailto:user@karaf.apache.org> >>>> Subject: Re: Levels of Containerization - focus on Docker and Karaf >>>> >>>> I use Docker and Karaf. I've never had a problem creating a Docker image >>>> of my Karaf container. What I gain is freedom from having to worry about >>>> dependency related issues such as whether the right JRE is available. >>>> >>>> That being said there are some challenges when using Karaf to build >>>> 12-factor apps. FWIW here's my two item list of what would make Karaf a >>>> more attractive platform from a 12-factor app perspective. >>>> >>>> 1. The ability to inject Karaf configuration through the environment (e.g. >>>> environment variables). Not just a single property, but an entire config >>>> admin managed configuration file if necessary. Even the existing support >>>> for reading property values from the environment is cumbersome because it >>>> requires having to setup that relationship as a Java system property as >>>> well. >>>> 2. The ability to package Karaf as a standalone runnable jar. Looks like >>>> Karaf boot is addressing this. I hope it comes with tooling that makes it >>>> easy to transition to this kind of model. >>>> >>>> D >>>> >>>> On 01/12/2017 04:44 AM, Nick Baker wrote: >>>> 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 <gno...@apache.org> <mailto:gno...@apache.org> >>>> 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 >>>> <https://github.com/apache/karaf/blob/master/demos/profiles/static/pom.xml> >>>> >>>> >>>> 2017-01-11 21:07 GMT+01:00 CodeCola <prasen...@rogers.com >>>> <mailto:prasen...@rogers.com>>: >>>> 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 >>>> >>>> <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>http://karaf.922171.n3.nabble.com/Levels-of-Containerization-focus-on-Docker-and-Karaf-tp4049162.html >>>> >>>> <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: <mailto:gno...@redhat.com>gno...@redhat.com >>>> <mailto:gno...@redhat.com> >>>> Web: http://fusesource.com <http://fusesource.com/> >>>> Blog: http://gnodet.blogspot.com/ <http://gnodet.blogspot.com/> >>>> >>>> >>> >> > >
