Add docker for production

[arthurpar06]

Closes #1815

STILL WIP

[Lapotor]

We don't need to expose ports if the DB will only be used for the app.

[arthurpar06]

Hi @Lapotor,
Thanks for your feedback. I'll be pushing quite a few things in the coming days. I've worked a lot on it to get cron, queue workers, etc. I'll switch my production over to it, and after a few days of testing, I'll update this PR.

[Slyplayer8990]

Should be approved, it is important for getting a development environment as easy as possible.

[nabeelio]

Should be approved, it is important for getting a development environment as easy as possible.

Looks like a few things still need to be addressed

[arthurpar06]

Alright, so I've been running a Docker stack on my server for a while, but it has some drawbacks, and I'm not skilled enough with Docker to fix everything. I need your opinions.

For me, there should be 4 containers:

• Our container built from the Dockerfile to handle web requests
• Our container built from the Dockerfile to handle tasks (cron + queues, including Laravel Horizon for queues)
• MariaDB
• Redis

A few things I think need to be revisited:

1. If a user has modules mounted in /modules, they need to run composer dump-autoload for the classes to be loaded at launch. However, I don’t know how to modify the app container's entrypoint while still keeping the default entrypoint afterward (I haven’t managed to figure out the command that the default entrypoint runs).

2. Is it really a good practice to have two containers from the same image with two different entrypoints for tasks (queues/cron) and for the web application? I don’t know Docker well enough to understand what the best practices are in this case.

3. If the user has multiple apps on their server, they would then have a reverse proxy. Is it a good idea to have a reverse proxy that then points to the Caddy/FrankenPHP instance of this application? That’s what I use in production, but is there a better way to do it?

[arthurpar06]

Ultimately, we’re not going to use FrankenPHP in order to have something more stable and robust with PHP-FPM, see #1914