I have different databases for development and production. I want to access those depending on the environment I'm working with. So is there a way to specify that I want to work with "development" or "production" without actually having to change it everytime on the Realm GUI or CLI?
Related
I just wanted to know what the specific differentiation is between
environment variables ENV[SOME_VARIABLE]
vs.
Rails 5.2 credentials Rails.application.credentials.some_variable
When should I use one vs. the other? Did the credentials replace the env variables?
Credentials are stored in an encrypted file and are checked into your repository. There is a master key file that acts as the key in development, and you set the value of the master key file as an environment variable in production and both environments have access to the credentials. environment variables, on the other hand, should be used for values which are not secrets. Environment variables are generally not checked into your repository though still.
When should you use env:
When you have fixed no variables in your project
When you don't need environment-specific keys
When should you use credentials:
When you need to update keys frequently and you want to update it locally to test and also wish to maintain it securely ( since every environment has its own credential file and own key to access it
When you want environment-specific key values to isolate environment-wise service access. for example, you wish to maintain different fcm service channel at staging and on production to prevent information leak while testing internally
I have a rails app that will run on 3 web instances behind a load balancer.
I understand that the secret_key_base must be the same across the 3 instances.
Whats a good way to keep it synced without having to set the environment variable manualy on each instance?
Just initialize them during deploy of your Rails application (i.e. put it to .bash_profile or define env variable in command which run your Rails server, etc.) or during provisioning your servers use such tools like Puppet, Chef, Ansible, etc.
You have a lot of ways to make it automatically. Just choose one.
If it's only going to be 3 instances that's not a key than ever changes so you could set it once in /etc/environnement on 3 instances and forget it.
If you are planning on deploying more instances I would suggest you to try https://www.docker.com/ you will have an automatic deployment system that lets you set specifics
The company I'm working for currently has a Rails 3 application on a dedicated remote server. The current development environment is a local machine.
We are trying to put some infrastructure in place to hire some contractors to be able to do some development remotely. Obviously this won't work with our current development setup because it's local.
I was thinking that I could put the development and test code in separate subdomains i.e.
test.mydomain.com and dev.mydomain.com.
This is a small (but growing) project and we would not have more than one developer working on one or two changes on our system at any given time. We are starting out with smaller enhancements and working our way up to bigger ones.
My question is, what is the best way to deploy a development system that contractors would be able to access remotely and securely?
Normal practice would be for developers to still develop locally on their own systems, cloning the code using a version-control system (VCS) such as git. Then, you'd either 'pull' new code from a location they give you, or allow them to 'push' code to a location you give them. There might well be a 'staging' server set up, though, where the application is deployed as an additional check before deploying to the 'live' server; Rails lets you set up an arbitrary number of environments ('development', 'production', 'test' are the defaults, but more can be added), or you could use a deployment solution which ignores these settings and uses a different approach (such as Heroku).
You need to have source control, preferrably svn, then access that source code anywhere you want. Give a user id and password to the contractor and yourself to access the svn and install local development environment using local development database on your/contractor's pc. Anyone can deploy to dev. env. Or production env only if he/she has the authentication.
I am doing something similar. We use GITs to manage the code. To manage those different environments, I think using the GIT workflow is great, but the next step is configuring a remote database for development that all the developers access. They would just need to pull the code via git, once you are able to configure a remote database in the yaml., everyone would be in sync because you are developing on the same "dev" database.
Is it safe to alter application settings (config.*) on a Rails application that is already running?
How can I persist the changes, preferably to a database?
Update:
I want to allow the administrator to configure things like Action Mailer through an admin control panel, but I'm not sure if Rails will pick up on the changes.
Another approach instead of querying DB is to use Environment variables.
This is how you access environment variables:
ENV['name']
You may define those variables in .bash_rc for example.
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.