That will not work as the assemble script runs as non-root so it can't copy files into /
On Thu, Feb 4, 2016 at 5:41 PM, Mateus Caruccio < [email protected]> wrote: > Yeah, that's exactly the use case I'm talking about. > Since there's .sti/environment, it seams to me a natural path to have > .sti/templates/ containing a mirror-like tree, i.e. everything inside > .sti/templates/<tree> becomes /<tree> inside the container. > > > > *Mateus Caruccio* > Master of Puppets > +55 (51) 8298.0026 > gtalk: > > > *[email protected] <[email protected]>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 2:32 PM, Erik Jacobs <[email protected]> wrote: > >> 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: [email protected] >> AOL Instant Messenger: ejacobsatredhat >> Twitter: @ErikonOpen >> Freenode: thoraxe >> >> On Thu, Feb 4, 2016 at 8:23 AM, Mateus Caruccio < >> [email protected]> 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: >>> >>> >>> *[email protected] <[email protected]>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 <[email protected]> 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: [email protected] >>>> AOL Instant Messenger: ejacobsatredhat >>>> Twitter: @ErikonOpen >>>> Freenode: thoraxe >>>> >>>> On Mon, Feb 1, 2016 at 4:43 PM, Mateus Caruccio < >>>> [email protected]> 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: >>>>> >>>>> >>>>> *[email protected] <[email protected]>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 >>>>> [email protected] >>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>>>> >>>>> >>>> >>> >> > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
