Служба AWS ECS, выполняющая SSH за сетевым балансировщиком нагрузки + целевая группа, медленно развертывается с помощью CodeDeploy

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

gedit-> edit-> preferens-> editor

и удалите проверку на

«замените закладку пробелом»

0
задан Eric M. Johnson 17 January 2019 в 06:24
поделиться

1 ответ

Вы не делаете ничего плохого здесь; это просто кажется (текущим) ограничением этого продукта.

Недавно я заметил подобные задержки во времени регистрации / доступности со службами ECS за NLB и решил исследовать. Я создал простой эхо-сервер TCP Javascript и настроил его в качестве службы ECS за NLB (счетчик служб ECS, равный 1). Как и вы, я использовал проверку работоспособности TCP с порогом работоспособности / нездоровья 2 и задержкой интервала / отмены регистрации 10 секунд.

После того, как начальное развертывание было успешным, и сервис, доступный через NLB, я хотел посмотреть, сколько времени потребуется для восстановления сервиса в случае полного сбоя базового экземпляра. Для симуляции я убил сервис через консоль ECS. После нескольких итераций этого теста я последовательно наблюдал временную шкалу, похожую на следующую (время в секундах):

0s:   killed service
5s:   ECS reports old service draining
      Target Group shows service draining
      ECS reports new service instance is started
15s:  ECS reports new task is registered
      Target Group shows new instance with status of 'initial'
135s: TCP healthcheck traffic from the load balancer starts arriving 
      for the service (as measured by tcpdump on the EC2 host running 
      the container)
225s: Target Group finally marks the service as 'healthy'
      ECS reports service has reached a steady state

Я выполнял те же тесты с простым приложением Express за ALB, и разрыв между ECS запустил службу, и ALB сообщил, что она исправна, через 10-15 секунд. Наилучший результат, достигнутый нами при тестировании NLB, составил 3,5 минуты от остановки сервиса до полной доступности.

Я поделился этими выводами с AWS в форме поддержки, специально попросив уточнить, почему до начала проверки работоспособности службы NLB был постоянный промежуток в 120 секунд, и почему мы постоянно видели 90-120 секунд между началом проверок работоспособности и доступностью службы , Они подтвердили, что это поведение известно, но не предложили время для разрешения или стратегии по снижению задержки в доступности услуг.

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

0
ответ дан bjcube 17 January 2019 в 06:24
поделиться