System administration
Network technologies
DevOps
Comments 15
0
А можно вопрос по теме:
Если появилась необходимость в одном из запущенных контейнеров в swarm-кластере, запускать другие контейнеры.
Как это правильно организовать с тем учетом, чтобы у запущенных контейнеров «второго порядка» был доступ в overlay сеть «родительского» контейнера.
0
По идее, если вы примонтируете docker.sock к контейнеру запущенному на менеджере, то получите возможность управлять всем кластером из контейнера. В том числе и запускать сервисы.
+1
Иногда Swarm mode бывает не совсем удобен, да и не очень стабилен он пока. Нашел бесплатное простое решение для развертывания сети между докерами на разных физических хостах — Waves Net называется (https://www.weave.works/oss/net/) — поднимает виртуальные сети одной командой, умеет шифровать и обеспечивает discovery. Может сгодится кому :)
0
Все таки Swarm это не только сети. Есть баллансировщик из коробки, есть готовый к бою haproxy, ну и деплой напрямую из compose.

Из альтернатив я бы тут выделил Kubernetes. Однако он сложнее в понимании и на данным момент не сильно функциональнее сварма
0
и на данным момент не сильно функциональнее сварма

Kubernetes немного дальше в например с той же интеграцией стораджа…
Ну и сама API не завязана на докер, это конечно как плюсы и минус можно видеть. Минус в сложности, так как ко всему есть абстракции, их надо один раз понять. Но зато, поняв их, вы становитесь независимы от сущностей облака или железа на которм бежит k8n. Как-бы принцип Контеэнров но в более широком смысле.
Со swarm пока больше возни в этом плане, но похоже с LinuxKit они тоже как-то по своему решают вопрос с абстракциями — IMHO пока слишком омбизиозный ( не совсем мне понятный) подход. Я бы сказал с k8n на данный момент не ошибится, он просто популярнее и активнее поддерживается (включая крупных игроков).
Но если есть/желание и возможность то и swarm надо иногда щупать

UFO landed and left these words here
0
Не совсем понятно зачем быть не зависимым от докера. Он все равно под капотом. Лично мне приятнее использовать нативные инструменты.

Касаемо стораджа. Я раньше тоже послушав как все прекрасно полез изучать. Оказалось не совсем. Вам в любом случае придется поднять ceph/glusterfs/поставьте своё руками. Так что магии нет. Апи возможно удобнее, но это кому как.
0
Не совсем понятно зачем быть не зависимым от докера. Он все равно под капотом. Лично мне приятнее использовать нативные инструменты.

Ну я же говорю это зависит от… Я к примеру тоже люблю.
С k8s вы не заморачиваетесь с тем где это все бежит. При случае можно и сменить все под k8s. Для больших и очень больших проектов это становится очень важно и не только по соображениям то-го что мы тоеоритически можем поменять облако, а скорее в более общем плане, как создание, абстркций — которые становятся технологически независимым стандартом.
В маленьком проекте может гораздо выжнее совсем другие вещи, как мотивация, одного девелопера ;)
Вот я в все пили свой частный проектик по ночам и там смотрю тоже на swarm но еще не решился.

0
Независимость от инфраструктуры это фиш а докера в целом или я чего то не понимаю? Сварки все равно где и какие у него годы. Переключение не стоит почти ничего
0

Нет докер абстрагирует только процесс на ядре линукс (с разными плюшками конечно) на одной машине.
Сворм добавляет новую абстракцию, мы абстрагируемся от конкретной машины и деплоим в кластер тут у нас конечно и k8s он тоже это делает. Делают они это по разному и по своему интересно и поэтому мне оба интересны хоть и знаком поверхностно.
Но в k8s все немного шире. Особенно со стораджем (где конечно до сих пор не все гладко), но достаточно посмотреть список все-го того что можно подключить и как хорошо ИМХО это подлючение абстрагированно от деталей самих технологий.
https://kubernetes.io/docs/concepts/storage/persistent-volumes/


Или такая штука как igress которая если я правильно помню гораздо шире того, что предлагает sworm, где к сервису просто порт открывается и мэпится виртуально через кластер.
В k8s igress позволяет в большей степени не думать о нодах, сети (на до кибернетовском уровне) а перед sworm если не путаю надо сначало заглушку поставить если не хотите сервисы из кластера делать доступными по портам, не говоря уже о балансировке по путям, TLS и т.д.
И так во многом.

0
достаточно посмотреть список все-го того что можно подключить


Но у докера же volume драйверы. И драйверов явно не меньше, хоть и third party да, но это работает прозрачно, и переключение с одного стораджа на другой бесплатно.

В k8s igress позволяет в большей степени не думать о нодах, сети (на до кибернетовском уровне) а перед sworm если не путаю надо сначало заглушку поставить если не хотите сервисы из кластера делать доступными по портам

Load balancing идет из коробки, о нодах можно не думать. Dockre-Flow haproxy в коробку не входит, но он есть и прекрасно работает со свармом. Вариантов роутинга там достаточно

В целом Swarm еще пол года назад сильно уступал kubernetes, но развивается он очень быстро.

Плюс по поводу Kubrnetes у меня большие опасения. Это вендор лок, на этом самом Kubernetes. Swarm использует механизмы которые есть в докере. Что будет если Swarm победит? Вы привязаны к legacy технологии.
0
Но у докера же volume драйверы.

ими можно уже на уровне кластера управлять? а не на конкретной машине?


Load balancing идет из коробки

Вообщето это обширная тема. Из коробки там по портам. Если просто называть сущности.то никуда не придем ;)
LB есть и там и там
Scheduling есть и там и там
Persintance есть и там и там..


Dockre-Flow haproxy

Сторонние инструменты можно и с k8s использовать… Не аргумент. Да и костыль это например если интегрировать в ресурсе предостовлямые клауд-провайдерарами а k8s какраз под них заточен. и модули написаные под него абстрагируйту такие вещи. Это фишка дизйна…
Сворм похоже и не стремится туда..


Плюс по поводу Kubrnetes у меня большие опасения. Это вендор лок, на этом самом Kubernetes. Swarm использует механизмы которые есть в докере. Что будет если Swarm победит? Вы привязаны к legacy технологии.

Тут какраз все упорекают докер что это вендор лок ;)
k8s какраз и сторит все абстракцие которы могут быть реализованны где угодно и на чем угодно, вы многие компоненты можете выкинутЭи заменить, включая сам докер. А сворм это какраз больше на легаси похоже, потому что пытается быть минималистичным (что хорошо).


k8s преподносит себя как платформа, вот линукс с башем — тоже же вендор лок своебразный.


Что будет если Swarm победит?

swarm пока проигрывет очень в плане распространенности и поддержке, да и сырости.

0
ими можно уже на уровне кластера управлять? а не на конкретной машине?

Если это не локальный вольюм, а, какой то облачный драйвер, конечно он без проблем примонтируется к контейнеру, на какой бы ноде он не находился. А в kubernetes не так? Локальный вольюм по умолчанию расшарен на все ноды? Насколько я помню Kubernetes предлагает для этого использовать NFS, но NFS есть и в докере из коробки.

swarm пока проигрывет очень в плане распространенности и поддержке, да и сырости.

Я вот замечаю что его больше и больше внедряют в продакшн.

Я ставлю на Swarm, так как докер уже стал де факто стандартом. А если посмотреть на последние релизы то станет очевидно, что Swarm становится режимом по умолчанию (но еще не стал) даже для одиночных серверов. Ибо все новые плюшки, типа compose v3 с деплоем реализуются только под swarm mode.

PS Вы постоянно подчеркиваете что Kubernetes это абстракция. А много ли контейнерных движков вы знаете, что нужна абстракция?

0
Я вот замечаю что его больше и больше внедряют в продакшн.
k8s гораздо распространненей сворма. А гугл его как продукт в своейм облаке предлагает… из коробки.

А в kubernetes не так?
не так.

PS Вы постоянно подчеркиваете что Kubernetes это абстракция. А много ли контейнерных движков вы знаете, что нужна абстракция?
Абстракция от того где это все будет бежать полезна без того что-бы без того что-бы стравнивать движки...

Ну и как-бы ваша аргументаци о том что вы любите и что вам нравится…
Любите заниматься вопросами настройки кластера? — какие проблемы… Я вовсе не сказал что докер сворм плохой.

Only those users with full accounts are able to leave comments.  , please.