Rails 4: среда разработки Capistrano вместо производства?

Я развертываю производственную среду моего приложения ruby ​​on rails с драгоценным камнем capistrano на виртуальный частный сервер. Я запускаю следующую команду для развертывания:

bundle exec cap production deploy

Кажется, все работает хорошо, если я не попытаюсь проверить, в какой среде работает мой текущий производственный выпуск.

Один из способов, который я использую, чтобы проверить это, - запустить:

rails console
Rails.env

Ответ, который я получаю, — «развитие», что довольно пугающе.

Во время другого теста: когда я запускаю следующее в моей текущей версии:

rails db

Я получаю сообщение об ошибке, в котором говорится, что mydatabase_development не создана.

Мое приложение, кажется, работает хорошо, но я не знаю, вызовет ли это серьезные проблемы в будущем. Прежде всего: есть ли способ определить, действительно ли моя живая копия находится в разработке? Во-вторых: учитывая, что у меня есть проблема, как мне настроить capistrano для развертывания производственной среды?


ruby-on-rails deployment vps environment capistrano3
person hec    schedule 04.06.2014    source источник
comment
На какой системе вы работаете rails console?   -  person tadman    schedule 05.06.2014
comment
Запуск rails console на VPS с установленным дистрибутивом Ubuntu 14.04. Каталог, в котором я запускаю команду: /var/www/myapp/current/   -  person hec    schedule 05.06.2014

Ответы (1)


arrow_upward
6
arrow_downward

Имейте в виду, что rails console взаимодействует с текущей средой в соответствии с RAILS_ENV или RACK_ENV в вашей среде. Если вы не настроите это явно на своем сервере, то, вероятно, по умолчанию будет development.

Один из способов исправить это — принудительно включить его в свой .bash_profile или любой другой профиль оболочки, который вы используете. Например:

export RAILS_ENV=production

Это должно сделать его доступным, и когда вы задействуете оболочку Rails, он сработает должным образом.

Обратите внимание, что вы даже не сможете запустить режим разработки на своем рабочем сервере, поскольку в config/database.yml не должно быть записи с таким именем. Лучше всего хранить config/database.yml только на рабочем сервере и перемещать его во время развертывания Capistrano.

Добавьте это в свой config/deploy.rb:

set :linked_files, %w[
  config/database.yml
]

Затем вы создаете конфигурацию только для производства в shared/config/database.yml, которая будет привязана к месту при развертывании. Не забудьте исключить config/database.yml из вашей системы контроля версий, чтобы он не был развернут.

Причина, по которой ваш сайт, вероятно, в порядке, заключается в том, что программа запуска, такая как Passenger, автоматически устанавливает RACK_ENV на production, если не настроено иное. Однако это не влияет на вашу оболочку, которая по умолчанию имеет значение development.

person tadman    schedule 04.06.2014
comment
Блестящий ответ tadman. Спасибо. Нужно ли мне делать то же самое с моим файлом config/application.yml (используемым для переменных окружения в figaro gem), что и с файлом config/database.yml? - person hec; 05.06.2014
comment
Как правило, не рекомендуется проверять такие вещи, как ключи API, учетные данные, пароли и т. д., в репозиторий исходного кода. Такие вещи должны надежно храниться на вашем сервере, и только на вашем сервере, кроме безопасных резервных копий. Обычно я создаю файл config/database.example.yml, который служит шаблоном, который может настроить каждый разработчик. То же самое касается других вещей, таких как application.yml, если он у вас есть. - person tadman; 05.06.2014