Laravel workers requires a separate application to be spun up as its health check type, route and commands are different from running a Laravel application served through HTTP(s). In this post, I describe considerations to take, problems that you might face and how I resolved them.
State Management
Having a separate application process means that state has to be well managed. This is a concurrency problem. You can think of your two different applications as two different threads. States include: cache, application, queue and file. Preferably through non-file system drivers.
Hence, you’ll minimally require a simple database table as your queue driver. However, it is recommended to have something better than just that – Redis. For my filesystem, I use S3 to store and share files.
User Provided Services
Application secrets are shared through User Provided Services. This is to ensure the ease of secret sharing between your main Laravel application and your worker application.
The following is a manifest is a Laravel worker that I would like to share with you. And I hope you’ll find it useful for your Laravel projects running on Pivotal Web Services or any other Pivotal Cloudfoundry out there.
worker-manifest.yml
---
applications:
- name: laravel-api-v1-worker
memory: 256M
path: .
services: [
api-redis,
api-db,
api-instagram,
api-pay-pal,
api-config,
api-aws,
api-jwt,
api-cache
]
buildpack: php_buildpack
env:
CACHE_DRIVER: "redis"
QUEUE_DRIVER: "redis"
SESSION_DRIVER: "redis"
MAIL_DRIVER: "ses"
FILESYSTEM_DRIVER: "s3"
instances: 1
health-check-type: process
no-route: true
command: php artisan queue:work --tries=3 --daemon --memory=256
One thought on “Laravel Worker On Pivotal Cloudfoundry”