Comments 4
Похожий опыт с ECS и Terraform. Терраформ в отличии от ECS очень нравится кстати...
Как назло, после всей этой баталии AWS начал запускать собственный сервис для хостинга Kubernetes под названием EKS
Ну и конечно ждем это, но пока никаких дат не озвучено кроме 2018. Надеюсь не Q4
Миша, привет!
Тарифицируются ли образы, которые хранятся в ECR и ведете ли вы их контроль в случае, если они тарифицируются по месту использования (в Google Cloud Storage например для этого используются региональные бакеты для хранения образов)? Какие именно Task Definitions Amazon определяет как устаревшие?
Сколько времени занимает rollback на старую версию приложения?
Планируете ли переходить на EKS, когда она выйдет в stable?
Тарифицируются ли образы, которые хранятся в ECR и ведете ли вы их контроль в случае, если они тарифицируются по месту использования (в Google Cloud Storage например для этого используются региональные бакеты для хранения образов)? Какие именно Task Definitions Amazon определяет как устаревшие?
Сколько времени занимает rollback на старую версию приложения?
Планируете ли переходить на EKS, когда она выйдет в stable?
Привет, Амет.
1. Да, на самом деле в статье словно «бесплатный» было сказано слишком громко. Тарификация составляет $0.10/GB за месяц. Вообще они так же хранятся на S3, но прямого контроля к файлам ты не имеешь. Собственно говоря, такая ситуация наблюдается почти в большинстве сервисов AWS.
Вести контроль нужно не только если бюджет слишком сильно лимитирован, но из-за лимитов Амазона — 1000 образов на один репозиторий/приложение. У нас пока такое случилось только один раз, решалось простой чисткой образов. Можно автоматизировать простеньким скриптом.
2. Сам Амазон по умолчанию считает все Task Definitions активными. Ты можешь их пометить как устаревшие либо сам (пометить их как inactive), либо просто удалить их. Это можно сделать через тот же ecs-deploy, кстати, удобная штука.
3. Смотря в каком случае: если ECS сам понимает, что новая версия не работает, то он по сути на нее даже не переключит трафик и старая версия приложения по-прежнему будет работать. Правда, он будет пытаться перезапускать новую версию до тех пор, пока ты не выставишь старую версию обратно (в ecs-deploy это тоже решается). Если сам хочешь откатиться, то время отката будет равно времени деплоя. Мы деплоим сервисы с маленьким количеством тасок за полторы-две минуты, большие не больше 3-4 минут. Зависит от ситуации.
4. Пока нет. Имхо для того, чтобы запрыгнуть на новую вещь, которая по сути решает ту же задачу, да еще через полгода-год после перехода на ECS, нужно иметь довольно много причин и понятный business-value. Ибо в конечном итоге можно потратить месяцы команды инженеров на переход, а в итоге в показателях эксплуатации (имею в виду uptime, latency, время деплоя) вообще не продвигаться. Сложный вопрос в общем.
1. Да, на самом деле в статье словно «бесплатный» было сказано слишком громко. Тарификация составляет $0.10/GB за месяц. Вообще они так же хранятся на S3, но прямого контроля к файлам ты не имеешь. Собственно говоря, такая ситуация наблюдается почти в большинстве сервисов AWS.
Вести контроль нужно не только если бюджет слишком сильно лимитирован, но из-за лимитов Амазона — 1000 образов на один репозиторий/приложение. У нас пока такое случилось только один раз, решалось простой чисткой образов. Можно автоматизировать простеньким скриптом.
2. Сам Амазон по умолчанию считает все Task Definitions активными. Ты можешь их пометить как устаревшие либо сам (пометить их как inactive), либо просто удалить их. Это можно сделать через тот же ecs-deploy, кстати, удобная штука.
3. Смотря в каком случае: если ECS сам понимает, что новая версия не работает, то он по сути на нее даже не переключит трафик и старая версия приложения по-прежнему будет работать. Правда, он будет пытаться перезапускать новую версию до тех пор, пока ты не выставишь старую версию обратно (в ecs-deploy это тоже решается). Если сам хочешь откатиться, то время отката будет равно времени деплоя. Мы деплоим сервисы с маленьким количеством тасок за полторы-две минуты, большие не больше 3-4 минут. Зависит от ситуации.
4. Пока нет. Имхо для того, чтобы запрыгнуть на новую вещь, которая по сути решает ту же задачу, да еще через полгода-год после перехода на ECS, нужно иметь довольно много причин и понятный business-value. Ибо в конечном итоге можно потратить месяцы команды инженеров на переход, а в итоге в показателях эксплуатации (имею в виду uptime, latency, время деплоя) вообще не продвигаться. Сложный вопрос в общем.
Sign up to leave a comment.
Cluster of Puppets: опыт использования Amazon ECS в iFunny