Possible to run something after `php-fpm` has started?

[Matt Foxx]

I'd like to run a script once after exec tini -- "${@}" in entrypoint-base but I'm coming up short on an easy way to do this other than tacking it into healthcheck-liveness..is there a better way to do this?

[Sherif Abdel-Naby]

Container should run one and only one process, the exec here ensures that entrpoint will handover process control to tini which in turn will run the container CMD which defaults to php-fpm but technically can be any command like php <some-background-job-or-db-migration> and so -and by design- there is no way to run a command once after the exec.

Although I'd not recommend it but you can technically run a command in the background before the exec part and let it run the background (maybe with a sleep to make sure it runs after the entrypoint has executed).

What's your use-case ? What are you trying to achieve ?

[Matt Foxx]

Thanks for the insight. I'm trying to use laravel-opcache to compile application code when a container first starts. The issue is that to set data in opcache for php-fpm (not cli) it has to be done from an actual HTTP request.

So I need the web container to be ready (it is) and php-fpm to be running in order to make a successful call. It's also more ideal to make the call from the app container so I can check headers/app key from the same environment for security reasons.

I could alternatively have a postStart container with just curl installed and have it run once with the condition

depends_on:
  app:
    condition: service_health

and make the call from the container...but i was hoping to avoid doing something this heavy.

[Sherif Abdel-Naby]

@FoxxMD you can use postStart container, in Kubenretes you can use a PostStart hook but it's not guaranteed that it will run after Entrypoint is executed, but you can make a script that waits until php-fpm starts to execute.

But lets take a step back, AFAIK opcache will be generated once the application starts receiving requests, are you trying to warm it up ? or clear the cache? If the latter why do you want to clear the cache in production? The way kubephp is deployed in production assumes that the code will be immutable and hence the defaults in php.ini

[Matt Foxx]

are you trying to warm it up ?

Yes and no-ish...I misinterpreted some behavior of opcache and thought I needed to explicitly cache some app files (that opcache would not ever cache) but I think I was wrong on this point.

My infra doesn't use kubernetes but this discussion has been helpful -- in the future if I need to run-once anything after the app container starts I'll just use a small scratch or alpine container to communicate with app. Thanks for the insight.

EDIT: Also want to add that I absolutely love kubephp and am appreciative of the work you've done here :)