Laravel - Running Horizon in Google Cloud Run (via Docker) - laravel

Question

I'm trying to set up laravel horizon to run on my google cloud (run) containers. I have gotten installed successfully, however when I navigate to the dashboard, it always indicates to be inactive. Jobs are getting scheduled but are not being executed.
For clarification:
The laravel application also houses an application on which actual end-users end up. I want to add Horizon to manage the jobs that are generated by that platform. It's a serverless application (housed on Cloud Run as mentioned), however there are atleast 3 containers running at all times and the Redis instance which powers the queue is also housed seperately.
Dockerfile:
FROM composer:2.1.3 as build
WORKDIR /app
COPY . /app
RUN apk update
RUN apk add libpng libpng-dev libjpeg-turbo-dev supervisor libwebp-dev zlib-dev libxpm-dev gd && docker-php-ext-install gd && docker-php-ext-install pdo pdo_mysql
RUN docker-php-ext-install pdo pdo_mysql pcntl
RUN composer install
FROM php:8.1-apache-buster
RUN docker-php-ext-install pdo pdo_mysql pcntl
RUN pecl install redis && docker-php-ext-enable redis
EXPOSE 8080
COPY --from=build /app /var/www/
COPY docker/000-default.conf /etc/apache2/sites-available/000-default.conf
COPY docker/supervisord.conf /etc/supervisord.conf
COPY .env.example /var/www/.env
RUN echo 'max_execution_time = 1200' >> /usr/local/etc/php/conf.d/docker-php-maxexectime.ini;
RUN echo 'memory_limit = 1G' >> /usr/local/etc/php/conf.d/docker-php-memlimit.ini;
RUN echo 'php artisan horizon'
RUN chmod 777 -R /var/www/storage/ && \
echo "Listen 8080" >> /etc/apache2/ports.conf && \
chown -R www-data:www-data /var/www/ && \
a2enmod rewrite
Horizon configuration file:
return [
/*
|--------------------------------------------------------------------------
| Horizon Domain
|--------------------------------------------------------------------------
|
| This is the subdomain where Horizon will be accessible from. If this
| setting is null, Horizon will reside under the same domain as the
| application. Otherwise, this value will serve as the subdomain.
|
*/
'domain' => env('HORIZON_DOMAIN', null),
/*
|--------------------------------------------------------------------------
| Horizon Path
|--------------------------------------------------------------------------
|
| This is the URI path where Horizon will be accessible from. Feel free
| to change this path to anything you like. Note that the URI will not
| affect the paths of its internal API that aren't exposed to users.
|
*/
'path' => env('HORIZON_PATH', 'horizon'),
/*
|--------------------------------------------------------------------------
| Horizon Redis Connection
|--------------------------------------------------------------------------
|
| This is the name of the Redis connection where Horizon will store the
| meta information required for it to function. It includes the list
| of supervisors, failed jobs, job metrics, and other information.
|
*/
'use' => 'default',
/*
|--------------------------------------------------------------------------
| Horizon Redis Prefix
|--------------------------------------------------------------------------
|
| This prefix will be used when storing all Horizon data in Redis. You
| may modify the prefix when you are running multiple installations
| of Horizon on the same server so that they don't have problems.
|
*/
'prefix' => env(
'HORIZON_PREFIX',
Str::slug(env('APP_NAME', 'laravel'), '_').'_horizon:'
),
/*
|--------------------------------------------------------------------------
| Horizon Route Middleware
|--------------------------------------------------------------------------
|
| These middleware will get attached onto each Horizon route, giving you
| the chance to add your own middleware to this list or change any of
| the existing middleware. Or, you can simply stick with this list.
|
*/
'middleware' => ['web', 'sessionvalidation'],
/*
|--------------------------------------------------------------------------
| Queue Wait Time Thresholds
|--------------------------------------------------------------------------
|
| This option allows you to configure when the LongWaitDetected event
| will be fired. Every connection / queue combination may have its
| own, unique threshold (in seconds) before this event is fired.
|
*/
'waits' => [
'redis:default' => 60,
],
/*
|--------------------------------------------------------------------------
| Job Trimming Times
|--------------------------------------------------------------------------
|
| Here you can configure for how long (in minutes) you desire Horizon to
| persist the recent and failed jobs. Typically, recent jobs are kept
| for one hour while all failed jobs are stored for an entire week.
|
*/
'trim' => [
'recent' => 60,
'pending' => 60,
'completed' => 60,
'recent_failed' => 10080,
'failed' => 10080,
'monitored' => 10080,
],
/*
|--------------------------------------------------------------------------
| Metrics
|--------------------------------------------------------------------------
|
| Here you can configure how many snapshots should be kept to display in
| the metrics graph. This will get used in combination with Horizon's
| `horizon:snapshot` schedule to define how long to retain metrics.
|
*/
'metrics' => [
'trim_snapshots' => [
'job' => 24,
'queue' => 24,
],
],
/*
|--------------------------------------------------------------------------
| Fast Termination
|--------------------------------------------------------------------------
|
| When this option is enabled, Horizon's "terminate" command will not
| wait on all of the workers to terminate unless the --wait option
| is provided. Fast termination can shorten deployment delay by
| allowing a new instance of Horizon to start while the last
| instance will continue to terminate each of its workers.
|
*/
'fast_termination' => false,
/*
|--------------------------------------------------------------------------
| Memory Limit (MB)
|--------------------------------------------------------------------------
|
| This value describes the maximum amount of memory the Horizon master
| supervisor may consume before it is terminated and restarted. For
| configuring these limits on your workers, see the next section.
|
*/
'memory_limit' => 128,
/*
|--------------------------------------------------------------------------
| Queue Worker Configuration
|--------------------------------------------------------------------------
|
| Here you may define the queue worker settings used by your application
| in all environments. These supervisors and settings handle all your
| queued jobs and will be provisioned by Horizon during deployment.
|
*/
'defaults' => [
'supervisor-1' => [
'connection' => 'redis',
'queue' => ['default'],
'balance' => 'auto',
'maxProcesses' => 1,
'maxTime' => 0,
'maxJobs' => 0,
'memory' => 128,
'tries' => 1,
'timeout' => 60,
'nice' => 0,
],
],
'environments' => [
'production' => [
'supervisor-1' => [
'maxProcesses' => 10,
'balanceMaxShift' => 1,
'balanceCooldown' => 3,
'queue'=> ['low', 'medium', 'high', 'vip'],
],
],
'local' => [
'supervisor-1' => [
'maxProcesses' => 3,
'queue'=> ['low', 'medium', 'high', 'vip'],
],
],
],
];
Supervisord.conf
[supervisord]
nodaemon=true
[program:laravel-worker]
process_name=%(exampleprocessname)s_%(process_num)02d
command=php /var/www/artisan horizon
autostart=true
autorestart=true
numprocs=1
redirect_stderr=true
Would anyone be able to give me some clues as to where it might go wrong?
Thank you
Ps. The environment variables are exactly the same between the .env and the horizon configuration file.

Answer 1

Is it possible to run background tasks in Cloud Run ? i thought it operates only on request, and therefore after a request is handled it stops working, until the next requests comes in.

Answer 2

The trick is to pass a custom container command in Cloud Run with the value /usr/bin/supervisord to actually start the supervisor/Horizon.
But there's another trick you need, as Cloud Run expects the service to respond to a health check request. You should not only start Horizon from supervisor (which by default would override the container command and not start Apache), but also start Apache, so the service can be considered healthy.
You can also pick a more lightweight solution, that will return HTTP 200 on request to the root of your service, as Apache feels a bit overkill for this purpose.
Disclosure: I believe I happen to be currently working for ilovecookies