fly-apps / dockerfile-laravel Goto Github PK

What and Why:
What: Run Filament Cache command when Filament is installed for a Laravel application

Why: Thanks to community post, it was discovered that Laravel apps with Filament installed get really low requests per second( I tested, and got 5 requests per second ). This can be improved by running Filament's cache commands.

How:
Revise Laravel's Dockerfile template to run the Filament cache commands when "filament/filament" is detected in the composer.json file

Related to:
flyctl PR
Community post

We need this package to be installable via composer. This can be done by publishing it in https://packagist.org.
Before publishing please make sure to:

• Review Repository
  • #3
  • Push fix for Dockerfile template missing ";" in line 22, which without throws an error during docker build
• Update ReadMe to include Usage and Contribution Guides
  • Add features handled by the Dockerfile generator
  • Make sure to mention about permission issue fix when build is not working!
• Publish the package in Packagist.org. Check this Laravel Zero docs on it.
• Fix issue with installation through composer " cannot find ... version ... matching your minimum-stability (stable)"

Running a docker build for the Dockerfile generated generated by the package, would throw an error:

0.341 /bin/sh: 1: Syntax error: end of file unexpected (expecting "fi")

This can be fixed by adding ; to the command before the fi; directive.

What:
Changes from superfly/flyctl#3372, should also be added in the dockerfile-laravel generator

Why:
To accommodate the new syntax in setting trusted proxies for Laravel 11 which is different from the previous versions.

What:
To make the Dockerfile smaller, can we move bash statements out of the Dockerfile generated, and into the generator?

https://flyio.slack.com/archives/C042W39VAMB/p1710508019502139

Reason:
"...makes the Dockerfile smaller and easier to understand."

Changes in view files are not included in the built phar file after building changes. Using the storage/framework/views for storing view cache can make these cached views visible, deletable, and once deleted, allow for new changes to be reflected on the built package/application.

What:
Detect the Laravel Version of a Laravel project.

How:
Check the contents of the composer.json file, or the result of php artisan --version

Why:
We can generate Dockerfile content to accommodate to different Laravel versions

Hi, would it be a good idea to create a layer for dependencies for both npm and composer to only run if the .json or lockfiles change?

Currently if any file changes it will re-install dependencies.

What:
We can detect the PHP version. And include that version(or the nearest supported version) as the PHP version declared in the Dockerfile generated.

Similar to this snippet we have in the Fly Laravel Scanner

Why:
This will help in providing a closer environment a local Laravel project has with its deployed Laravel project in Fly.io.

please let me know if this should rather be posted in the community forum.

If i trigger an exception all i see in the fly logs is: ERROR unknown error

more precisely:

no details about it.
i tested this locally with frankenphp and stderr and did see the exception in frankenphp's log

logging.php

'stderr' => [
    'driver' => 'monolog',
    'level' => env('LOG_LEVEL', 'debug'),
    'handler' => StreamHandler::class,
    'formatter' => env('LOG_STDERR_FORMATTER'),
    'formatter_with' => [
        'includeStacktraces' => true,
    ],
    'with' => [
        'stream' => 'php://stderr',
    ],
    'processors' => [PsrLogMessageProcessor::class],
],

fly.toml

[build]
  [build.args]
    NODE_VERSION = '18'
    PHP_VERSION = '8.3'

[env]
    APP_ENV = 'production'
    LOG_CHANNEL = 'stderr'
    LOG_LEVEL = 'info'
    LOG_STDERR_FORMATTER = 'Monolog\Formatter\JsonFormatter'
    SESSION_DRIVER = 'cookie'
    SESSION_SECURE_COOKIE = 'true'


[http_service]
  internal_port = 8000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

[processes]
  app = ""
#  cron = "cron -f"
#  worker = "php artisan queue:listen"

[[vm]]
  size = 'shared-cpu-1x'
  memory = "512MB"

What:
Create a dockerfile-laravel binary that is standalone, and executable by itself

Why:
There are cases when the dockerfile-laravel package is not installable via composer.
In this cases we would want to download the binary instead.

Right now the phar file created by Laravel Zero relies on the environment it is run on to contain a suitable PHP interpreter.

HOW:
This is why we should try creating a standalone binary of our dockerfile-laravel generator through frankenphp's standalone binary creation

The current Dockerfile template used in the repository ends at EXPOSE 8080.

I'm not sure yet whether this starts the server or not though, gonna do some testing. After testing, I should be able to identify whether the Dockerfile starts a server or not. If it does not, Run a command that will run the server.

Should the .fly directory, which contains the /scripts folder that runs commands for caching, etc, be generated from the dockerfile-laravel command?

No:

1. The name of the repository is dockerfile-laravel, from the name, it is assumed that the command generates dockerfile-related stuff. Not fly scripts

Yes:

1. The dockerfile-laravel is already used by flyctl to generate the Dockerfile, it makes sense for it to generate other supporting scripts as well, like those found in the .fly directory
2. Although the .fly scripts are not Dockerfile variations, these scripts contain startup commands the Dockerfile use for deploying a Laravel app to Fly.io. So since these are used by the Dockerfile( to setup a Laravel app for production ), we can say that these scripts are "deploy-to-fly-production" scripts, hence an indirect part of a Dockerfile the generated.

What:
https://flyio.slack.com/archives/C042W39VAMB/p1710787888107569
Detect flavors of octane:

1. FrankenPHP
   > Presence of frankenphp file in base directory
2. RoadRunner
   > .rr dir in base directory
   > keywords in composer.json
3. Swoole
   > This is actually a default option in the dockerfile generatedby flyctl for laravel apps with octane
   maybe
   > Can this be detectable if the swoole extension is available in the current dev environment? So check php.ini?

Why:
https://flyio.slack.com/archives/C042W39VAMB/p1711553910059719?thread_ts=1711549635.827029&cid=C042W39VAMB

TLDR: detectables should be defaultables.

Build a new binary of the package for production when new changes are pushed to the repository.

Also, look at this from packagist:

This package is not auto-updated. Please set up the [GitHub Hook](https://packagist.org/about#how-to-update-packages) for Packagist so that it gets updated whenever you push!

WHAT AND WHY
Update the generated Dockerfile to use an upstream image, similar to how the current laravel-docker repository is..

There are three primary reasons behind this move:

1. To remove the scope of having to maintain the custom image built from the laravel-docker repository for SOC2 compliance. This was brought up from a customer request for periodic security patches and maintenance for the custom image we have provided, which we currently cannot fully commit to.
2. Consistency: The generated Dockerfiles for other frameworks like Rails, Elixir, Javascript, all use upstream images as base. For consistency, we should also follow for the Dockerfile generated for Laravel apps.
3. Finally, this move will result in depositing config files to the users' project directory where they can visibly and readily find them, providing them full control over these files, as I quote @rubys :

they can rerun dockerfile-laravel when they want to pick up changes, hold back, and even make their own changes to these files."

HOW:
It's simple really! The laravel-docker repository already makes use of a Dockerfile that makes use of an upstream base image. So, we'll just make use of that Dockerfile. Further, since that Dockerfile requires several config file, we'll copy those over to the dockerfile-laravel repository as well.

Basically copy over the laravel-docker logic to dockerfile-laravel. This will result in the same Dockerfile logic, while using an upstream base image instead of the custom one we've provided.

NOTES:

1. For reference here is the discourse post tackling this issue
2. To make this a clean move and reduce the number of files to check. I'll create more than one PR to address this issue:
   a. Move the config files required by the laravel-dockerfile over to this repository
   b. Move the Dockerfile logic of laravel-dockerfile over to this repository

What:
Create Test that can later be used in the pipeline to allow/block merges.

Why:
The current repository is vulnerable to new changes as no existing tests are available to tell whether the new changes will break any previous ones.

Notes:
We can get inspiration from earlier dockerfile generators here!