and faster in a production environment. We can actually do this with a separate production Docker Compose file that contains overrides. In our terminal, let's create a new file called docker-compose.prod.yml and open it up. In this file, we'll want to specify just those services and their changes that are going to be different in production. Off the top of my head, I can think of two things I'd like to change, starting with the nginx service. Under this, we are going to use a different Docker file to build out this container. nginx.prod.dockerfile. And add in a ports heading for 8080 and 443.

nginx.prod.dockerfile. And add in a ports heading for 8080 and 443443. That's all the changes for nginx. The second service I want to focus on is php. Like with nginx, we'll use a different Dockerfile to build it out, php.prod.dockerfile. And that's it. Let's create those two new files. We can just copy over the ones we've already created, since our changes aren't going to be very drastic. Opening up the nginx.prod.dockerfile, we're going to make one change.

be very drastic. Opening up the nginx.prod.dockerfile, we're going to make one change. Instead of adding in the default conf, we'll add in one called default-prod.conf, but replacing the default one that nginx expects in the container. And copy over that default conf file to our production version. Opening it up, we'll add in a whole new block for the HTTPS port 443. Here's where we would include a line for SSL certificates. And I'm just going to use a tool called makecert to create these certificates locally. And add these into our container using the nginx.prod.dockerfile. As for the server name in both blocks, I'll change this to our test domain, laraveldocker.tests.

And add these into our container using the nginx.prod.dockerfile. As for the server name in both blocks, I'll change this to our test domain, laraveldocker.tests. Alright this looks good, so let's save it and turn our attention back to php. Opening up the php.prod.dockerfile, our goal here is to install and configure opcache in the production environment to help speed up response time. At the end of our docker-php-ext-install command, we can just tack on opcache, and it'll handle the installation of that extension for us. But we need to include a config file in order to activate it and use it in our app. Under that, we'll just use ADD, and bring in an opcache.ini file to /usr/local/etc/php/conf.d/opcache.ini.

Under that, we'll just use add, and bring in an opcache.ini file to /usr/local/etc/php/conf.d/opcache.ini. Save this, and let's create that opcache.ini file. I'm going to paste in some boilerplate values here that work pretty well for basic applications. Let's save that, and now we're good to go. Well so how do we differentiate between production and local environments now? In our command line, to bring up our local environment that we've been using, we've just been running docker-compose up -d nginx. But if we want to run our production environment, we use the -f flag, which specifies a file to parse and use.

But if we want to run our production environment, we use the -f flag, which specifies a file to parse and use. The downside with this is that we need to specify all files, so we can't just pass in our production overrides with docker-compose.prod.yml. Instead, it ends up looking something like this. If we use -f docker-compose.yml, -f docker-compose.prod.yml, we should also add in the --build flag to rebuild our container with the new production docker files that we just made. We can already see that Docker is running the opcache extension install, meaning that our production values are being parsed in this build. Alright once everything is up, we can navigate to our site and verify that everything is

our production values are being parsed in this build. Alright once everything is up, we can navigate to our site and verify that everything is working as expected. Using the test domain that we created, our site's loading up as expected. And to verify that we are on production, we can try to go to the HTTPS version of the site and it loads as expected, with our local certificate provided and pulled in. Just to be sure that our production changes are being pulled in, we can open up a new window in our terminal and run docker-compose run rmphpi grep opcache. And in this environment, we are seeing opcache enabled and its configuration parsed in, exactly what we would expect.

And in this environment, we are seeing opcache enabled and its configuration parsed in, exactly what we would expect. Now depending on your pipeline, your next steps would be committing everything in this project and deploying it to your production servers. If you have a continuous deployment system set up, you could set up additional helpful workflows. On each deployment, after the main, nginx, php, and mysql containers are spun up, you could do something like docker-compose run rmcomposer update, or composer install, or build the assets each time with npm run production. We can automate this a bit.

build the assets each time with npm run production. We can automate this a bit. If we go back and open up the docker-compose.prod.yml file, let's add a service just for production to compile our assets at spin up. Let's call it assets. It'll be built just like our npm service, image node:current-alpine, volumes from source to /var/www/html. But the difference is that we are not going to include an entry point. We are not going to use this container to run the npm command multiple times. Instead, it's going to run each time that docker-compose up is ran.

We are not going to use this container to run the npm command multiple times. Instead it's going to run each time that docker-compose up is ran. For that, we'll use an attribute called command. This overrides the default command that the container runs. But unlike entrypoint, it does so regardless of input from the host machine. Our command to run is npm install and npm run production, except this will kick back an error to us because of the way it's parsed. If we want to run multiple commands like this, we'll have to pass it as a string in exec mode to /bin/bash with a -c flag, like this. We're using alpine linux as the base for this image though, so instead of /bin/bash,

mode to /bin/bash with a -c flag, like this. We're using alpine linux as the base for this image though, so instead of /bin/bash, it's /bin/sh. Now all we have to do is add this as a depends_on to our nginx container in production, alongside the mysql and php services. Don't forget we also need to tack on the working dir for /var/www/html. Now if we go back to the terminal and run our production docker-compose up again. After a few moments, our assets are starting to be compiled because of the new container that was ran on startup. And you can see the output of that here in the logs that were streamed back to us.

that was ran on startup. And you can see the output of that here in the logs that were streamed back to us. The same principle can be applied to php artisan or composer containers to do things like run seeders during each deployment and subsequent spin up. Alright this Docker setup is ready for production to serve your Laravel app in a server of your choice. Moving forward, you might want to consider learning more about orchestration and load balancing of multiple containers with Docker Swarm or Kubernetes, or automated testing with dedicated Docker containers for phpunit or pest, or even using queues and dispatching jobs with a dedicated Redis container.

with dedicated Docker containers for phpunit or pest, or even using queues and dispatching jobs with a dedicated Redis container. Docker is a powerful tool to have under your belt and it partners well with php and Laravel. Thanks for watching.