Почему при первом развертывании с помощью Capistrano запускается db:migrate?

Я использую Capistrano для развертывания в рабочей среде в первый раз и получаю сообщение об ошибке при запуске

cap production deploy

Ошибка:

** Invoke deploy:migrate (first_time)
** Invoke deploy:set_rails_env
** Execute deploy:migrate
DEBUG [048f89c6] Running /usr/bin/env if test ! -d /home/deployer_user/apps/ap_production/releases/20140209005208; then echo "Directory does not exist '/home/deployer_user/apps/ap_production/releases/20140209005208'" 1>&2; false; fi on eslope.net
DEBUG [048f89c6] Command: if test ! -d /home/deployer_user/apps/ap_production/releases/20140209005208; then echo "Directory does not exist '/home/deployer_user/apps/ap_production/releases/20140209005208'" 1>&2; false; fi
DEBUG [048f89c6] Finished in 0.160 seconds with exit status 0 (successful).
INFO [52f75214] Running ~/.rbenv/bin/rbenv exec bundle exec rake db:migrate on eserver.net
DEBUG [52f75214] Command: cd /home/deployer_user/apps/ap_production/releases/20140209005208 && ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.1.0 RAILS_ENV=production ~/.rbenv/bin/rbenv exec bundle exec rake db:migrate )
DEBUG [52f75214]    rake aborted!
DEBUG [52f75214]    An error has occurred, this and all later migrations canceled:
DEBUG [52f75214]    
DEBUG [52f75214]    PG::UndefinedTable: ERROR:  relation "client_infos" does not exist
DEBUG [52f75214]    : ALTER TABLE "client_infos" RENAME TO "clients

Ошибка на самом деле имеет полный смысл. Указанная таблица не существует. Чего я не понимаю, так это почему миграция вообще выполняется? Почему база данных не создается из схемы при первом запуске. Я непреднамеренно удалил файл, в котором говорится, какие миграции были выполнены? Либо просто удалив его, либо ".gitignoring"?

Я думаю, что знаю, как я могу это исправить (rake db:create или подобное), но чего я не понимаю, так это того, что если в Capistrano v3 он знает, что это первый раз, почему бы ему не использовать схему напрямую, а не запускать все миграции? Я нуб, это кажется разумным, но, с другой стороны, выполнение миграций приведет к тому же результату, так что... (Но как насчет людей, которые не знают, что использовать миграции вслепую в производстве; не будут они застряли?) Спасибо.


ruby-on-rails migration capistrano capistrano3
person codenoob    schedule 09.02.2014    source источник
comment
Не похоже на стандартный набор рецептов капистрано для развертывания, поэтому трудно сказать, что вызывает это.   -  person Tanel Suurhans    schedule 09.02.2014
comment
Например, почему первый запуск НЕ делает что-то вроде этого: RAILS_ENV=production rake db:create db:schema:load   -  person codenoob    schedule 09.02.2014
comment
Вы пробовали cap deploy:cold ?   -  person gmaliar    schedule 09.02.2014
comment
gmaliar — отличное предложение, но cap deploy:cold устарел в Capistrano v3, который, как я должен был упомянуть, я использую.   -  person codenoob    schedule 10.02.2014

Ответы (4)


arrow_upward
0
arrow_downward

db:migrate берет файлы миграции и выполняет их. поэтому, если таблица не существует, она сообщит вам об этом. Если ваше развертывание является первым развертыванием на этой машине или настроенная БД еще не инициализирована, вы должны сделать:

  1. Создать БД

    rake db:create

это создаст все таблицы

2 Запустите миграцию

 `rake db:migrate`

Здесь, очевидно, вам нужно иметь миграцию на месте.

Настоятельно рекомендуется не загружать схему (если у вас нет выбора), так как после этого сложно работать со схемой (откат и т. д.), но если у вас нет выбора, вы можете сделать rake db:schema:load

см. это для получения дополнительной информации

рейк db:schema:load и миграции

Как обновить производство схема базы данных безопасно в rails 3.1.3?

person Nick Ginanto    schedule 09.02.2014
comment
Спасибо, Ник. Определенно полезная информация, и я думаю, что могу сделать именно то, что вы предлагаете, но в данном случае мой вопрос действительно о том, почему Capistrano (v3.x) делает то, что делает. Я хочу иметь возможность понять это, чтобы, если я снова развернусь таким образом, это сработало (я добавил ваш ответ). - person codenoob; 10.02.2014
comment
Я считаю, что не могу запустить rake db:create для успешного развертывания только потому, что перед развертыванием у меня нет файлов проекта на удаленном сервере, за исключением файла database.yml, созданного вручную, поэтому rake просто не запустится без rakefile. Ожидается ли, что я сделаю все, чтобы запустить rake перед первым развертыванием? - person antiplayer; 31.03.2016

arrow_upward
1
arrow_downward

В конце концов, я сделал то, что предложили Имарс и Ник. Я запустил что-то вроде этого прямо на рабочей машине:

RAILS_ENV=production bundle exec rake db:drop
RAILS_ENV=production bundle exec rake db:schema:create
RAILS_ENV=production bundle exec rake db:schema:load

Это, конечно, уничтожает данные в базе данных, но при первом развертывании это не проблема.

Я бы подумал, что есть способ проще, но... я его не знаю.

person codenoob    schedule 09.02.2014

arrow_upward
0
arrow_downward

Проверьте вашу конфигурацию database.yml, производственную часть, если она верна. Затем убедитесь, что сервер Postgresql работает на рабочем сервере, а приложение (как пользователь) имеет права доступа. Я предполагаю, что «развертчик» — это пользователь, поэтому проверьте, есть ли у этого пользователя все необходимые права.

person Nikos    schedule 09.02.2014
comment
Никос, спасибо за предложение. Я могу подключиться с помощью psql -h (ip-адрес) -U (правильное имя пользователя) и -d (имя базы данных) с другого компьютера. Пользователь базы данных НЕ является тем же пользователем, что и развертыватель, но у меня есть настройка db как m5, а часть database.yml (единственная часть - это prod) выглядит нормально. - person codenoob; 10.02.2014

arrow_upward
0
arrow_downward

Судя по ошибке, вы пытаетесь переименовать таблицу client_infos в clients, но таблицы client_infos не существует, но у вас нет более ранней миграции, которая создала таблицу client_infos?

Если у вас нет миграции, которая создает таблицу client_infos, то откуда она взялась? Вы создали его вручную? Все изменения в базе данных должны сопровождаться миграцией.

Если у вас есть миграция для таблицы client_infos, таблица базы данных schema_migrations (в которой Rails хранит записи о выполненных миграциях) может каким-то образом рассинхронизироваться. Учитывая, что вы выполняете развертывание в первый раз, вероятно, стоит удалить всю базу данных и начать заново.

Чего я не понимаю, так это почему миграция вообще выполняется? Почему база данных не создается из схемы при первом запуске

При правильном написании миграции должны иметь тот же эффект, что и загрузка схемы, просто они будут выполняться постепенно. Вы, конечно, можете вручную загрузить схему, если хотите, но Capistrano не будет этого делать, поскольку запускать ее довольно опасно (вероятно, вы никогда не захотите воссоздавать свою производственную базу данных).

person lmars    schedule 09.02.2014
comment
Имарс, спасибо, что посмотрели это. Вы правы, ошибка связана с таблицей (думаю, в своем вопросе я отметил, что таблица, на которую он жалуется, не существует). Мой вопрос действительно о том, почему миграции вообще выполняются в этом случае. Я превзошел ваш ответ, я не думаю, что он отвечает на вопрос (хотя он дает мне еще несколько идей о том, как это исправить). Спасибо. - person codenoob; 10.02.2014