No, composer is just fine pulling its dependencies. The problem are packages not found on composer. Newrelic.so, for instance, must be installed by newrelic's own yum repo, thus it need to be inside the build image already.
*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 Wed, Feb 3, 2016 at 1:45 PM, Ben Parees <[email protected]> wrote: > > > On Wed, Feb 3, 2016 at 9:40 AM, Mateus Caruccio < > [email protected]> wrote: > >> 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. >> >> > Sorry, I did not understand the dependencies you were referring to were > coming from RPMs. No, it is not possible to install RPMs as part of the > assemble process, due to the root requirement. and yes, stashing the blobs > in the source repo would be undesirable as well. > > I was assuming you were referring to additional dependencies that would be > pulled in by composer. > > > > >> >> >>> >>> >>>> 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 >>> >>> >> > > > -- > Ben Parees | OpenShift > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
