ФТ
если так рассуждать, то и в миграции в ECS смысла нет
Size: a a a
2020 April 15
ФТ
Elastic Beanstalk достаточно за глаза
VM
Elastic Beanstalk достаточно за глаза
Для определенных задач - да. Beanstalk не может в service discovery и многие другие плюшки микросервисов. Ecs и eks могут.кубер идёт ещё дальше и даёт возможность ставить сторонние компоненты, типа контроллеров сервисов. Для компаний которые строят что-то на сервисах ecs успешно закрывает 85% кейсов. Для остальных уже надо eks городить.
ФТ
из коробки service discovery не умеет, да, но если сильно хочется можно самому заморочиться с консул агентом, но это изврат уже)
а как же вендор лок в случае с ECS?
я понимаю, что лучше AWS нихрена нет на рынке на данный момент, но всё же, хочется иметь в жизни меньше вендор лока)
с EKS вендор лока меньше, чем c ECS
а как же вендор лок в случае с ECS?
я понимаю, что лучше AWS нихрена нет на рынке на данный момент, но всё же, хочется иметь в жизни меньше вендор лока)
с EKS вендор лока меньше, чем c ECS
AP
ECS - вроде беспатный, а EKS - стоит 0.1$ в час, почему такие расценки и довольно недешево стоит EKS использовать,
у google cloud, намного дешевле.
у google cloud, намного дешевле.
Это старая информация. Google сделал его платным и цена аналогичная.
«Starting June 6, 2020, GKE clusters will accrue a management fee of $0.10 per cluster per hour, irrespective of cluster size or topology.»
https://cloud.google.com/kubernetes-engine/pricing
«Starting June 6, 2020, GKE clusters will accrue a management fee of $0.10 per cluster per hour, irrespective of cluster size or topology.»
https://cloud.google.com/kubernetes-engine/pricing
AP
вопрос хороший, задаюсь им по сей день
думаю кубер тебе даст сильно больше возможностей
думаю кубер тебе даст сильно больше возможностей
Смотря что считать «больше возможностей»
AP
ECS и EKS - нашел вот такие сервисы в сервисе aws, мне интересно какой из них когда лучше использовать?
Elastic Container Service
Elastic Kubernetes Service
Elastic Container Service
Elastic Kubernetes Service
Если у вас нет требования использовать именно K8s, то используйте ECS. Они оба это всего лишь оркестраторы, функционал и терминология аналогичная. С точки интеграции с остальными сервисами AWS у ECS намного все проще и быстрее.
VM
из коробки service discovery не умеет, да, но если сильно хочется можно самому заморочиться с консул агентом, но это изврат уже)
а как же вендор лок в случае с ECS?
я понимаю, что лучше AWS нихрена нет на рынке на данный момент, но всё же, хочется иметь в жизни меньше вендор лока)
с EKS вендор лока меньше, чем c ECS
а как же вендор лок в случае с ECS?
я понимаю, что лучше AWS нихрена нет на рынке на данный момент, но всё же, хочется иметь в жизни меньше вендор лока)
с EKS вендор лока меньше, чем c ECS
Вполне умеет, и через route53 и через cloudmap. В ui вообще несколько кликов. Вендорлок это не ecs, с него относительно просто куда угодно съехать. Вендорлок это iam, alb, dynamodb, redshift, cognito...
ФТ
> Для определенных задач - да. Beanstalk не может в service discovery и многие другие плюшки микросервисов.
сами себе противоречите в таком случае
с alb легче съехать, чем с ecs имхо
сами себе противоречите в таком случае
с alb легче съехать, чем с ecs имхо
AP
Elastic Beanstalk достаточно за глаза
Так он ECS и использует для контейнеров.
AWS часть своих сервисов как раз на ECS крутит, например Sagemaker.
AWS часть своих сервисов как раз на ECS крутит, например Sagemaker.
ФТ
да, но там же помимо докера еще и Java, .NET, PHP, Node.js, Python, Ruby и Go которые он на чистом EC2 запускает
VM
> Для определенных задач - да. Beanstalk не может в service discovery и многие другие плюшки микросервисов.
сами себе противоречите в таком случае
с alb легче съехать, чем с ecs имхо
сами себе противоречите в таком случае
с alb легче съехать, чем с ecs имхо
Ecs легко экспортируется в docker compose и дальше куда угодно импортруй. Многие фишки же alb в сумме с отказоустойчивостью и масштабированием не так и просто повторить
ФТ
Как угодно импортируй это куда? Чтобы именно не на одном хосте запуститься, а в кластере
VM
Как угодно импортируй это куда? Чтобы именно не на одном хосте запуститься, а в кластере
В любой удобный оркестратор. K8s, swarm, rancher. Пул ресурсов уже проблема оркестратора
ФТ
Ок, согласен
ФТ
Только rancher2 = k8s, а первый ранчер при смерти 😊
VM
Только rancher2 = k8s, а первый ранчер при смерти 😊
Он поверх k8s, такой себе ui. Так же и konvoy
i
Если у вас нет требования использовать именно K8s, то используйте ECS. Они оба это всего лишь оркестраторы, функционал и терминология аналогичная. С точки интеграции с остальными сервисами AWS у ECS намного все проще и быстрее.
Вот про функционал можно поспорить учитывая расширяемость куба
AP
Вот про функционал можно поспорить учитывая расширяемость куба
С учетом расширяемости, полностью согласен