frankenphp
frankenphp copied to clipboard
Can I run frankenphp with supervisor?
Describe you feature request
I'd like to be able to run daemon jobs via supervisor.
Is this possible or not?
I've tried, but I can't run supervisor with frankenphp, even though it's installed in a Dockerfile.
Yes, for instance Laravel Sail runs FrankenPHP using supervisord: https://laravel.com/docs/10.x/octane#frankenphp-via-laravel-sail
i need to run without laravel sail + octane. Its possible ?
Definitely!
i need to run without laravel sail + octane. Its possible ?
You can see the docs (link) to install supervisor. Something like this:
Dockerfile
FROM dunglas/frankenphp
RUN apt update && apt install supervisor
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
ENTRYPOINT ["/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]
supervisord.conf
[program:octane]
command=php /app/artisan octane:frankenphp --host=127.0.0.1 --port=80 --admin-port=2019 --workers=16
@kilwir76 solved your problem? could you close the issue? :)
Thanks ! yes sorry for the wait
its a same fonctionnality on symfony ?
its a same fonctionnality on symfony ?
Yes. you only need to set your entrypoint command in supervisord configuration.
Supervisor is a process control system. It's not exclusive for laravel or anything. You can control any command with.
What would be the supervisor command to run a Laravel app in the same way as the default Frankenphp image does? (without Octane)
For instance, does the base image do more than something like this:
[program:frankenphp]
directory = /srv
command=/usr/local/bin/frankenphp run --config /etc/caddy/Caddyfile
Does it run in worker mode by default, and how to run in worker mode with supervisor?
Just wondring is there benefits of running frankenphp in supervisor than doing an entrypoint like this ENTRYPOINT ["php", "artisan", "octane:frankenphp", "--caddyfile=/app/Caddyfile"] with restart: always in docker service 🤔 .
I think the entrypoint is simple and achieve same need as running in supervisor.
Supervisor is indeed useless if you're using Docker Compose.
Supervisor is indeed useless if you're using Docker Compose.
Why useless? There are objectives that can benefit from it, such as running Messenger workers. Or does FrankenPHP somehow replace Supervisor role in that context?
FrankenPHP doesn't, but Docker Compose does: https://stackoverflow.com/a/57564372
Why useless?
Why run a supervisor on a supervisor?
@kitro For me the benefit was mainly to handle all the processes required by my application in the same way (frankenphp, horizon, reverb...) without extracting these services to separate containers
@kitro For me the benefit was mainly to handle all the processes required by my application in the same way (frankenphp, horizon, reverb...)
But you can run each "process" as a service in docker compose, like this:
My comment was before your edit but still with same opinion about to have multiple services instead one with supervisord
Why useless?
Why run a supervisor on a supervisor?
TL;DR I misunderstood @dunglas's comment. He's talking about it being useless to use Docker compose to start Supervisor that manages FrankenPHP. I agere with that, that's pointless.
For context, I found this topic when I was trying to figure out how to run supervisor inside a dedicated FrankenPHP container where the user was not root. I was running into some permission issues (now solved), so I started searching, and found this.
We run supervisor next to the frankenphp process to manage additional background jobs. Locally, we use Docker compose to start the FrankenPHP container. That's where my confusion with "Supervisor is indeed useless if you're using Docker Compose." started.
But you can run each "process" as a service in docker compose, like this:
My comment was before your edit but still with same opinion about to have multiple services instead one with supervisord
@sneycampos I understand your point, thank you for taking the time to explain. I think you're right, your approach is better and I will look into it, maybe I will get rid of supervisor in my setup as well.
@sneycampos I understand your point, thank you for taking the time to explain. I think you're right, your approach is better and I will look into it, maybe I will get rid of supervisor in my setup as well.
I used to run my apps with supervisor too, its ok, but since we are using docker-compose we really don't need supervisor
another project uses the same approach (queue, scheduler, horizon, etc)