Re: Runtime values in sti-php ini templates

[Erik Jacobs]

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 twitter:
> @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  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 twitter:
>>> @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

Re: Runtime values in sti-php ini templates

[Mateus Caruccio]

On Tue, Feb 2, 2016 at 9:51 PM, Ben Parees  wrote:

>
>
> On Tue, Feb 2, 2016 at 12:21 PM, Mateus Caruccio <
> mateus.caruc...@getupcloud.com> 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:
>>
>>
>> *mateus.caruc...@getupcloud.com twitter:
>> @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  wrote:
>>
>>>
>>>
>>> On Tue, Feb 2, 2016 at 2:39 AM, Honza Horak  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
>  >>
>
> 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]?

Re: Runtime values in sti-php ini templates

[Mateus Caruccio]

Exactly. I'm going to send a PR today. Just need to test it here.
Em 02/02/2016 05:39, "Honza Horak"  escreveu:

> 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)?
>
> 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
>> >
>> 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
>> 
>> twitter: @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
>>
>>
>>
>>
>> --
>> Ben Parees | OpenShift
>>
>>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Runtime values in sti-php ini templates

[Ben Parees]

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 <
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 twitter:
> @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
>
>


-- 
Ben Parees | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev