Related
I've built a Rails-Api with React SPA frontend following this guide (very helpful, would recommend). I'm having issues getting Heroku to set the environment variables in the .env file that React uses for config vars. The values of the file are just set as literally "ENV[...]" instead of evaluating and setting the value. On the Rails side the Heroku ENV vars are being set correctly because I can see them in the console.
.env file:
REACT_APP_API_KEY=ENV['API_KEY']
REACT_APP_AUTH_DOMAIN=ENV['AUTH_DOMAIN']
App.js (top level Component):
console.log(config,process.env);
// which logs:
{
NODE_ENV: "production"
REACT_APP_API_KEY: "ENV['API_KEY']"
REACT_APP_AUTH_DOMAIN: "ENV['AUTH_DOMAIN']"
...
}
Rails Console:
irb(main):001:0> ENV
=> {"LANG"=>"en_US.UTF-8", "NODE_ENV"=>"production",
"API_KEY"=>"<correct-value>", "AUTH_DOMAIN"=>"<correct-value>",......}
Is there something I need to do in order to alert Heroku that the ENV vars need to also be set in the .env file for the react app? The tutorial has the Heroku deployment use both the nodejs and ruby buildpacks (in that order). The app is built and then copied into the "public" dir for Rails to serve:
package.json
{
//...
"engines": {
"node": "12.9.0",
"yarn": "1.22.4"
},
"scripts": {
"build": "yarn --cwd client install && yarn --cwd client build",
"deploy": "cp -a client/build/. public/",
"heroku-postbuild": "yarn build && yarn deploy"
}
}
I don't know enough about the internal workings with Heroku's env vars swap. From what I understand with Create React App... the .env file's contents are set at build time so it is possible that the js is compiled before Heroku has any chance to inject the env vars. I'm open to suggestion on other ways to do this if this method isn't doable. Thanks!
You can expand environment variables in .env file. When React app is built, it has access to variables in your Heroku dyno, and react-scripts supports referencing them in your .env file. See more in docs.
With this in mind, your .env file would look like:
REACT_APP_API_KEY=$API_KEY
REACT_APP_AUTH_DOMAIN=$AUTH_DOMAIN
Assuming API_KEY and AUTH_DOMAIN variables are set in Heroku.
If you name these variables REACT_APP_API_KEY and REACT_APP_AUTH_DOMAIN in Heroku in the first place, then they will be picked up by react-scripts directly from the environment (no need for .env file then)
NOTE: with the above said, it sounds like you are trying to expose secrets in React app. The Create React App docs strongly warns NOT to do that, because:
Environment variables are embedded into the build, meaning anyone can view them by inspecting your app's files.
I tried to set the environment variables in .bashrc, .profile, .bash_profile, /etc/environment and also in /etc/defaults/nginx but nothing worked. Only /etc/environment was the file who actually responded echo $MY_VAR output but Rails application didn't picked those variables even after nginx and puma restarted along with daemon-reload other files even didn't responded in terminal (because When i do the ssh it renew the LINUX session). I'm using these environment variables in my_app/config folder's files. Can anyone tell a better way to make these variables work.
I'm using Nginx, Puma, Ruby on Rails 5, Capistrano and Ubuntu 18.04. Thanks in advance
If you're open to using the Dotenv gem, I used it recently in combination with keeping my environmental vars in .env (be sure to add it to your .gitignore). The docs for Dotenv explain how to do the setup. In config/application.rb, you need to add Dotenv::Railtie.load followed by YOUR_SECRECT = ENV['YOUR_SECRECT'] and any other vars you have in .env. Supposedly, if you're using Capistrano, you should be able to append .env with other linked_files in config/deploy.rb, but I ended up having to add the .env file manually to the shared dir on my server. Nevertheless, that setup made my environmental variables available to the config/environments/production.rb file.
I have a Rails 4 app with Dotenv gem to read variables from the file .env.
There are some variables I've set in order to have a mysql user other than "root" for my rails app, for example:
MYSQL_ROOT_USER='rootuser'
MYSQL_ROOT_PASSWORD='rootpassword'
APP_DATABASE_USER='mydbuser'
APP_DATABASE_PASSWORD='userpassword'
I've also created a bash script to create the mysql user under scripts/database_setup.bash
#!/bin/bash
source ../.env
# creates the user
mysql -u${MYSQL_ROOT_USER} --password="${MYSQL_ROOT_PASSWORD}" -e "CREATE USER '${APP_DATABASE_USER}'#'localhost' IDENTIFIED BY '${APP_DATABASE_PASSWORD}';"
# grants permission
mysql -u${MYSQL_ROOT_USER} --password="${MYSQL_ROOT_PASSWORD}" -e "GRANT ALL PRIVILEGES ON \`myapp\_%\`.* TO '${APP_DATABASE_USER}'#'localhost';"
On the server side, Capistrano deploys to `/home/myuser/apps/myapp/
I have three questions:
Where is the best place to put my server-side .env file? Right now I'm putting it in /home/myuser/apps/myapp/ directory.
How can I tell Capistrano to copy it to Rails root directory?
How can I tell Capistrano to execute my bash script before running migrations?
If anyone is still having troubles with this, here is how I got my .env working in production with Capistrano 3.5+:
Add your .env.production to /shared directory in production. Then, inside the deployment script, use Capistrano's append command to load linked files from the /shared directory like so:
append :linked_files, ".env.production"
Run the standard deploy (cap production deploy)
You can test whether env vars were appended by launching the rails console in production mode (rails c p) from inside the /current directory.
In production environment I think you shouldn't use .env at all.
Probably it's better to put the ENV vars in:
/etc/environment
by writing your variables like this:
export ENV_VARIABLE=value
We are using GAE with Ruby flexible environment, and we're trying to deploy a rails app with staging configurations (i.e. RAILS_ENV=staging).
According to https://cloud.google.com/appengine/docs/flexible/ruby/configuring-your-app-with-app-yaml we should be able to set the value of RAILS_ENV configuring an app.yaml with:
env_variables:
RAILS_ENV: 'staging'
However, when we run:
gcloud app deploy
A (temporary) Dockerfile is generated with
# Temporary. Will be moved to base image later.
ENV RACK_ENV=production \
RAILS_ENV=production \
RAILS_SERVE_STATIC_FILES=true
Which results in a deployment in the PRODUCTION environment (default value for RAILS_ENV).
Is this a bug or am I missing something?
The flexible environment sets RAILS_ENV by default to 'production'.
https://cloud.google.com/appengine/docs/flexible/ruby/runtime#environment_variables
Environment variables set in app.yaml under env_variables should now override the defaults (which come from the generated Dockerfile).
I just deployed a sample application to App Engine with RAILS_ENV customized in my env_variables.
env_variables:
APP_YAML_VAR: this was set in the app.yaml
RAILS_ENV: overridden
When deployed, ENV["RAILS_ENV"] shows my customized, overridden value.
Screenshot of customized environment variable
I am trying to bring up a staging instance of rails applciation using elastic beanstalk. I followed the documentation and did the following :
eb init --environment staging
eb start --environment staging
After this, I checked that the .elasticbeanstalk/optionsettings still had 'production' as the environment. I manually updated this to staging, and tried the git aws.push command.
After sometime, everything was deployed, However, when I load the URL, the application still seems to be using all the production configs and not the staging. Am I missing any step ?
The --environment switch in the eb CLI tool does not refer to the Rails environment, it refers to the Elastic Beanstalk environment which you are attempting to launch. The Elastic Beanstalk environment is a set of provisioned resources for a deployed application version. This is different from a Rails/Rack environment, which is simply a user defined context for application code to run in on an individual machine.
In order to set your Rails environment, you will want to set the RACK_ENV (or RAILS_ENV) environment variable inside of your .elasticbeanstalk/optionsettings file after an eb start and then call eb update to trigger an update of these environment variables. Or, you can edit your Elastic Beanstalk environment configuration through the Elastic Beanstalk console; click on "Environment details" on the correct environment, "Edit Configuration" in the Overview, and go to "Container" to adjust environment variables (in this case, you will edit the RACK_ENV field).
While I'm using eb_deployer and not the eb commandline, during an attempt to deploy a RAILS_ENV: development I found that db:migrate etc ran in the development environment, but it still started up the server in production mode. To solve this, passing in both RACK_ENV and RAILS_ENV was necessary in the option_settings:
[{
namespace: 'aws:elasticbeanstalk:application:environment',
option_name: 'RACK_ENV',
value: "development"
},
{
namespace: 'aws:elasticbeanstalk:application:environment',
option_name: 'RAILS_ENV',
value: "development"
}]
Here is the clear guidance for first time application deployment to elasticbeanstalk.
1) eb init --profile profile-name(profile name will be there in .aws > config)
2) Select default region as you wish to, by entering serial number.
3) Select an application to use, by entering serial number.
4) eb list
5) eb use (name in the list)
6) eb status (will give you the status)
That's it you are done with the initialization.
And now, if you want to change environment just use following commands.
eb setenv RACK_ENV=staging (takes a while).
eb deploy (after git staging).
You are done!!!!