I am trying to configure Sidekiq in a Rails 4.1.4 application that connects to an AWS Elasticache Node running Redis.
I set up my Redis server, and followed the directions in this AWS Guide:
http://docs.aws.amazon.com/opsworks/latest/userguide/other-services-redis-cluster.html
And my Redis server was running properly and my app server could connect properly.
I followed these directions to set up Sidekiq to run on the external worker:
https://github.com/mperham/sidekiq/wiki/Advanced-Options
Whenever I visited my app server at the /sidekiq url to view the Sidekiq panel, I kept getting the error on screen saying "Internal Server Error".
My Unicorn error logs do not contain any relevant information, so I am not sure how to get this working. AWS support did not have any answers either.
Any information would be greatly appreciated. Thanks!
This problem is normally seen when assets are not compiled or are not configured to be served from your environment. Start your app/sidekiq in production mode (or whatever environment this is referring to) after changing the production config to point to your local resources (redis+db) and see if the pages are able to load then.
RAILS_ENV=production bundle exec unicorn
RAILS_ENV=production bundle exec sidekiq -c config/sidekiq.yml
Related
I'm looking to deploy solr-8 in production as standalone mode with Ruby on Rails application. While running bundle exec rake sunspot:solr:reindex getting this error
RSolr::Error::Http - 500 Internal Server Error
Any help would be appreciated!
using gem sunspot in development and is working fine with standalone solr-8 on local machine.
Solr is running in cloud mode. Please share the configuration which is used to talk to solr and rails for index
It's really straight forward setup but took long time for me to resolve.
In standalone mode it is bit tricky to communicate with rails
we need to copy schema.xml and solrconfig.xml to server/solr/your-core/conf/
as Solr-8 have some deprecation warning. Please carefully read warnings.
Once you copied files restart solr and run
rake sunspot:solr:reindex
Sorry, this is my first time deploying my site on Heroku. The main elements of website does run, but none of my fetch requests are working. So, none of the data from my Rails backend is rendering. I've been receiving this in my console whenever the site is supposed to make a fetch request (to localhost:3000) => "Failed to load resource: net::ERR_CONNECTION_REFUSED"
Should I not be trying to fetch from localhost when my site is deployed on heroku?
I've tried creating a Procfile, updating my production and development environments, etc.
web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-production}
I made new project with Rails and Vue using webpacker. Firstly I got strange error
Cannot read property 'compile' of undefined
So I hit yarn upgrade webpack-dev-server --latest which was the correct answer and helped me but then when I hit: ./bin/webpack-dev-server my webpack dev server starts and all looks fine but at http://localhost:3035/ I am getting the "Cannot GET /" message.
JS console: Failed to load resource: the server responded with a status of 404
I also tried to reinstall webpacker...
When running your Rails application locally you'll need to start both the rails server and the webpack-dev-server. I typically use foreman with a simple Procfile, although you can also start both of these by hand.
# Procfile
server: bin/rails server
assets: bin/webpack-dev-server
Then you can run the Procfile and startup both servers with: foreman start
The webpack-dev-server port (3035) is not the port you'll be connecting to for seeing your application. Start up both servers and go to localhost:3000 and you'll see your rails application root path page (or default rails page if you dont have routes yet).
One thing to note, if you're using Foreman to start your servers it will default your rails port to 5000 instead of 3000. You can configure this either in the Procfile or when you call foreman if you want different behavior.
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.
I'm attempting to mimic, as close as possible, the Heroku deployment environment but in actual development mode for a Rails app. In other words, I'd like more verbose output from the thin console logs web and worker processes and I'd like for the assets pipeline to be refreshed appropriately vs having to run a command to refresh them.
The reason I have to do this is due to some testing of additional workers that need to function during development and testing phases.
Currently I have foreman running a procfile locally which spawns thin. Here are the commands that it steps through:
First I start it via Foreman with RACK_ENV=development PORT=3000 foreman start --port $PORT
Second, in my Procfile I have:
`web: bundle exec thin start -p $PORT -e $RACK_ENV`
`worker: bundle exec ruby worker.rb`
These execute just fine, however I have two seeming problems that I'd like to overcome:
A) I have to run bundle exec rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile so it seems as though thin does not honor a development mode that does not require asset precompilation. I tried to add config.assets.compile = true into my config/environments/development.rb, but that did not seemingly help the situation. The real problem seems to be that actual images in the assets folder are not refreshed without this manual preocompile step.
B) I am not seeing any more verbose development level logging in the output console. I would like to see a verbose request log as well as the debug print statements that I have in my worker script. None of these propagate back up to the console log where the foreman command is initially run.
The thought has come to mind that perhaps I should just have a Procfile.development and in there have webrick instead of thin, however that only resolves point A and leaves the question of point B above.
Thus my question, how can I accomplish my original designs using foreman + thin?
I ended up approaching this at a little different slant and got through the issue. The core problem I was having was the the logging facility was being overridden by one of gem's we've been using and therefore had to force logging to use the Rails logger with more verbosity:
How to increase Heroku log drain verbosity to include all Rails app details?