cloudtasker 0.5.0 → 0.8.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 2fa7ae9744ddccc745bae1202b99e3891f9ba1035fe26eec3663cfa705ae22e1
-  data.tar.gz: 92d090b796b74c09803ccb4e7cf9468f230b9aeb5df51eb8c630b677988a49b4
+  metadata.gz: c4c3ce66208b1b45f5ec361f098ac3ceb1db562f2b4af45b3d42ef6ce54b6aac
+  data.tar.gz: 52ed1b155fea5ce6c307498f058b4b57d115b97e73ac7d0e1ab685c10c62672d
 SHA512:
-  metadata.gz: 7284aa0d993977e53c40d9ecdcc05cca8a0448a32f1189a5f50e38afc538581eac491c47443f0b9c39c0bd0288ce5d6693da0ae07efb8eee93a447276da6e656
-  data.tar.gz: 256a041b899f4a4b1e52f8d5ded83fc4bc370fd7ead98873658f60e107d60cf45c7817d019f13565d4cbd8bb2a0b58ce0a78db2aaaf7de023a37c299103c6a0b
+  metadata.gz: a3a4276e4494fc8912480a06cfe81f283340b516ec45cc9a504ffe02c733b42c3dfe3e14e9d132aacf93ff5d4f25534459d85467426497bc46383fbfc4c7fa08
+  data.tar.gz: ce32054e9e9f6fe496bcd3c36b6e15d012720834f71c237da1cbe82119a6a09d23c4b1463c11044261e890f3e1262fc94ed6dd42e86f72bfb340f79fed6cbbba

data/.gitignore

@@ -12,5 +12,8 @@
 /spec/dummy/tmp/
 /tmp/
 
+# Ignore lock files (e.g. Gemfile.lock)
+*.lock
+
 # rspec failure tracking
 .rspec_status

data/.rubocop.yml

@@ -1,5 +1,10 @@
 require: rubocop-rspec
 
+AllCops:
+  Exclude:
+    - 'gemfiles/vendor/**/*'
+    - 'vendor/**/*'
+
 Metrics/ClassLength:
   Max: 150
 

data/.travis.yml

@@ -2,11 +2,11 @@
 language: ruby
 cache: bundler
 rvm:
-  - 2.3
-  - 2.4
   - 2.5.5
+services:
+  - redis-server
 before_install: gem install bundler -v 2.0.2
-before_script: rubocop
+before_script: bundle exec rubocop
 gemfile:
   - gemfiles/google_cloud_tasks_1.0.gemfile
   - gemfiles/google_cloud_tasks_1.1.gemfile

data/CHANGELOG.md

@@ -0,0 +1,45 @@
+# Changelog
+
+## [v0.8.1](https://github.com/keypup-io/cloudtasker/tree/v0.8.1) (2019-12-03)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.8.0...v0.8.1)
+
+**Fixed bugs:**
+- Local dev server: ensure job queue name is kept when taks is retried
+- Rails/Controller: bypass Rails munge logic to preserve nil values inside job arguments.
+
+## [v0.8.0](https://github.com/keypup-io/cloudtasker/tree/v0.8.0) (2019-11-27)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.7.0...v0.8.0)
+
+## [v0.7.0](https://github.com/keypup-io/cloudtasker/tree/v0.7.0) (2019-11-25)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.6.0...v0.7.0)
+
+## [v0.6.0](https://github.com/keypup-io/cloudtasker/tree/v0.6.0) (2019-11-25)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.5.0...v0.6.0)
+
+## [v0.5.0](https://github.com/keypup-io/cloudtasker/tree/v0.5.0) (2019-11-25)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.4.0...v0.5.0)
+
+## [v0.4.0](https://github.com/keypup-io/cloudtasker/tree/v0.4.0) (2019-11-25)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.3.0...v0.4.0)
+
+## [v0.3.0](https://github.com/keypup-io/cloudtasker/tree/v0.3.0) (2019-11-25)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.2.0...v0.3.0)
+
+## [v0.2.0](https://github.com/keypup-io/cloudtasker/tree/v0.2.0) (2019-11-18)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.1.0...v0.2.0)
+
+## [v0.1.0](https://github.com/keypup-io/cloudtasker/tree/v0.1.0) (2019-11-17)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/c137feb1ceaaaa4e2fecac0d1f0b4c73151ae002...v0.1.0)
+
+
+
+\* *This Changelog was automatically generated by [github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)*

data/README.md

@@ -1,14 +1,40 @@
+[![Build Status](https://travis-ci.org/keypup-io/cloudtasker.svg?branch=master)](https://travis-ci.org/keypup-io/cloudtasker) [![Gem Version](https://badge.fury.io/rb/cloudtasker.svg)](https://badge.fury.io/rb/cloudtasker)
+
 # Cloudtasker
 
 Background jobs for Ruby using Google Cloud Tasks.
 
 Cloudtasker provides an easy to manage interface to Google Cloud Tasks for background job processing. Workers can be defined programmatically using the Cloudtasker DSL and enqueued for processing using a simple to use API.
 
-Cloudtasker is particularly suited for serverless applications only responding to HTTP requests and where running a dedicated job processing is not an option (e.g. deploy via [Cloud Run](https://cloud.google.com/run)). All jobs enqueued in Cloud Tasks via Cloudtasker eventually gets processed by your application via HTTP requests.
+Cloudtasker is particularly suited for serverless applications only responding to HTTP requests and where running a dedicated job processing is not an option (e.g. deploy via [Cloud Run](https://cloud.google.com/run)). All jobs enqueued in Cloud Tasks via Cloudtasker eventually get processed by your application via HTTP requests.
 
 Cloudtasker also provides optional modules for running [cron jobs](docs/CRON_JOBS.md), [batch jobs](docs/BATCH_JOBS.md) and [unique jobs](docs/UNIQUE_JOBS.md).
 
-A local processing server is also available in development. This local server processes jobs in lieu of Cloud Tasks and allow you to work offline.
+A local processing server is also available in development. This local server processes jobs in lieu of Cloud Tasks and allows you to work offline.
+
+## Summary
+
+1. [Installation](#installation)
+2. [Get started with Rails](#get-started-with-rails)
+3. [Configuring Cloudtasker](#configuring-cloudtasker)
+    1. [Cloud Tasks authentication & permissions](#cloud-tasks-authentication--permissions)
+    2. [Cloudtasker initializer](#cloudtasker-initializer)
+4. [Enqueuing jobs](#enqueuing-jobs)
+5. [Managing worker queues](#managing-worker-queues)
+    1. [Creating queues](#creating-queues)
+    2. [Assigning queues to workers](#assigning-queues-to-workers)
+6. [Extensions](#extensions)
+7. [Working locally](#working-locally)
+    1. [Option 1: Cloudtasker local server](#option-1-cloudtasker-local-server)
+    2. [Option 2: Using ngrok](#option-2-using-ngrok)
+8. [Logging](#logging)
+    1. [Configuring a logger](#configuring-a-logger)
+    2. [Logging context](#logging-context)
+9. [Error Handling](#error-handling)
+    1. [HTTP Error codes](#http-error-codes)
+    2. [Error callbacks](#error-callbacks)
+    3. [Max retries](#max-retries)
+10. [Best practices building workers](#best-practices-building-workers)
 
 ## Installation
 
@@ -77,13 +103,13 @@ Launch Rails and the local Cloudtasker processing server (or add `cloudtasker` t
 > cloudtasker
 ```
 
-Open a Rails console and enqueue your job
+Open a Rails console and enqueue some jobs
 ```ruby
   # Process job as soon as possible
   DummyWorker.perform_async('foo')
 
   # Process job in 60 seconds
-  DummyWorker.perform_in(10, 'foo')
+  DummyWorker.perform_in(60, 'foo')
 ```
 
 Your Rails logs should display the following:
@@ -136,13 +162,31 @@ Cloudtasker.configure do |config|
   # config.secret = 'some-long-token'
 
   # 
-  # Specify the details of your Google Cloud Task queue.
+  # Specify the details of your Google Cloud Task location.
   #
   # This not required in development using the Cloudtasker local server.
   #
   config.gcp_location_id = 'us-central1' # defaults to 'us-east1'
   config.gcp_project_id = 'my-gcp-project'
-  config.gcp_queue_id = 'my-queue'
+
+  #
+  # Specify the namespace for your Cloud Task queues.
+  #
+  # The gem assumes that a least a default queue named 'my-app-default'
+  # exists in Cloud Tasks. You can create this default queue using the
+  # gcloud SDK or via the `rake cloudtasker:setup_queue` task if you use Rails.
+  #
+  # Workers can be scheduled on different queues. The name of the queue
+  # in Cloud Tasks is always assumed to be prefixed with the prefix below.
+  #
+  # E.g.
+  # Setting `cloudtasker_options queue: 'critical'` on a worker means that
+  # the worker will be pushed to 'my-app-critical' in Cloud Tasks.
+  #
+  # Specific queues can be created in Cloud Tasks using the gcloud SDK or
+  # via the `rake cloudtasker:setup_queue name=<queue_name>` task.
+  # 
+  config.gcp_queue_prefix = 'my-app'
 
   # 
   # Specify the publicly accessible host for your application
@@ -194,7 +238,7 @@ Cloudtasker.configure do |config|
 end
 ```
 
-If your queue does not exist in Cloud Tasks you should [create it using the gcloud sdk](https://cloud.google.com/tasks/docs/creating-queues). 
+If the default queue `<gcp_queue_prefix>-default` does not exist in Cloud Tasks you should [create it using the gcloud sdk](https://cloud.google.com/tasks/docs/creating-queues). 
 
 Alternatively with Rails you can simply run the following rake task if you have queue admin permissions (`cloudtasks.queues.get` and `cloudtasks.queues.create`).
 ```bash
@@ -214,10 +258,15 @@ MyWorker.perform_in(5 * 60, arg1, arg2)
 # or with Rails
 MyWorker.perform_in(5.minutes, arg1, arg2)
 
-# Worker will be processed on specific date
+# Worker will be processed on a specific date
 MyWorker.perform_at(Time.parse('2025-01-01 00:50:00Z'), arg1, arg2)
 # also with Rails
 MyWorker.perform_at(3.days.from_now, arg1, arg2)
+
+# With all options, including which queue to run the worker on.
+MyWorker.schedule(args: [arg1, arg2], time_at: Time.parse('2025-01-01 00:50:00Z'), queue: 'critical')
+# or
+MyWorker.schedule(args: [arg1, arg2], time_in: 5 * 60, queue: 'critical')
 ```
 
 Cloudtasker also provides a helper for re-enqueuing jobs. Re-enqueued jobs keep the same worker id. Some middlewares may rely on this to track the fact that that a job didn't actually complete (e.g. Cloustasker batch). This is optional and you can always fallback to using exception management (raise an error) to retry/re-enqueue jobs.
@@ -241,6 +290,52 @@ class FetchResourceWorker
 end
 ```
 
+## Managing worker queues
+
+Cloudtasker allows you to manage several queues and distribute workers across them based on job priority. By default jobs are pushed to the `default` queue, which is `<gcp_queue_prefix>-default` in Cloud Tasks.
+
+### Creating queues
+
+More queues can be created using the gcloud sdk or the `cloudtasker:setup_queue` rake task.
+
+E.g. Create a `critical` queue with a concurrency of 5 via the gcloud SDK
+```bash
+gcloud tasks queues create <gcp_queue_prefix>-critical --max-concurrent-dispatches=5
+```
+
+E.g. Create a `real-time` queue with a concurrency of 15 via the rake task (Rails only)
+```bash
+rake cloudtasker:setup_queue name=real-time concurrency=15
+```
+
+When running the Cloudtasker local processing server, you can specify the concurrency for each queue using:
+```bash
+cloudtasker -q critical,5 -q important,4 -q default,3
+```
+
+### Assigning queues to workers
+
+Queues can be assigned to workers via the `cloudtasker_options` directive on the worker class:
+
+```ruby
+# app/workers/critical_worker.rb
+
+class CriticalWorker
+  include Cloudtasker::Worker
+
+  cloudtasker_options queue: :critical
+
+  def perform(some_arg)
+    logger.info("This is a critical job run with arg=#{some_arg}.")
+  end
+end
+```
+
+Queues can also be assigned at runtime when scheduling a job:
+```ruby
+CriticalWorker.schedule(args: [1], queue: :important)
+```
+
 ## Extensions
 Cloudtasker comes with three optional features:
 - Cron Jobs [[docs](docs/CRON_JOBS.md)]: Run jobs at fixed intervals.
@@ -256,7 +351,7 @@ When working locally on your application it is usually not possible to have a pu
 ### Option 1: Cloudtasker local server
 The Cloudtasker local server is a ruby daemon that looks for jobs pushed to Redis and sends them to your application via HTTP POST requests. The server mimics the way Google Cloud Tasks works, but locally!
 
-You can configure your applicatiion to use the Cloudtasker local server using the following initializer:
+You can configure your application to use the Cloudtasker local server using the following initializer:
 ```ruby
 # config/initializers/cloudtasker.rb
 
@@ -272,25 +367,28 @@ end
 
 The Cloudtasker server can then be started using:
 ```bash
-cloudtasker
-# or
 bundle exec cloudtasker
 ```
 
 You can as well define a Procfile to manage the cloudtasker process via foreman. Then use `foreman start` to launch both your Rails server and the Cloudtasker local server.
 ```yaml
 # Procfile
-web: rails s
-worker: cloudtasker
+web: bundle exec rails s
+worker: bundle exec cloudtasker
+```
+
+Note that the local development server runs with `5` concurrent threads by default. You can tune the number of threads per queue by running `cloudtasker` the following options:
+```bash
+bundle exec cloudtasker -q critical,5 -q important,4 -q default,3
 ```
 
 ### Option 2: Using ngrok
 
 Want to test your application end to end with Google Cloud Task? Then [ngrok](https://ngrok.io) is the way to go.
 
-First start your ngrok tunnel and take note of the :
+First start your ngrok tunnel:
 ```bash
-ngrok tls 3000
+ngrok http 3000
 ```
 
 Take note of your ngrok domain and configure Cloudtasker to use Google Cloud Task in development via ngrok.
@@ -299,9 +397,9 @@ Take note of your ngrok domain and configure Cloudtasker to use Google Cloud Tas
 
 Cloudtasker.configure do |config|
   # Specify your Google Cloud Task queue configuration
-  # config.gcp_location_id = 'us-central1'
-  # config.gcp_project_id = 'my-gcp-project'
-  # config.gcp_queue_id = 'my-queue'
+  config.gcp_location_id = 'us-central1'
+  config.gcp_project_id = 'my-gcp-project'
+  config.gcp_queue_prefix = 'my-app'
 
   # Use your ngrok domain as the processor host
   config.processor_host = 'https://your-tunnel-id.ngrok.io'
@@ -313,7 +411,7 @@ end
 
 Finally start Rails to accept jobs from Google Cloud Tasks
 ```bash
-rails s
+bundle exec rails s
 ```
 
 ## Logging
@@ -322,7 +420,7 @@ There are several options available to configure logging and logging context.
 ### Configuring a logger
 Cloudtasker uses `Rails.logger` if Rails is available and falls back on a plain ruby logger `Logger.new(STDOUT)` if not.
 
-It is also possible to configure your own logger. For example you can setup Cloudtasker with [semantic_logger](http://rocketjob.github.io/semantic_logger) by doing the following your initializer:
+It is also possible to configure your own logger. For example you can setup Cloudtasker with [semantic_logger](http://rocketjob.github.io/semantic_logger) by doing the following in your initializer:
 ```ruby
 # config/initializers/cloudtasker.rb
 
@@ -368,7 +466,7 @@ Cloudtasker::WorkerLogger.log_context_processor = lambda { |worker|
 }
 ```
 
-You could also decide to log all available context (including arguments passed to perform) for specific workers only:
+You could also decide to log all available context - including arguments passed to `perform` - for specific workers only:
 ```ruby
 # app/workers/full_context_worker.rb
 
@@ -383,7 +481,7 @@ class FullContextWorker
 end
 ```
 
-See the [Cloudtasker::Worker class](blob/master/lib/cloudtasker/worker.rb) for more information on attributes available to be logged in your `log_context_processor` proc.
+See the [Cloudtasker::Worker class](lib/cloudtasker/worker.rb) for more information on attributes available to be logged in your `log_context_processor` proc.
 
 ## Error Handling
 
@@ -394,7 +492,7 @@ Jobs failing will automatically return an HTTP error to Cloud Task and trigger a
 Jobs failing will automatically return the following HTTP error code to Cloud Tasks, based on the actual reason:
 
 | Code | Description |
-|------|-------------|-----------|
+|------|-------------|
 | 205 | The job is dead and has been removed from the queue |
 | 404 | The job has specified an incorrect worker class.  |
 | 422 | An error happened during the execution of the worker (`perform` method) |
@@ -515,7 +613,7 @@ MyWorker.new.perform({ 'foo' => 'bar', 'baz' => { 'key' => 'value' } })
 ```
 
 ### Be careful with default arguments
-Default arguments passed to the `perform` method are not actually considered as job arguments. Default arguments will therefore be ignored in contextual logging and by extensions relying on arguments such as the `unique-job` extension.
+Default arguments passed to the `perform` method are not actually considered as job arguments. Default arguments will therefore be ignored in contextual logging and by extensions relying on arguments such as the [unique job](docs/UNIQUE_JOBS.md) extension.
 
 Consider the following worker:
 ```ruby
@@ -566,6 +664,45 @@ Rails.cache.write(payload_id, data)
 BigPayloadWorker.perform_async(payload_id)
 ```
 
+### Sizing the concurrency of your queues
+
+When defining the max concurrency of your queues (`max_concurrent_dispatches` in Cloud Tasks) you must keep in mind the maximum number of threads that your application provides. Otherwise your application threads may eventually get exhausted and your users will experience outages if all your web threads are busy running jobs.
+
+#### With server based applications
+
+Let's consider an application deployed in production with 3 instances, each having `RAILS_MAX_THREADS` set to `20`. This gives us a total of `60` threads available.
+
+Now let's say that we distribute jobs across two queues: `default` and `critical`. We can set the concurrency of each queue depending on the profile of the application:
+
+E.g. 1: The application serves requests from web users and runs backgrounds jobs in a balanced way
+```
+concurrency for default queue: 20
+concurrency for critical queue: 10
+
+Total threads consumed by jobs at most: 30
+Total threads always available to web users at worst: 30
+```
+
+E.g. 2: The application is a micro-service API heavily focused on running jobs (e.g. data processing)
+```
+concurrency for default queue: 35
+concurrency for critical queue: 15
+
+Total threads consumed by jobs at most: 50
+Total threads always available to API clients at worst: 10
+```
+
+Also always ensure that your total number of threads does not exceed the available number of database connections (if you use any).
+
+#### With serverless applications
+
+In a serverless context your application will be scaled up/down based on traffic. When we say 'traffic' this includes requests from Cloud Tasks to run jobs.
+
+Because your application is auto-scaled - and assuming you haven't set a maximum - your job processing capacity if theoretically unlimited. The main limiting factor in a serverless context becomes external constraints such as the number of database connections available.
+
+To size the concurrency of your queues you should therefore take the most limiting factor - which is often the database connection pool size of relational databases - and use the calculations of the previous section with this limiting factor as the capping parameter instead of threads.
+
+
 ## Development
 
 After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
@@ -574,7 +711,7 @@ To install this gem onto your local machine, run `bundle exec rake install`. To
 
 ## Contributing
 
-Bug reports and pull requests are welcome on GitHub at https://github.com/alachaum/cloudtasker. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
+Bug reports and pull requests are welcome on GitHub at https://github.com/keypup-io/cloudtasker. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
 
 ## License
 
@@ -582,7 +719,7 @@ The gem is available as open source under the terms of the [MIT License](https:/
 
 ## Code of Conduct
 
-Everyone interacting in the Cloudtasker project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/alachaum/cloudtasker/blob/master/CODE_OF_CONDUCT.md).
+Everyone interacting in the Cloudtasker project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/keypup-io/cloudtasker/blob/master/CODE_OF_CONDUCT.md).
 
 ## Author
 

data/Rakefile

@@ -2,7 +2,13 @@
 
 require 'bundler/gem_tasks'
 require 'rspec/core/rake_task'
+require 'github_changelog_generator/task'
 
 RSpec::Core::RakeTask.new(:spec)
 
 task default: :spec
+
+GitHubChangelogGenerator::RakeTask.new :changelog do |config|
+  config.user = 'keypup-io'
+  config.project = 'cloudtasker'
+end