Okay, we have PHP, MySQL, and Nginx ready to go. But, well, we don't have an app yet. If you're a Laravel or PHP developer, chances are you already have Composer installed in your local system. So we could just cd into this source directory and run composer create-project laravel/laravel, here. Or we can let Docker handle this for us. This way we can provide our Dockerfile on a server or other machines that may not have Composer installed, or that require certain software to run it, and they can still run Composer commands without any problems. To do this, in our docker-compose.yml file, at the bottom, we'll add a new service called Composer. We can use an image for this, but like with our PHP and Nginx containers, there are some possible permissions issues since it will be writing files to a mounted volume. Instead, let's build it off a Dockerfile called Composer.dockerfile.

our PHP and Nginx containers, there are some possible permissions issues since it will be writing files to a mounted volume. Instead, let's build it off a Dockerfile called Composer.dockerfile. And we'll attach a volume to the same point as our Nginx and PHP containers, /var/www/html. We'll also need to specify a new attribute, working_dir. By default, Composer is going to run commands inside of its home directory. But we want it running in our project directory, /var/www/html. Let's save this and create our Composer Dockerfile. From Composer to, and like with our other containers, we'll create env variables for the user, ComposerUser, and ComposerGroup. Then run, adduser --ingroup ComposerGroup --disabled-password ComposerUser. All right, that's all we need to do. Let's save this and return back to our terminal. All right, so how do we use this? Unlike our three previous services, Composer

d, Composer user. All right, that's all we need to do. Let's save this and return back to our terminal. All right, so how do we use this? Unlike our three previous services, Composer is not designed to stay up and running in the background. This container is meant to be created for the sole purpose of running a Composer command, and then once completed, be destroyed to free up any resources. First, let's remove that index.php and public directory from our source folder. And then we'll build our Composer container using docker-compose build Composer. All right, once that finishes up, we can use it just like this. docker-compose run rm Composer create-project laravel/laravel and the current directory. While this finishes up, let me break down this command. docker-compose run tells Docker that we want to run a command on a container, not just spin it up and let it be. The rm flag,

While this finishes up, let me break down this command. docker-compose run tells Docker that we want to run a command on a container, not just spin it up and let it be. The --rm flag, like we learned previously, lets Docker know to destroy this container fully once it's finished running. Then we specify the container's service name, composer, and finally the command that we'd like it to run. The composer docker image runs the composer command, so we just need to specify what we normally would after typing composer in our local terminal. Create a project, Laravel, Laravel, in the current directory. And for the container, the current directory is the working /var/www/html. All right, let's see where this is at. Everything finished up successfully, the application key was set, and because we're using volumes, if we cd into the source directory and see what's in there, it's all of the Laravel application files downloaded from composer as

the application key was set, and because we're using volumes, if we cd into the source directory and see what's in there, it's all of the Laravel application files downloaded from Composer as expected. And if we run docker-compose ps, we can see that the Composer container is not running, meaning that it was destroyed after the process finished. Let's run docker-compose up nginx to bring up the nginx, php, and mysql containers again and visit localhost in our browser. We can see the welcome view for a new Laravel application, exactly what we were expecting. Not only can we use the Composer service and docker-compose run for creating projects, we can do any Composer command that's traditionally available to you. We just have to prefix it with docker-compose run to run it through the docker system. And we can do this while the other docker-compose containers are running.

We just have to prefix it with docker-compose run to run it through the docker system. And we can do this while the other docker-compose containers are running. So docker-compose run rm composer require, and in the package name, like spatie/laravel-permission, or even docker-compose run rm composer dump-autoload. All right, in the next video we'll use docker-compose run some more to fire off artisan and npm commands for things like migrations and asset builds.