使用新的环境变量刷新 .bashrc答案

【问题标题】：Refresh .bashrc with new env variables使用新的环境变量刷新 .bashrc
【发布时间】：2015-08-28 16:09:50
【问题描述】：

我有一个运行我们的 Rails 应用程序的生产服务器，其中有 ENV 变量，格式正确。它们显示在 rails c 中，但我们无法在应用实例中识别它们。

在 ubuntu 机器上运行 puma、nginx。每次更改 .bashrc 需要重新启动什么？这就是我们所做的： 1.编辑.bashrc 2.. .bashrc 3.重启彪马 4.重启nginx

仍然无法识别..但是在 rails c 中，我们缺少什么？

编辑：根据其他帖子的建议将环境变量添加到/etc/environment，说.bashrc 仅适用于特定的shell 会话，这可能会产生影响。据说/etc/environment 可供所有用户使用，所以这是我的。仍然有同样的问题：

在 rails c 中显示良好
当我在 shell 中回显它们时显示良好

不显示在应用程序中

export G_DOMAIN=sandboxbaa3b9cca599ff0.mailgun.org
export G_EMAIL=mailgun@sandboxbaa3ba3806d5b499ff0.mailgun.org
export GEL=support@xxxxxx.com
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

编辑：

在应用程序中，我以纯 html 格式请求 G_DOMAIN 和 G_EMAIL（这适用于使用 dotenv 进行开发，一旦使用 ubuntu 服务器推送到生产服务器就不起作用）：

      ENV TEST<BR>
      G_DOMAIN: <%= ENV['G_DOMAIN'] %><br>
      G_EMAIL:<%= ENV['G_EMAIL'] %>

但是，可以使用以下 env 变量（在 .bashrc 和 /etc/environment 中，与我们上面显示的所有变量相同），因为我们的图像可以正常工作并在生产环境中毫无问题地上传到 s3。

生产.rb

  # Configuration for Amazon S3
  :provider              => 'AWS',
  :aws_access_key_id     => ENV['AWS_ACCESS_KEY_ID'],
  :aws_secret_access_key => ENV['AWS_SECRET_ACCESS_KEY']

edit2：这可能与美洲狮问题有关吗？

https://github.com/puma/puma/commit/a0ba9f1c8342c9a66c36f39e99aeaabf830b741c

【问题讨论】：

你有没有想过让应用程序从文本文件而不是环境变量中读取数据，这些数据可能会像这样发生变化？它更简单、更可靠。
这对我来说是正确的，但我不确定您是否需要重新启动 NGINX。您确定要为您的应用程序更新.bashrc 中的环境变量吗？因此，例如，就我而言，我在服务器上运行了多个应用程序，因此我需要以应用程序用户身份登录，重新加载 .bashrc，然后在同一上下文/文件夹中重新启动应用程序（在我的情况下为 unicorn ，但puma 应该是一样的，只是不那么神秘:)。
@steveklein 我们使用了正确的.bashrc，因为其他env 变量被拾取得很好，并且在同一个文件中。只有我们添加的最新版本有问题
@MaxWilliams 我们可以这样做，但是我们已经在 .bashrc 中的所有变量都可以正常工作，我宁愿找出我们做错了什么
因此，如果您更改“现有”变量的值，它会在应用程序中被拾取，但新变量无法识别？听起来像是某个地方的错字...您可以使用来自.bashrc 的经过消毒的 sn-p 更新您的帖子。

标签： ruby-on-rails nginx environment-variables

【解决方案1】：

我也遇到过这样的问题。对我来说，这只发生在我添加新环境变量时。

通过this post 并在谷歌搜索后，我了解到Puma 的restart 命令（通过gem capistrano-puma）可能看不到新的环境变量，因为进程在重新启动时会自行分叉而不是杀死自己并重新启动（这是在部署期间保持服务器响应的一部分）。

链接的帖子建议使用仅存储在生产服务器上的 YAML 文件（阅读：不在源代码管理中），而不是依赖于部署用户的环境变量。这就是你实现它的方法：

将此代码插入到 Rails 应用的 config/application.rb 文件中：

config.before_configuration do
  env_file = File.join(Rails.root, 'config', 'local_env.yml')
  YAML.load(File.open(env_file)).each do |key, value|
    ENV[key.to_s] = value
  end if File.exists?(env_file)
end

将此代码添加到您的 Capistrano 部署脚本 (config/deploy.rb)

  desc "Link shared files"
  task :symlink_config_files do
    on roles(:app) do
      symlinks = {
        "#{shared_path}/config/local_env.yml" => "#{release_path}/config/local_env.yml"
      }
      execute symlinks.map{|from, to| "ln -nfs #{from} #{to}"}.join(" && ")
    end
  end

  before 'deploy:assets:precompile', :symlink_config_files

利润！使用来自1 的代码，您的Rails 应用程序会将您在服务器的Capistrano 目录的./shared/config/local_env.yml 文件中定义的任何键加载到ENV 哈希中，这将在其他配置文件（如secrets.yml 或database.yml）之前发生已加载。 2 中的代码确保您服务器上 ./shared/config/ 中的文件在每次部署时符号链接到 current/config/（1 中的代码期望它是）。

local_env.yml 示例：

SECRET_API_KEY_DONT_TELL: 12345abc6789
OTHER_SECRET_SHH: hello

例如secrets.yml:

production:
  secret_api_key: <%= ENV["SECRET_API_KEY_DONT_TELL"] %>
  other_secret: <%= ENV["OTHER_SECRET_SHH"] %>

这将保证您的环境变量被找到，而不是真正使用环境变量。似乎是一种解决方法，但基本上我们只是将ENV 对象用作方便的全局变量。

（capistrano 语法可能有点旧，但这里的东西在 Rails 5 中对我有用......但我确实必须从链接的帖子中更新一些东西才能让它为我工作，我是刚开始使用 capistrano。欢迎编辑）

【讨论】：