Comments 8
Привет!
Спасибо за статью
Подскажите, пожалуйста, как в 2017 году решают проблему стейт-фулл сервисов в разрезе контейнеризации? Volumes докера? Или что-то ещё?
Интересно, как в этом месте с перфомансом. То есть, на сколько дешевле остаться на обычных виртуалках для БД, или уже можно посматривать на контейнеризацию таких сервисов?
Для примера можно рассмотреть парочку индустриальных БД: PostgreSQL, MongoDB, Cassandra.
Спасибо за статью
потому что дела со stateful-продуктами обстоят сложнее и «[для обслуживания] MySQL, Redis и Git у нас [в GitHub] уже налажена обширная автоматизация
Подскажите, пожалуйста, как в 2017 году решают проблему стейт-фулл сервисов в разрезе контейнеризации? Volumes докера? Или что-то ещё?
Интересно, как в этом месте с перфомансом. То есть, на сколько дешевле остаться на обычных виртуалках для БД, или уже можно посматривать на контейнеризацию таких сервисов?
Для примера можно рассмотреть парочку индустриальных БД: PostgreSQL, MongoDB, Cassandra.
в k8s есть StatefulSet. Вот пример для mysql.
P.S. В дополнение к этому мы ещё писали про операторов Kubernetes (есть, например, такой для PostgreSQL — собирались добраться до его тестирования и написать об этом, но пока никак не выходит…).
Лично мы на текущий момент (в production) выносим MySQL/PostgreSQL на отдельные виртуалки. Это не значит, что нельзя делать иначе, но (как и ребята из GitHub) пока не добрались до того, чтобы гарантировать нужное качество в их контейнеризации.
Тут начинается кусок доклада (на пару минут) от нашего техдира про этот вопрос: youtu.be/CgCLPYJRxbU?t=41m21s
Тут начинается кусок доклада (на пару минут) от нашего техдира про этот вопрос: youtu.be/CgCLPYJRxbU?t=41m21s
Я тоже не рискнул бы stateful в Kubernetes и докеры класть. Мне кажется, что ими управлять проще классическим способом.
Также я не могу пока решить для себя головоломку миграции сервисов (легко) и миграции данных (вверх — легко, но если что-то идет не так, как откатывать?), особенно в разрезе blue-green deployment. Вот в статье указано, что гитхаб разернул несколько кластеров — я к этой же мысли пришел быстро, когда в staging кластере умерла внутренняя сеть кубернетиса, включая dns. Три дня восстановления — это катастрофа в production. А если там ещё и stateful — это конец. Допустим, развернуть на одном кластере свежую версию кода — элементарно. Но без применения миграций (а они через ORM) — новый код не взлетит. А применение миграций положит старый кластер. В итоге вся идея выглядит неубедительной. Пока мы обновляем свои сервисы «по живому». Даунгрейд в случае серьезных изменений и неожиданных проблем будет той еще головной болью.
Также я не могу пока решить для себя головоломку миграции сервисов (легко) и миграции данных (вверх — легко, но если что-то идет не так, как откатывать?), особенно в разрезе blue-green deployment. Вот в статье указано, что гитхаб разернул несколько кластеров — я к этой же мысли пришел быстро, когда в staging кластере умерла внутренняя сеть кубернетиса, включая dns. Три дня восстановления — это катастрофа в production. А если там ещё и stateful — это конец. Допустим, развернуть на одном кластере свежую версию кода — элементарно. Но без применения миграций (а они через ORM) — новый код не взлетит. А применение миграций положит старый кластер. В итоге вся идея выглядит неубедительной. Пока мы обновляем свои сервисы «по живому». Даунгрейд в случае серьезных изменений и неожиданных проблем будет той еще головной болью.
Просто тут, в случае использования отдельных железок для Базок, теряется такая приятная инварианта, как — всё железо описано в одном месте. Но видимо пока мы к этому ещё не пришли.
А какая у вас проблема с откатыванием данных? Вроде бы эта проблема никак не связана с контейнерами, и всегда решается примерно одинаковыми путями? Например, версионированием данных, и поддержикой со стороны приложения нескольких версий. Или я о другом?
А какая у вас проблема с откатыванием данных? Вроде бы эта проблема никак не связана с контейнерами, и всегда решается примерно одинаковыми путями? Например, версионированием данных, и поддержикой со стороны приложения нескольких версий. Или я о другом?
> всё железо описано в одном месте.
На самом деле описание всего железа идёт в Terraform, хотя с ним и сложно работать, но он свою задачу в итоге решает.
На самом деле описание всего железа идёт в Terraform, хотя с ним и сложно работать, но он свою задачу в итоге решает.
> А какая у вас проблема с откатыванием данных?
С контейнерами не связана, но в контексте кубернетиса связь в том, что stateless обновляется очень легко и быстро, но код так или иначе использует базы и выполняет при обновлении ряд миграций. И в этот момент нивелируется вся красота этого быстрого обновления контейнеров.
С контейнерами не связана, но в контексте кубернетиса связь в том, что stateless обновляется очень легко и быстро, но код так или иначе использует базы и выполняет при обновлении ряд миграций. И в этот момент нивелируется вся красота этого быстрого обновления контейнеров.
Sign up to leave a comment.
Истории успеха Kubernetes в production. Часть 3: GitHub