Allow application to specify PHP-FPM configuration

[Nyholm]

From #593, the idea was first to allow the user to configure php fpm by themselves. A directive like include=/var/task/php/fpm/conf.d/*.conf was added.

That failed because the user had to specify php/fpm/conf.d/ in their applicaiton or php fpm would fail to start.

This issue want to discuss how to move forward with this feature.

Solution A.

Specify include=/var/task/bref-php-fpm.conf. This requires the user to have bref-php-fpm.conf in the root of their project.

Solution B.

Specify include=/opt/bref/fpm/conf.d/*.conf and also create that folder. We also create a "extra exptension" that writes to that folder and add include=/var/task/php/fpm/conf.d/*.conf

Then we can allow people to "opt-in" to create php/fpm/conf.d/ in their applicaiton.

Solution C

???

[markomitranic]

Hey, good thing you opened up a new issue for this. Ok, so i am not an expert on bref and would like to hear from someone who is, but this is a common issue when containerizing php.

The way we usually solve it is by always forcing the creation of conf.d folder during build. Bear in mind that an empty folder hurts no one, so no opt-in/out mechanism is required.

RUN mkdir -p /var/task/fpm/conf.d/ And specify an import for this folder.

In this case, we would usually have a folder that holds multiple config files, for ease of use. For example fpm folder would contain pool.conf, logging.conf, fpm.conf. Since we are importing the whole folder, this gives a large amount of freedom to the user. Same foes for php ini files.

Option 2 that is commonly used (but i am unsure if it is applicable with bref) is to provide an empty (.gitkeep) conf.d folder in the current build context that would always be copied into the layer during build, even if it is empty. The result is basically the same as above, but allows for easier use in some cases.

Some containers opt to do stuff like this within the entrypoint.sh, after the build, when the mounted volumes are available, before starting fpm. I am unsure if this is applicable to bref at all, since lambda is not writeable from the inside afaik.

[mnapoli]

@markomitranic I see, that makes sense indeed.

However with Bref and how projects are setup, that means users have to create that empty directory in their projects (their git repository). This is the "Option 2" you mentioned, and fits "Solution A" from Nyholm's post. I don't think this is a viable solution, it has too much impact on users and their projects :/

And yes, since /var/task is readonly there is no way for Bref to automatically create it at runtime.

Solution B could work, but has an extra-step too complicated I would say.

Solution C ?

Just having include=/opt/bref/fpm/conf.d/*.conf, and we can encourage users to create their own layer (instead of providing one).

Creating a layer is not that hard with serverless.yml (https://serverless.com/framework/docs/providers/aws/guide/layers/):

functions:
    hello:
        handler: hello.php
        layers:
            - # bref layer here ...
            - { Ref: php-fpm-config }
layers:
    php-fpm-config:
        path: php/fpm

(I haven't tested though, it is just to illustrate)

[Nyholm]

@markomitranic What you are saying make sense. But AWS has restrictions. A (Bref) layer can only write in the /opt folder. And applications are placed on the /var/task folder.

C):

Oh, i did not know about that. That is definitely something we should test and move forward with.

[markomitranic]

@mnapoli as far as i see, creating a layer is as simple as doing a multipart container build. In which case, we only need to provide the include, and an empty folder in a location of our choosing, and the users can do the rest themselves. That sounds very good.

[mnapoli]

I'll close this issue to provide some clarity (since it's been open for more than 2 years): this isn't a feature that is in the roadmap.

The best solution might be to create an AWS Lambda layer to override the existing file.

Feel free to revive the discussion if you have a use case you want to share here!