2017-01-09 16 views
0

У меня есть приложение для рельсов (рельсы 3.2.1, ruby ​​1.9.3 на всякий случай), размещенные на экземпляре ec2. При развертывании в новых экземплярах развертывание завершается с ошибкой, потому что нет семян, и сначала запускается сценарий предварительного развертывания (12_db_migrate.sh), что приводит к сбою. Ручное выселение db, а затем бег migrate исправляет его.Как выполнить пользовательский сценарий предварительного развертывания на эластичном шланге?

Я хочу создать сценарий предварительного развертывания в .ebextensions (я не хочу вручную создавать скрипт под ... appdeploy/pre /, поскольку это не поможет мне при развертывании приложения в новом экземпляре, скажем,) Возможно ли это сегодня?

PS: Я знаю, что я не хочу, чтобы это семя при каждом развертывании, поэтому я думаю о достижении этого через переменную среды.

ответ

0

Вы можете сказать, эластичный бобовый стебель, чтобы запустить container_commands до развертывания, путем добавления файла .ebextensions/packages.config, содержащий что-то вроде

container_commands: 
    01_node_install_if_not_installed: 
    cwd: /tmp 
    test: '[ ! -f /usr/bin/node ] && echo "node not installed"' 
    command: 'echo "e" > tst.txt' 
    leader_only: true 
  • cwd, test и leader_only не являются обязательными.
  • command будет работать только тогда, когда test оценивает истинный
  • leader_only наборы или нет, чтобы сделать это на первом ec2 инстанции (в случае, если вы используете несколько)

PS! Вы не можете использовать eb setenv для установки переменных среды, на которые следует воздействовать на этом этапе, поскольку эти переменные среды используются пользователем webapp, тогда как эти команды запускаются с помощью root.

+0

container_commands выполняются ПОСЛЕ выполнения appdeploy/pre hooks. Это не то, чего я хочу. – user2076106

1

Я думаю, что лучшим вариантом может быть переоценка того, почему ваши миграции зависят от конкретных данных, которые были засеяны ранее, но, независимо от того, я считаю, что вы можете выполнить то, что хотите, с помощью ключа files.

Что-то вроде этого, вероятно, сделало бы трюк - я скопировал 12_db_migration.sh и обрезал его, чтобы просто сделать семя. Установив префикс на 09_, он будет запущен до миграции.

files: 
    "/opt/elasticbeanstalk/hooks/appdeploy/pre/09_seed_database.sh": 
    mode: "000755" 
    owner: root 
    group: root 
    content: | 
     #!/usr/bin/env bash 

     EB_SCRIPT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k script_dir) 
     EB_APP_STAGING_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k app_staging_dir) 
     EB_APP_USER=$(/opt/elasticbeanstalk/bin/get-config container -k app_user) 
     EB_SUPPORT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k support_dir) 

     . $EB_SUPPORT_DIR/envvars 

     . $EB_SCRIPT_DIR/use-app-ruby.sh 

     cd $EB_APP_STAGING_DIR 

     su -s /bin/bash -c "leader_only bundle exec rake db:seed" $EB_APP_USER 
+0

Я согласен с вашей первой частью комментария, что миграция необходимо переоценить. Я довольно новичок в Ruby on Rails, но могу сказать, что код находится в довольно грязном состоянии. Я попытался использовать ключ «файлы», как вы уже упоминали, но он по-прежнему продолжался и сначала выполнял миграцию, и не удалось (я проверил YAML). В любом случае, я закончил выполнение семян в качестве миграции (я знаю его взломать, но он выглядел самым чистым из всех других автоматизированных подходов, о которых я мог думать). – user2076106