Development
Google Cloud Tasks with Rails Active Job
You use Rails on Cloud Run or any other serverless runtime? This article explains how to run Active Job via Google Cloud Tasks using the latest version of the cloudtasker gem.
TL;DR; It is now possible to use Google Cloud Tasks with Active Job using the cloudtasker gem. If you  intend to deploy your Rails app on Cloud Run, Cloudtasker is the easiest solution to get started with background jobs on Rails.
Serverless has become an integral part of deployment infrastructures nowadays. While not designed for it originally, Rails can easily be deployed in serverless mode using platforms like GCP Cloud Run.
Cloud Run takes care of scaling your applications automatically based on volume on concurrent requests and bills you per millisecond of CPU usage. It also allows you to scale down to zero instances, making it a perfect choice for test environments.
Your app is a bit slow to boot? Cloud Run  also takes care of keeping a warm pool of instances to ensure your service doesn't suffer from slow starts.
For all the reasons above, Cloud Run is certainly one of the most (cost) efficient infrastructure to deploy your Rails app.
The problem? Well with serverless you can't rely on background processes anymore - everything must be managed as an HTTP request. If your application requires background jobs then traditional solutions such as Sidekiq or Resque will not work because they require an active daemon.
Introducing Cloudtasker
Comes cloudtasker, the easiest way to have background jobs for Rails on Cloud Run. We wrote previously about cloudtasker, but this time it's even easier thanks to a native Active Job integration for Rails.
Cloudtasker is an interface to Google Cloud Tasks, a Google-managed job scheduler. It allows you to enqueue and process jobs in exactly the same way as other background job solutions (Active Job, Sidekiq, Resque).
When you enqueue jobs using Cloudtasker, they get pushed to Google Cloud Tasks. When the job is due for processing, Cloud Tasks sends a webhook to your application to process the job. Because this whole enqueue/process logic is HTTP based, it's completely compatible with serverless deployments.
What about working locally then? We've got you covered. Cloudtasker is shipped with a local server that mimics Cloud Tasks so you can work locally without relying on ngrok to receive webhooks.
Getting started with Cloudtasker and Active Job
In order to run jobs locally with Cloudtasker you'll need to install and run Redis. Redis is only required when working locally with the local processing server, not in production.
Then add the following to your Gemfile:
Add an initializer to configure Cloudtasker:
Edit your config/application.rb and configure Active Job to use cloudtasker:
You're done with the setup part. Now let's define a job.
Launch Rails and the cloudtasker local processing server. This local processing server is only required in development to mimic Google Cloud Tasks locally.
Now launch a Rails console and try enqueuing your first job.
That's it! You should now see your jobs running in your logs.
Deploying to production
In order to deploy to production we'll need to add a few Cloud Task configuration details in our Cloudtasker initializer.
You should now create the Cloud Task queues in your project. Active Jobs will be pushed to the gcp_prefix-queue_as queue (e.g. myapp-critical). By default, this is gcp_prefix-default (e.g. myapp-default).
You can create your job queues via the Cloud Task UI, using the gcloud CLI or using the cloudtasker-provided rake task.
The bare minimum is to create the gcp_prefix-default queue.
Once you are done creating your queues, just deploy your app and enjoy seamless background jobs!
Kudos to the author
I'd like to thank Roberto Quintanilla for developing the Active Job integration. It's a really great addition to the gem.
.webp)
