I have set up a bunch of initialising tasks that call various APIs and save them to constants for access in my controller (this may well be bad form, but I don't need them saved to the database for now).
Is there any way to run
rails s
without initializers, such as a setting up a specific environment that ignores them, or would this be bad practice?
There are option to group initializers and then run only certains of them (see this answer), but if this is a temporary situation, you have a lot of options:
Just comment out the ones you don't need (if this is just a test on your machine)
Add a if Rails.env.development? clause to those you don't want to run locally (if this is for all development environments)
Related
I'm working on a Rails application and I am attempting to organize my secret_key_base and related important secrets (Think API keys, database credentials, etc.)
I am trying to find a way to setup something like the following, under /config
/config
credentials.yml.enc
master.key
/config/credentials
development.yml.enc
development.key
production.yml.enc
production.key
test.yml.enc
test.key
First Question:
Is it that secret_key_base exists in /config/credentials.yml.enc, which is loaded (first?) and then the credentials are loaded for the environment rails is running in? Or should I create a different secret_key_base for each environment?
Second Question:
No matter what I do, when I run in development or test, tmp/development_secret loads first. In addition, whenever I try to access my secrets in development, (Rails.application.secret_key_base) as referenced here: What's the correct way of defining secret_key_base on Rails 6, I run into an issue where I only ever receive nil when looking for secrets I've defined in my development.yml.enc, which I assume is because it's not loading anything in that file, it's going to tmp/development_secret and not finding anything else (Maybe I'm wrong.)
Goals:
Stop tmp/development_secret from being created, and instead access
secrets using the specific .yml.enc file depending on the
environment.
Understand why /config/credentials.yml.enc exists if it doesn't
load in all the environments. If it doesn't, then it isn't clear when it loads.
Why?
Using config/database.yml as an example, I want to store different creds for each environment, but none of them in version control. (I want nobody but a few to have production.) However, I want to access them the exact same way in all of my environments. Not having creds load in production because of an issue with a .yml file will crash my app, so I don't want to load them differently in test/development.
Put together a blog post about this because searching for documentation on this feature is painful. It's a really easy thing because then only the master.key, and production.key would need loaded as ENV variables which is great. (Or possibility just one of them.)
This really should be a simple, out-of-the-box thing, but it's hard to find real documentation on best practices.
I've found the answer, at least the one I'm looking for. You can have your initializer load whatever file you want by overriding the defaults.
config.credentials.content_path = 'config/credentials/development.yml.enc'
config.credentials.key_path = 'config/credentials/development.key'
https://edgeapi.rubyonrails.org/classes/Rails/Application.html
I'm using Twilio for an app and on production I set the auth token using heroku's CLI. I'm using sms-spec (https://github.com/monfresh/sms-spec) to test my app's Twilio integration locally. I want to set ENV['TWILIO_AUTH_TOKEN'] to my token in the test environment.
I use guard to auto-run my tests whenever I make changes so I don't want to have to manually set the ENV variable each time I run tests. I also don't want to put the token in my source code for security reasons.
Is there a way I can set the ENV variable for my local test environment such that it is permanent and not in my source? I've spent a few hours researching this and can't seem to find a good explanation of how to do this. Any help is much appreciated :)
Two approaches:
Use a gem like Dotenv (link). This is the approach I use in most of my applications for development. Simply include the gem in your gemfile, bundle install and then store any environment variable settings in a top level file called .env. Restart your rails server and ENV will be automatically loaded. Very easy to use and convenient.
If you are flexible on the ENV part, and you are running Rails 4.1+, you can use config/secrets/yml. This is documented very well in the Rails 4.1 release notes, Section 2.2. So, in your case, you would set it up like so:
development:
twilio_auth_token: verysecretstring
Then, in your initializer, instead of referencing ENV['TWILIO_AUTH_TOKEN'], you would use Rails.application.secrets.twilio_auth_token. I haven't tried this myself, but it is on my list as I would rather use native Rails functionality than a separate gem.
Of course, any files which contain your secrets needs to be safeguarded carefully. At a minimum, make sure you include in .gitignore so that your secrets do not find their way into your code respository.
I read a post about the rails load_paths, here is the link.
But, I am still confused about the difference between the autoload_paths and eager_load_paths:
I have tested them in a newly created Rails 4 project. It seems that they run the same way, that auto-reload in the development mode but in the production mode.
Author of the linked article here. Here's an attempt to clear up the confusion, going off of #fkreusch's answer.
In Ruby you have to require every .rb file in order to have its code run. However, notice how in Rails you never specifically require any of your models, controllers, or other files in the app/ dir. Why is that? That's because in Rails app/* is in autoload_paths. This means that when you run your rails app in development (for example via rails console) — none of the models and controllers are actually required by ruby yet. Rails uses special magical feature of ruby to actually wait until the code mentions a constant, say Book, and only then it would run require 'book' which it finds in one of the autoload_paths. This gives you faster console and server startup in development, because nothing gets required when you start it, only when code actually needs it.
Now, this behavior is good for local development, but what about production? Imagine that in production your server does the same type of magical constant loading (autoloading). It's not the end of the world really, you start your server in production, and people start browsing your pages slightly slower, because some of the files will need to be autoloaded. Yes, it's slower for those few initial requests, while the server "warms up", but it's not that bad. Except, that's not the end of the story.
If you are running on ruby 1.9.x (if I recall correctly), then auto-requiring files like that is not thread safe. So if you are using a server like puma, you will run into problems. Even if you aren't using a multi-threaded server, you are still probably better off having your whole application get required "proactively", on startup. This means that in production, you want every model, every controller, etc all fully required as you start your app, and you don't mind the longer startup time. This is called eager loading. All ruby files get eagerly loaded, get it? But how can you do that, if your rails app doesn't have a single require statement? That's where eager_load_paths come in. Whatever you put in them, all the files in all the directories underneath those paths will be required at startup in production. Hope this clears it up.
It's important to note that eager_load_paths are not active in development environment, so whatever you put in them will not be eagerly required immediately in development, only in production.
It's also important to note that just putting something into autoload_paths will not make it eager-loaded in production. Unfortunately. You have to explicitly put it into eager_load_paths as well.
Another interesting quirk is that in every rails app, all directories under app/ are automatically in both autoload_paths and eager_load_paths, meaning that adding a directory there requires no further actions.
Basically, autoload_paths are paths Rails will use to try loading your classes automatically. E.g. when you call Book, if that class isn't loaded yet, it will go through the autoload_paths and look for it in those paths.
In production, it might be better to load those upfront to avoid autoload concurrent issues. For that, it provides the eager_load_paths. Paths in that list will be required upfront when your application starts.
I have some iPhone client tests that run against my development rails server. The whole suite runs an order of magnitude faster if I turn on class caching in the Rails config. On the other hand, that slows down development when I'm not actually running the tests.
I want the test suite to hit an action at the beginning to turn on class caching and another action at the end to turn class caching off again.
Is this even possible? If so, how?
Not without some serious hacking. Rails goes to quite a lot of trouble to make sure your files are reloaded on every request (when cache_classes=false). The value of the cache_classes configuration variable is used by initializers in several places not the least of which being:
using require to load ruby files when cache_classes is true (meaning they are no longer reloadable)
setting up dispatcher callbacks to reaload the application on every request when cache_classes is false
You do have access to the value of the cache_classes variable, and you can even change it if you like:
Rails.configuration.cache_classes = true
But, this will have no effect on the running rails instance as the initializers where that value is used only run once when the rails app starts up.
What this means is this, unless you're prepared to invest some serious time and hacking effort you can't really avoid a restart of your server. So, what you need to look at is controlling this restart process via your test suite.
For example you can try to restart rails from within rails. This would allow you to define an action that your test suite can hit right before it begins executing (to restart the server in the right mode), and another action which the server can hit after all tests have finished, to restart everything with cache_classes set to what it used to be. You would control the value of cache classes via an environment variable like this post suggests.
It would still require a bit of work to set all of this up and get it to hang together, but this is probably your best bet if you want an 'auto-magical' solution.
I don't think doing what you suggest will work.
But I suggest you may be looking for the wrong solution.
If what you want is to access your development database from your iphone testing,
then why not add a new environment.
Add a new file config/environments/iphone_dev.rb
require File.dirname(__FILE__)+"/development.rb"
config.cache_classes = true
And in your database.yml (or mongoid.yml or whatever)
iphone_dev:
host: localhost
database: my_app_development
There is no reason the database cant be the same
Now just run rails server -eiphone_dev -p3001
You should have a server, almost the same as your dev server,
but running on a different port, with caching enabled.
Is it possible to run "rails console" in one shell and then "rails server" in another and then have code changes in the console permeate to the running application? Presumably this isn't possible, but I'd just like to check if there is a way.
Edit: Both are running in the same environment. And by code changes I mean changes to class definitions (e.g. rewriting a method on the Post model).
If you modify any data, that will indeed permeate. However modifications to methods done on the fly by opening classes and "monkey-patching" them will not affect your running application - unless your modified method modifies data.
However, it is always advisable to run the console in a different environment with different data to avoid harming a running application.
If you are changing data in your console IN THE SAME ENVIRONMENT then it will be changed in the browser.