Статьи

Нулевое время простоя с помощью AWS ECS и ELB

Ноябрь 27, 2018

По мере того, как команды разработчиков стремятся к непрерывной доставке, развертывание обновлений приложения без сбоев для пользователей становится все более востребованной практикой. Контейнерный сервис Amazon EC2 помогает сделать это проще, чем когда-либо, благодаря тесной интеграции Elastic Load Balancer .

Кому нужно нулевое время простоя?

Ответ на этот вопрос зависит от того, кого вы спрашиваете. Наиболее распространенным ответом были глобальные веб-сайты с постоянным трафиком двадцать четыре / семь или сервисы высокой доступности с Соглашениями об уровне обслуживания (SLA), которые включали гарантии на время простоя. Все, что не помещается в этот блок, теоретически может быть развернуто в нерабочее время с минимальным вмешательством пользователя.

По мере того как все большее число команд переходят к непрерывной доставке / развертыванию с упором на быструю обратную связь, растет желание иметь возможность развертывания несколько раз в день, в середине дня и в то время, когда пользователи активны на сайте. Другие команды могут просто ценить свой сон. Независимо от причины, развертывание без процесса простоя в середине дня создаст заметные сбои для ваших пользователей, подрывая их доверие к вашему сайту или услуге. Это плохо.

Как выглядит нулевое время простоя?

На базовом уровне развертывание с нулевым временем простоя включает замену серверов, на которых выполняется новый код, на серверы, на которых работает старый код на балансировщике нагрузки. Вот общий сценарий процесса:

  1. Создайте новый образ виртуальной машины (VM) с новым кодом.
  2. Запустите количество виртуальных машин, использующих этот образ, равное числу запущенных в данный момент.
  3. Убедитесь, что каждый из этих экземпляров работает правильно и отвечает на проверки.
  4. Добавьте новые экземпляры в ELB, удаляя старые (с опустошением соединения).
  5. Убедитесь, что все работает правильно. Если нет, поменяйте старый на новый и диагностируйте проблему. Если это так, удалите старые экземпляры.

Процесс будет выглядеть немного иначе, если изменения в базе данных будут задействованы. Для управления изменениями схемы необходимы строгие политики разработчика, чтобы исключить возможность отката без развертывания. Как правило, никогда не удаляйте и не изменяйте столбец или таблицу, которые используются в данный момент. Если есть проблема, вы не сможете выполнить откат без восстановления из резервной копии. Задержите это изменение до следующего развертывания.

Изменения в базе данных с нулевым временем простоя — гораздо более сложная тема, которая может варьироваться в зависимости от уровня нагрузки базы данных в зависимости от того, что делается. Но общее правило обеспечения обратной совместимости при развертывании охватывает большинство основ. Пока ничего не сломается со старым кодом и новым кодом, работающим бок о бок в течение пары минут, вы должны быть в курсе.

Чем он отличается от ECS?

ECS не использует отдельные виртуальные машины. Он использует кластер из нескольких для развертывания Docker-контейнеров к ним через определения задач. Однако основные строительные блоки развертывания с нулевым временем простоя одинаковы. Нам нужно запустить новый контейнер, убедиться, что он работает, а затем заменить его на балансировщике нагрузки. Это важно для кластера, потому что у вас должно быть достаточно ресурсов в кластере, чтобы запустить новые контейнеры, в то время как другие уже работают. Если необходимые ресурсы недоступны, вы увидите заметку в консоли событий, которая выглядит следующим образом:

1
service sample-webapp was unable to place a task because the resources could not be found.

Если у вас есть эти ресурсы, вы увидите набор сообщений по следующим направлениям:

1
2
3
4
5
service sample-webapp has started 2 tasks: task TASK-ID-1 task TASK-ID-2.
service sample-webapp registered 2 instances in elb LOAD-BALANCER-NAME
service sample-webapp has begun draining connections on 2 tasks.
service sample-webapp stopped 2 running tasks.
service sample-webapp has reached a steady state.

Сообщения, которые вы видите, являются работой существующей интеграции ECS с Elastic Load Balancer для выполнения этих развертываний с нулевым временем простоя без необходимости вмешательства. Все, что вам необходимо, если у вас нет доступных ресурсов, — это добавить дополнительные экземпляры в кластер. Это можно сделать, изменив нужные экземпляры в группе автоматического масштабирования или перейдя непосредственно к EC2, чтобы добавить больше экземпляров в кластер.

Попробуй сам

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

  1. Во-первых, если вы этого еще не сделали, завершите процесс настройки с помощью Amazon ECS .
  2. Затем перейдите к мастеру первого запуска консоли ECS.
  3. Просмотрите руководство по началу работы с ECS, чтобы запустить пример веб-приложения.
  4. Перейдите к определению задачи и создайте ревизию console-sample-app-static .
  5. Отредактируйте JSON для «команды», чтобы заметно изменить отображаемый HTML-код.
  6. Теперь перейдите в кластер, выберите свой кластер.
  7. В кластере нажмите на свой сервис.
  8. В Сервисе нажмите Обновить и измените определение задачи на ревизию, которую вы сделали на шаге 4. Она будет указываться рядом с номером ревизии. Затем нажмите Обновить службу.
  9. На вкладке «Развертывания» вы сможете увидеть количество ожидающих и счетчиков изменений через несколько секунд. Не стесняйтесь обновлять вкладку браузера, на которую было нацелено приложение, чтобы наблюдать за переходом.
  10. Когда вы закончите, не забудьте пройти процесс очистки .

Это оно!

Ссылка: Нулевое время простоя с AWS ECS и ELB от нашего партнера по JCG Барри Джонса в блоге Codeship Blog .
47
Share: