I have a RoR3 app with multiple environment configs, development.rb, test.rb and production.rb.
Is there a way I can instruct the application to used a specific config based on a value in the URL or machine name??
For instance if the machine name contains "dev", then use development.rb.
Edit
If that is not possible, is there a way I can access the request URL from the application.rb or environment.rb files maybe. If so, I could probably use a regex on the URL to determine and set the environment settings dynamically within if blocks.
In the end, we'll end up having many more than just 3 environments, all with certain differences. So I need a very flexible way to set the config.
Probably not. By the time the rails app is running (and can look at the machine name) it's already picked an environment. Unless you hack the boot script...
It'd be much easier to just put the environment into the startup-command-line for each machine.
Related
Here begins the road. I need to configure a working environment manageable and accessible. I've been reading a bit about environment variables. Windows have an easy configuration, as can be easily changed through window panes. In unix is different ...
export environment_variable = argument
eg. export DISPLAY = localhost: 0.0.
The question is: should I declare the environment variables when I install rvm? need to work with ruby, and not have to be writing the source myvar each time I start the console.
Same question for node and git.
Obviously I ask because in windows if I had to do, and I have unix doubt.
The short answer to your question is No. During the installation, setup and use of rvm, you will not be setting any environment-specific variables that relate to your application, nor for the rubies/gemsets/gems that rvm will be managing for you.
Once rvm is up and running, and you have installed at least one version of ruby (managed by rvm), there are a few options available to you for conveniently managing your environment variables.
a) You can use your unix shell config files (.bashrc, .bash_profile, etc.) to set env variables, but I don't recommend it. This is the equivalent of the Windows scenario you quoted in your question, but is not the common practice in the ruby-unix community.
b) If you are using Rails, environment-specific configurations can be managed in the source code itself, in environment files. For example, production.rb, development.rb, test.rb. etc.
c) If this is a Ruby codebase (i.e. no Rails) then, you can define your environment variables in an 'initializer' file, which can be invoked at the entry point of your ruby project. I typically put my application-specific variables in a yaml file like below.
In file: env_vars.yaml
---
:env_var_a: a.b.com
:env_var_b: 1111
:env_var_c: foo
:env_var_d: bar
To load these environment variables for use in your codebase,
require 'yaml'
env_vars = YAML.load(File.read(file_path('env_vars.yml')))
If you prefer to not use YAML, you can save the configs in a text file, and use ruby's native File class to access them. I like YAML because it easily creates a hash for me.
Regardless of which option you choose, there is no way you will need to type source every time you start a session
I have a url that I am using in one of the controllers. Is there a better place to put this url? The url uses an API key and I was wondering if there is a better place to add this url and/or api key such that its not added in the controller class code and ergo more editable? If i add it as an environment variable or anything else how do i access it from my controller class? thank you. ITS A RUBY AND RAILS PROJECT
Using environment variables might be a good idea if you want to keep things like API keys and passwords out of your source code. Accessing them from within your code is done with the ENV object:
my_api_key = ENV['MY_API_KEY']
To use this technique, you need to set up the variables in your environment before launching your app, and how you do this depends on your local setup, and will likely also vary between development and production.
In development, you can simply set the environment vars in your shell, e.g. with bash:
$ export MY_API_KEY=foobar123abc
$ rails s
Now rails will start and have access to this environment variable. You can also set variables for just a single command:
$ MY_API_KEY=foobar123abc rails s
Depending on what the sevice/api is, you could set some of them to default development/test values in config/environments/development.rb (or test.rb):
ENV['MY_API_KEY'] = 'non_secret_api_key_that_can_be_shared_around'
Setting up environment variables in production will depend on how you're deploying your app. Phusion have an article on using environment variables in Passenger if your using that. There's also a useful article on using environment variables with Heroku which is worth a read even if you're not using them for deployment.
You can add it to application.rb file as
config.service {
:api_key => 'api_key'
}
Or better yet, add it to development.rb and production.rb files so that you can test it better.
You can access this api_key from controller like
Rails.application.config.service[:api_key]
I have an app that has a lot of api keys and setting to be managed and they are loaded using an initializer. BEcause they are different for each environment, I can't set a constant in the environment.rb file. (I tried that; didn't work.) So I started comment-and-uncomment by hand before every deployment, which is tedious. I'm wondering what would be a best practice for a situation where you have to deal with multiple configuration settings loaded in an initializer.
In your environment.rb you can set your keys if the request is coming from local:
Rails::Initializer.run do |config|
if local_request?
CONSTANT1 = 10
else
CONSTANT1 = 20
end
end
What this will do is check if you are on localhost which is localhost:3000, your development environment. If so then the if/else statement will pick which constant to set.
another option would be to set the constants in your environments folder which is probably a better idea
so for your production constants put them in config/environments/production.rb.
and for your development constants put them in config/environments/development.rb.
You should be setting these constants in initializer files, which you can create under the initializer directory. Then, use the environment-specific config files that are under the environments directory to set them per environment.
I am trying to deploy my first rails app and struggling a bit. My plan is to initially host it on a heroku free account to get a feel for live deployments and do some production testing. Eventually I might move it to a VPS.
I use git and do not use Capistrano at the moment.
Heroku primarily uses git, which is fine, but git manages the entire project state not files. So I have issues managing configuration files that are different from production to development, for example captcha keys in the environment.rb or goolge js api keys.
So what I did was to..
1 - Take the environment specific configuration out of the enviornment.rb and put it in the development.rb and production.rb. Created a branch called dev where I do my development and then merge it with master and push master to the production heroku remote.
This all works ok, but wondering if there is a better way to do it.
The other massive problem is I might have to use different gems in dev and in herouku. For example, I use ThinkingSphinix for search in dev, but Heroku I have to use acts_as_solr, which means my "Article.search call in the controller, will have to be Article.find_by_solr in production. This can become messy very fast.
What's the best way to deal with this kind of situation?
Thanks
For non-sensitive keys such as Google's JS API key etc., I found this RailsCasts episode very helpful.
Just created a config file under config/ and store your development settings in there.
# /config/google.yml
development:
google:
js:
key: 123456
test:
google:
js:
key: 345678
production:
google:
js:
key: 567890
Then create an initializer inside config/initializers/ that will parse the yaml and create an object which can be used without worrying about the current environment.
# /config/initializers/google.rb
GOOGLE_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/google.yml")[RAILS_ENV]
The environment variable RAILS_ENV refers to the current environment, so on application startup it picks up the current type, and you can refer to the settings in your code through GOOGLE_CONFIG:
<script type="text/javascript" src="http://www.google.com/jsapi?key=<%= GOOGLE_CONFIG['js']['key'] %>"></script>
For the latter issue, where code itself differs from environment to environment, I believe Capistrano would be a better solution.
For values that you want to keep different between environments, Heroku offers config vars.
As for using one indexing program in production and another in development, that's a bad idea, and will make things way messier than they need to be. Either start using Solr locally, or set up a Thinking Sphinx instance in EC2 yourself, and have your dynos connect to it.
I would suggest that it is very unwise to have different code in development and production.
Your development, test and production environments should be as similar as possible.
In fact, I would go so far as to say the entire point of the different environments is to simply provide an easy system for allowing minor configuration changes between setups. Different databases, different API parameters, different aching options, but the core system MUST be the same.
The the issue you will face is doubling your development effort. You still have to write the code. So in the search example you provide above, you will have to develop and test twice - once for the Solr production system and once for you local Sphinx, then you need to be able to switch and test between the two approaches in all of your environments to ensure test coverage and functionality.
If I have a constant in my Rails environment.rb, for example...
SOME_CONSTANT = 3
Is it possible to access this in my capistrano deploy.rb somehow? It seems simple but I can't figure out how.
This ended up working:
created a file config/initializers/my_constant.rb
put my constant in there (rails automatically loads files there so I can use the constant in my app)
then in deploy.rb added load 'config/initializers/my_constant' so it could be used there as well.
You should access it via the ENV[] hash (this is a Ruby thing), here is an example using the TERM environmental variable.
puts "Your Terminal is #{ENV['TERM']}"
If you need a ruby constant, from your rails environment, you should load it:
require 'config/environment'
Beware that this will load your whole application environment, you should think to use something like AppConfig, or SimpleConfig (insert other tool here) to store configurations, then you need only load the tool, which processes your config files.
Why not define these constants in a file in lib/ and then require the file in both your Rails app and your Capfile?
As the value is not only used by the rails app, I would probably store such configuration information in a language agnostic format (yaml, json, ini, xml) which can be easily parsed by different tools without fear of possible side effects.