Customizing php.ini

[mdegrees]

Will there be support for php.ini customization? I'm specifically looking to set session handler to redis store. Thank you.

[ties-v]

I think it is a nice one to add to the roadmap, especially for use cases like you just mentioned.

And as always, if you would like, open a PR with this feature 😉

[mdegrees]

Awesome! Sure, I'll try to get my head around the code base and see if I can do that.

[f3l1x]

Hi guys. I like the idea. Could you please elaborate about the configuration?

• Should we put it into the special file? Like php.ini? Should it be in the root folder?
• Or should we put it into the now.json? Only a few override items will be there right?

[mdegrees]

Wow I was just about to post this:

The three options I can think of:

1. Enabling the user to add a php.ini file that will co-live with now.json. When factoring in the user php.ini, we import the directives that are overridable and silently ignore the ones that are not.
2. Enabling the user to add a php.ini again at the root level but this time only with supported directives. For example session.save_handler , session.save_path ...
3. Doing 2 but instead of the user including a php.ini, adding php.ini directive to now.json. something like

{
  "version": 2,
  "builds": [
    {
      "src": "index.php",
      "use": "now-php@canary",
      "config": {
        "composer": true,
        "php.ini": {
          "session.save_handler": "redis",
          "session.save_path": "tcp://127.0.0.1:6379"
        }
      }
    }
  ]
}

I'm in favor of the option 3 to keep everything in one place. I think something like this https://github.com/npm/ini can help a lot.

[ties-v]

In a "normal" *nix environment, you usually extend configuration files by adding multiple files in a conf.d directory. With this in mind I think it is nice to let the user (as in the developer using this builder) write one (or multiple?) php.ini files and points to the file(s) in now.json. A php.ini file in the same directory as now.json is set as default "zero-config" value.

Also, I don't think it is needed to filter only "supported" directives, as they need to be updated with every extension update. The user probably notices from the build process if they entered some non supported value.

I'm not convinced about putting the directives directly in now.json as this can get quite big fast. A simple .ini file somewhere in the project seems nicer because it is clear what it does and works like any other php.ini file.

If you have other opinions and/or insights, please share them 😊

[mdegrees]

I'm not convinced about putting the directives directly in now.json as this can get quite big fast. A simple .ini file somewhere in the project seems nicer because it is clear what it does and works like any other php.ini file.

This makes total sense. Similar to what docker-compose.yml does with the Dockerfile. it looks neat.
I'm not yet clear though on how a user can add extensions and how this will play out with php.ini. Can you please shed some lights on how the workflow would look like for someone wanting to add an extension, php7-gd for example.

[ties-v]

I think adding extensions a different problem. As I have understood so far @f3l1x added as much extensions as he could to this builder. Maybe in the future there will be ways to specifically select which ones you want in your builder (or by composer.json?) This can make the resulting lambda smaller (= faster cold starts).

But for now if someone whats to add an extension, I guess they have to create a PR with the binary (which is not safe because there could be anything in it 😐, so maybe a build folder for all the extensions and tools needs to be added to this repository. Also makes updates easier i guess.)

[mdegrees]

@ties-v oh I see. I think this a Lambda related problem. Having to supply a binary artifact makes things hard to customize. This is what I miss about Docker 🙃. I did some digging though and found this: https://github.com/awslabs/aws-lambda-container-image-converter . Apparently we can convert a Docker image to a Lambda binary 🤯. This will solve all the customization problems (giving that the input is a Docker file). But I'm still thinking of how this could be mashed up with now-php.

[f3l1x]

I have copy&paste already build PHP modules+libs by my self.

https://github.com/juicyfx/now-builders/tree/master/src/php-lib

Still thinking about to take to this repo or separate to solo repository. Maybe others can build a layer from this builded php.

I like awslabs/aws-lambda-container-image-convert, @Malihs, can you please test it how it works?

[mdegrees]

@f3l1x have you seen this example? https://github.com/awslabs/aws-lambda-container-image-converter/tree/master/example :

Basically they're using Docker to build a php runtime that would work along with the current lambda OS (amazonlinux:2018.03.0.20190514). The Docker image runs composer and a handler file. Interestingly enough, instead of using a phpDevServ, they're using Guzzle to manage HTTP.

php.ini might be factored in simply by copying it to /etc/php/ . With something like: COPY path/to/local/php.ini /etc/php7/php.ini. Here is an example of how I do it https://github.com/malihs/alpine-php7-fpm-apache/blob/master/Dockerfile

The built up image could be run locally (docker should be installed on the machine) .
If you run the built up image with img2lambda: the runtime get extracted form the docker image and get publish to lambda.

hope this makes it clearer. I was about to reproduce this locally but we decided to steer away from Now Monorepo for the time being.

[calebporzio]

Hi everyone, great work on this btw!

I need to be able to set things in php.ini for my app to work (some of the options don't work with ini_set).

I personally would love just a simple way to set php.ini options in now.json. That way there is only 1 file now is concerned with. All my now-specific env settings and php.ini options would live there.

[f3l1x]

I'm thinking also about some option in now.json. Can you please show me what kind of php.ini do you need to override? I would like to setup now-php for most cases.

[f3l1x]

@mdegrees @calebporzio @ties-v Can you please test it? #17

[f3l1x]

{
    "version": 2,
    "name": "now-php-ini",
    "scope": "juicyfx",
    "regions": [
        "all"
    ],
    "public": true,
    "builds": [
        {
            "src": "*.php",
            "use": "now-php@experimental",
            "config": {
                "php.ini": {
                    "memory_limit": "128M",
                    "post_max_size": "32M"
                }
            }
        }
    ],
    "build": {
        "env": {
            "NOW_PHP_DEBUG": "1"
        }
    }
}

[mdegrees]

@f3l1x working like a charm, thank you!

[calebporzio]

Sorry, I didn't get back to you sooner. Thanks @f3l1x - you're the man!