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

Question

Я перемещаю приложение Rails в AWS и использую EB. Мне нужно запустить демон в отдельном экземпляре (я не хочу, чтобы этот экземпляр обслуживал HTTP-запросы).

Демон является частью кодовой базы приложения и будет связываться с тем же экземпляром RDS, что и экземпляры веб-сервера. Я хотел бы узнать, по возможности, как настроить EB для развертывания приложения rails в дополнительном экземпляре, но elide добавляет этот экземпляр в load-balancer и (повторно) запускает демон в этом экземпляре после новой ревизии развертывается.

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

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

Это первый раз, когда я использовал эластичный бобовый шток; У меня есть некоторый опыт работы с AWS. Надеюсь, мой вопрос имеет смысл. Если это не так, будет принят ответ, который указывает, почему это не имеет смысла.

Спасибо!

Answer 1

С Elastic Beanstalk, это, как правило, достигается за счет использования работник ярус среды в одном и том же приложении EB (такая же база кода, то же самое .eb* файлов, только в разных средах.

Вот пример приложения rails, которое развернуто на одном веб-сервере, и два специализированных рабочих:

[yacin@mac my_rails_app (master)]$ eb list -v 
Region: us-west-1 
Application: my_rails_app 
    Environments: 3 
     email-workers-production : ['i-xxxxxxx'] 
     * web-servers-production : ['i-xxxxxx'] 
     job1-workers-production : ['i-xxxxxxx', 'i-xxxxxx'] 

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

Это очень гибкий и масштабируемый подход, но потребует некоторой работы по настройке. Вот несколько ресурсов по теме: Amazon Worker Tier Video Tutorial, Elastic Beanstalk.

Answer 2

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

This example of speeding up a deploy показывает запуск некоторых скриптов и перемещение данных взад и вперед. Еще лучше, автор описывает последовательность и процесс развертывания.

Я только начинаю эту настройку контейнера. Я читал о других, отбрасывающих файлы в каталогах /opt/elasticbeanstalk/hooks/appdeploy/pre и /opt/elasticbeanstalk/hooks/appdeploy/post, большую часть которых можно получить, прочитав сообщение, указанное выше.

Также обратите внимание, что вы можете включить content скрипта в файле YAML .config, как этот, который я нашел вчера:

files: 
    "/opt/elasticbeanstalk/hooks/appdeploy/post/99_restart_delayed_job.sh": 
    mode: "000755" 
    owner: root 
    group: root 
    content: | 
     #!/usr/bin/env bash 
     . /opt/elasticbeanstalk/support/envvars 
     cd $EB_CONFIG_APP_CURRENT 
     su -c "RAILS_ENV=production script/delayed_job --pid-dir=$EB_CONFIG_APP_SUPPORT/pids restart" $EB_CONFIG_APP_USER