Comments 16
Хорошая документация. Сожмите до 1 статьи, так как материала по этой теме пруд пруди в сети. Добавьте информацию о существовании других балансиров/revers-proxy (aka nginx, angie или HAproxy
Приятно видеть что стартапы начали замечать докер сварм(про который постоянно вижу как в интернете пишут что неактуальная никем не используемая технология) вместо кубера. В рф только бигтехам нужен кубер, пока вы 1.5 землекопа с 3к юзеров в сутки - дальше сварма смотреть запрещено.
У меня 3 землекопа и нам очень удобно на кубере.
Кубер поднят на digital ocean, никаких усилий. Дальше только репо с манифестами и argocd.
А как писать манифесты ребята с прошлых работ знают.
Ага, замечают до первого split-brain и посещения чистилища https://github.com/moby/moby/issues/34384#issuecomment-1030750324
Молодцы!Очень хорошая, структурированная статья, особенно в части объяснения\мотивации бизнес-критериев при выборе решения. Я не так часто вижу от Sr. Engineer такой последовательный, рассудительный подход. К сожалению.
Большая просьба-наполните раздел документации на Github. У вас отличная статья здесь,и как написали выше, сожмите чуть и в README.md!
Монолитная с докером — если не самый надежный хостинг, то сильно страдает надежность, а с вертикальным расширением сильно растет и цена. Также сложно поддерживать изолированно различные окружения (dev/test/prod).
На мой взгляд, уж лучше начинать с простого docker (docker-compose). И уже потом смотреть на docker swarm.
Цена VPS не сказать что нелинейно растет с масштабом - в два раза более мощный сервер стоит примерно в два раза дороже. Т.е. разницы с двумя серверами особой нет (а если и есть - то зачастую в пользу более мощного сервера).
Пара серверов у ненадежного хостера не сильно выиграют в надежности.
Уж если делить по серверам - то выделять лучше сервер для "офисных" нужд (VPN-ка, Git-хранилище, CI/CD, работа с документами и т.д.) и для прода (отдельные на dev/tst/prd если так хочется).
Да, docker swarm может помочь с масштабированием - но и только. Все равно проще вертикально расти (пока есть возможность) - меньше накладных расходов. Резервирование же требует очень грамотного подхода.
P.S. совсем не понял про изоляцию окружения - и как этот вопрос решает docker swarm. Docker-compose дает изоляцию на уровне сети, установленные лимиты должны помочь с потреблением ресурсов сервисами. Какая еще нужна изоляция? Особенно если прод на отдельном сервере держать хотя бы из соображений безопасности.
Если говорить про vps, то вертикально расти не проще. Бизнес облака - продажа vps с некоторым оверкомитом, который в хорошем облаке, при "средних" задачах/утилизации vps , клиент и не заметит. Чем виртуалка толще, тем сложнее её облаку содержать и у клиента больше рисков пострадать от "шумного соседа"
Ну и 1 толстая vps проиграет по вероятности отказа 3 маленьким vps
Мы говорим о надежности железа или о работоспособности сервиса?
Если железо - да, живучей 3 будет (хотя процент "повышенной живучести" будет небольшой, с учетом того, что хостер один и тот же), то для повышенной надежности сервиса надо полноценно дублировать все сервисы. Не говоря уже о реализации сервисов для работы в распределенном режиме.
Но в статье речь о нескольких серверах из-за проблем масштабирования. Так что это не повышает надежность сервиса, а только понижает - точек отказа становится больше.
Мы говорим о надежности железа или о работоспособности сервиса?
Не понимаю разницы и применения ИЛИ
Не понимаю разницы и применения ИЛИ. Доступость/надежность/availability - это одна из метрик сервиса (я, честно, не понимаю что под работоспособностью имеется ввиду).
Но в статье речь о нескольких серверах из‑за проблем масштабирования. Так что это не повышает надежность сервиса, а только понижает — точек отказа становится больше.
Почитайте как рассчитывается уровень надежности\отказоустойчивости и как это связано с масштабированием. Для современного инженера, работающего на каждом шагу с масштабируемостью и отказоустойчивостью, это обязательные знания.
Гугл, Яндекс, Амазон закроются с понедельника, а то у них столько серверов и точек отказа, что нет никакой возможности работать.
Я знаю, что такое отказоустойчивость, как считается и т.д.
Но также я и знаю, что это заслуга не просто "запустили 2-3 сервера вместо одного", но и софта, умеющего в распределенном режиме работать.
И основной камень преткновения - именно в софте, а не в железе.
Гугл, Яндекс, Амазон имеют нужные компетенции и ресурсы для работы в подобном режиме. И то бывает всплывают нюансы.
Стесненный в средствах стартап - сомневаюсь.
Многие не могут позволить Я.сервисы, а их более дешевые конкуренты не так стабильны. И на самом деле, как показала практика, действительно, три маленькие vps выигрывают у 1 большой.
Мы сами сначала сидели на одном сервачке с компоузом и разными сетями, постепенно поднимая мощность, однако постоянные сбои заставили нас попробовать другой хостинг, который также оказался нестабильным. В итоге мы пришли к такому решению с несколькими машинками + сварм.
Говоря про изоляцию, имелось в виду именно про разные сервера для разных окружений (prod/dev). Вероятно, не так поняли, что я в статье хотел донести.
В случае отказа, сварм позволит просто подключить новую машинку и на ней все задеплоить (поменяв лейбл деплоя).
Также столкнулись с тем, что если падает одна машинка, то о таком инциденте бот хостинга единожды сообщает в лс и дальше молчание... Отсюда решили, что поднять вторую впску для мониторинга -- хорошая идея. Пока что с минусами системы не столкнулись, но возможно в этом моменте -- оверкил.
Отсюда могу сделать вывод, что отказоустойчивость, в таких условиях, явно выше. И, вероятно, хороший хостинг может решить многие проблемы :)
Многие не могут позволить Я.сервисы, а их более дешевые конкуренты не так стабильны.
Сомневаюсь, что надежность self-hosted docker swarm выше чем у конкурентов. И не забываем, что распределенный софт (без единой точки отказа) - это крайне сложная задача.
Мы сами сначала сидели на одном сервачке с компоузом и разными сетями, постепенно поднимая мощность, однако постоянные сбои заставили нас попробовать другой хостинг, который также оказался нестабильным.
Без понимания причин и характера сбоев, лично для меня звучит скорее как "пытались на коленках все запускать - было плохо, занялись вопросом плотнее, перешли на docker swarm - стало лучше". Но тогда заслуга тут не в docker swarm, а в "занялись вопросом плотнее".
Говоря про изоляцию, имелось в виду именно про разные сервера для разных окружений (prod/dev).
Разные окружения должны быть полностью изолированы, без общих точек отказа. Т.е. в рамках одного сервера / docker swarm они не должны жить.
В случае отказа, сварм позволит просто подключить новую машинку и на ней все задеплоить (поменяв лейбл деплоя).
Только если речь идет о state-less сервисах или полноценной репликации у сервиса.
Docker swarm я вижу скорее в сценарии с state-less воркерам, на которых выполняются ресурсоемкие задачи. Тогда да, просто масштабировать, выше надежность. Но единые точки отказа остаются - как минимум в виде мастера с централизованными сервисами (как минимум БД, очереди, внешнее API и т.д.).
Также столкнулись с тем, что если падает одна машинка, то о таком инциденте бот хостинга единожды сообщает в лс и дальше молчание...
Внешний мониторинг нужен - на хостера не надейтесь в этом вопросе вообще. Даже 2я нода на этом же хостере - не лучший выбор. Есть бесплатные мониторинги (от selectel, например) - для простых сценариев должно хватить (как минимум проверять доступность).
Отсюда могу сделать вывод, что отказоустойчивость, в таких условиях, явно выше.
Вот не знаю... Docker-compose сейчас в сам docker встраивается, так что надежность с swarm должна быть сравнимой - продукт одной компании (и более чем уверен, механики работы общие). Если с compose были проблемы надежности, то и swarm им же подвержен.
Но пока лично для себя причин перехода с compose на swarm я не понял. Только если ресурсоемкие задачи на отдельных серверах гонять не сильно заморачиваясь с инфраструктурой и доступами.
В какой-то мере масштабирование - да, но без полноценной репликации, больше точек отказа не дадут большую надежность.
Мы мож по разному слово стартап понимаем? )
Знаю как устроены две фирмы, названия которых здесь все знают, потому что одна входит в тройку гэмблинговых контор и всех замучала рекламой, вторая в тройку обучающих контор.
В одной руками жарник на линух деплоили на проме, в другой ваще был конструктор сайтов и вообще айтишников не было в штате ни одного.
DevOps инфраструктура для стартапов ч.1