Comments 60
UFO landed and left these words here
попробуйте в swarm mode сделать аналог куберовского пода

Исходя из этого описания пода, я так понимаю, что это не более чем логическая группа контейнеров со своими «namespaces and shared volumes». Так чего же из этого нет сейчас в Docker?
UFO landed and left these words here

оно пилится. в 1.13 docker service create уже умеет больше ручек из docker run, просто дайте им время)

UFO landed and left these words here
--network сервису Docker задать можно. При помощи этой опции и задается отдельный namespace для контейнеров сервиса. IPC — видимо пока нет. Не использовал последнюю опцию. Можете рассказать какие преимущества дает это в работе с контейнерами? Когда это целесообразно применять?
UFO landed and left these words here
В сварм моде не сделаешь --network=container:<name|id> — reuse another container's network stack.

В контексте сервисов это было бы странной фичей. В сервисе же мы не можем сказать точно где какой контейнер в данный момент работает. Нет, можем конечно, если обратимся к менеджеру с соответствующим запросом. Но ведь контейнер в любой момент может «переехать» на другой хост, и как в таком случае должен будет повести себя… кстати, вы хотите сервис к имеющемуся контейнеру подключить?

--IPC — был кейс года был нужен IPC неймспейс поделить хостовой с контейнером.

Опять же, хостов в кластере много, с каким именно хостом делить IPC namespace?
UFO landed and left these words here
UFO landed and left these words here
Pod — еще один уровень абстракции в дополнение к уже существующим (образ, контейнер, сервис). Но на самом деле его обязанности чрезвычайно размыты (pod — для него даже названия нормального не нашлось). Возможно необходимость в нем и была на каком-то этапе развития технологии Docker, но сейчас она (эта абстракция) стала совершенно ненужной и только вводит людей в заблуждение.
UFO landed and left these words here
И все-таки я считаю, что Docker обеспечивает «все те же возможности», может не «один в один», но основное уже точно реализовано. А может я просто фанат Docker )
UFO landed and left these words here
UFO landed and left these words here

Не, я имею ввиду что когда у меня утилизировано 80% мощности CPU или объёма RAM доступного контейнеру — надо создать ещё один инстанс.

UFO landed and left these words here

В вопросе масштабирования довольно рискованно доверять автоматическим системам. Решение о введении в строй новых инстансов все равно должно приниматься человеком.

UFO landed and left these words here

Ну так конкретно для хэзелкаста значит не включаем автомасштабирование :) Я же не говорю что надо в прод без тестирования.

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

UFO landed and left these words here

Видимо моя жизнь скучна — автомасштабироавние на компьют-нодах работает идеально, БД я в кубернетисе не кручу, ФС у меня — Ceph, железные.

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.
Ваш случай ( я про баг) довольно нетипичен для стандартных сценариев использования контейнеров. Конечно, это не повод не иметь возможности гибкого управления healthcheck, но думаю тут вопрос в приоритетизации задач.

Плюс, странно, что вы зная, что это вызовет проблемы, все же применили такое решение. Мне кажется, что в таких случаях стоит подумать о том, чтобы решать задачи длительных вычислений не в процессе инициализации контейнера, а, например, производить эти вычисления заранее, до старта контейнера. Либо делать это асинхронно, давая возможность 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 будет полноценной системой оркестрации.

по поводу volumes можно попробовать использовать плагины (экспериментальная фича 1.12, выходит из экспериментальной в 1.13) типа flocker

Спасибо! Планирую использовать фабрицио для деплоя текущего проекта.
Ждем новых плюшек. Еще раз спасибо, желаю уверенного развития тулзы.

Как раз сегодня с этим играюсь сижу.
Я пока в докере не очень, по этому вопрос есть. Увеличиваем кол-во реплик до Х, потом уменьшаем до У, в итоге имеем такую картину
http://take.ms/r5B66
Что собственно делать с теми, что в состоянии shutdown? Или они так и будут копиться до остановки самого сервиса?
UFO landed and left these words here
А их кол-во (в состоянии shutdown) не сказывает на производительности? Ресурсы не кушает?
UFO landed and left these words here
Насколько я понял, на каждой ноде хранится какое-то количество «бэкапов», и при достижении их количества определенного значения они начинают ротироваться. Во всяком случае я не видел ситуации, когда на одной ноде их было бы больше 4-х для одного сервиса.

Чего лично я не смог получить от swarm mode — поддержка сетевых плагинов. Так что ксли нужен кластерный дискавери, то ой...

Объединить в одну тоннелями/vpn/роутерами. У нас так объединены два облака, две стойки в дата-центрах и две в главных офиса в трёх странах в две 10.0.0.0/16 подсети. Один-два белых IP для каждого «дата-центра», метки на докер-нодах и в ограниченях конфигураций запуска контов, чтобы логически локальный трафик не ходил в другую часть света.
Сразу прошу простить меня за вещи сказанные неправильно, если таковые будут.
У меня возникли проблему со swarm mode когда понадобилось охватить больше одного региона в aws. Т.е. как я понимаю swarm может висеть на одно из доступных интерфейсов. У инстанса на aws это внутренняя сеть. Соответственно между регионами\зонами внутренняя сеть разная. Как быть в такой ситуации?
Прежде всего, я бы задался вопросом, а действительно ли вам это нужно. Например, разработчики Kubernetes где-то писали, что даже их «супер-пупер» облака спроектированы из расчета на применение внутри одного датацентра. Нужно несколько датацентров (в вашем случае: зон AWS) — создавайте несколько независимых кластеров. Как-то так…
UFO landed and left these words here
Понятно, что всё еще сыро, ребята из Docker Inc слишком увлекаются фичами и оставляют много багов по сторонам.

Но принципиально смущает ingress load balacing. По сути он обманывает внешний балансировщик. По идее HAProxy должен знать, что не нужно равномерно распределять трафик на 3 ноды, а нужно на 2 и куда запрос пришел, там и остался. Если запросы «тяжелые» и нагрузка относительно железа небольшая, то потенциально можно себе позволить гонять данные через лишние ноды и сеть, но далеко не для всех сценариев такое подходит. Есть механизм обхода этого? Т.е. выбрасывание портов на конкретной ноде только (ну и информирование о списке нодов через какой-нибудь service discovery можно уже внутри контейнера сделать).
Можно создать сервис с опцией --mode global, в этом случае Docker будет создавать по одному контейнеру на всех доступных нодах. В этом режиме количество реплик равно количеству нод. Возможно, что в этом случае внутренней балансировки не происходит, и ее полностью можно делегировать внешнему балансировщику.
UFO landed and left these words here
1.12 вообще привнесла путаницу какую-то. Везде в интернете во всяеских статейках было написано что multi-host можно разворачивать через swarm + docker-compose. распределяя какой контейнер на какой ноде — через labels.
(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 — какой-то бред.

наши админы пока юзают мейкфайлы, ждем 1.13, будем пробовать бандлы

как я понимаю, налицо путаница между Docker Swarm и swarm-mode Docker Engine.
https://www.docker.com/products/docker-swarm и https://docs.docker.com/engine/swarm/ — не одно и то же
действительно кошмар. еще и начинается с использования docker-machine и virtualbox. Видимо по этой причине я и обошел эту доку
UFO landed and left these words here
UFO landed and left these words here
А вот эти все Deploy заботятся хоть как-то о состоянии существующих tcp сессий? Или хипстеры не знают что это такое, как в случае с Kubernetes?
Deploy системы об этом никак не заботятся, об этом, как вы верно заметили, заботится Kubernetes, или, как в данном случае, это должен делать сам Docker. То есть, оркестрация не входит в задачи инструментов для деплоя.
Я про
Это достигается за счет того, что Docker обновляет контейнеры сервиса по очереди.


Это задача Docker Swarm или Kubernetes. Он должен понимать можно рвать сейчас tcp-сессии или нет. Например, как это сделано в haproxy или nginx.
Only those users with full accounts are able to leave comments. Log in, please.