On Tue, Feb 2, 2016 at 9:51 PM, Ben Parees <[email protected]> wrote:
> > > On Tue, Feb 2, 2016 at 12:21 PM, Mateus Caruccio < > [email protected]> wrote: > >> 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. >> >> > well i'd expect those dependencies to also be defined by the source repo > that was including the template ini file. > > > Doesn't it breaks security for non-root pods? Is it even possible to install RPMs on runtime if restricted scc is enforced? IMHO the best way to allow for custom modules is through rpm/yum. It seams to me that blobs on a source repo is way too ugly. I'm thinking on a more simple scenario, where users are enabled to provide custom configs for already-available containers. > > >> 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). >> >> > fair enough, processing at run/startup is ok with me, given that that's > what the existing run script is doing anyway. > > > > >> 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. >> >> > There are lots of options, mustache is a popular one for example, but i'm > reluctant to make the PHP image dependent on a particular templating > language if we can avoid it. Those discussions tend to break down into > religious wars over which templating framework should be anointed. > > > Agree. The number of template engines are too damn high! Please note that PHP itself can be used as a template engine. In the end, php IS a template engine. BTW, each lang has some kind of standard template system. Maybe it could be better if we stick with it, i.e. php for php, jinja2/django for python/django, erb for ruby, "whatever" for nodejs. All of them are able to substitute env vars and provide some level of control blocks. > > >> 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 >>> >>> >> > > > -- > Ben Parees | OpenShift > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
