Как устранить ошибку «Отсутствует« secret_key_base »для« производственной »среды» (Rails 4.1)

Я создал приложение Rails с использованием Rails 4.1 с нуля и столкнулся со странной проблемой, которую не могу решить.

Каждый раз, когда я пытаюсь развернуть свое приложение на Heroku, я получаю ошибку 500:

Missing `secret_key_base` for 'production' environment, set this value in `config/secrets.yml`

secret.ymlФайл содержит следующую конфигурацию:

secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

В Heroku я настроил SECRET_KEY_BASEпеременную окружения " " с результатом rake secretкоманды. Если я запускаю heroku config, я могу видеть переменную с правильным именем и значением.

Почему я все еще получаю эту ошибку?

У меня была та же проблема, и я решил ее, создав переменную среды, которая будет загружаться при каждом входе на рабочий сервер, и сделал мини-руководство по его настройке:

Я использовал Rails 4.1 с Unicorn v4.8.2, и когда я попытался развернуть свое приложение, оно не запустилось должным образом, и в unicorn.logфайле я обнаружил это сообщение об ошибке:

app error: Missing `secret_key_base` for 'production' environment, set this value in `config/secrets.yml` (RuntimeError)

После некоторых исследований я обнаружил, что Rails 4.1 изменил способ управления secret_key, поэтому, если вы прочитаете secrets.ymlфайл, расположенный в, exampleRailsProject/config/secrets.ymlвы найдете что-то вроде этого:

# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

Это означает, что Rails рекомендует вам использовать переменную среды для secret_key_baseвашего рабочего сервера. Чтобы устранить эту ошибку, вы должны выполнить следующие шаги, чтобы создать переменную среды для Linux (в моем случае Ubuntu) на вашем производственном сервере:

1. В терминале вашего производственного сервера выполните:

   $ RAILS_ENV=production rake secret

   Это возвращает большую строку с буквами и цифрами. Скопируйте то, что мы будем ссылаться на этот код как GENERATED_CODE.

2. Войдите на ваш сервер

   • Если вы вошли в систему как пользователь root, найдите этот файл и отредактируйте его:

     $ vi /etc/profile

     Перейти в конец файла с помощью Shift+ G(заглавная "G") в vi.

     Напишите переменную окружения GENERATED_CODE, нажав, iчтобы вставить в vi. Будьте уверены, чтобы быть в новой строке в конце файла:

     $ export SECRET_KEY_BASE=GENERATED_CODE

     Сохраните изменения и закройте файл, используя, Escа затем " :x" и Enterдля сохранения и выхода в vi.

   • Но если вы войдете как обычный пользователь, давайте назовем это " example_user" для этой сути, вам нужно будет найти один из следующих файлов:

     $ vi ~/.bash_profile
     $ vi ~/.bash_login
     $ vi ~/.profile

     Эти файлы расположены в порядке важности, что означает, что если у вас есть первый файл, вам не нужно редактировать остальные. Если вы нашли эти два файла в своем каталоге ~/.bash_profileи ~/.profileвам нужно будет записать только первый ~/.bash_profile, потому что Linux будет читать только этот, а другой будет игнорироваться.

     Затем мы снова переходим в конец файла с помощью Shift+ и Gснова записываем переменную окружения, GENERATED_CODEиспользуя наше использование i, и обязательно добавляем новую строку в конце файла:

     $ export SECRET_KEY_BASE=GENERATED_CODE

     Написав код, сохраните изменения и закройте файл, используя Escснова и " :x", Enterчтобы сохранить и выйти.

3. Вы можете проверить, что наша переменная окружения правильно установлена ​​в Linux с помощью этой команды:

   $ printenv | grep SECRET_KEY_BASE

   или с:

   $ echo $SECRET_KEY_BASE

   Когда вы выполните эту команду, если все прошло хорошо, она покажет вам GENERATED_CODEранее. Наконец, со всей выполненной конфигурацией вы сможете без проблем развернуть свое Rails-приложение с Unicorn или каким-либо другим инструментом.

Когда вы закроете свою оболочку и снова войдете в систему на производственном сервере, у вас будет установлена ​​эта переменная среды, и она будет готова к ее использованию.

И это все! Я надеюсь, что это мини-руководство поможет вам решить эту ошибку.

Отказ от ответственности: я не гуру Linux или Rails, поэтому, если вы обнаружите что-то не так или любую ошибку, я буду рад это исправить.

Я собираюсь предположить, что у вас нет вашего secrets.ymlзарегистрированного в системе контроля версий (т.е. она находится в .gitignoreфайле). Даже если это не ваша ситуация, это то, что сделали многие другие люди, просматривающие этот вопрос, потому что они выставили свой код на Github и не хотят, чтобы их секретный ключ плавал вокруг.

Если это не в системе контроля версий, Heroku не знает об этом. Поэтому Rails ищет, Rails.application.secrets.secret_key_baseи он не был установлен, потому что Rails устанавливает его, проверяя secrets.ymlфайл, который не существует. Простой обходной путь - перейти в ваш config/environments/production.rbфайл и добавить следующую строку:

Rails.application.configure do
    ...
    config.secret_key_base = ENV["SECRET_KEY_BASE"]
    ...
end

Это говорит вашему приложению установить секретный ключ, используя переменную окружения, а не искать его в secrets.yml. Это сэкономило бы мне много времени, чтобы узнать это заранее.

Добавьте config/secrets.ymlк контролю версий и разверните снова. Возможно, вам придется удалить строку, .gitignoreчтобы вы могли зафиксировать файл.

У меня была точно такая же проблема, и оказалось, что шаблон .gitignoreGithub, созданный для моего приложения Rails, включен config/secrets.yml.

Это сработало для меня.

SSH на ваш рабочий сервер и cdв ваш текущий каталог, запустите bundle exec rake secretили rake secret, вы получите длинную строку в качестве вывода, скопируйте эту строку.

Теперь беги sudo nano /etc/environment.

Вставить внизу файла

export SECRET_KEY_BASE=rake secret
ruby -e 'p ENV["SECRET_KEY_BASE"]'

Где rake secretнаходится строка, которую вы только что скопировали, вставьте вместо нее скопированную строку rake secret.

Перезагрузите сервер и протестируйте, запустив echo $SECRET_KEY_BASE.

Хотя вы можете использовать инициализаторы, как и другие ответы, традиционным способом Rails 4.1+ является использование config/secrets.yml. Причина, по которой команда Rails представила это, выходит за рамки этого ответа, но TL; DR заключается в том, что он secret_token.rbобъединяет конфигурацию и код, а также представляет угрозу безопасности, поскольку токен проверяется в истории контроля версий и является единственной системой, которая должна Знать секрет производства - это производственная инфраструктура.

Вы должны добавить этот файл так .gitignoreже, как вы не добавили бы config/database.ymlв систему контроля версий.

Обращаясь к собственному коду Heroku для настройки config/database.ymlиз DATABASE_URLих Buildpack для Ruby , я закончил разветвление их репозитория и изменил его для создания config/secrets.ymlиз SECRETS_KEY_BASEпеременной среды.

Поскольку эта функция была представлена ​​в Rails 4.1, я счел целесообразным отредактировать ./lib/language_pack/rails41.rbи добавить эту функцию.

Ниже приведен фрагмент измененного билда, который я создал в своей компании:

class LanguagePack::Rails41 < LanguagePack::Rails4

  # ...

  def compile
    instrument "rails41.compile" do
      super
      allow_git do
        create_secrets_yml
      end
    end
  end

  # ...

  # writes ERB based secrets.yml for Rails 4.1+
  def create_secrets_yml
    instrument 'ruby.create_secrets_yml' do
      log("create_secrets_yml") do
        return unless File.directory?("config")
        topic("Writing config/secrets.yml to read from SECRET_KEY_BASE")
        File.open("config/secrets.yml", "w") do |file|
          file.puts <<-SECRETS_YML
<%
raise "No RACK_ENV or RAILS_ENV found" unless ENV["RAILS_ENV"] || ENV["RACK_ENV"]
%>

<%= ENV["RAILS_ENV"] || ENV["RACK_ENV"] %>:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
          SECRETS_YML
        end
      end
    end
  end

  # ...

end

Конечно, вы можете расширить этот код, добавив другие секреты (например, ключи API сторонних производителей и т. Д.) Для считывания из переменной среды:

...
<%= ENV["RAILS_ENV"] || ENV["RACK_ENV"] %>:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
  third_party_api_key: <%= ENV["THIRD_PARTY_API"] %>

Таким образом, вы можете получить доступ к этому секрету очень стандартным способом:

Rails.application.secrets.third_party_api_key

Перед повторным развертыванием приложения обязательно сначала установите переменную среды:

Затем добавьте ваш измененный сборочный пакет (или вы можете добавить ссылку на мой) в свое приложение Heroku (см. Документацию Heroku ) и повторно разверните свое приложение.

Пакет компоновки автоматически создает config/secrets.ymlвашу переменную среды как часть процесса сборки dyno каждый раз, когда вы git pushподключаетесь к Heroku.

РЕДАКТИРОВАТЬ: собственная документация Heroku предлагает создать config/secrets.ymlдля чтения из переменной среды, но это означает, что вы должны проверить этот файл в системе контроля версий. В моем случае это не работает, так как у меня есть жестко закодированные секреты для сред разработки и тестирования, которые я бы предпочел не регистрировать.

Вы можете экспортировать секретные ключи в качестве переменных состояния окружающей среды на ~/.bashrcили ~/.bash_profileваш сервере:

export SECRET_KEY_BASE = "YOUR_SECRET_KEY"

И тогда вы можете получить ваш .bashrcили .bash_profile:

source ~/.bashrc 
source ~/.bash_profile

Никогда не передавайте свои секреты.

В моем случае проблема была в том, что config/master.keyне было контроля версий, и я создал проект на другом компьютере.

.Gitignore по умолчанию, который создает Rails, исключает этот файл. Поскольку невозможно развернуть без этого файла, он должен быть в управлении версиями, чтобы иметь возможность развертывания с компьютера любого члена команды.

Решение: удалите config/master.keyстроку .gitignore, зафиксируйте файл с компьютера, на котором был создан проект, и теперь вы можете выполнить его git pullна другом компьютере и выполнить развертывание с него.

Люди говорят не передавать некоторые из этих файлов для контроля версий, не предлагая альтернативного решения. Пока вы не работаете над проектом с открытым исходным кодом, я не вижу причин не фиксировать все, что требуется для запуска проекта, включая учетные данные.

Для rails6 я столкнулся с той же проблемой, так как мне не хватало следующих файлов, после того как я их добавил, проблема решена:

1. config/master.key
2. config/credentials.yml.enc

Убедитесь, что у вас есть эти файлы. !!!

Что я сделал: На своем производственном сервере я создаю файл конфигурации (confthin.yml) для Thin (я его использую) и добавляю следующую информацию:

environment: production
user: www-data
group: www-data
SECRET_KEY_BASE: mysecretkeyproduction

Затем я запускаю приложение с

thin start -C /whereeveristhefieonprod/configthin.yml

Работайте как шарм и тогда не нужно иметь секретный ключ для контроля версий

Надеюсь, это поможет, но я уверен, что то же самое можно сделать с Unicorn и другими.

У меня есть патч, который я использовал в приложении на Rails 4.1, чтобы позволить мне продолжать использовать устаревший генератор ключей (и, следовательно, обратную совместимость сеанса с Rails 3), позволяя secret_key_base быть пустым.

Rails::Application.class_eval do
  # the key_generator will then use ActiveSupport::LegacyKeyGenerator.new(config.secret_token)
  fail "I'm sorry, Dave, there's no :validate_secret_key_config!" unless instance_method(:validate_secret_key_config!)
  def validate_secret_key_config! #:nodoc:
    config.secret_token = secrets.secret_token
    if config.secret_token.blank?
      raise "Missing `secret_token` for '#{Rails.env}' environment, set this value in `config/secrets.yml`"
    end 
  end 
end

С тех пор я переформатировал патч и отправил его в Rails как Pull Request

Я создал config/initializers/secret_key.rbфайл и написал только следующую строку кода:

Rails.application.config.secret_key_base = ENV["SECRET_KEY_BASE"]

Но я думаю, что решение, опубликованное @Erik Trautman , более элегантно;)

Изменить: О, и, наконец, я нашел этот совет на Heroku: https://devcenter.heroku.com/changelog-items/426 :)

Наслаждайтесь!

это хорошо работает https://gist.github.com/pablosalgadom/4d75f30517edc6230a67 для пользователя root следует отредактировать

$ /etc/profile

но если вы не root, поместите сгенерированный код в следующее

$ ~/.bash_profile

$ ~/.bash_login

$ ~/.profile

На Nginx / Passenger / Ruby (2.4) / Rails (5.1.1) ничего не работало, кроме:

passenger_env_varв /etc/nginx/sites-available/defaultв блоке сервера.

Источник: https://www.phusionpassenger.com/library/config/nginx/reference/#passenger_env_var

Ответ Деми Магуса работал на меня до Rails 5.

На Apache2 / Passenger / Ruby (2.4) / Rails (5.1.6) мне пришлось поставить

export SECRET_KEY_BASE=GENERATED_CODE

из ответа Деми Магуса в / etc / apache2 / envvars, причина / etc / profile, похоже, игнорируется.

Источник: https://www.phusionpassenger.com/library/indepth/environment_variables.html#apache

У меня была такая же проблема после того, как я использовал файл .gitignore с https://github.com/github/gitignore/blob/master/Rails.gitignore

Все работало нормально после того, как я прокомментировал следующие строки в файле .gitignore.

config/initializers/secret_token.rb
config/secrets.yml