docker + rail + redis – i salvataggi non sono in esecuzione

Ho creato un ambiente docker che crea 3 immagini: rotaie, postgresql e redis. Ha funzionato abbastanza bene, ma ho scoperto che la mia image di redis non sembra avere i lavoratori in esecuzione.

Docker Info

Il mio docker-compose.yml è il seguente

web: build: . command: bundle exec unicorn -p 3000 -c config/unicorn.rb volumes: - .:/fitmo - ../fitmo-core:/fitmo-core ports: - "3000:3000" links: - db - redis environment: - REDIS_URL=redis://redis:6379 db: build: ./db/docker-files ports: - "5432" redis: image: redis:2.8 ports: - "6379" 

Resque Config

 require 'resque' require 'resque-scheduler' require 'resque_scheduler/server' require 'appsignal/integrations/resque' require 'yaml' if Rails.env.test? require 'mock_redis' $redis = MockRedis.new else uri = URI.parse(ENV['REDIS_URL']) $redis = Redis.new(host: uri.host, port: uri.port, password: uri.password) end Resque.redis = $redis Resque.schedule = YAML.load_file(File.join(Rails.root, 'config/resque_schedule.yml')) Resque.before_fork do defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnect! end Resque.after_fork do defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection end module Resque def queued_jobs queues = Hash.new Resque.queues.each do |queue| jobs = [] Resque.peek(queue, 0, 5000).each do |job| jobs.push({klass: job['class'], args: job['args']}) end queues[queue] = jobs end queues end def queued?(klass, *args) queued_jobs.select do |job| job[:klass] == klass.to_s && job[:args] == args end.any? end def enqueue_once(klass, *args) enqueue(klass, *args) unless queued?(klass, *args) end end 

Gemme di Rubino

Di seguito vengono indicate le gemme pertinenti utilizzate. Le versioni commentate sono le ultime versioni delle gemme, ma non credo che questo sia un problema dato che le versioni correnti funzionano bene negli ambienti Heroku. Ho incluso anche il messaggio di salvataggio e il pianificatore per la completezza. Non sono in gioco per la questione

 gem 'redis', '3.0.7' #'~> 3.2.0' gem 'resque', '~> 1.25.2' #'~> 1.25.2' gem 'resque_mailer', '~> 1.0.1' #'~> 2.2.7' gem 'resque-scheduler', '~> 2.5.5' #'~> 4.0.0' 

Testare le informazioni

Ho confermato che il redis è accessibile dal contenitore web tramite telnetizzazione per ospitare redis sulla port 6379. Ho anche prodotto il valore di Rescue.info che mostra che ci sono elementi in coda ma ora i lavoratori in esecuzione

 resque info: {:pending=>1, :processed=>0, :queues=>2, :workers=>0, :working=>0, :failed=>0, :servers=>["redis://redis:6379/0"], :environment=>"development"} 

Sono bloccato a questo punto perché non so come far funzionare i lavoratori. Eventuali suggerimenti?

Ho potuto risolvere questo problema includendo una nuova image da avviare sulla base dell'image web. Il mio nuovo file docker-compose.yml è il seguente (aggiunta nuova image del lavoratore):

 web: build: . command: bundle exec unicorn -p 3000 -c config/unicorn.rb volumes: - .:/fitmo - ../fitmo-core:/fitmo-core ports: - "3000:3000" links: - db - redis environment: - REDIS_URL=redis://redis:6379 worker: build: . command: bundle exec rake environment resque:work QUEUE=* volumes: - .:/fitmo - ../fitmo-core:/fitmo-core links: - db - redis environment: - REDIS_URL=redis://redis:6379 db: build: ./db/docker-files ports: - "5432" redis: image: redis:latest ports: - "6379" 

C'è un problema successivo se hai installato gem AppSignal e stai estendendo i tuoi lavori con "estendere Appsignal :: Integrations :: ResquePlugin" Il problema è che ResquePlugin tenta di scrivere una socket in una cartella tmp e Docker non lo consente .

Sono sicuro che ci sia una configuration Docker per consentire la scrittura del socket ma ho invece creato una sezione di sviluppo nel mio file appsignal.yml e impostato il flag attivo a falso. L'ultima versione della gem Appsignal tenta ancora di scrivere alla presa anche quando è attivo = falso. La versione 0.13.0 della gem (da rilasciare domani) dovrebbe avere una correzione per questo in atto

appsignal.yml

 production: api_key: "xxxxxxxxxxxxxxxxxxxxxxxx" active: true slow_request_threshold: 200 staging: api_key: "xxxxxxxxxxxxxxxxxxxxxxxx" active: true slow_request_threshold: 200 development: api_key: "xxxxxxxxxxxxxxxxxxxxxxxx" active: false slow_request_threshold: 200 

Nella pagina github di resque, https://github.com/resque/resque , viene indicato che è necessario eseguire lavori bin/resque work per avviare il polling della coda e avviare i lavoratori.