Развертывание производства в EC2 с минимальным временем простоя

У меня есть простое веб-приложение, развернутое на большом экземпляре с EC2. Теперь я хочу развернуть последний код на этом сервере, но я хочу сделать это таким образом, чтобы свести к минимуму время простоя и сделать его максимально удобным для конечного пользователя. Вот мой план:

  1. Запустите еще один большой экземпляр
  2. Установите все программные слои в этом экземпляре
  3. Восстановите и подключите диск EBS к экземпляру.
  4. Разверните наш последний готовый производственный код на новом экземпляре
  5. Запустите все тесты (включая ручное тестирование приложения)
  6. (Если тесты пройдены) Разместите уведомление "Сайт находится на обслуживании" на действующем сайте.
  7. Сделайте резервную копию EBS на действующем сайте
  8. Отсоедините экземпляр EBS от нового сервера и замените его последней резервной копией.
  9. Используйте ec2-associate-address для перемещения IP-адреса в новый экземпляр
  10. Расслабьтесь и подождите, пока трафик начнет течь через новый экземпляр
  11. Прекратить старый экземпляр

Кажется ли это хорошей стратегией? Существуют ли учебники или книги, которые могут охватить эту тему? Я уже читал "Архитектуру облачных приложений" Джорджа Риза, которая является отличной книгой, но не охватывает развертывание. Кроме того, я знаю, что есть инструменты, которые могут помочь с этим, такие как RightScale или enStratus, которые я буду использовать, когда начну использовать более одного экземпляра.

Источник

2 ответа

Решение

Это похоже на хороший общий подход. Вы можете сократить шаг 2 и, таким образом, сократить время запуска, создав собственный AMI, который включает все необходимые программные уровни; Сказав это, я все равно обновлю все пакеты при запуске, чтобы убедиться, что вы получаете все последние обновления безопасности.

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

Источник

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

Во-первых, вы должны разделить код приложения и постоянные данные на 2 разных виртуальных машинах. Это немного обойдется вам в задержке связи между виртуальными машинами, но значительно упростит администрирование. Помните, что наличие 2 маленьких виртуальных машин вместо одной большой виртуальной машины не дороже; поэтому выберите количество хостов, которое лучше всего соответствует вашим потребностям.

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

Во-вторых, вы должны подумать, подходят ли некоторые из управляемых сервисов Amazon, таких как SimpleDB или Relational Database Service (размещенный MySQL), для вашего постоянного хранилища данных.

Идеальный поток выглядит примерно так:

  1. Сначала измените "заднюю" бэкэнд-систему. Например, если ваше изменение требует добавления столбца в таблицу базы данных, добавьте его с помощью обычных инструментов MySQL на работающем экземпляре RDS. (Предполагается, что ваша архитектура позволяет изменять хранилище данных при сохранении обратной совместимости или что сначала вы обновляете код сервера приложений, чтобы обеспечить его прямую совместимость.)
  2. Создайте новый экземпляр сервера приложений, используя подготовленный заранее подготовленный AMI.
  3. Установите обновленный код на новый сервер приложений, т. Е. Новый код, который использует новый столбец и обладает новыми функциями.
  4. Тест.
  5. Перенесите часть или весь трафик, то есть перенесите IP-адрес / переключите Elastic Load Balancing на новый сервер приложений. (В идеальном мире вы будете перемещаться лишь на небольшой процент, скажем, сначала 5% трафика, а затем наблюдать за любыми проблемами. AFAIK Elastic Load Balancing пока не поддерживает взвешенную липкую маршрутизацию, поэтому вам, вероятно, не следует этого делать. Постепенное переключение также может быть достигнуто за счет наличия в вашем коде двух путей выполнения, но это отнимает много времени и раздражает - взвешенная балансировка нагрузки на липкой основе проще.)
  6. Сохраняйте старый экземпляр сервера приложений в течение нескольких дней, если в новом коде имеются регрессии и вам необходимо выполнить откат.
Источник
Другие вопросы по тегам