YM
Dmytro Zavalkin
А контейнеры ваши то умеют в несколько копий и graceful shutdown?
Пока не принципиально, но пример будет полезен
Size: a a a
2020 February 06
DZ
Если нет то как ни крути - будет даунтайм у контейнера пока он переезжает
YM
Dmytro Zavalkin
Если нет то как ни крути - будет даунтайм у контейнера пока он переезжает
Нужно без
DZ
Ну а как если ваш контейнер (приложение) не умеет этого?
DZ
Live migration не завезли для контейнеров не только в амазоне а вообще в-принципе, насколько я знаю
YM
Dmytro Zavalkin
Ну а как если ваш контейнер (приложение) не умеет этого?
Это хороший вопрос, я думал о нем. Но щас хочу добиться отсутствие 503 ошибки
DZ
Ну давайте еще раз, на теоретическом уровне - чтобы без даунтайма переехать с одного инстанса на другой нам нужно минимум две копии контейнера чтобы бежали и обслуживали траффик
DZ
Дальше нам нужно одну копию потушить graceful (то есть чтобы она не обрубила текущие соединения а завершила их и выключилась) на старом инстансе, запустить ее уже на новом
DZ
И повторить операцию со второй копией
YM
Да, я так и сделал. Но получился фак-ап - все старые инстансов ушли в дрейн, пока новые не стартонули
DZ
В мире VM есть альтернатива - VM live migration, это когда средствами гипервизора снимается дапм памяти и регистров процессора VM и потом она фризится на старом сервере а на новом запускается копия (это если в общих чертах, там более сложный процесс). В этом случае тоже не будет даунтайма но с 90% вероятностью будут некоторые фризы и задержки в момент переключения
DZ
Да, я так и сделал. Но получился фак-ап - все старые инстансов ушли в дрейн, пока новые не стартонули
Так контейнеры то имеют несколько копий или нет? Если имеют то имеет смысл дальше обсуждать ECS и node drain, иначе надо сначала фиксить приложение
YM
Да, 2 копии
YM
Реплика
YM
Dmytro Zavalkin
Так контейнеры то имеют несколько копий или нет? Если имеют то имеет смысл дальше обсуждать ECS и node drain, иначе надо сначала фиксить приложение
Можно будет тебе в лс с утра?
DZ
Ок, тогда давайте по шагам - как вы апдейтите ami? Спользуя офф доку https://aws.amazon.com/blogs/compute/automatically-update-instances-in-an-amazon-ecs-cluster-using-the-ami-id-parameter/ и прилагающийся код CFN стека, лямбды и т.д. https://github.com/awslabs/ecs-cluster-manager ?
YM
Dmytro Zavalkin
Ок, тогда давайте по шагам - как вы апдейтите ami? Спользуя офф доку https://aws.amazon.com/blogs/compute/automatically-update-instances-in-an-amazon-ecs-cluster-using-the-ami-id-parameter/ и прилагающийся код CFN стека, лямбды и т.д. https://github.com/awslabs/ecs-cluster-manager ?
Да, все так. Но все инстансы уходя в дрейн, дрейнят Коннект
YM
Но таска в статусе - ранинг
YM
Но в ивент логе она уходит в дрейнинг конекшн
DZ
Хорошо, тогда вторая часть - когда контейнер ваш получает SIGTERM от ecs agent на том инстансе что дрейнится - он делает graceful shutdown?