So, I have been using docker for a few months now to setup environments for non-Laravel projects. It is my understanding that the main purpose of docker is to help developers avoid environment related issues/errors when collaborating with others. I am confused and unsure how this works with Laravel, So many of the tutorials and articles I have seen show the developer executing the composer and Laravel commands on the host machine and then create a volume to a php:7.*-fpm container, if this is the correct way to do this, then does this not defeat the purpose of docker, since executing the commands on the host machine will use the composer/PHP version on the host and not the docker container?
I have tried following multiple YouTube tutorials and articles, i am not able to get a clear answer to this.
2
Answers
Laravel users always use the latest version of PHP. The commands are the same whether you run them inside or outside Docker.
How to use Docker in a real Laravel development environment.
Use Sail.
https://laravel.com/docs/11.x/sail
The sail command is used on the host. The actual command is executed within Docker.
Most artisan commands are the same inside and outside of Docker. There is no need to run it via the sail command as it is slow.
However, only database commands must be used within Docker.
Composer is the same and can be used inside or outside Docker.
Short
Use the tools in the container which are provided by the image.
If the tools are not provided by the image, add those to the image, and share it with the team.
Long
Let me explain two common use cases for images:
Side note: Using package managers on linux might (most probably) install different default versions of PHP on every linux distribution.
1. Providing a fixed development environment
In this case your docker image contains all the necessary packages your application needs. It provides a stable environment you can develop in.
For simplicity, let us reduce it to the very PHP version and composer you or your team decided to use.
During development, you mount your application into the running container. The application changes on every change you make.
Running composer or similar tools inside the container ensures that everybody uses the same version of those tools and prevents issues coming from version mismatches.
2. Providing a deployable image
When you are deploying your application into the test system or even into production system, you provide a configurable deployable image including a fixed version of the application and all the necessary tools.
As a simplified example, you use a Dockerfile to build the image, add your application to the image, and run composer. Resulting in an image containing the executable application.
Given your application is configurable by environment variables, you can run this image anywhere with docker, adjusting it to any given environment (e.g. different database credentials) : "works on any machine" .