Comments 60
UFO just landed and posted this here
попробуйте в swarm mode сделать аналог куберовского пода
Исходя из этого описания пода, я так понимаю, что это
UFO just landed and posted this here
оно пилится. в 1.13 docker service create уже умеет больше ручек из docker run, просто дайте им время)
--network сервису Docker задать можно. При помощи этой опции и задается отдельный namespace для контейнеров сервиса. IPC — видимо пока нет. Не использовал последнюю опцию. Можете рассказать какие преимущества дает это в работе с контейнерами? Когда это целесообразно применять?
UFO just landed and posted this here
В сварм моде не сделаешь --network=container:<name|id> — reuse another container's network stack.
В контексте сервисов это было бы странной фичей. В сервисе же мы не можем сказать точно где какой контейнер в данный момент работает. Нет, можем конечно, если обратимся к менеджеру с соответствующим запросом. Но ведь контейнер в любой момент может «переехать» на другой хост, и как в таком случае должен будет повести себя… кстати, вы хотите сервис к имеющемуся контейнеру подключить?
--IPC — был кейс года был нужен IPC неймспейс поделить хостовой с контейнером.
Опять же, хостов в кластере много, с каким именно хостом делить IPC namespace?
UFO just landed and posted this here
UFO just landed and posted this here
Pod — еще один уровень абстракции в дополнение к уже существующим (образ, контейнер, сервис). Но на самом деле его обязанности чрезвычайно размыты (pod — для него даже названия нормального не нашлось). Возможно необходимость в нем и была на каком-то этапе развития технологии Docker, но сейчас она (эта абстракция) стала совершенно ненужной и только вводит людей в заблуждение.
UFO just landed and posted this here
И все-таки я считаю, что Docker обеспечивает «все те же возможности», может не «один в один», но основное уже точно реализовано. А может я просто фанат Docker )
UFO just landed and posted this here
автомасштабирование?
UFO just landed and posted this here
Не, я имею ввиду что когда у меня утилизировано 80% мощности CPU или объёма RAM доступного контейнеру — надо создать ещё один инстанс.
Docker swarm самая сырая оркестрация из тех, что есть kubernetes, даже тот же rancher. Mой баг, который сделан во всех движках, кроме docker swarm, висит 4 месяца https://github.com/docker/docker/issues/26664. По моим оценкам docker надо пилить еще год минимум.
Используем docker swarm для production и CI/CD, самые большие проблемы с docker volume, эта логическая концепция абсолютно не проработана для работы с docker service.
Используем docker swarm для production и CI/CD, самые большие проблемы с docker volume, эта логическая концепция абсолютно не проработана для работы с docker service.
Ваш случай ( я про баг) довольно нетипичен для стандартных сценариев использования контейнеров. Конечно, это не повод не иметь возможности гибкого управления healthcheck, но думаю тут вопрос в приоритетизации задач.
Плюс, странно, что вы зная, что это вызовет проблемы, все же применили такое решение. Мне кажется, что в таких случаях стоит подумать о том, чтобы решать задачи длительных вычислений не в процессе инициализации контейнера, а, например, производить эти вычисления заранее, до старта контейнера. Либо делать это асинхронно, давая возможность healthcheck скрипту отдать вменяемый ответ на соответствующий запрос.
Насчёт volumes — вполне логично, что для распределённых систем реализация данной концепции не является простой штукой. И мое мнение в том, что надо избегать использования volumes для сервисов. Сервисы предназначены для stateless систем. А если состояние все-же нужно шарить между контейнерами сервиса, то для этого лучше использовать БД, которую запускать не как сервис, а как несколько обычных контейнеров на разных хостах.
Плюс, странно, что вы зная, что это вызовет проблемы, все же применили такое решение. Мне кажется, что в таких случаях стоит подумать о том, чтобы решать задачи длительных вычислений не в процессе инициализации контейнера, а, например, производить эти вычисления заранее, до старта контейнера. Либо делать это асинхронно, давая возможность healthcheck скрипту отдать вменяемый ответ на соответствующий запрос.
Насчёт volumes — вполне логично, что для распределённых систем реализация данной концепции не является простой штукой. И мое мнение в том, что надо избегать использования volumes для сервисов. Сервисы предназначены для stateless систем. А если состояние все-же нужно шарить между контейнерами сервиса, то для этого лучше использовать БД, которую запускать не как сервис, а как несколько обычных контейнеров на разных хостах.
В Healthcheck просто не хватает критического параметра, реакции на старт приложения. В Docker есть 3 состояния healthy, starting, unhealthy. Так вот управлять starting не возможно никак, если увеличиваешь интервал проверки страдает runtime check, который может стать слишком долгим для определенных задач, если уменьшаешь интервал, то страдает starting состояние, тупо процесс не успевает стартовать. Это абсолютное нормальное явление проверять http запрос каждую секунду и дать системе на старт 10 секунд.
Оправдать эти костыли никак нельзя, тем более в других системах такого нет.
Никто не говорит, что volume это просто, но в Кубернетес изначально есть persistent volume, а docker все пытается продать идею, что состояние не важно. Причем Docker Swarm выпустили абсолютно сырым в плане volume, невозможно создать сервис с volume с replicas > 1.
P.S. Docker купил http://infinit.sh/ и в принципе понятно, что будет с volume, когда будет в этом вопрос. Я оцениваю Docker может через год или 2 будет полноценной системой оркестрации.
Оправдать эти костыли никак нельзя, тем более в других системах такого нет.
Никто не говорит, что volume это просто, но в Кубернетес изначально есть persistent volume, а docker все пытается продать идею, что состояние не важно. Причем Docker Swarm выпустили абсолютно сырым в плане volume, невозможно создать сервис с volume с replicas > 1.
P.S. Docker купил http://infinit.sh/ и в принципе понятно, что будет с volume, когда будет в этом вопрос. Я оцениваю Docker может через год или 2 будет полноценной системой оркестрации.
по поводу volumes можно попробовать использовать плагины (экспериментальная фича 1.12, выходит из экспериментальной в 1.13) типа flocker
С flocker теперь непонятно что будет: https://techcrunch.com/2016/12/22/clusterhq-hits-the-deadpool/
Хотя надежды есть: https://twitter.com/thenewstack/status/812016009163001856
Спасибо! Планирую использовать фабрицио для деплоя текущего проекта.
Ждем новых плюшек. Еще раз спасибо, желаю уверенного развития тулзы.
Как раз сегодня с этим играюсь сижу.
Я пока в докере не очень, по этому вопрос есть. Увеличиваем кол-во реплик до Х, потом уменьшаем до У, в итоге имеем такую картину
http://take.ms/r5B66
Что собственно делать с теми, что в состоянии shutdown? Или они так и будут копиться до остановки самого сервиса?
Я пока в докере не очень, по этому вопрос есть. Увеличиваем кол-во реплик до Х, потом уменьшаем до У, в итоге имеем такую картину
http://take.ms/r5B66
Что собственно делать с теми, что в состоянии shutdown? Или они так и будут копиться до остановки самого сервиса?
Чего лично я не смог получить от swarm mode — поддержка сетевых плагинов. Так что ксли нужен кластерный дискавери, то ой...
Объединить в одну тоннелями/vpn/роутерами. У нас так объединены два облака, две стойки в дата-центрах и две в главных офиса в трёх странах в две 10.0.0.0/16 подсети. Один-два белых IP для каждого «дата-центра», метки на докер-нодах и в ограниченях конфигураций запуска контов, чтобы логически локальный трафик не ходил в другую часть света.
Сразу прошу простить меня за вещи сказанные неправильно, если таковые будут.
У меня возникли проблему со swarm mode когда понадобилось охватить больше одного региона в aws. Т.е. как я понимаю swarm может висеть на одно из доступных интерфейсов. У инстанса на aws это внутренняя сеть. Соответственно между регионами\зонами внутренняя сеть разная. Как быть в такой ситуации?
У меня возникли проблему со swarm mode когда понадобилось охватить больше одного региона в aws. Т.е. как я понимаю swarm может висеть на одно из доступных интерфейсов. У инстанса на aws это внутренняя сеть. Соответственно между регионами\зонами внутренняя сеть разная. Как быть в такой ситуации?
Прежде всего, я бы задался вопросом, а действительно ли вам это нужно. Например, разработчики Kubernetes где-то писали, что даже их «супер-пупер» облака спроектированы из расчета на применение внутри одного датацентра. Нужно несколько датацентров (в вашем случае: зон AWS) — создавайте несколько независимых кластеров. Как-то так…
Сейчас есть режим федерации, созданный для таких случаев
UFO just landed and posted this here
Понятно, что всё еще сыро, ребята из Docker Inc слишком увлекаются фичами и оставляют много багов по сторонам.
Но принципиально смущает ingress load balacing. По сути он обманывает внешний балансировщик. По идее HAProxy должен знать, что не нужно равномерно распределять трафик на 3 ноды, а нужно на 2 и куда запрос пришел, там и остался. Если запросы «тяжелые» и нагрузка относительно железа небольшая, то потенциально можно себе позволить гонять данные через лишние ноды и сеть, но далеко не для всех сценариев такое подходит. Есть механизм обхода этого? Т.е. выбрасывание портов на конкретной ноде только (ну и информирование о списке нодов через какой-нибудь service discovery можно уже внутри контейнера сделать).
Но принципиально смущает ingress load balacing. По сути он обманывает внешний балансировщик. По идее HAProxy должен знать, что не нужно равномерно распределять трафик на 3 ноды, а нужно на 2 и куда запрос пришел, там и остался. Если запросы «тяжелые» и нагрузка относительно железа небольшая, то потенциально можно себе позволить гонять данные через лишние ноды и сеть, но далеко не для всех сценариев такое подходит. Есть механизм обхода этого? Т.е. выбрасывание портов на конкретной ноде только (ну и информирование о списке нодов через какой-нибудь service discovery можно уже внутри контейнера сделать).
Можно создать сервис с опцией --mode global, в этом случае Docker будет создавать по одному контейнеру на всех доступных нодах. В этом режиме количество реплик равно количеству нод. Возможно, что в этом случае внутренней балансировки не происходит, и ее полностью можно делегировать внешнему балансировщику.
1.12 вообще привнесла путаницу какую-то. Везде в интернете во всяеских статейках было написано что multi-host можно разворачивать через swarm + docker-compose. распределяя какой контейнер на какой ноде — через labels.
(https://docs.docker.com/compose/swarm/#/multiple-dependencies)
Выходит docker-compose последней версии и вот уже нельзя поднимать контейнеры в swarm-моде.
На замену дали некие бандлы… но они экспериментальные.
https://docs.docker.com/compose/bundles/
Тоесть выпилили одну возможность, но не доделали замену. И как сейчас нормальным образом на 1.12 поднять swarm-кластер с overlay-network, и при этом что бы все описание кластера было в удобном виде, в текстовом файле — не понятно.
Выполнять руками десятки команд service create — какой-то бред.
(https://docs.docker.com/compose/swarm/#/multiple-dependencies)
Выходит docker-compose последней версии и вот уже нельзя поднимать контейнеры в swarm-моде.
WARNING: The Docker Engine you're using is running in swarm mode.
Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.
To deploy your application across the swarm, use the bundle feature of the Docker experimental build.
На замену дали некие бандлы… но они экспериментальные.
https://docs.docker.com/compose/bundles/
Тоесть выпилили одну возможность, но не доделали замену. И как сейчас нормальным образом на 1.12 поднять swarm-кластер с overlay-network, и при этом что бы все описание кластера было в удобном виде, в текстовом файле — не понятно.
Выполнять руками десятки команд service create — какой-то бред.
UFO just landed and posted this here
А вот эти все Deploy заботятся хоть как-то о состоянии существующих tcp сессий? Или хипстеры не знают что это такое, как в случае с Kubernetes?
Sign up to leave a comment.
Docker swarm mode (режим роя)