Hi Christian,
Environment variables are indeed the way to go. Using for example Amdatu
Configurator (http://amdatu.org/components/configurator.html
<http://amdatu.org/components/configurator.html>) you can create property files
(or metatype xml) that contain variables. For example:
mykey=${some_env_var}
Variables are replaced by environment variables. So with the example above you
could pass in an override "docker run -e some_env_var=somevalue ..."
Cheers,
Paul
> On 03 Jun 2016, at 10:33, Christian Schneider <[email protected]> wrote:
>
> I am currently looking into making OSGi projects deployable as docker images.
>
> For the plain deployment I already found some good solutions:
> - bndtools allows to package an application as a self contained jar. This can
> then be put into a docker image
> - A karaf custom distro can also be packaged as a docker image nicely. The
> static profile allows to even omit the feature service
>
> In both solutions though configuration is not nicely supported in a style
> suitable for docker.
>
> It is of course easy to supply config for karaf by putting configs into the
> etc dir when doing the custom distro. The problem is only how to allow
> overrides from the docker side.
> Bndtools or more precisely enroute allows to define default configs as magic
> property files in a bundle and can use an extender to apply these.
>
> The typical approach in docker and docker compose seems to be to use env
> variables and system properties.
> I wonder if we could support that better by allowing to override any config
> admin config.
>
> For an env var or system property something like this might do:
> cm:<pid>:<key>=value
>
> So the files could contain the defaults and env and system properties could
> override them. Does that make sense? Do we already have other options that I
> am missing?
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
