I have deployed an app to digitalocean using the Ruby on Rails image. It is set up by default with a user called rails. My rails.service file looks like:
[Unit]
Description=OneMathsExamQuestions
Requires=network.target
[Service]
Type=simple
User=rails
Group=rails
WorkingDirectory=/home/rails/one_maths_exam_questions/
ExecStart=/bin/bash -lc 'bundle exec puma'
TimeoutSec=30s
RestartSec=30s
Restart=always
[Install]
WantedBy=multi-user.target
I need to use some environment variables in my application. So I have added some lines to my /home/rails/.bashrc and /root/.bashrc files (I suspect only the first one should be necessary but neither seems to work):
export A="val1"
export B="val2"
...
Now: if I call echo $A in a terminal I get the expected output. If I go into the Rails console and do ENV["A"] I get the expected output. But my app does not seem to behave correctly (the desired behaviour is connecting to Amazon S3; the exact error is not important).
If I go into my controller and explicitly log the env vars with Rails.logger.debug ENV I just get ENV, and Rails.logger.debug ENV["A"] returns empty string (I guess nil). Similarly if I try to do ENV["RAILS_ENV"] which should definitely work, I get the same. But Rails.env returns "development", as expected.
Moreover, if I explicitly write
ENV["A"] = "val1"
ENV["B"] = "val2"
...
in my config/application.rb, the app works correctly. But this is obviously not a permanent solution, since I can't commit this to version control.
I'm not using the figaro gem, which I think a lot of places are suggesting, but I don't see why I should have to since it works just fine on my local machine.
OK, it looks like if I export my environment variables in .profile then they are picked up by the server no problem. If I remove them from .bashrc then the server has no problems, but I can't get the variables in terminal. I guess they just do different things?
Related
I have my rails (4.2) app running through Passenger (5.0.28) + Apache (2.4.7) on an Ubuntu (14.02) system, ruby (2.3.0) managed with rbenv . I deploy with Capistrano (3.4.0).
All my environment variables are set in a very simple profile.d script.
#!/bin/sh
export VAR1=VAL1
export VAR2=VAL2
This works like a charm. My app ENV has all the correct variables, Secrets.yml is properly populated... everything works EXCEPT for when deploying with Capistrano over ssh.
In my deploy.rb I have the following that I think is relavant:
set :ssh_options, {
forward_agent: true,
paranoid: true,
keys: "~/.ssh/id_rsa.pub"
}
Capistrano docs being incredibly limited and ssh\server config not my strong point I can't seem to figure out why my ENV variables aren't seen by Capistrano. If I run puts ENV.inspect during the deploy flow, I get things such as "TERM_PROGRAM"=>"Apple_Terminal" and my local machine user info and whatnot. Why isn't Capistrano using the remote environment? How can I amend my configuration either server side or in my deploy script to fix this?
Thanks for the help.
First I think some clarification of terminology and Capistrano's execution model is needed.
Capistrano is a program that runs on your local machine. So ENV within Capistrano sees your local environment, not the server's. There is no way for Capistrano to "see" the remote ENV with plain Ruby code because the Ruby code that makes up Capistrano is not executing there.
What Capistrano does do is use SSH to send commands to the server to be executed there. Commands like mkdir, bundle install, and so on.
To see this illustrated, add a Capistrano task to your deployment flow that does this:
task :puts_remote_env do
on roles(:all) do
remote_env = capture("env")
puts remote_env
end
end
This will run the env command on the remote server, capture the result, and print it to your console.
I hope this makes it more clear how Capistrano works.
So, as you can see from the puts_remote_env output, the variables defined in your profile.d script are not there. Why?
It is because Capistrano is using a non-login, non-interactive SSH session. In that SSH session, your profile.d script is not being evaluated. This is explained in detail in the Capistrano FAQ: http://capistranorb.com/documentation/faq/why-does-something-work-in-my-ssh-session-but-not-in-capistrano/
You need to find another way to set those variables other than profile.d script.
You could specify them in your Capistrano configuration itself (e.g. production.rb) like this:
set :default_env, { var1: "val1", var2: "val2" }
Capistrano will then explicitly set up that environment when it executes SSH commands.
Or you could use a tool like dotenv, which allows Rails to read variables variables from a special file instead of relying on the execution environment.
Or you could experiment with different dot file locations to see if there are some that are still evaluated even in a non-login, non-interactive session. On Ubuntu, I've had success exporting variables at the very top of ~/.bashrc.
I set up a Centos 7 VM using this tutorial (standalone passenger) and RVM. I am deploying the rails app via Capistrano.
https://www.phusionpassenger.com/library/walkthroughs/deploy/ruby/ownserver/standalone/oss/install_language_runtime.html
Everything seems to work, except no matter where I set environment variables, the ENV["myvar"] can't be read in Rails.
I've tried export myvar=test SSHed as the "deployers" as well as root. I've also tried adding it to bashrc. If I login as deployer and do the following:
#symlink to current capistrano deploy
cd ~/rails/railsapp/current/
rails r "puts ENV['myvar']"
It gives me the correct ENV output. However, if I try to output ENV['myvar'] from my actual deployed via capistrano rails app, I get nothing.
Where am I supposed to set these ENV vars? I know the ENV vars in rails are done correctly, because the app deployed to heroku, as well as on my dev machine, correctly output ENV['myvar'].
Generally, your setup should work. Since version 4, a standalone Passenger should inherit all variables defined in the shell startup scripts. There is a nice documentation about environment variables in various scenarios related to using Passenger.
I would check or two things:
That your .bashrc is loaded from .profile. If it weren't, then your variables would be loaded only in an interactive shell but not in passenger, which would explain the behavior your describe when you tried to log in as the deployers. Let me quote from the doc:
Make sure your ~/.bashrc is actually included by your ~/.profile, which might not be the case if you created the user with useradd instead of adduser for example.
Also, take a look at this section of the docs and check that you obey the conditions upon which Passenger actually passes the environment vars to the application.
What started as a minor annoyance has now turned into a headache. I am building a Rails 4 app and am using Foreman for my dev setup with a Procfile and .env file for configuration. When I set an ENV variable in the .env file, it is correctly picked up by my app. In this case I am setting some ENV options for Paperclip in an initializer.
The problem surfaces when I go to change the value of the ENV variables. In the console, if I type ENV["MY_VAR"], it shows the new value. However, the value that was used in my initializer, which presumably was run when I started the console, shows the old value! Nowhere in my project is the old value listed anywhere. This leads me to believe that the environment is being cached somehow or that the env variables are being exported to my shell. I'm running out of places to look so any help would be greatly appreciated! I am developing on a Mac (10.9.4) with Ruby 1.9.3-p374 and Rails 4.1.0.
Example:
ROOT/.env
S3_BUCKET=mybucket
config/initializers/paperclip.rb
Paperclip::Attachment.default_options[:s3_credentials] = {bucket: ENV["S3_BUCKET"]}
If I change the value of S3_BUCKET to "newbucket" and run "foreman run rails c" or "rails c" to enter the console, this is what happens:
ENV["S3_BUCKET"] # => "newbucket"
Paperclip::Attachment.default_options[:s3_credentials] # => {bucket: 'mybucket'}
I should mention that this behavior also occurs in my classes that I've put in /lib. I imagine this is all due to something silly that I've overlooked. Any ideas?
If you're using Rails 4 out of the box, it comes with a gem called Spring that's intended to make your life easier by preloading an instance of your application in the background and reloading it as your code and configuration files change.
Spring, however, only monitors Rails' default configuration files, so you'll need to configure Spring to monitor additional any other files that you wish to trigger a reload.
Spring reads ~/.spring.rb and config/spring.rb for custom settings. You can add add the following line to the file of your choosing to watch your .env file for changes:
Spring.watch '.env'
See Spring's configuration documentation in the README for more info.
Never had such problem before with vps that I set up from zero, this one (Ubuntu 12.04, 64bit) was installed by some other developer.
The problem
in .bashrc file i have:
export FACEBOOK_ID=123456789
export FACEBOOK_SECRET=987654321
now in terminal if I type env I see these variables.
if I open rails console and type ENV["FACEBOOK_ID"] or ENV["FACEBOOK_SECRET"] I also can see the apropriate values.
The problem is that I have to use FACEBOOK_ID in the app in a view file and I do it with:
<%= ENV["FACEBOOK_ID"] %>
on local machine this returns the right value, in production on vps it returns nothing.
My idea is that the vps was not set up correctly, I couldnt find apache on it or ngnix, and the app is in var/www/apps/app_name/.
What could be wrong and how can I get this env variables in my template?
update
files available in root directory:
.bash_profile .bashrc .cshrc .zprofile .zshrc
Don't put it in local environment. What to do when you deploy the app? What to do when you want to develop another app on your local machine which use Facebook id as well?
Use Figaro gem. It's built for handling such case, env variables and private data. The env variables can be set in YAML file in app and won't be committed to repo. You won't regret.
I've got a staging server with both standard Ruby and Ruby Enterprise installed. As standard Ruby refuses to install a critical gem, I need to set $PATH so that ruby/gem/rake/etc. always refer to the REE versions. And since I use Capistrano to deploy to our machines, I need to do it in Capistrano.
How can I set an environment variable once, and have it persist throughout the Capistrano session?
1) It's easy to do in bashrc files, but Capistrano doesn't read bashrc files.
2) I'd use Capistrano's
default_environment['PATH'] = 'Whatever'
but Capistrano uses these environment variables like
env PATH=Whatever command arg ...
and they're lost whenever another shell is spun up within the executable passed to env. Like when you use sudo. Which is kinda important:
[holt#Michaela trunk]$ env VAR=hello ruby -e "puts ENV['VAR']"
hello
[holt#Michaela trunk]$ env VAR=hello sudo ruby -e "puts ENV['VAR']"
nil
3) And I can't use the bash export command, as these are lost too - Capistrano seems to start up a new shell for each command (or something like that), and that's lost, too:
cap> export MYVAR=12
[establishing connection(s) to xxx.xxx.xxx.xxx]
cap> echo $MYVAR
** [out :: xxx.xxx.xxx.xxx]
cap>
4) I've tried messing with Capistrano's :shell and :pty options as well (and in combination with the other approaches), but no luck there, either.
So - what's the right way to do this? This seems like such a basic task that there should be a really simple way to accomplish it, but I'm out of ideas. Anyone?
Thanks in advance!
I have the exactly same problem, but I think this solution is better:
set :default_environment, {
'env_var1' => 'value1',
'env_var2' => 'value2'
}
This works for me like a charm.
If you need to set a variable on the remote host other than PATH, you should know that sshd only allows certain /etc/profile or ~/.bashrc environment variables by default, for security reasons. As Lou said, you can either do cap shell and use the cap> printenv command, or you can do cap COMMAND=printenv invoke in one command.
If you see the variable when you ssh into the remote shell normally, but you don't see it in the cap printenv command, here's one solution:
Set PermitUserEnvironment yes in your remote server's /etc/ssh/sshd_config file, and restart sshd
Edit the ~/.ssh/environment file for the remote user you are ssh'ing in as, and put your variable(s) there as VARIABLE=value
Now those should show up when you do cap COMMAND=printenv invoke
I think you have in fact 2 problems:
1) You want to change the PATH on your remote host(s).
Alter/set the path in your .bashrc on your remote host(s) and run cap> printenv, if your path is right, goto #2, else try to add export BASH_ENV=~/.bashrc to your /etc/profile (be careful, ~/.bashrc will then be run for all non-interactive shell for all users)
2) You want sudo to keep your PATH
Run visudo on your remote host(s) and add:
Defaults exempt_group = "<your_user>"
I needed to set an environment variable for a specific task to work. The "run" command allows you to pass options which include :env:
run "cmd", :env => { 'name' => 'value' }
In my case, I wanted to add the environment variable to a task that I didn't write, so I used default_run_options which is used by all invocations of run. I added this to the top of my Capfile:
default_run_options[:env] = { 'name' => 'value' }
I tried unsuccessfully to use #brian-deterling's technique, which is pretty commonly used by others who have discussed this... Maybe I'm doing something wrong, but meanwhile I found the dotenv-rails gem, and it worked very nicely for loading up values out of a .env file in my project root.
The instructions on their Github repo are pretty straight-forward. I added the Dotenv.load to my config/application.rb