I'm trying to deploy my app on railway.app with Redis (using Sidekiq).
I'm using buildpacks and the problem is I have 2 buildpacks and railway says in its documentation only one buildpack is executed in the Procfile.
This is my Procfile:
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq
How could I execute both processes?
From the railway documentation:
All you need to do is connect your GitHub account, create a new project, and then deploy your repo. We even support Procfiles out of the box. (Caveat: only a single process is supported for now) [0]
[0] - https://docs.railway.app/reference/compare-to-heroku#moving-from-heroku-to-railway
Looks like you would need multiple "projects" to invoke extra processes.
Related
I use the shopify_app gem to add webhooks to my app.
They work as expected in my local environment, but when I use the app from my Heroku environment, nothing happens when I do actions that should trigger the webhooks, nor is there any errors or anything at all in the logs.
Any ideas for how I should proceed to determine what the error is?
Update c.f. Davids comment (thanks for the input David):
I've added a call to the API to see which webhooks are installed for the app, and I can see the webhooks have not been succesfully installed - I will dig into this.
My procfile for Heroku has the following content:
web: bundle exec rails s
webpacker: ruby bin/webpack-dev-server
inventoryworker: bundle exec sidekiq -q default -q urgent -c 3
clock: bundle exec clockwork scheduler.rb
The Heroku setup is as follows:
one dyno for "web bundle exec rails s"
one dyno for "clock bundle exec clockwork scheduler.rb"
one dyno for "inventoryworker bundle exec sidekiq -q default -q urgent -c 3"
one off dyno for "webpacker ruby bin/webpack-dev-server"
I am expecting the webhooks to be handled by inventoryworker?
Thanks,
-Louise
Heroku logs. When you install the App, examine the logs. You'll see the webhooks be created or not. Ensure you setup Heroku correctly too. If you forgot a worker process, your webhook job won't run. Lots of little things to check.
Thanks to Davids hints I found out that the webhooks were not installed.
Looking at the logs during install I saw that the installation of webhooks works by adding a job to a queue - this queue name was not included in my configuration of starting sidekiq and for this reasonn webhooks were not installed.
Thanks,
-Louise
I'm confused how heroku and sidekiq work. My Procfile looks like:
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq -e $RAILS_ENV
Now inside my rails I run my sidekiq jobs in my code like:
SomeWorker.perform_async(some.id)
Now will this automatically somehow make this process run in the worker dyno?
If yes, how does it just know to run this out of process?
It is confusing because when I am in my main git folder I can run heroku commands and I know this are for my web dyno, but how do I then see the logs for my worker dyno or will these be in my same dyno logs?
When you setup your Procfile, you're telling Heroku to setup 2 types of dynos: web and worker. It's likely that these are using the same Rails app code but are starting up with different commands (bundle exec puma vs. bundle exec sidekiq). You then can scale however many VMs (dynos) that you need for each type of process.
The glue that holds the two together is Redis. When you run SomeWorker.perform_async(some.id) from your web process, you're adding a record to Redis describing a job to run. Your worker process watches Redis for new records and then processes them.
The Heroku logs show logs from all running dynos. So you should see logs from both your web and worker processes mixed in together.
I recently added the dokku-shoreman plugin and a Procfile so that my app runs both a worker and web process when I deploy. It looks like this:
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
However, now I when I use dokku run <app> <cmd> such as ...rake db:migrate a server and worker start running instead.
Currently the only way I know how to run the worker is with the Procfile. It's not a big issue to start it manually after I deploy - only I don't know how.
Though the ideal would still be to have the both the Procfile and dokku run working.
Update 2 Dokku now supports this http://dokku.viewdocs.io/dokku/deployment/process-management/
Update: checkout dokku-alt (no longer maintained) first - it's what I've switched to instead.
This is a known issue with dokku.
This was a temporary solution detailed in the issue discussion that worked for me:
rename actualProcfile to Procfile.real
create a new Procfile with the following content:
web: bundle exec foreman start -f Procfile.real
add gem 'foreman' as a dep in Gemfile
run bundle install
commit Procfile* and Gemfile*
push
I have an app on (ruby/rails) heroku. It's running 1 web and 1 worker (for example)
I want to be able to tell what "type" of dyno the app is running under.
I suspect it's a simple thing to tell, but I can't see anything that tells me how to tell.
I don't know if there's a more elegant way to do this, but you can set an environment variable in your Procfile:
web: bundle exec ... PROC_TYPE=web
worker: bundle exec ... PROC_TYPE=worker
Then in your rails code, you can check ENV['PROC_TYPE']
EDIT: more detailed Procfile example, typical for a rails app:
web: bundle exec rails server -p $PORT PROC_TYPE=web
worker: bundle exec rake jobs:work PROC_TYPE=worker
New to Rails and very new to Delayed Jobs.
Got one that's supposed to be triggered after 5 minutes. I finally got it to work so that if I run
rake jobs:work
in my terminal, the job starts up and works correctly. If I CTRL-C and exit that action in my terminal, the delayed job stops working correctly. This is one thing on my local server and another on Heroku, where I have to start up the delayed job using
heroku run rake jobs:work
I looked into the new Heroku toolbelt and downloaded the gem they suggest for worker maintenance, foreman, but when I run "foreman start", I get this error
ERROR: procfile does not exist
I don't know what a procfile is, I'm afraid of breaking things after spending pretty much a day debugging my delayed_jobs actions, and I want to do this right to make sure it works instead of figuring out some hacky fix that breaks down later -- so I figured I should ask this question, however obnoxiously vague it may be.
Should I be using foreman for this? Or workless? (Saw that in another SO question). Where's my procfile? Should I do anything with it?
Thanks,
Sasha
You should be using a procfile to set up your Heroku processes, this is the standard method that Heroku uses to define and control the processes.
If you haven't utilised a procfile to this point everything will probably still work as Heroku adds some default processes when you push a Rails app, including both the web and worker processes. The default worker process is set to delayed job.
Foreman was developed in order to set up your local machine to use the same approach but, unlike the Heroku service, Foreman actually requires a procfile to be present to control the services that are started when Foreman is started as it doesn't know how to setup defaults.
I would suggest creating a procfile, placed in the root directory of your project, to ensure that your processes are set up and operating in the same manner on your local machine as on Heroku. If you want to mimic what Heroku sets up automatically you add the following to the procfile depending on whether you are using the Thin web server (which Heroku recommends) or not.
With Thin in your gemfile:
web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT
worker: bundle exec rake jobs:work
Without a special web server (eg you are using webrick, the rails default):
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
Once this file is in place you can run foreman on your local machine and it will start your web server and delayed_job workers automatically.
Running through this process will only impact starting delayed_job on the local machine. As you are running the exact same command bundle exec rake jobs:work as you are currently using there should be no impact on your dj actions in either locally or on Heroku. Obviously some testing is required to make suer this is actually the case.
Workless is designed to scale workers on Heroku so that you don't have to pay for them when there is no work available. It has no bearing on the procfile or defining how to actually start a dj worker process.
as far as I know, there are 2 version of delayed_job:
original(tobi's) https://github.com/tobi/delayed_job
collectiveidea's fork: https://github.com/collectiveidea/delayed_job
when using the collectiveidea version, you should start it as below:
# Runs two workers in separate processes.
$ RAILS_ENV=production script/delayed_job -n 2 start
I am not familiar with delayed_job on Heroku, please follow its instructions.