Consider public use of Bref\Runtime\LambdaRuntime for containers who does not inherit from bref/php-?? images

[Maks3w]

TL;TR Consider public use of Bref\Runtime\LambdaRuntime for containers who does not inherit from bref/php-?? images

After check all those announcements around the possibility of use custom container images for Lambda, I've feel those examples are unnecessary complicated.

All those examples assume you should inherit from AWS Lamda images (public.ecr.aws/lambda/*) when the only thing those images provide is the Lambda RIE used for local development/testing.

I have wrote an small example (https://github.com/Maks3w/php-lambda-example) showing how it could be possible base your custom containers in the official PHP images and only install Lambda RIE for development.

I think this approach is more simple than others where you have to deal with the installation of PHP or you have more PHP extensions than you really need.

In fact the example shows there is less room for bref for this kind of deployment. However there is still a need for manage the Lambda payloads received and the return of the results. These things are well implemented by bref in Bref\Runtime\LambdaRuntime but this class is tagged as @internal what it means no forward guaranteed compatibility.

It could be possible to open Bref\Runtime\LambdaRuntime as a public class?

[mnapoli]

Hi, this is something I'm considering too.

But when I compare that to how easy it is with Bref now: https://github.com/brefphp/bref/releases/tag/1.2.0

FROM bref/php-80-fpm

# Add your code to the docker image
ADD . $LAMBDA_TASK_ROOT

# Set the Lambda "handler"
CMD [ "index.php" ]

So I'm not sure it's worth all the trouble.

Could you explain why not use the Bref images?

[Maks3w]

Yes of course. (Disclaimer, my reasons are totally subjective and does not represent a truth). Following reasons are related to container based deployment and not for Lambda Runtimes (Original bref implementation)

• Bref images depends on AWS Lambda images but the concept of lambda+containers means you are free to use any image from any source. So for me, PHP official images looks like a better option to inherit, another scenario is the use of a common image in the company or special hardening things. I really think is wrong to shift the origin of the image to Lambda instead of PHP

• Inline with the previous thing. What I think it's important is to be up-to-date with the latest language features/bugfixes and not to be up-to-date with the latest Amazon Linux 2. (Assuming OS level fixes are kept up-to-date by both providers). Also it work better with tools for autoupdate releases (like Dependabot feature for update Dockerfile FROM)

• The time for to have a PHP security fix ready for to be deployed should be less (and easier) since there are less actors in the deployment chain (Amazon Linux 2 compatibility, bref maintainers executing a new building cycle)

• With official PHP images I can keep fixed on minor PHP versions so my build is more reproducible across all the workstations and environments. With bref I cannot fix to an specific PHP versions, instead I've to use an image signature for to be sure every tool will build from the same source)

• It's easier to install additional extensions because there are lot of tutorials based on the PHP official image. For AL2 it may be harder because different libc versions or different packages names.

• PHP based images have less extensions enabled by default what I think is good because it aligns better with security principles like don't install what you don't need (Anyway, bref and PHP have their own opinions so I think this could be a tie)

• Inline with the previous comment. bref don't need to handle requests about to provide extra images for extra extensions or Could you install extension Foo-2030. Just rely to the official PHP documentation.

• Again, inherit from Lambda image is a waste for production images because the only purpose of that image is to provide Lambda RIE which is only useful for non AWS environments (mainly local development)

• I can place my files at any place of the image file system. I'm not forced to use /var/task neither /var/runtime/bootstrap

Resume: Inherit from bref derived image implies extra time for to have available a critical PHP security fix, or the latest version of PHP. I really appreciate your job, I think it's very good and you have dedicated a lot effort for to bring Lambda Runtime to PHP ecosystem, but since we can run our own containers the implementation and maintenance is from far more simple.

FROM php as production
# ...
ENTRYPOINT runtime/bootstrap.php

# Development
FROM production as development

# Copy Lambda RIE when it's needed. aka local development
COPY --from=public.ecr.aws/lambda/provided /usr/local/bin/aws-lambda-rie /usr/local/bin/aws-lambda-rie
ENTRYPOINT aws-lambda-rie runtime/bootstrap.php

So what is the place of bref for this kind of deployments? bref implements many nice features like:

• Dealing with the Lambda API implementation (Read the request, send the response)
• Typed handlers
• Implements a loop for avoid cold starts In fact, bref acts a as framework for deal with all those tiny details from Lambda and I would like to use bref as a helper but not as a runtime

[Maks3w]

One additional note:

I'm not arguing if bref/php-xx-xxx images should inherit from PHP images. Probably it never happen because for Lambda Runtimes is more important to rely on the Amazon Linux 2 subsystem rather of build things on Ubuntu or Alpine may fail to execute later.

The topic of this issue is to discuss if bref should give support (and forward compatibility) for custom container scenarios who are not based on bref/php-xx-xxx images.

[Maks3w]

Another note:

On 4th of february (6 days ago) new minor versions were released for every supported PHP version but Bref images still based on the previous minor versions

[mnapoli]

Hey, sorry for the delay.

So, first, I agree with you now. I think this is a sensible direction to go and will provide more flexibility to users.

One thing to note is that the runtime requires specific PHP extensions, and we can't require those in composer.json because we don't need them in development. So far we've been in control of the production environment, and we won't anymore. I think we should document that clearly, basically:

If you use bref runtimes/images, all good. If you don't, it's up to you to make sure you're doing things correctly.

Now comes the question of how to make that happen 🤔 I think I'll need to take a day or two to work properly on this, and I'm not sure when I'll have the time in the near future. But at least we know where to go from here.

[Maks3w]

I'm glad to help if you see feasible.

About the specific extensions I'm not sure what extensions do you mean. For the basic functionality, message interchange between AWS and Docker with the curl extension seems enough and it is already required in composer.json.

For the long term I guess two different projects may have sense, one focused on the common part and another one focused on the Lambda layers. Anyway I'm ok if LambdaRuntime could be consider for public use and then add documentation about that (If you think is enough stable)

[mnapoli]

One other problem is exposing the bootstrap scripts, those are currently trimmed from releases. I don't have a clear vision yet on these parts TBH.

[Sh1d0w]

Hey @mnapoli

Is there any progress on this issue? Recently I've tried to use Bref to deploy our Dusk load test to Lambda so we can have scalability. The only problem is we can't install google chrome and make it work under lambda/provided docker image.

That's why we need to use another base image as the OP suggested. Would be great if we could easily integrate Bref in such case.

[deleugpn]

@Sh1d0w Have you considered pulling Google Chrome from an additional layer?

[Sh1d0w]

@deleugpn Yes, I've compiled a layer that provides headless chrome binary and the chrome driver at pinned version, the case is that both things are 180 MB and Lambda has limit of 250 MB size, which is exceeded when I deploy the code with the vendor directory.

So the only option is to use docker images which has 10 GB size limit.

[mnapoli]

Hey everyone! I haven't forgotten about this :)

In Bref 2, this will now be possible, and be actually simpler. The 3 different runtimes (fpm, function and console) now have each a public API, though slightly different from what was discussed here (i.e. that's what I mean by simpler).

FPM

I actually moved the FPM runtime to a separate repository (https://github.com/brefphp/php-fpm-runtime), and its main entrypoint (bootstrap.php) is now a public API.

In short, run vendor/bref/php-fpm-runtime/src/bootstrap.php.

Function

Require bref/bref and run Bref\FunctionRuntime\Main::run().

Function

Require bref/bref and run Bref\ConsoleRuntime\Main::run().

---

Let me know if that doesn't cover your needs!