вопросов с выборами лидера фасонов

Question

У нас есть приложение для рельсов, которое работает отлично в течение нескольких месяцев. Сегодня мы обнаружили некоторые несоответствия с выборами лидеров. В первую очередь:

su - "leader_only bundle exec rake db:migrate" webapp 

После многих часов проб и ошибок (и десятки внедрений) ни один из экземпляров в нашей Dev приложения запустить эту миграцию. /usr/bin/leader_only ищет переменную окружения, которая никогда не устанавливается ни в одном экземпляре (приложение-разработчик имеет только один экземпляр).

Установка развертывания приложения в 1 экземпляр за раз и предоставление значения, которое /usr/bin/leader_only ожидает как env var работает, но не так, как было и должно. (Теперь все экземпляры являются лидерами, поэтому они бесплодно запускают db: migrate, и это будет 1 за раз, поэтому, если у нас будет много примеров, это замедлит нас)

Мы думали, возможно, это связано с некоторыми проблемами с кодом и/или приложение, поэтому мы перестроили его. Без изменений.

Я даже клонировал наш RDS-сервер тестового приложения и создал новое приложение из сохраненной конфигурации, развернул новый git-хэш и никогда не выполнял db: migrate. Он пытается и показывает строку leader_only, но он никогда не запускается. Это исключает код, конфигурацию, артефакты.

Кроме того, для его ценности он никогда не говорит о пропуске миграций из-за RAILS_SKIP_MIGRATIONS, который имеет значение false. Это означает, что на самом деле он пытается запустить db: migrate, но не из-за того, что его не называют лидером.

Answer 1

Мы беседовали с командами поддержки AWS. Кажется, что выборы лидера в ЕС очень хрупкие. Per тек:

Кроме того, как было объяснено выше (лидер является первым экземпляром в автоматического масштабирования группы и, если он удаляется мы потерять лидера и даже используя leader_only: истинно в container_commands, дБ : migrate не работа.)

Что случилось, что мы потеряли все экземпляры. Лидер избирается один раз и проходит через ротацию экземпляра. Если вы не потеряете все экземпляры, все в порядке.

Я не упоминал деталь.У нас много непроизводственных сред, и благодаря настройкам автомасштабирования бобовых стекол мы используем масштабирование по времени, чтобы подсчитать количество экземпляров до 0 в ночное время и вернуться к ожидаемой 1-2-й сумме в течение дня. Мы делаем это для наших сред dev, test и UAT, чтобы убедиться, что мы не работаем на полной скорости 24/7. Из-за этого мы потеряли лидера и так и не получили его обратно.

За следование от технологий:

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

Answer 2

В Elastic Beanstalk вы можете запустить команду в одном экземпляре «лидер». Просто создайте файл .ebextensions, содержащий container_commands, а затем разверните его. Убедитесь, что значение leader_only установлено в true.

Например:

.ebextensions/00_db_migration.config

container_commands: 
    00_db_migrate: 
    command: "rake db:migrate" 
    leader_only: true 

рабочий каталог этой команды будет ваше новое приложение.

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

Answer 3

«Elastic Beanstalk использует лидер выборы, чтобы определить, какой экземпляр в вашей среды работника очереди периодической задачи. Каждый экземпляр попытки стать лидером по записи в таблицу DynamoDB. Первый экземпляр, который преуспевает является и должен продолжать писать в таблицу , чтобы сохранить статус лидера. Если лидер выходит из службы , другой экземпляр быстро занимает свое место ».

http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html#worker-periodictasks