Нет не нужно. Можно заучить кучу алгоритмов, и даже их реализацию. Чем собственно и занимаются девочки-зубрилочки в ВУЗе. И что непременно сделает кандидат при подготовке к собеседованию на котором точно спросят.
Проблема в том что это долго. Не считая всяких штук типа Packet (который и стоит как амазон) физ сервер ставят несколько дней с договором и вот это всё. Плюс вертикальное масштабирование означает повторение данной процедуры.
Для проекта у которого уже все хорошо и понятно это приемлемо, а вот для экспериментов не очень.
.
Не сказал бы что они надуманные. Под конкретную задачу вы можете предусмотреть специальный запрос (который кстати нарушит REST). Что будет когда клиенту понадобиться ещё один такой?
Хорошо, вы можете предусмотреть inclusion на манер JSON-API. А если понадобиться больше чем один уровень вложенности?
Все это в лучшем случае ведёт к грязному апи. В худшем к необоснованной денормализации данных и страданиям.
ими можно уже на уровне кластера управлять? а не на конкретной машине?
Если это не локальный вольюм, а, какой то облачный драйвер, конечно он без проблем примонтируется к контейнеру, на какой бы ноде он не находился. А в kubernetes не так? Локальный вольюм по умолчанию расшарен на все ноды? Насколько я помню Kubernetes предлагает для этого использовать NFS, но NFS есть и в докере из коробки.
swarm пока проигрывет очень в плане распространенности и поддержке, да и сырости.
Я вот замечаю что его больше и больше внедряют в продакшн.
Я ставлю на Swarm, так как докер уже стал де факто стандартом. А если посмотреть на последние релизы то станет очевидно, что Swarm становится режимом по умолчанию (но еще не стал) даже для одиночных серверов. Ибо все новые плюшки, типа compose v3 с деплоем реализуются только под swarm mode.
PS Вы постоянно подчеркиваете что Kubernetes это абстракция. А много ли контейнерных движков вы знаете, что нужна абстракция?
достаточно посмотреть список все-го того что можно подключить
Но у докера же volume драйверы. И драйверов явно не меньше, хоть и third party да, но это работает прозрачно, и переключение с одного стораджа на другой бесплатно.
В k8s igress позволяет в большей степени не думать о нодах, сети (на до кибернетовском уровне) а перед sworm если не путаю надо сначало заглушку поставить если не хотите сервисы из кластера делать доступными по портам
Load balancing идет из коробки, о нодах можно не думать. Dockre-Flow haproxy в коробку не входит, но он есть и прекрасно работает со свармом. Вариантов роутинга там достаточно
В целом Swarm еще пол года назад сильно уступал kubernetes, но развивается он очень быстро.
Плюс по поводу Kubrnetes у меня большие опасения. Это вендор лок, на этом самом Kubernetes. Swarm использует механизмы которые есть в докере. Что будет если Swarm победит? Вы привязаны к legacy технологии.
Независимость от инфраструктуры это фиш а докера в целом или я чего то не понимаю? Сварки все равно где и какие у него годы. Переключение не стоит почти ничего
Не совсем понятно зачем быть не зависимым от докера. Он все равно под капотом. Лично мне приятнее использовать нативные инструменты.
Касаемо стораджа. Я раньше тоже послушав как все прекрасно полез изучать. Оказалось не совсем. Вам в любом случае придется поднять ceph/glusterfs/поставьте своё руками. Так что магии нет. Апи возможно удобнее, но это кому как.
По идее, если вы примонтируете docker.sock к контейнеру запущенному на менеджере, то получите возможность управлять всем кластером из контейнера. В том числе и запускать сервисы.
В этом году продавали виртуальные билеты, поэтому видео не сразу.
Для проекта у которого уже все хорошо и понятно это приемлемо, а вот для экспериментов не очень.
.
Что до метеора, я что то не готов настолько прочно связывать клиент и сервер.
Хорошо, вы можете предусмотреть inclusion на манер JSON-API. А если понадобиться больше чем один уровень вложенности?
Все это в лучшем случае ведёт к грязному апи. В худшем к необоснованной денормализации данных и страданиям.
Если это не локальный вольюм, а, какой то облачный драйвер, конечно он без проблем примонтируется к контейнеру, на какой бы ноде он не находился. А в kubernetes не так? Локальный вольюм по умолчанию расшарен на все ноды? Насколько я помню Kubernetes предлагает для этого использовать NFS, но NFS есть и в докере из коробки.
Я вот замечаю что его больше и больше внедряют в продакшн.
Я ставлю на Swarm, так как докер уже стал де факто стандартом. А если посмотреть на последние релизы то станет очевидно, что Swarm становится режимом по умолчанию (но еще не стал) даже для одиночных серверов. Ибо все новые плюшки, типа compose v3 с деплоем реализуются только под swarm mode.
PS Вы постоянно подчеркиваете что Kubernetes это абстракция. А много ли контейнерных движков вы знаете, что нужна абстракция?
Но у докера же volume драйверы. И драйверов явно не меньше, хоть и third party да, но это работает прозрачно, и переключение с одного стораджа на другой бесплатно.
Load balancing идет из коробки, о нодах можно не думать. Dockre-Flow haproxy в коробку не входит, но он есть и прекрасно работает со свармом. Вариантов роутинга там достаточно
В целом Swarm еще пол года назад сильно уступал kubernetes, но развивается он очень быстро.
Плюс по поводу Kubrnetes у меня большие опасения. Это вендор лок, на этом самом Kubernetes. Swarm использует механизмы которые есть в докере. Что будет если Swarm победит? Вы привязаны к legacy технологии.
Касаемо стораджа. Я раньше тоже послушав как все прекрасно полез изучать. Оказалось не совсем. Вам в любом случае придется поднять ceph/glusterfs/поставьте своё руками. Так что магии нет. Апи возможно удобнее, но это кому как.
Из альтернатив я бы тут выделил Kubernetes. Однако он сложнее в понимании и на данным момент не сильно функциональнее сварма