Forem: Jorge Santos

How I deploy Laravel apps in Docker with just two commands

Jorge Santos — Sat, 07 Sep 2024 20:54:00 +0000

Hi there! It's Jorge. It's been a while since my last post, and this one might sound the same as one that you might have read around here. But come along and I promise you that you never again will have to build docker images from scratch to your Laravel projects!

⚡TL;DR

Tired of configuring Docker from scratch for every Laravel project? This is the link to the Github repository for the Laradocker project, a brand new composer package that sets up your Laravel project with Docker with just these two simple commands:




# Run these commands inside your Laravel project:

composer require --dev jdsantos/laradocker

php artisan laradocker:install

# That's it! Follow the instructions and you are done!

On your way there, please leave a star ⭐ on the repo to show your support.

Thanks in advance ❤️

📜The backstory

In my previous post, I brought you LANPOD a Laravel/Docker deployment strategy that allows you to deliver a Laravel app on-premise or cloud environments relying on a battle tested tech recipe consisting of laravel + alpine linux + nginx + php-fpm + opcache + docker you absolutely loved.

This recipe allows you to deploy your app in a redistributable, virtualized, os agnostic, self-contained and self-configured software image and run it in virtualization engines such as Docker or Podman. It even includes things out of the box like the supervisor's tidy configuration for handling your queues, nice defaults for php, opcache and php-fpm, nginx, etc.

All good, but...

😵The pain

Something was off.

While LANPOD as a template repository on Github was a helpful starting point for a brand new Laravel app, and a LOT better than having to go about wiring virtualization over and over again on the same structured apps, it was completely useless to an already existing/legacy project. You would have to MANUALLY extract the recipe’s files and directories of the bunch of other stuff, and adapt them to your needs. As it was meant to be a template-only repository, it didn’t include right out of the box any native database support (because if it did, it would have to include all of them in the same image), and if an update to the configuration was needed, it would be hell on earth just to know how and what to change in your project.

💊The solution

Having felt this pain myself enough times already, especially when having to add by hand the database dependencies to the Dockerfile/Containerfile over and over again, I realized: how cool would it be to have this recipe as a dependency in my projects, in such a way that is easy peasy to install, uninstall and update in the future?

"That's it! I'm going to create a Laravel package that I can install in my projects! Let's do this!"

So, the adventure began!

I started to scaffold my brand new composer project with all required dependencies to develop and test Laravel packages including orchestra/testbench, laravel/pint and larastan/larastan.

After that, I set up right from the start a Github repository for the project, auto-publish capabilities to Packagist, the PHP composer package repository, and spawned Github actions for a super simple CI/CD pipeline to run my tests at each push.

With all this in place, the rest was peanuts: I used all of LANPOD's files as mere stubs for this project, and used the plain Artisan Console to develop a pretty silly and basic UI for installing this recipe:

After launching Laradocker inside your project, the installer will guide you through the necessary steps to build the proper dependencies in the image, such as database connectivity support and you are done!

All files get generated in an instant and copied into your project!

👨‍💻The code

This package is completely free & open-source and you can find the source code here!. On your way there, please leave a star ⭐ on the repo to show your support.

Thanks in advance ❤️

💻 Environment

This was the environment that I used:

Hardware

Intel i7-8750H
24 GB of RAM
SSD 250GB

Software

Windows 11 Enterprise
Docker Desktop with WSL backend
Visual Studio Code

Hope this helped you in any way.

See you soon! 👋

Laravel 10 + NGINX + PHP-FPM - my ready to use all in one recipe for your Laravel 10 deployment in Docker

Jorge Santos — Sat, 17 Feb 2024 00:00:00 +0000

Hi there! It's Jorge. Is it just me, or did January felt like it had 90 days or so? Well, nevermind. Let's dive right in on what brought you here.

In this post, I'm continuing on the Docker + Laravel theme but now on a diferent topic: my deployment strategy for either on premise or cloud Laravel apps using containerization.

IMPORTANT UPDATE: I've PROMOTED this recipe to an installable composer package! Go check it out at
How I deploy Laravel apps in Docker with just two commands

If you are on a hurry, you can find this on my github repo LANPOD - Laravel + Alpine + Nginx + PHP-FPM + OPCache + Docker and on your way there please leave a star ⭐ on this repo! Thanks in advance!

🤯 but why? why when there are so many options?

You're absolutely right. There are a lot of options out there with ready to use base images, lots and lots of configurations out of the box, but at least to me all of them were a bit too much: either they packed a lot of stuff I didn't need, or they required lots of tunning to be able to run my apps accordingly to my clients requirements. Some of them were really heavy weight images 🥊, and extending them was also hard.

That is why I prefered to build these small docker images, that pack the absolute minimum to run my Laravel apps, using the proven php-fpm on a base lightweight Alpine image, merged together with NGINX so that you can make the configuration an absolute breeze. I also packed supervisor and opcache that I usually use in my deployments.

☝️ first things first

First of all, I started by inheriting from the base alpine php-fpm:8.3 base image and installed opcache + nginx + supervisor:



FROM php:8.3-fpm-alpine

RUN apk --no-cache add \
    nginx \
    supervisor \
    && docker-php-ext-enable opcache

🦸 supervisor: a single process to rule them all

Then, as my apps usually need to process Laravel queues, I included supervisor to be able to run (and keep running at all times) the worker processes. Docker is really good at maintaining and restarting a single entrypoint process. However, if you launch sub processes within your app like supervisor, you must ensure it starts with things like service start supervisor. Then it hit me: what if I used supervisor as my main docker process and entrypoint, and not only to run my queues? Then supervisor could handle and monitor all sub processes I need on my image on its own!

I went for it, and in the end this is how my entrypoint exec command looks:




# Start supervisord
exec /usr/bin/supervisord -c /etc/supervisord.conf

This instruction launches supervisor that spawns correctly these sub processes:



[program:nginx]
command=/usr/sbin/nginx -g "daemon off;"

[program:php-fpm]
command=/usr/local/sbin/php-fpm

[program:crond]
command=/usr/sbin/crond -f

[program:queue-worker]
command=php /opt/laravel/artisan queue:work --sleep=3 --tries=3 --backoff=3 --max-time=3600

✨ nginx: my frontend server of choice

nginx is my choice in terms of serving content and handling incoming requests. The configuration is also very simple, and with these few lines, I got it working just fine:




        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass localhost:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        # Block httpoxy attacks. See https://httpoxy.org/.
        fastcgi_param HTTP_PROXY "";
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;

        # FastCGI buffering settings
        fastcgi_buffering on;
        fastcgi_buffers 16 32k;
        fastcgi_buffer_size 64k;
        fastcgi_busy_buffers_size 128k;
        fastcgi_temp_file_write_size 128k;

⚡ php-fpm: a good php process manager

As far as handling requests to my Laravel php backend, I prefer to use FastCGI Process Manager that manages PHP processes nicely. With just this configuration file, everything is looking good:



[www]
listen = 9000
listen.allowed_clients = 127.0.0.1
user = www-data
group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Notice that although the 127.0.0.1 ip address seems harcoded, it works fine as the nginx + php-fpm run inside of the same container (no need for complicated networking here...)

🔥 opcache: speedy requests

In production environments you should use OPCache so that PHP doesn't need to load up and parse your PHP scripts on each request.

Therefore, I configured my instance as follows:



[opcache]

opcache.enable=${PHP_OPCACHE_ENABLE}
opcache.revalidate_freq=0
opcache.validate_timestamps=1
opcache.max_accelerated_files=10000
opcache.memory_consumption=192
opcache.max_wasted_percentage=10
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1

You can find this on my github repo LANPOD - Laravel + Alpine + Nginx + PHP-FPM + OPCache + Docker and on your way there please leave a star on this repo ⭐! Thanks in advance!

💻 Environment

This was the environment that I used:

Hardware

Intel i7-8750H
24 GB of RAM
SSD 250GB

Software

Windows 11 Enterprise
Docker Desktop with WSL backend
Visual Studio Code

Hope this helped you in any way.

See you soon! 👋

Docker + Windows for Laravel Development: How I boosted performance with just this simple hack

Jorge Santos — Mon, 18 Dec 2023 11:00:00 +0000

Hi there! It's Jorge. In this post, I'm going to reveal a simple hack you can make on your docker-compose file if you're developing a Laravel project on a Windows machine with Docker, and experiencing really slow disk performance.

This was the docker-compose.yml file used in the development:

version: "2.3"
services:
  app:
    build: ./app
    container_name: app
    environment:
      PHP_OPCACHE_ENABLE: 0
      PRODUCTION: 0
    ports:
      - "8080:80"
    depends_on:
      - "database"
      - "redis"
    volumes:
      - ./app:/app

Notice the volume ./app:/app. This volume allows us to bind our local directory app to the container's /app directory so that when we change the code in the host machine, that code changes immediately on the container so that we can run and test our changes.

😈 vendor directory - the root of all evil

When trying to figure out why the hell was this app so slow in local development environment vs the deployed production environment, I started to monitor my machine's resources at each step of the request. I noticed that serving static resources with nginx was always fast, but when the PHP backend kicked in, my SSD disk usage skyrocketed.

I started to dig in the Laravel PHP backend, and noticed that even running a simple command like composer dump-autoload was extremely slow; so my focus was now on optimizing this step alone. Again, started to notice that my container was heavily using my SSD just for the autoload generation.

In my research on this problem, I bumped this post about how to improve performance on VS Code DevContainers (which I was already trying as well). This explanation by Microsoft said it all:

Since macOS and Windows run containers in a VM, "bind" mounts are not as fast as using the container's filesystem directly. Fortunately, Docker has the concept of a local "named volume" that can act like the container's filesystem but survives container rebuilds. This makes it ideal for storing package folders like node_modules, data folders, or output folders like build where write performance is critical.

I then changed my docker-compose.yml file to include a named volume specifically for the /vendor directory but kept the original bind mount as well. After running docker-compose up -d again, running composer dump-autoload got really fast! The problem was solved. 😌

Here is what my final docker-compose.yml looked like:

version: "2.3"
services:
  app:
    build: ./app
    container_name: app
    environment:
      PHP_OPCACHE_ENABLE: 0
      PRODUCTION: 0
    ports:
      - "8080:80"
    depends_on:
      - "database"
      - "redis"
    volumes:
      - ./app:/app
# Add this vendor named volume for disk read/write performance boost
      - vendor-dir:/app/vendor
volumes:
# Don't forget to add it to the volumes section!
  vendor-dir:

💻 Environment

This was the development environment that I used for this legacy project:

Hardware

Intel i7-8750H
24 GB of RAM
SSD 250GB

Software

Windows 11 Enterprise
Docker Desktop with WSL backend
Visual Studio Code

Hope this helped you in any way.

Hope to see you soon 👋