I couldn't find an answer in the documentation so I'm asking here.
In Grails when you create an app you get the Production, Development etc environments by default.
If you want to build a WAR for Production you can run either of these commands:
grails war
OR
grails -Dgrails.env=prod war
If you want to create a WAR for the development environment you use the command:
grails -Dgrails.env=dev war
My questions;
1) Can I use the word 'production' instead of 'prod' and use 'development' instead of 'dev'? I assume that 'prod' and 'dev' are just shorthand for 'production' and 'development', so I should be able to use either?
2) If so, if I introduce my own environment called 'Stage' can I create a shorthand for use in setting -Dgrails.env? Something like 'stg' for example.
Thanks.
1) Can I use the word 'production' instead of 'prod' and use 'development' instead of 'dev'? I assume that 'prod' and 'dev' are just shorthand for 'production' and 'development', so I should be able to use either?
The short answer is yes. You can use either the short name or full name of an environment to the grails.env parameter. The short and full names of the environments defined by Grails are shown below
short name|full name
prod |PRODUCTION
dev |DEVELOPMENT
test |TEST
The value provided for grails.env is matched case-insensitively against the short and full name of all environments.
2) If so, if I introduce my own
environment called 'Stage' can I
create a shorthand for use in setting
-Dgrails.env? Something like 'stg' for example.
No, the short names are stored within a private static field of grails.util.Environment, which you should not access
Related
TL; DR
How to use production.yml.enc and staging.yml.enc credential files in two production- and staging- Rails apps, while the app has only the regular development, test and production environments?
I'm using Heroku and refer to it in this question. Yet this is not specific to this vendor.
In detail
An application is often deployed multiple times. An instance serves as the production, while another is the staging app, expected to be put in production. Rails facilitates this pattern, since creating new environments is easy.
However, Heroku suggests not to do this, with good reasons. For example, one can be tempted to put some if Rails.env.production? here and there, paving the way for some "but it works in staging!?" on Friday evening. It is better to have a single production environment, with different sets of parameters to actually differentiate the stages (eg. a different AWS S3 bucket name, a different API key, etc.). To achieve this, Heroku's advice is to rely on environment variables.
Since Rails 5.2 and later in Rails 6, credentials are conveniently handled via encrypted Yaml files in config/credentials. This is typically where one would like to store all these variables that change from an environment to another, instead of using messy environment variables. This mechanism can be used in Heroku thanks to a single RAILS_MASTER_KEY environment variable that contains the key used to decrypt the credentials file.
But these pieces do not fit well. How can we have a single production environment, whereas credentials files are per-environment?
This can be implemented with a staging credentials file and key, and a switch in application.rb based on an environment variable:
Create and populate a staging credentials file and key with EDITOR=vi rails credentials:edit --environment staging.
In application.rb, add:
# Introduce the environment variable RAILS_CREDENTIALS_ENVIRONMENT to specify a custom
# environment name of which to use the credentials file. Specifically aimed to use in staging,
# where the environment is set to "production", but we need to use the "staging" environment variables.
# This environment variable is also used to select the corresponding key file or -if that does not exist-
# the corresponding environment variable.
if ENV['RAILS_CREDENTIALS_ENVIRONMENT'].present?
new_filename_no_ext = Rails.root.join 'config', 'credentials', ENV['RAILS_CREDENTIALS_ENVIRONMENT']
config.credentials.content_path = "#{new_filename_no_ext}.yml.enc"
if File.exist? "#{new_filename_no_ext}.key"
config.credentials.key_path = "#{new_filename_no_ext}.key"
end
end
Set an environment variable RAILS_CREDENTIALS_ENVIRONMENT to production or staging, depending on the case. For example, Heroku does this with:
heroku config:set -a theapp-staging RAILS_CREDENTIALS_ENVIRONMENT=staging
If on staging or produciton you want to store your key in an environment variable instead of a key file, then simply assign the key to the RAILS_MASTER_KEY environment variable. As documented, this takes precendence over keys stored in files. Note that on your development machine you wouldn't want to have a RAILS_MASTER_KEY set, otherwise the credential files for all environments still get the same key and are thus accessible by everyone that needs to have access to (e.g.) only the development credentials.
Have several files one by each environment in your source code repository o local server disk, works but you will have several files with hardcoded values.
But, if you expect several teams with several requirements on your single app, you will need several development and test environments in order to keep an independent teams which are fully responsible for their Services:
Development
Release / Deployment
Ops (not platform/system administration)
An approach to management this is : externalize your configurations on platforms called: Configurations Manager
This platforms, must have the following features:
key-vaue pair creation by app. Like heroku web dashboard
expose http endpoint to get this variables from remote apps
security
Your rails app must get the variables at the startup stage or instantaneous if your language support hot reload variables.
Here some Configurations Managers:
Zookeeper : http://www.therore.net/java/2015/05/03/distributed-configuration-with-zookeeper-curator-and-spring-cloud-config.html
Consul : https://www.consul.io
Spring Cloud : https://www.baeldung.com/spring-cloud-configuration
Confignet: https://github.com/software-architect-tools/confignet
Whit this approach you will have a platform to management several apps for several environments like heroku web variables creation but more sophisticated.
I need to set up an environment variable for my rails app. Both in my local machine and in the production server. I read some tutorials on the internet but NONE has given the complete instruction on how to set and use these variable in the actual production server. I use digital ocean and linux server to host my rails app.
I have spent days trying to figure this out, but still haven't found a clear and complete instruction from setting the variables on my local machine -> push it to git repo -> set and use the variables in production server. So, hope somebody can help me here, thanks!
UPDATE:
This is how I currently setup the environment variables in my rails app by using figoro gem:
You can set system-wide environment variables in the /etc/rc.local file (which is executed when the system boots). If your Rails app is the sole user of the Linux system, that is a good place to store credentials such as API keys because there is no risk of including this file in a public Git repository, as it is outside the application directory. The secrets will only be vulnerable if the attacker gains shell access to your Linux server.
Set the environment variables within /etc/rc.local (do not include the <> characters):
export SOME_LOGIN=<username>
export SOME_PASS=<password>
To see the value of an environment variable, use one of the following commands in the Linux shell:
printenv MY_VAR
echo $MY_VAR
To access those environment variables within Rails, use the following syntax:
Inside .rb files or at the rails console
ENV['MY_VAR']
Inside .yml files:
<%= ENV['MY_VAR'] %>
For anyone still having this issue, figaro now has an easy method in setting the production variables in heroku. Just run:
$ figaro heroku:set -e production
ryzalyusoff.
For Unix
You can use LINUX ENV in rails application.
# .env
GITHUB_SECRET_KEY=SECRET
TWITTER_ACCESS_KEY=XXXXXXXXXXXX
# in rails code
puts ENV["TWITTER_ACCESS_KEY"] # => SECRET
Create .env files for local machine and your production server. Export environment variables like this(on server with ssh):
export GITHUB_SECRET_KEY="XXXXXXXXXXXXXXXXXX"
Anyway, storing keys in config - bad idea. Just add .env.example, others keys configs add to .gitignore. Goodluck.
Example with Rails
For Windows
Syntax
SET variable
SET variable=string
SET /A "variable=expression"
SET "variable="
SET /P variable=[promptString]
SET "
Key
variable : A new or existing environment variable name e.g. _num
string : A text string to assign to the variable.
expression : Arithmetic expression
Windows CMD
I believe we should not push a secret file on git.
To ignore such file use gitignore file and push other code on the git.
On the server side just copy the secret file and create a symlink for that file.
You can find demo here http://www.elabs.se/blog/57-handle-secret-credentials-in-ruby-on-rails
You can set your environment variables in production in the same way, you do it for local system. However, there are couple of gems, which make it easier to track and push to production. Have a look at figaro. This will help you in setting up and deployment of env vars.
You can do this with figaro gem
or in rails 4 there is a file named secret.yml in config folder where you can define your environment variables this file is by default in .gitignore file.For production you need to manually copy that file to server for security reason so that your sensitive information is not available to any one
First create your variable like:
MY_ENV_VAR="this is my var"
And then make it global:
export MY_ENV_VAR
You can check if the process succeeded with:
printenv
Or:
echo MY_ENV_VAR
ootb rails has the 3 environments
development
test
production
How do you handle your other environments for example staging ?
When I think about what I want from a staging environment I want most of the production settings, but typically server names and other specific values are different from production.
Do you create 1:N environment/*.rb for each custom environment you have? Or do you treat the environments more as like a profile and then use something like application.yml or secrets.yml for running the application with different server configurations?
What has worked well for you in the past and what has not?
It depends if your "staging" environment is a different thing or is actually a variation on the "production" environment as is usually the case.
Normally you just deploy in full production mode, using the production.rb file and everything, to a non-production server. This distinction is irrelevant to rails, and matters only to your deployment script. For example Capistrano would be concerned about this.
The only time you need another environment is if you need a different group of settings for Rails.
In my opinion, when I run the app in an staging environment I want it to have exactly the same settings as in production, because it's when I check if everything is alright before releasing the new code. So I create a environments/staging.rb that actually is a symbolic link to environments/production.rb. To deploy, I use Capistrano, which lets you define the server settings for every environment you want to. I really encourage you to take a look at it if you don't know it, as it makes deploying as easy as running a simple command, and it takes care of uploading the new code, precompiling the assets, restarting the server, etc.
Appropriate any way described above.
In some cases I am using 1:N way because it easy when you have fixed count of deployment environments (for example when I am deploying own pet-project to remote server).
But in other cases I am using default set of environments (for example when I am deploying project to different customers).
Just choose any way appropriate for you and your project.
I use require_relative to create a staging environment that is identical to production, and then override the parts that are different. Typically the only difference is hostnames.
Here's what my environments/staging.rb looks like:
# Staging configuration is identical to production, with some overrides
# for hostname, etc.
require_relative "./production"
Rails.application.configure do
config.action_mailer.default_url_options = {
:host => "staging.example.com",
:protocol => "https"
}
config.action_mailer.asset_host = "https://staging.example.com"
end
I'm using AWS Opsworks to host my Rails App (Ruby 2.0/Rails 3.2).
For assets compilation process, I am using AssetSync to upload the compiled assets automatically on S3. I used to store the credentials as environment variables.
Do you have any idea how can I do this with Chef/Opsworks?
Thanks.
I know this is an older post, but I'm posting this in case this helps someone else.
I found the easiest way actually was to use one of Chef's deploy hooks (http://docs.opscode.com/resource_deploy.html#deploy-phases).
Add a directory called 'deploy' at the Rails project root.
In it add a file called before_restart.rb, with the code:
Chef::Log.info("Running deploy/before_restart.rb")
# map the environment_variables node to ENV
node[:deploy].each do |application, deploy|
deploy[:environment_variables].each do |key, value|
Chef::Log.info("Setting ENV[#{key}] to #{value}")
ENV[key] = value
end
end
When you trigger the OpsWorks deploy, you should be able to see the ENV vars being set in the Rails App Server instance log.
I ended up using https://github.com/joeyAghion/opsworks_custom_env.
It works pretty well.
I used a slightly different approach, using OpsWorks hook to copy JSON to application.yml. you can read more about it here: http://zaman.io/how-to-import-aws-opsworks-json-into-rails-app/
Another option outside of environment variables is you can generate a file with the variables in it at deploy time.
For example, for a Rails app, the config/secrets.yml is a reasonable place to put these. I created a deploy/before_restart.rb deploy hook with the following content:
def create_secrets(secrets, release_path)
Chef::Log.info("Creating secrets")
file_path = ::File.join(release_path, 'config/secrets.yml')
::File.open(file_path, 'w') do |f|
f.write("production:\n")
secrets.each do |k,v|
f.write(" #{k}: #{v}\n")
end
end
end
node[:deploy].each do |application, deploy|
create_secrets(deploy[:secrets], release_path)
end
And then in your OpsWorks stack Custom JSON you can add your secrets:
"deploy": {
"super_cool_app": {
"secrets": {
"some_service_id": "foo",
"some_password": "bar"
}
}
You can create a deploy folder in the root of your application, create a file before_restart.rb inside it, then in your file run the precompile task
run "cd /srv/www/myapp/current && /usr/local/bin/bundle exec rake assets:precompile"
This file will run on every deployment
Source:
https://www.youtube.com/watch?v=nHu8fCp9GR4&list=WL&index=7
This can now be done directly from the AWS Console, on the application configuration, as per documentation : http://docs.aws.amazon.com/opsworks/latest/userguide/workingapps-creating.html#workingapps-creating-environment
I already answered here: AWS OpsWorks Environment variables not working
Is important to understand that from OpsWorks dashboard we can pass all declared environment variables to Chef, then we need to handle these variables with a Chef recipe to let them available to Rails environment.
Here you can find what you are looking for: https://medium.com/#diego_durante/opsworks-rails-and-environment-variables-30c6a143253c#.696grsgg9
At the time bootstrap.groovy is running GrailsUtil.environment is automatically switch to development.
Can any one explain,How can i manually change that variable before bootstrap starts..??
Where it is setting as default to development in grails framework..??
Thanks.
Your grails environment is specified on the command line when you type run-app, for example. I don't believe you can switch the environment setting within Bootstrap.groovy--or any file--at runtime. Instead, you can change it by how you execute the grails commands:
-Dgrails.env=production run-app-- you can create your own environments to run, just change the value for -Dgrails.env to your custom environment.
Some of the grails tasks will run in a given environment by default; you don't need to set it explicitly.
run-app -- defaults to run in the development environment
test-app -- defaults to test environment
war -- defaults to production environment
More info here: http://www.grails.org/Environments