I've seen posts where the suggestion was to create an initializer or create a config.after_initialize block in the config/application.rb file; however, this doesn't properly work for me because I'm relying on Rails credentials.
For example, I have a class called SlackBot that basically sends a message to our slack channel. I'd like to create an initializer that sends a message once the rails s command is run, but the config.after_initialize doesn't actually work since the SlackBot class pulls creds from Rails.application.credentials
I get the following error when trying to do this:
ubuntu#bf29b8edfeea:~/myapp$ rails s --binding 0.0.0.0 -p 80
=> Booting Puma
=> Rails 6.1.4.4 application starting in development
=> Run `bin/rails server --help` for more startup options
Exiting
/usr/local/bundle/gems/activesupport-6.1.4.4/lib/active_support/message_verifier.rb:176:in `verify': ActiveSupport::MessageVerifier::InvalidSignature (ActiveSupport::MessageVerifier::InvalidSignat
ure)
from /usr/local/bundle/gems/activesupport-6.1.4.4/lib/active_support/message_encryptor.rb:154:in `decrypt_and_verify'
from /usr/local/bundle/gems/activesupport-6.1.4.4/lib/active_support/messages/rotator.rb:22:in `decrypt_and_verify'
from /home/ubuntu/myapp/app/helpers/user_helper.rb:19:in `decrypt_data'
The only way I can get rid of this error of course is by removing the custom initializer.
Is there a way that I can call an initializer or method after rails is fully initializer, perhaps as the last step that runs?
According to The Rails Initialization Process of the Rails official reference, the last file to be executed in the initialization sequence is config/environment.rb (Note that although the reference states the last one is config/application.rb, the file should have been in default require-d in the earlier process).
In Rails 6 (or maybe earlier ones, too?), the last line in config/environment.rb is
Rails.application.initialize!
So, if you write your own statements after the line in the file config/environment.rb, your Rails app must have been fully initialized by the time your statements are executed.
Related
Before, I added code to a file called config/initializers/remote_publishers.rb which set up a connection to RabbitMQ using the Bunny gem on server startup.
However, this is now also executed when running rails c, rails g model SomeModel foo:integer, rails db:migrate etc.
For this app, the RabbitMQ-connection only makes sense when rails is started using rails s(erver).
What is the proper way to conditionally execute this code? Is there a way to see if Rails is starting as server, or only as task-runner?
What web server are you using? On Puma, for example, you can use
on_worker_boot do
# Establish RabbitMQ connection
end
Another possibility might be to check if defined?(Rails::Server) in your initializer: this should only be true when running in the context of the web server.
I would like to use information stored within a the credentials.yml.enc file for a Rails 5.2 app. However, I am struggling to get a command which works perfectly within the console to behave in the same way when inserted into a .rb file.
In the Rails console (on my local development computer) Rails.application.credentials.username returns "my_username"
If I insert this line within a very simple db_backup.rb file as shown below, I get the error:
NameError: uninitialized constant #<Class:#<Backup::Config::DSL:0x00007fb0db941d10>>::Rails
db_backup.rb:
Model.new(:db_backup, 'Description for db_backup') do
##
# PostgreSQL [Database]
#
database PostgreSQL do |db|
db.username = Rails.application.credentials.username
end
end
Please could you explain why I get the different behaviour when using exactly the same line of code in the Rails console / within a .rb file?
The context in which the code is executed is not the same. One is the rails console and the other is the backup command
What happens when you load the Rails console
Launching the rails console means you launch all of the rails stack before executing your code against it. The Rack applications like Sinatra, Rails etc. use the config.ru file as a convention for which file should be run to boot. (You can explore the rabbit hole if you want to have a deep understanding of this)
It means that the vast majority of errors you can encounter when will occur during the console boot, preventing you from executing anything in the console (because boot failed). Instead it will print the stack trace errors for you to figure out what went wrong so you can correct and give it another try.
TL; DR Rails.application.credentials.username in console is executed after all of the Rails stack (models, dependencies, initializers) has loaded in a particular order
What happens when you run the backup command
The backup command is defined here in the bin repo of the backup repo
It goes like this
#!/usr/bin/env ruby
# encoding: utf-8
require File.expand_path("../../lib/backup", __FILE__)
Backup::CLI.start
If you open the required file lib/backup.rb and look around in the Gemfile, you won't fine a place where you have a dependency or a define for the Rails constant.
Thus when you run the backup command and execute your db_backup.rb, the constant Rails called here is ... not defined. Ruby being kind will try to find a nested version of this constant in the current scope which is the Model.new do; end block.
It is still not defined which ruby tells you about with NameError: uninitialized constant #<Class:#<Backup::Config::DSL:0x00007fb0db941d10>>::Rails.
#giglemad gives a great explanation of the issue of class resolution in the execution context (rails console vs. running of the backup ruby file).
To fix your error, just let the code know to use the top-level class lookup (::Rails):
Model.new(:db_backup, 'Description for db_backup') do
##
# PostgreSQL [Database]
#
database PostgreSQL do |db|
db.username = ::Rails.application.credentials.username
end
end
If you're still seeing the missing Rails constant, you'll need to put your script in either a rake task, or require your rails environment.
I ended up resolving this by simply adding the line below to the top of my db_backup.rb:
require './config/environment' # added to enable credentials to be read from Rails environment
I'm have a server where I deploy using capistrano and I use delayed_jobs to do some mailing but at my server for some reason the jobs do not execute. The delayed_job process is running (running bin/delayed_job status answers me correctly saying there's a process there by some pid), but I don't know if the process just isn't executing my jobs or even if my jobs aren't being enqueued. Locally it all works fine, but at production staging in the server it does not.
I'd like to know if there's a way I can at least check what jobs are there, since I can't do it by accessing the console
Another gem that works with delayed job is delayed-web which you can find here https://github.com/tatey/delayed-web
you add it to your gemfile
gem 'delayed-web'
then run
rails generate delayed:web:install
this will generate an initializer file delayed_web.rb under config/initializers with the following:
Rails.application.config.to_prepare do
Delayed::Web::Job.backend = 'active_record'
end
and in config/application.rb this will be added for you as well by the generator
# config/application.rb
config.assets.enabled = true
config.assets.precompile << 'delayed/web/application.css'
In routes.rb it may add a route as well but if you are using devise then maybe you want to restrict access to admin user(s) only as follows:
authenticated :user, -> user { user.admin? } do
mount Delayed::Web::Engine, at: '/jobs'
end
Ok so I'm checked my jobs through the database itself, I entered psql through postgres user and did some queries in the delayed_jobs table, you can also try doing RAILS_ENV=production bin/delayed_jobs run (for rails 4, rails 3 use "script/" instead of "bin/") which will show you what the workers are doing while they execute the job.
You can also, as Swards commented above, use a gem to have a web interface for delayed_jobs: https://github.com/ejschmitt/delayed_job_web
If you still wanna see what was my problem with the email sending I've opened another question because it got to far away from what this one was about: What port to use sending email with SMTP (mailgun) in rails app on production server (DigitalOcean)?
I need to run a command after or before starting Rails. It will start a server on port 9292 so my chat app will work.
This command should preferably be executed automatically with Rails (on production and development).
How do we do that in Rails 4?
Is Capistrano the only option? Can we schedule it to be executed when Rails starts?
Use capistrano and forman or systemd to manage your chat server instance, like, for example you would do for sidekiq.
A good start would be : http://anlek.com/2015/01/using-foreman-with-upstart-capistrano/
You have 2 options that I know of if you don't want to use Capistrano. In your config/application.rb
config.after_initialize do
# ....
end
http://guides.rubyonrails.org/configuring.html
or you can write a custom initializer that is run with on_server_start event.
There's a whole section of config/ intended for startup behavior: config/initializers/. If you need to do anything as part of the startup of your app, you can create an initializer file here, and it will automatically get run as Rails starts.
To do this, simply create a new file: config/initializers/chat_app.rb:
# This file will start and establish an initial connection to the chat app
`chat-app --some-arg` # <== The chat app
We use this for various startup and system sanity checks for the application. It's independent of your deployment, so if you need it for other deployment purposes, creating a Capistrano (or even Rake) task is the better option.
I'm using rufus-scheduler for handling cron jobs for a Rails 3.2.x app. The root worker.rb is being fired off by foreman (actually upstart on this particular server) and therefore when it starts off it does not have the Rails context in which to operate. Obviously when I attempt to call logger or Rails.logger it will fail each time.
I'm using log4r as a replacement for the default Rails Logger, which is quite nice, but I am wondering what the proper solution for this problem would be:
1) Do I need to give the script the Rails context at startup (it is simply running rake tasks right now so it ends up getting the Rails environment when the worker script hands off to the rake task and I fear giving the script the Rails env before running the timed task would be overkill since it takes so long to fire up the env)? or
2) Should I just set up log4r as one would do in a non-Rails Ruby script that simply reads in the same log4r.yml config that the Rails app is using and therefore participate in the same log structure?
3) Or some other option I'm not thinking of?
Additionally, I would appreciate either an example or the steps that I should consider with the recommended implementation.
For reference, I followed "How to configure Log4r with Rails 3.0.x?" and I think this could be helpful when integrated with the above: "Properly using Log4r in Ruby Application?"
I think this might be what you're looking for..
Use this within the worker itself, and create a custom named log file
require 'log4r'
logger = Log4r::Logger.new('test')
logger.outputters << Log4r::Outputter.stdout
logger.outputters << Log4r::FileOutputter.new('logtest', :filename => 'logtest.log')
logger.info('started script')
## You're actual worker methods go here
logger.info('finishing')