تماشای این درس نیاز به اشتراک حرفه‌ای دارد.

Adding NPM Service0:00

What the... We saw how to use Docker Compose in a Composer container to run one-off commands without having to install the software on our host machine. We can do the same to run artisan or NPM commands, traditionally ran through php or Node respectively, installed on the host system. Let's start with NPM. Opening up our docker-compose.yml file, we'll add a new service at the bottom called NPM. This will be built with an image from the Docker Hub, node:current-alpine. Just like our other containers, we'll attach our project root as a volume at /var/www/html.

Just like our other containers, we'll attach our project root as a volume at /var/www/html. Now unlike Composer, whose container runs the Composer command by default, the node image doesn't run NPM by default. This is easy to change, however, with the addition of an entry point attribute. This takes an array of strings, the exec form of commands, like we saw with building the PHP Dockerfile. In this case, we want it to just be NPM. Let's save this, and since it's using a Docker Hub image, we don't need to build the container first. In our terminal, we can just use docker-compose run rm npm install. Uh-oh, we get an error. Well that's because NPM was running in the root directory.

Fixing NPM Working Directory1:16

the container first. In our terminal, we can just use docker-compose run rm npm install. Uh-oh, we get an error. Well that's because NPM was running in the root directory instead of the /var/www/html directory that it should have been. We can fix this, just like we did with Composer, by creating a working dir attribute and setting it to our project root in the container. Now let's try running that command again. docker-compose run rm npm install. All right, it's running through the asset dependencies install process, just like if node and NPM were installed on our local system. Except we didn't have to install those. Things like NPM and Composer will run a little bit slower through the Docker system because of the restricted resources that you're having,

Except we didn't have to install those. Things like NPM and Composer will run a little bit slower through the Docker system because of the restricted resources that you're having, as opposed to running on your host system. The upside though is the fact that you don't have to have these dependencies installed in your local machine, and they can be matched to specific target environments on production or locally. All right, once that finishes up, we can then compile the assets with docker-compose run rm npm run dev. All right, perfect. Laravel Mix ran successfully and compiled both our JavaScript and CSS files provided in the Laravel framework by default. Okay, let's move on to Artisan commands. These will be just a little different because Artisan isn't a software that's readily available outside of Laravel. It's a script bundled with the application and runs through php. Building a

Creating Artisan Service2:53

will be just a little different because artisan isn't a software that's readily available outside of Laravel. It's a script bundled with the application and runs through php. Building a service to run it isn't that much of a problem though, since we already have a perfectly good php container image available. In our docker-compose.yml file, let's add a new service at the bottom called Artisan. Just like our php service, it will be built with a Dockerfile. Specifically, php.dockerfile. That way, the same version of php, the same plugins and configuration, the same user and group that runs our Laravel application will also run the artisan commands. Again, we'll use the same volume, source to /var/www/html. Add a new working dir attribute to this same directory. And Artisan will depend on the mysql container. In case we're running any commands that access

Add a new working dir attribute to this same directory. And php artisan will depend on the mysql container. In case we're running any commands that access the database, that service should be up and running beforehand. And lastly, an entry point. Like with npm, we'll need to specify the command that will be used when we run the service. That's php, and then the full path to the artisan script, /var/www/html/artisan. Let's save this and see it in action. In our terminal, docker-compose run rm artisan migrate. Once it's built, this should connect to our MySQL database and run the default migrations for our app. Uh-oh, there is a problem. Connection refused. It can't connect to the database. Well,

Updating Database Env Settings4:40

and run the default migrations for our app. Uh-oh, there is a problem. Connection refused. It can't connect to the database. Well, that's because we haven't updated the .env file that contains our database credentials. Opening it up. Remember what we chose for the database name and username under the MySQL service in our docker-compose file. That's Laravel and Laravel, and the password set to secret. But there's one more change that needs to be done. The host name for the database isn't the local host IP address. artisan and php are both isolated from the MySQL container. Specifying local host here means that the MySQL service would be running in their container. Instead, we need to use the IP address for the MySQL container.

both isolated from the MySQL container. Specifying localhost here means that the MySQL service would be running in their container. Instead, we need to use the IP address for the MySQL container within the docker-compose network. Just like we did with Nginx, we can use the service name as a placeholder for it. So just MySQL. Let's save this and try running the migrations again. docker-compose run --rm artisan migrate Perfect! Our database migrations went through smoothly. And just like with Composer and NPM, we can use the same commands that we'd normally run with artisan on a local machine. Like artisan make:model Post -m which will generate a Post model and migration file. And since we're using volumes, these files are available to our host machine immediately.

Wrapping Up and Production Next6:16

which will generate a Post model and migration file. And since we're using volumes, these files are available to our host machine immediately. We can also use php artisan tinker. Bringing up a terminal that we can use to play around in our Laravel app using the docker-php in MySQL containers. All right, so I think we have everything working smoothly with docker on our local machine. Next, we'll see what modifications we'll have to make, and how we can package up everything for a production environment.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟