Thanks for the Docker info. You’re looking for a management agent, not a different config admin. I suggested one, it would also be easy to write one that used suitably encoded keys for environment variables to construct configurations e.g. <pid>.<configkey>=<value>. Not knowing how much of the configuration one might want to supply in environment variables, or how many values might be reused in many places, I assumed this would be less convenient to use than substituting a few values into larger files. My point is intended to be that it’s not hard to write a management agent, especially after you’ve decided what you want it to do.
david jencks > On Jan 13, 2017, at 1:13 PM, Nick Baker <nba...@pentaho.com> 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> > Sent: Friday, January 13, 2017 3:21:17 PM > To: 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/> >>> >>> >> > >
