How does one add PHP extensions to the docker-compose.yml configuration that comes with Laravel Sail?

Question

I created a new Laravel 8 project, which comes with Laravel Sail, a pre-configured Docker environment. It works well, until I need to use a PHP extension.

The Laravel Sail documentation does not appear to mention anything about PHP extensions, which is a significant problem. Any non-trivial PHP site has to use several PHP extensions. Without the ability to add PHP extensions, Laravel Sail (or any other PHP environment) is more or less useless.

There's a Dockerfile and a php.ini in vendor/laravel/sail/runtimes/8.0/. I could copy those files out of vendor and into my own project's code, and hack the docker-compose.yml to point to my versions of those files. However, if I do that, I'll lose any future fixes or improvements that the Laravel Sail people make to those files.

I'm aware of the sail artisan sail:publish command that they mention at the end of the Laravel Sail documentation (https://laravel.com/docs/8.x/sail#sail-customization). It seems to just do what I mentioned above: copies the third-party code into my project, and now suddenly this end-user website is responsible for maintaining its own copy of Laravel Sail.

Surely there's an idiomatic way to add PHP extensions in Laravel Sail, without re-implementing a fork of Laravel Sail in my site's code?

Podolsk

What is expected behavior after restarting container? Is extension supposed to "survive" container restart? And how exactly would you like to achieve having possibility to install PHP extension in your docker container and persist it without rebuilding container locally? I asked these question because I believe the only way is to take care of your Dockerfile and do with it what you need, therefore build image yourself and if you need it yourself, you should upload it to docker registry. – Dreadfully

The extension survives the container restart. It has to. If it doesn't, then the container isn't useful for developing the site that uses these extensions. It's not reasonable to expect a developer to connect to the machine and manually install the extensions, every time they restart the container, because the whole point of Docker is to avoid that kind of manual machine configuration. With my current, hacky solution outlined above, this works. – Podolsk

I am building the image myself, currently. I understand that using a Docker image requires you to build it first. That's not what I'm trying to avoid. What I'm trying to avoid is bringing Laravel Sail's Dockerfile into my project, and therefore making the developer of my end-user website responsible for maintaining this fork of Laravel Sail. It's third-party code, so it belongs in the vendor directory. The sail artisan sail:publish solution that I'm using works, but it pollutes this website's code with third-party code that should be in vendor. – Podolsk

Yup, I see your point. I have Dockerfiles in separate repo, rebuild them when extension is added and push to a docker registry (either Docker hub, private gitlab repo or whatever you like). sail artisan sail:publish is there just to give you the files, do with it whatever you want. If someone decides to keep them with application, its their choice, but its better to separate them as you pointed out. – Dreadfully

I wrote: "Is extension supposed to "survive" container restart?" But it was wrong question, better would be: "Is extension supposed to "survive" container removal?" because this is what decides either when using docker image for deploys or using image for local development. It should matter even for a lone developer, because change of workstation would cause loss of such extension that wasnt installed during a build of image. – Dreadfully

Do you happen to find an answer to this? Currently experiencing the same problem. – Tibold

I never found an answer, so far the only working solution is to fork this file and maintain my own copy :( – Podolsk

Well... your customizations have to live somewhere. If you don't want them to live specifically in the project, maybe you could have the Dockerfiles in a private repo like Johny and then use git submodules to add them to the project. That way, it "becomes" code that is independent of the project. – Krefetz

@Krefetz That sounds like it could work, but it seems like way more custom infrastructure than what should be necessary to do something as simple and commonplace as adding a few PHP extensions to a website in the leading PHP website framework. – Podolsk