Download the PHP package dusterio/laravel-aws-worker without Composer

On this page you can find all versions of the php package dusterio/laravel-aws-worker. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package laravel-aws-worker

laravel-aws-worker

Code Climate Total Downloads Latest Stable Version Latest Unstable Version License

Run Laravel tasks and queue listeners inside of AWS Elastic Beanstalk workers

We've dropped future support for Lumen, however you can still use v0.1.40 for Lumen.

Overview

Laravel documentation recommends to use supervisor for queue workers and *IX cron for scheduled tasks. However, when deploying your application to AWS Elastic Beanstalk, neither option is available.

This package helps you run your Laravel jobs in AWS worker environments.

Standard Laravel queue flow AWS Elastic Beanstalk flow

Dependencies

Scheduled tasks - option 1

Option one is to use Kernel.php as the schedule and run Laravel schedule runner every minute. You remember how Laravel documentation advised you to invoke the task scheduler? Right, by running on regular basis, and to do that we had to add an entry to our cron file:

AWS doesn't allow you to run *IX commands or to add cron tasks directly. Instead, you have to make regular HTTP (POST, to be precise) requests to your worker endpoint.

Add cron.yaml to the root folder of your application (this can be a part of your repo or you could add this file right before deploying to EB - the important thing is that this file is present at the time of deployment):

From now on, AWS will do POST /worker/schedule to your endpoint every minute - kind of the same effect we achieved when editing a UNIX cron file. The important difference here is that the worker environment still has to run a web process in order to execute scheduled tasks. Behind the scenes it will do something very similar to a built-in schedule:run command.

Your scheduled tasks should be defined in - just where they normally live in Laravel, eg.:

Scheduled tasks - option 2

Option two is to use AWS schedule defined in the cron.yml:

Note that AWS will use UTC timezone for cron expressions. With the above example, AWS will hit /worker/schedule endpoint every hour with run:command artisan command and every 5 minutes with do:something command. Command parameters aren't supported at this stage.

Pick whichever option is better for you!

Queued jobs: SQS

Normally Laravel has to poll SQS for new messages, but in case of AWS Elastic Beanstalk messages will come to us – inside of POST requests from the AWS daemon.

Therefore, we will create jobs manually based on SQS payload that arrived, and pass that job to the framework's default worker. From this point, the job will be processed the way it's normally processed in Laravel. If it's processed successfully, our controller will return a 200 HTTP status and AWS daemon will delete the job from the queue. Again, we don't need to poll for jobs and we don't need to delete jobs - that's done by AWS in this case.

If you dispatch jobs from another instance of Laravel or if you are following Laravel's payload format you should be okay to go. If you want to receive custom format JSON messages, you may want to install Laravel plain SQS package as well.

Configuring the queue

Every time you create a worker environment in AWS, you are forced to choose two SQS queues – either automatically generated ones or some of your existing queues. One of the queues will be for the jobs themselves, another one is for failed jobs – AWS calls this queue a dead letter queue.

You can set your worker queues either during the environment launch or anytime later in the settings:

AWS Worker queue settings

Don't forget to set the HTTP path to – this is where AWS will hit our application. If you chose to generate queues automatically, you can see their details later in SQS section of the AWS console:

AWS SQS details

You have to tell Laravel about this queue. First set your queue driver to SQS in file:

Then go to and copy/paste details from AWS console:

To generate key and secret go to Identity and Access Management in the AWS console. It's better to create a separate user that ONLY has access to SQS.

Installation via Composer

To install simply run:

Or add it to composer.json manually:

Usage in Laravel 5

After adding service provider, you should be able to see two special routes that we added:

Environment variable is used to trigger binding of the two routes above. If you run the same application in both web and worker environments, don't forget to set to in your web environment. You don't want your regular users to be able to invoke scheduler or queue worker.

This variable is set to by default at this moment.

So that's it - if you (or AWS) hits , Laravel will process one queue item (supplied in the POST). And if you hit , we will run the scheduler (it's the same as to run in shell).

Usage in Lumen 5

Errors and exceptions

Please make sure that two special routes are not mounted behind a CSRF middleware. Our POSTs are not real web forms and CSRF is not necessary here. If you have a global CSRF middleware, add these routes to exceptions, or otherwise apply CSRF to specific routes or route groups.

If your job fails, we will throw a . If you want to customize error output – just customise your exception handler. Note that your HTTP status code must be different from 200 in order for AWS to realize the job has failed.

Job expiration (retention)

A new nice feature is being able to set a job expiration (retention in AWS terms) in seconds so that low value jobs get skipped completely if there is temporary queue latency due to load.

Let's say we have a spike in queued jobs and some of them don't even make sense anymore now that a few minutes passed – we don't want to spend computing resources processing them later.

By setting a special property on a job or a listener class:

We can make sure that we won't run this job later than 300 seconds since it's been queued. This is similar to AWS SQS "message retention" setting which can only be set globally for the whole queue.

To use this new feature, you have to use provided class that extends Laravel's default . A special exception will be thrown when expired jobs arrive and then it's up to you what to do with them.

If you just catch these exceptions and therefore stop Laravel from returning code 500 to AWS daemon, the job will be deleted by AWS automatically.

ToDo

  1. Add support for AWS dead letter queue (retry jobs from that queue?)

Video tutorials

I've just started a educational YouTube channel that will cover top IT trends in software development and DevOps: config.sys

Also I'm glad to announce a new cool tool of mine – GrammarCI, an automated typo/grammar checker for developers, as a part of the CI/CD pipeline.

Implications

Note that AWS cron doesn't promise 100% time accuracy. Since cron tasks share the same queue with other jobs, your scheduled tasks may be processed later than expected.

Post scriptum

I wrote a blog post explaining how this actually works.


All versions of laravel-aws-worker with dependencies

PHP Build Version
Package Version
Requires php Version >=5.5.0
illuminate/support Version 5.*|^6.0|^7.0|^8.0|^9.0|^10.0|^11.0
illuminate/queue Version 5.*|^6.0|^7.0|^8.0|^9.0|^10.0|^11.0
illuminate/bus Version 5.*|^6.0|^7.0|^8.0|^9.0|^10.0|^11.0
aws/aws-sdk-php Version ~3.0
illuminate/http Version 5.*|^6.0|^7.0|^8.0|^9.0|^10.0|^11.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package dusterio/laravel-aws-worker contains the following files

Loading the files please wait ....