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.
​



> 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.

​



> 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

Reply via email to