This could lead to an issue since most .ini files depend on some module to be available, newrelic.so in my case. Simply processing templates with no way to install modules my not suffice.
In my case i've create an sti-php-extra[1] docker image with a bunch of new modules (in fact, only one for now). On the other hand it may be useful for users to provide custom template files from their source repo. I believe it must be processed by s2i/bin/run instead assemble because it may depende on environment variables available only on runtime (think on an api key, which is much easier to set and use than a secret). For example, there could be a dir structure from source repo reflected inside de pod: (repo) .sti/templates/etc/php.d/mymodule.ini.template -> envsubst -> (pod) /etc/php.d/mymodule.ini BTW, does anyone known of more flexible template processing engine that could fit for docker images? Something capable to understand conditionals. Thoughts? [1] https://github.com/getupcloud/sti-php-extra (still outdated) *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 Tue, Feb 2, 2016 at 12:50 PM, Ben Parees <[email protected]> wrote: > > > On Tue, Feb 2, 2016 at 2:39 AM, Honza Horak <[email protected]> wrote: > >> It seems fine to me as well, we need to make the images extensible. >> >> I'd just like to make sure I understand the use case -- that would mean >> you'd add a file like /etc/opt/rh/rh-php56/php.d/newrelic.ini.template >> (using bind-mount or in another layer)? >> >> > I wouldn't expect it to be a bindmount or additional layer. I'd expect > "newrelic.ini.template" would be supplied via the source repository that > was being built, and the assemble script should copy the source-supplied > templates into an appropriate location and then process them. (or process > them into the appropriate location). > > so this file would not be a part of the php56 image. > > > >> Also adding Remi to comment on this. >> >> Honza >> >> On 02/02/2016 12:54 AM, Ben Parees wrote: >> >>> I think that sounds reasonable, i'd be inclined to accept it as a PR. >>> Adding Honza since his team technically controls the PHP image now (5.6 >>> anyway). >>> >>> >>> On Mon, Feb 1, 2016 at 4:43 PM, Mateus Caruccio >>> <[email protected] <mailto:[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] >>> <mailto:[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] <mailto: >>> [email protected]> >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>> >>> >>> >>> >>> -- >>> Ben Parees | OpenShift >>> >>> > > > -- > Ben Parees | OpenShift > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
