how to setup/run good_job with capistrano in vps?

[buncis]

hello I have vps on amazon lightsail and I want to add good_job to my app

I have added it smoothly in development mode with :async

problem is the readme told us that it prefer to run good_job in production with :external

but I don't understand how to run the good_job with capistrano on :external mode, and it seems there is no capistrano add ons for good_job

did I just need to ssh the server and run good_job with daemon mode or what?

[bensheldon]

I haven't used AWS Lightsail before, but it looks similar to Elastic Beanstalk, whose limitations I'm very familiar with 😞

GoodJob's default in production is :external but it's also supported running in :async in production in your web process. :async is how I run my own apps and many others run their enterprise stuff that way too. The only limitation is you can't scale your webservers and jobs independently. (I should make that clearer in the Readme 🙏🏻 )

The simplest way to change the configuration would be via an environment variable:

GOOD_JOB_EXECUTION_MODE=async

Or you could add Rails configuration:

# config/production.rb
config.good_job.execution_mode = :async

[buncis]

sorry I forgot to mention that I use nginx+passenger

is that enough or did I need to add another config like this one from the readme? is this config should be added at config/application.rb?
If my understanding is correct these codes means to restart and stop goodjob whenever a passenger starting a worker right?

if defined? PhusionPassenger
  PhusionPassenger.on_event :starting_worker_process do |forked|
    # If `forked` is true, we're in smart spawning mode.
    # https://www.phusionpassenger.com/docs/advanced_guides/in_depth/ruby/spawn_methods.html#smart-spawning-hooks
    if forked
      GoodJob.logger.info { 'Starting Passenger worker process.' }
      GoodJob.restart
    end
  end

  PhusionPassenger.on_event :stopping_worker_process do
    GoodJob.logger.info { 'Stopping Passenger worker process.' }
    GoodJob.shutdown
  end
end

# GoodJob also starts in the Passenger preloader process. This one does not
# trigger the above events, thus we catch it with `Kernel#at_exit`.
PRELOADER_PID = Process.pid
at_exit do
  if Process.pid == PRELOADER_PID
    GoodJob.logger.info { 'Passenger AppPreloader shutting down.' }
    GoodJob.shutdown
  end
end

[bensheldon]

I don't have a lot of experience with PhusionPassenger, but that overall looks correct (I tried to find those in the Passenger documentation but had to go to the code). 👍🏻

One difference I notice between Puma and Passengeris that it's possible that GoodJob may end up running in the "preloader process" if it is started before forking. That isn't ideal, but I'm not sure if it would actually happen in practice. If you see a GoodJob::Process.all record that corresponds to the preloader process, you might want to do something like this:

# Ensure GoodJob is shut down before any forking
GoodJob.shutdown

PhusionPassenger.on_event :starting_worker_process do |forked|
  # Always restart, whether in fork or non-fork mode
  GoodJob.logger.info { 'Starting Passenger worker process.' }
  GoodJob.restart
end

[dyerc]

Thank you both for your info on running GoodJob with Passenger. With the code from the readme or the version from @bensheldon above (if I'm interpreting everything correctly) at the end of application.rb, in the /good_job admin panel I still see two processes?

One has the proctitle "Passenger RubyApp: /path/to/app" and the other Passenger AppPreloader: /path/to/app". I don't know if this is the expected behaviour or a major problem in practice?

The bottom of my application.rb file looks like:

if defined? PhusionPassenger
  # Ensure GoodJob is shut down before any forking
  GoodJob.shutdown

  PhusionPassenger.on_event :starting_worker_process do |forked|
    # Always restart, whether in fork or non-fork mode
    GoodJob.logger.info { 'Starting Passenger worker process.' }
    GoodJob.restart
  end

  PhusionPassenger.on_event :stopping_worker_process do
    GoodJob.logger.info { 'Stopping Passenger worker process.' }
    GoodJob.shutdown
  end
end

# GoodJob also starts in the Passenger preloader process. This one does not
# trigger the above events, thus we catch it with `Kernel#at_exit`.
PRELOADER_PID = Process.pid
at_exit do
  if Process.pid == PRELOADER_PID
    GoodJob.logger.info { 'Passenger AppPreloader shutting down.' }
    GoodJob.shutdown
  end
end

[bensheldon]

One has the proctitle "Passenger RubyApp: /path/to/app" and the other Passenger AppPreloader: /path/to/app". I don't know if this is the expected behaviour or a major problem in practice?

I think it would be better for GoodJob to not be running in the Passenger AppPreloader, but I don't expect it to be actively harmful.

I think I'm going to have to set up Passenger myself and try to debug this. My hypothesis is that the initial GoodJob.shutdown is happening too early in the Rails framework loading process and GoodJob is subsequently being started for the first time (not re-started). I don't think I have a guard against that in GoodJob, so that could be a bug (or uncovered edge-case) in GoodJob, but I really want to poke at this myself.