Nginx boots up and starts accepting connections when running a non default command.

[joshmanders]

Affected Docker Images

{
  "org.opencontainers.image.authors": "Jay Rogers (@jaydrogers)",
  "org.opencontainers.image.description": "Supercharge your PHP experience. Based off the official PHP images, serversideup/php includes pre-configured PHP extensions and settings for enhanced performance and security. Optimized for Laravel and WordPress.",
  "org.opencontainers.image.documentation": "https://serversideup.net/open-source/docker-php/docs/",
  "org.opencontainers.image.licenses": "GPL-3.0-or-later",
  "org.opencontainers.image.source": "https://github.com/serversideup/docker-php",
  "org.opencontainers.image.title": "serversideup/php ()",
  "org.opencontainers.image.url": "https://serversideup.net/open-source/docker-php/",
  "org.opencontainers.image.vendor": "ServerSideUp",
  "org.opencontainers.image.version": "v3.0.2"
}

Current Behavior

Following this guide on running Laravel Task Scheduler it says to just call use this command command: ["php", "/var/www/html/artisan", "schedule:work"] and it should work. I ran a test command into Docker as just php artisan to get alternative output, and this was the result.

Expected Behavior

When not running the default command, the only output that should be is the command output not output that nginx is booted up and accepting (and receiving ping/status requests internally).

Steps To Reproduce

1. Use serversideup/php:8.3.6-fpm-nginx-alpine as a base
2. Run docker run ... and pass a command off to override the built in one per instructions in docs
3. See nginx output

Anything else?

No response

[sneycampos]

You must use the cli variant, not nginx

[jaydrogers]

I could see some people liking to use the same base image for all services. There are some new things that I learned that we can bypass S6 from executing. Stay tuned 😃

I'll get to this soon 👍

[joshmanders]

@jaydrogers

I could see some people liking to use the same base image for all services. There are some new things that I learned that we can bypass S6 from executing. Stay tuned 😃

I'll get to this soon 👍

Yeah honestly I switched away from this docker image because it complicates my deployment to require 2 separate images and builds to produce a k8s pod for running the web app and queue and schedulers.

[jaydrogers]

@joshmanders: You shouldn't need two separate images at all.

I like to use one base image (like serversideup/php:8.3-fpm-nginx), then I build my entire application to publish myorg/myapp.

The docs then suggest using three separate processes (following the Docker Philosophy of "do one thing well").

The trick with NGINX being in there with S6 Overlay is S6 Overlay wants to demand PID 1. This is where you're getting the extra processes with your original post.

To workaround that, we can just override the entrypoint for a Queue, Scheduler, Horizon, etc then S6 Overlay won't initialize its own PID to supervise anything else. Everything will come from a single base image of myorg/myapp when it runs.

I'll have more documentation on this approach soon.

[sneycampos]

@joshmanders: You shouldn't need two separate images at all.

I like to use one base image (like serversideup/php:8.3-fpm-nginx), then I build my entire application to publish myorg/myapp.

The docs then suggest using three separate processes (following the Docker Philosophy of "do one thing well").

The trick with NGINX being in there with S6 Overlay is S6 Overlay wants to demand PID 1. This is where you're getting the extra processes with your original post.

To workaround that, we can just override the entrypoint for a Queue, Scheduler, Horizon, etc then S6 Overlay won't initialize its own PID to supervise anything else. Everything will come from a single base image of myorg/myapp when it runs.

I'll have more documentation on this approach soon.

Basically you are changing dynamically the entrypoint according to the application type?

[jaydrogers]

I wouldn't call it "dynamic" as that seems automatic.

In short terms, I am statically disabling S6 overlay only on services that don't need S6 Overlay (anything that doesn't need a web server).

This gives me the strategy of keeping one image as my source of truth, but also reducing footprint in my other services while getting it close to the "single process per container" approach as Docker strives for.

It's just with PHP-FPM + NGINX is where things get weird (hence the point of why I started this project 😃)

[joshmanders]

I'll have more documentation on this approach soon.

Yes please, seems a lot of usefulness is missing in the docs. I tried for days to make this work before submitting this issue, then tried for days again before I found it was easier to just replace it with a custom dockerfile using FrankenPHP and went that route.