Как улучшить время загрузки узла OpsWorks?

Мне нравится AWS OpsWorks, но с одним большим недостатком, с которым я сталкиваюсь сейчас, является время загрузки: узлы загружаются очень медленно.

В моем случае для экземпляра t1.micro требуется около 10 минут, прежде чем моя кулинарная книга сможет запуститься (хотя с точки зрения консоли EC2 экземпляр должен быть готов примерно через 2 минуты: после этого короткого периода к нему можно получить доступ через SSH) . Вы также можете обратиться к этой теме.

Я попытался использовать пользовательский AMI, но столкнулся с другой проблемой: узел загружался вечно. Но это может быть моя вина при создании AMI.

Вернемся к исходному вопросу: как улучшить время загрузки узлов OpsWorks?


amazon-web-services boot chef-infra aws-opsworks
person tung    schedule 03.12.2013    source источник

Ответы (4)


arrow_upward
7
arrow_downward

В моем случае, используя m1.small, я следовал этому документу, чтобы создать собственный AMI.

Я думаю, что причина, по которой он продолжал загружаться вечно, заключается в том, что файлы агента opsworks все еще там. См. шаг 4 в разделе Чтобы создать собственный образ AMI из экземпляра AWS OpsWorks, вам потребуется остановить агент и удалить его файлы.

Полный цикл улучшился с ~ 25 минут до ~ 10 минут. К ~11-й минуте он находится на этапе проверки работоспособности LB.

Надеюсь, это поможет.

person mrclmrvn    schedule 12.12.2013
comment
Приятно иметь представление о том, почему экземпляр зависает навсегда. Я попробую ваше решение и вернусь с результатом. Благодарю вас! - person tung; 12.12.2013
comment
Удивительно! Работает как часы. Это экономит мне 6 минут на экземпляре t1.micro. Большое тебе спасибо. - person tung; 13.12.2013

arrow_upward
1
arrow_downward

(Не могу комментировать. Нужно 50 баллов) Я не понимаю. Если вы удалите агента, какой смысл использовать OpsWorks? Агент позволяет обновлять экземпляр и добавлять рецепты по мере необходимости. Не говоря уже о добавлении экземпляров на основе предопределенных конфигураций. Я что-то упускаю?

person Michael Andrews    schedule 14.05.2014
comment
Я не уверена. Это для создания нового AMI, поэтому я предполагаю, что OpsWorks хочет чистый AMI и каким-то образом установит новый агент в этом экземпляре при его запуске. С уважением. - person tung; 15.05.2014
comment
Opsworks по-прежнему полезен для создания и настройки машины для создания AMI. Если вам нужно обновить AMI, лучше иметь возможность обновить конфигурацию и рецепты Opsworks и создать новый экземпляр с нуля, а затем просто вручную обновить свой AMI вручную. - person Bazman; 08.01.2015

arrow_upward
0
arrow_downward

Если ваш экземпляр не запустится, проверьте мой ответ здесь:

Экземпляры AWS Opworks не начиная с момента создания из Custom AMI на EC2

может решит вашу проблему...

person cosmin    schedule 27.02.2015

arrow_upward
0
arrow_downward

Хотя в этой ветке четко не указано, похоже, что вы создавали собственный AMI либо из Amazon Linux, либо из экземпляров Ubuntu, которые уже предлагаются. В моем случае (из-за которого я оказался здесь) я создал пользовательский AMI непосредственно из обычного экземпляра EC2, и все же спустя почти 14 часов экземпляр не запустился. Я убедился, что удалил все другие конфигурации, которые могли нам помешать, такие как конфигурации ELB/VLC и пользовательские рецепты. Экземпляр в основном застрял на этапе установки.

Одна из возможных причин, по которой он зависает при загрузке, заключается в том, что пользовательский AMI, созданный из образа, имеет агент Opworks, который должен быть связан только с этим образом. Посмотрите документацию здесь: http://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-custom-ami.html Но это не мой случай.

Я попробую с предопределенным образом Amazon и пойду оттуда.

person eco    schedule 18.11.2014
comment
Обновление: мне удалось заставить инстанс Amazon Linux 12.9 перейти от загрузки к запуску установки. Мне потребовалось только время, чтобы написать исходный пост выше. Возможно ли, что мы также должны удалить агентов из обычных EC2 Ami? Это не имело бы смысла, но кто знает, возможно, что-то еще блокирует загрузку пользовательских AMI. И кстати, мой исходный пользовательский экземпляр AMI был из 32-разрядной версии RHEL 6.5 на экземпляре t1.micro. В нем не было установлено НИЧЕГО необычного. - person eco; 18.11.2014
comment
Эйнарк привет. Как указал mrclmrvn в своем ответе, вам нужно остановить агент и удалить его файлы. - person tung; 19.11.2014
comment
@TungNguyen Привет Тунг. Я знаю, я написал это в своем самом первом комментарии, но он был удален администратором. Подробнее о проблеме, с которой я столкнулся, см. здесь. Хотя AMI по умолчанию работает нормально, я не могу заставить его работать с пользовательскими AMI из EC2: stackoverflow.com/questions/27005004/ - person eco; 28.11.2014