Hi Mateus, At this time each image kind of handles this differently, as best I can tell. For example, the JBoss EAP image will look for settings.xml in the code repository and substitute that instead of the built-in one (over-simplifying).
The issue is how you would do this in some kind of "generic" way. EG: how do I inform any builder image that it should place file X from the code repository into location Y, possibly creating a directory (eg: mkdir -p) in the process... Would you say the following user story is accurate? As a user/developer with OpenShift I want to place a (config) file in my source code repository And through some mechanism tell the S2I process to place this file in a specific location Env vars would be the "values" of the config options, as opposed to the config itself, I would think. For example, the "custom config mechanism" might allow you to put a foo.ini file in a specific location, and that file might contain a GETENV-type reference which would be substituted by an env var of CONFIG_VALUE_FOO_THING=BLAH Is that all an accurate assessment? Erik M Jacobs, RHCA Principal Technical Marketing Manager, OpenShift Enterprise Red Hat, Inc. Phone: 646.462.3745 Email: ejac...@redhat.com AOL Instant Messenger: ejacobsatredhat Twitter: @ErikonOpen Freenode: thoraxe On Thu, Feb 4, 2016 at 8:23 AM, Mateus Caruccio < mateus.caruc...@getupcloud.com> wrote: > Hi Erik. > > That may work, but it won't be able to substitute runtime env vars. Also, > it adds an extra step for something that should be simple: custom configs. > The point here is not my specific use case. I'm looking now for a more > generic way to allow users to define/overwrite container config in a user > friendly way, like a simple file placed in a predetermined place inside the > code repository. > > The I see now is what could be used as a simple template engine, that adds > little or no impact on already available docker images. > > Regards, > > > *Mateus Caruccio* > Master of Puppets > +55 (51) 8298.0026 > gtalk: > > > *mateus.caruc...@getupcloud.com <diogo.goe...@getupcloud.com>twitter: > @MateusCaruccio <https://twitter.com/MateusCaruccio>* > This message and any attachment are solely for the intended > recipient and may contain confidential or privileged information > and it can not be forwarded or shared without permission. > Thank you! > > On Thu, Feb 4, 2016 at 12:50 AM, Erik Jacobs <ejac...@redhat.com> wrote: > >> Hi Mateus, >> >> Maybe I'm misunderstanding the problem, but would the secrets mechanism >> not work for this? You could have the ini file be a secret which would be >> attached/mounted into the pod at run-time and could be in that folder as an >> .ini file... I think? >> >> Ben? >> >> >> Erik M Jacobs, RHCA >> Principal Technical Marketing Manager, OpenShift Enterprise >> Red Hat, Inc. >> Phone: 646.462.3745 >> Email: ejac...@redhat.com >> AOL Instant Messenger: ejacobsatredhat >> Twitter: @ErikonOpen >> Freenode: thoraxe >> >> On Mon, Feb 1, 2016 at 4:43 PM, Mateus Caruccio < >> mateus.caruc...@getupcloud.com> wrote: >> >>> Hi. >>> >>> I need to run newrelic on a php container. Its license must be set >>> from >>> php.ini >>> or >>> any .ini inside /etc/opt/rh/rh-php56/php.d/ >>> . >>> >>> >>> The problem is it need >>> s >>> to be set on run time, not build time because the license key is stored >>> in >>> a >>> n >>> env var. >>> >>> What is the best way to do that? >>> Wouldn't be good to have some kind of template processing like [1]? >>> Something like this: >>> >>> for tpl in $PHP_INI_SCAN_DIR/*.template; do >>> envsubst < $tpl > ${tpl%.template} >>> done >>> >>> There is any reason not to adopt this approach? Is it something origin >>> would accept as a PR? >>> >>> [1] >>> https://github.com/openshift/sti-php/blob/04a0900b68264642def9aaea9465a71e1075e713/5.6/s2i/bin/run#L20-L21 >>> >>> >>> *Mateus Caruccio* >>> Master of Puppets >>> +55 (51) 8298.0026 >>> gtalk: >>> >>> >>> *mateus.caruc...@getupcloud.com <diogo.goe...@getupcloud.com>twitter: >>> @MateusCaruccio <https://twitter.com/MateusCaruccio>* >>> This message and any attachment are solely for the intended >>> recipient and may contain confidential or privileged information >>> and it can not be forwarded or shared without permission. >>> Thank you! >>> >>> _______________________________________________ >>> dev mailing list >>> dev@lists.openshift.redhat.com >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>> >>> >> >
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
