Comments 46
А с пользовательскими файлами решил просто: для контейнеров это локальный путь, для докера — volume с nfs драйвером, а для меня — nfs шара, которую подняли амины.
Нужно читать сайт и блок перконы (http://percona.com), ключевые термины — pxc (синхронная репликация в mysql почти из коробки) и proxysql (который с недавних пор они пакуют в pxc).
Во-первых, это медленно. Во-вторых, на той стороне nfs это тоже надо реплицировать, бэкапить, вот это всё.
1) это медленно
2) все равно нужно решать вопросы с надежностью
:)
1) медленно — это вы про сам протокол или про идею хранить данные на сетевом хранилище в принципе?
Никто из разработчиков никогда про это не подумает. И однажды это больно укусит строителя такой системы за жопу.
"Никогда не говори никогда" :) Монтирование файловых систем (в том числе по сети) — очень распространенный приём (по крайней мере в Linux) и в худшем случае разработчик должен задокументировать, что та или иная функциональность рассчитана исключительно на локальные файловые системы, нарушает принцип "всё файл".
Не согласен. Разработчик в общем случае не должен предполагать какая ФС (а может и иерархия файловых систем, как часто бывает в случае docker или сетевых ФС) и в каком режиме она примонтирована под тем или иным путём и рассчитывать на особенности её поведения. Если предполагает, то должен свои предположения задокументировать.
Есть объективная реальность.
В объективной реальности файлы могут быть самыми разными и есть функции проверки различных свойств и способностей этих файлов. В некоторых субъективных реальностях эти функции игнорируются, а файлы субъективно наделяются свойствами по умолчанию, которых объективно у них нет.
И, внезапно, при смонтированном nfs или gluster можно получить абсолютно неприятные последствия. Поскольку он вроде бы как и есть, но с таким latency… что лучше бы его не было вообще
Статья зашла на одном дыхании.
Огромное спасибо от начинающего devOps'ера
У меня у самого сейчас, к несчастью, нечто похожее, т.к. кубернетес начальство не хочет, честно говоря, когда серверов больше 15, хотя бы раз в 5, уже возникают некоторые сложности.
Ну и плюс докерный healthcheck, а не консульный. У меня zabbix автоматом ругается, если контейнер начинает чудить, т.к. на контейнеры есть lld, хотя можно и консульный использовать, но неудобно опрашивать несколько dc, т.к. lld скрипт становится весьма развесистым.
Ну с Kubernetes вам не понадобился бы тот же Consul для service discovery, не пришлось бы решать проблему 1 pid на контейнер и настройкой сети под каждый отдельный хост.
Можно было бы автоматически экспозить ваши сервисы как вам хочется, настроить выдачу persistent volumes, хранить конфиги/секреты как отдельные сущности, запускать привелегированные контейнеры и все такое
Но swarm да — он проще…
Это была тема довольно долгой и горячей дискуссии на РИТ сразу после моего выступления.
Кубер нравится админам своей фичастостью. Для разработчика он добавляет ещё один, довольно широкий, пласт абстракции и новую предметную область. И это проблема.
Но вообще, если посмотреть на то что мы в итоге получили — это ведь даже не swarm (мы от него фактически только scheduling) используем. Это ОЧЕНЬ простая система, которая ОЧЕНЬ завязана на внутренние соглашения в команде и знание про окружающий ландшафт. Поэтому она довольно бодро работает.
Ну проблема в том, что «заставлять» — против моей личной идеологии, а значит надо дать инструменты. :)
Ну, назовем это не заставить, а поставить в список обязанностей протестировать код на вот таком вот тестовом кластере.
А пользоваться кубером вроде просто, особенно если уже есть pod для приложения. Но у меня такого нет, я только читал.
Это же минус. Зная kubernetes, я могу в любой компании\проекте эти знания использовать.
> Это ОЧЕНЬ простая система
Конечно, когда вы ее релизовывали. Поработав с kubernetes, он тоже становиться простым и понятным, если смотреть со стороны разработчика, а не devops. Им то наверное посложнее.
Ну с Kubernetes вам не понадобился бы тот же Consul для service discovery
Это не плюс а минус.
Consul стабильнее, чем ectd работал даже пребывая в виде зародыша альфа-версии
А ещё swarm можно развернуть локально, а кубер — почти нет. :)
Это ещё почему?
kubeadm init
Затем положить конфиг для CNI, и разрешить деплой на мастере:
kubectl taint nodes --all node-role.kubernetes.io/master-
Вот вам и готовый локальный кластер.
В последнее время все сильно упростилось и развернуть кубер немногим сложнее чем тот же swarm.
Другое дело — целесообразность такого решения:
Например, я использую Docker дома в виртуалке и доволен этим решением. Не вижу смысла в Kubernetes, если все что нужно — это просто запускать контейнеры из Docker Hub на локалхосте.
Но когда речь заходит о кластере, отказоустойчивсти, CI, rolling-update или statefull-приложениях я бы всерьез рассмотрел Kubernetes на эту роль.
Да, он несколько сложнее в освоении, но если разобраться вы получите отличный инструмент, который подойдет для решения широкого спектра задач.
Мое мнение, что Swarm — он слишком ограничивает.
что мы в итоге получили — это ведь даже не swarm (мы от него фактически только scheduling) используем
Да, но заметьте, вам пришлось прибегать и к сторонним решениям, например обучать каждый сервис регистрироваться в Consul. Хоть это и не такая большая проблема, но придет время и вам захочется большего. Придется создавать новые сервисы и придумывать новые абстракции, когда в Kubernetes это все уже реализовано в единой экосистеме.
Придется создавать новые сервисы и придумывать новые абстракции, когда в Kubernetes это все уже реализовано в единой экосистеме.
Или перейти на Kubernetes или конкурентов, когда это станет экономически выгодно. Время на изучение, время на внедрение сложных систем (а Kubernetes простым не назвать) — это инвестиции в долгосрочные перспективы, а не в краткосрочные.
Вот представьте себя даже на месте ПМ, не говоря о собственнике бизнеса. Приходит вы к нему и говорите: "у нас сейчас инфраструктура на Docker swarm, предлагаю дать мне задачу изучить Kubernetes и перевести инфраструктуру на него". Примерный список вопросов к предложению:
- чем не устраивает текущая?
- сколько вашего времени потребует изучение?
- сколько внедрение?
- какие дополнительные ресурсы кроме вашего рабочего времени?
- что мы получим от внедрения? Экономию ресурсов на разработку и доставку фич? Экономию ресурсов на эксплуатацию? Возможность нанимать менее квалифицированных разработчиков/девопсов/админов? Уменьшение потерь от простоев? Уменьшение числа и(или) длительности простоёв?
Это так, только навскидку.
у нас сейчас инфраструктура на Docker swarm, предлагаю дать мне задачу изучить Kubernetes и перевести инфраструктуру на него
Кажется я начал холивар :)
Хочу заметить, я ничего против Docker Swarm не имею, и если вам уже удалось выстроить нормально работающую инфраструктуру на нем, то зачем, в срочном порядке, пытаться заменить его на что-то другое?
А ты админ, да? :)
Кубер действительно любят админы. :)
Это очень идеалистичный взгляд на мир. На самом деле всё вот это невозможно сделать ТОЛЬКО на уровне ops и оркестрации, не учитывая особенности приложения.
А если всё равно часть надо делать в приложении с учётом опыта разработчиков — почему не сделать это всё там? Тот вариант который я описывал в докладе не пытается решать проблему мирового голода и ответить на главный вопрос жизни, вселенной и всего остального.
Но когда речь заходит о кластере, отказоустойчивсти, CI, rolling-update или statefull-приложениях я бы всерьез рассмотрел Kubernetes на эту роль.
CI он не решает. А только помогает.
С rolling updates на stateful вы снаружи приложения ничего не сделайте. Нужно участие самого приложения.
Про кластер рассказали в этой статье. Кибер не особо нужен
Кибер — штука хорошая.
Но она к сожалению многих вещей не решает.
Да, если у вас 1000 нод, то облегчит жизнь.
Но не более
Но при этом относительно Swarm Kubernetes — просто следующий уровень, лично я большой его фанат.
Все миньены работают на bare metal нодах.
Как результат есть и отказоусточивость, и ресурсы утилизируются по максимуму (по умолчанию деплой на мастере не рекомендуется), и бэкапить виртуальную машину гораздо проще чем физический хост.
Если интересно: вот мой конфиг, что бы заставить kubernetes работать внутри LXC-контейнера:
gist.github.com/kvaps/25f730e0ec39dd2e5749fb6b020e71fc
Ссылки картинками? 8-О
За что вы нас так не любите?
О, Автор! В Вашем случае, какая была разница между микро- и просто сервисом?
Я понимаю, что это холиворная тема и понятия растяжимые, но в данный момент сам замешан в распиливании монолита, и любопытно, где другие люди проводят границу?
— микросервис это сервис «одной функции» (не в смысле один def, а в бизнес-смысле. один справочник с crud, например)
— просто сервис это сервис «одной предметной области», например сервис «коммерция» в интернет-магазине и прайсы поставщиков разбирает, и лучший оффер выбирает, и цены считает с учётом пятка разных стратегий (и интерфейс для коммерсов для настройки этих стратегий даёт), и аналитику всякую считает и изменнённые цены пушит в системы, которым это важно… ну в общем делает «всё, что про цены». :)
Я для себя при дроблении монолита на (микро)сервисы решаю примерно так: если сервис, отвечает (читай — create/update/delete) только за одну сущность (вернее только за один агрегат), то он микросервис. Если же он для реализации своей бизнес-логики меняет несколько сущностей, про которые нельзя однозначно сказать, что одна является частью другой, то это просто сервис, минимонолит.
Спасибо за отсылку к Василию, порадовала )))
Самоорганизующаяся сервисная инфраструктура на базе Docker