Пятничный формат: Диалог о контейнерах




В нашем блоге мы пишем не только о развитии облачного сервиса 1cloud, но о наиболее обсуждаемых ИТ-темах, например, разработках VMware в области контейнеров, соответствующих мифах, а еще мы адаптировали подборку тематических инструментов.

Сегодня мы решили поговорить об этой теме в «пятничном формате».


А: Привет, мой босс сказал, что ты кое-что знаешь о веб-приложениях и можешь мне помочь.

Б: Да, теперь я занимаюсь распределенными системами. Я недавно вернулся с ContainerCamp и Gluecon, а на следующей неделе еду на Dockercon. Мне очень нравится направление, в котором движется индустрия – все упрощается, но одновременно становится надежнее. Вот оно – наше будущее!

А: Круто. Я пишу простенькое веб-приложение на Rails – это обычное CRUD-приложение, которое я хочу развернуть на Heroku. Так все еще делают?

Б: Нет-нет-нет. Heroku – это прошлый век, больше никто им не пользуется. Все переключились на Docker. За ним будущее.

А: О, ну хорошо, а что это?

Б: Docker – это новое решение для контейнеризации. Он похож на LXC, является форматом упаковки, платформой для распределения приложений и упрощает работу с распределенными системами.

А: Контейнеры… Что? Что такое LXC?

Б: LXC. Это такая «прокачанная» операция chroot!

А: Что? cher-oot?

Б: Ну, хорошо, смотри. Docker. Контейнеризация. Будущее. Это сродни виртуализации, вот только быстрее и дешевле.

А: Точно, то как Vagrant.

Б: Нет, Vagrant умер. Теперь все будет делаться с использованием контейнеров. Это будущее.

А: Получается, что мне можно забыть про виртуализацию?

Б: Нет, виртуализация нужна, потому что контейнеры имеют потенциальные проблемы с безопасностью. Пока. Если требуется запустить что-нибудь в многопользовательской среде, нужно убедиться, что программа не сможет выйти за пределы своей «песочницы».

А: Я немного запутался. Давай вернемся назад. Есть такая вещь, называемая контейнеризацией, которая похожа на виртуализацию. Я могу использовать её на Heroku?

Б: Ну, Heroku поддерживает Docker, но я говорю, что Heroku – это прошлый век. Нужно запускать контейнеры в CoreOS.

А: Понял, но что это?

Б: Это крутая хост-система, способная работать с Docker. Ты сможешь использовать rkt.

А: Rocket?

Б: Нет, rkt.

А: Ну, я и говорю, Rocket.

Б: Нет, сейчас он называется rkt и претерпел изменения. Это альтернативный формат контейнеризации, который представляет не столько единый пакет, как Docker, сколько более сборное решение.

А: Это хорошо?

Б: Конечно, это хорошо! Будущее за возможностью сборки.

А: Понял, но как им пользоваться?

Б: Я не знаю. Не думаю, что кто-то им пользуется.

А: Жаль. Ты что-то говорил про CoreOS?

Б: Да, это ОС хоста, работающая с Docker.

А: Что такое «ОС хоста»?

Б: Это ОС, в которой запускаются все ваши контейнеры.

А: Запускаются мои контейнеры?

Б: Да, они же должны где-то запускаться. Скажем, вы запустили инстанс и установили на нем CoreOS. После запуска демона Docker можно разворачивать образы Docker.

А: Какая часть моего приложения будет контейнером?

Б: Все. Смотри, ты берешь свое приложение, создаешь Dockerfile, превращаешь его в локальный образ и загружаешь на любой хост Docker.

А: А, как Heroku?

Б: Нет, не Heroku – он мертв, я уже говорил. С Docker у тебя есть свое собственное облако.

А: Что?

Б: Да, это легко. Погугли #gifee.

А: Gify?

Б: Gifee – это аббревиатура от «Google’s infrastructure for everyone else» («Инфраструктура Google для всех»). Ты берешь готовые решения, используя контейнеры и получаешь ту же инфраструктуру, которую использует Google.

А: Почему бы просто не использовать сервис Google?

Б: Ты думаешь, что через полгода он все еще будет существовать?

А: Но разве нет других хостинг-сервисов? Я очень не хочу самостоятельно этим заниматься.

Б: Это просто. Тебе всего лишь нужно настроить кластер Kubernetes.

А: Мне нужен кластер?

Б: Кластер Kubernetes. Он будет управлять загрузкой обновлений всех твоих сервисов.

А: Но у меня всего один.

Б: В смысле всего один? У тебя есть приложение, а это около 8-12 сервисов.

А: Что? Нет, всего одно приложение. Или сервис, неважно. Всего один!

Б: Есть такая вещь как микросервисы. За ними будущее. Сейчас мы все строим на их основе. Ты берешь свое приложение и разбиваешь его на 12 сервисов, каждый из которых выполняет свои задачи.

А: Думаю это лишнее. Зачем столько?

Б: Это единственный способ сделать приложение надежным. Если сервис аутентификации «упадет»…

А: Сервис аутентификации? Я собирался использовать gem, которым пару раз пользовался.

<Б: Отлично. Используй gem, но создай для него отдельный проект. Оберни его в RESTful API. Твои сервисы будут использовать API и с легкостью обрабатывать все ошибки и сбои. Помести все в контейнер, и пусть оно там работает.

А: Ну, хорошо, теперь, что мне делать с этими десятками неуправляемых сервисов?

Б: Я как раз говорил о Kubernetes. Он поможет управлять всеми сервисами.

А: Управлять сервисами?

Б: Рабочие сервисы должны быть надежными, а для этого необходимо создать их копии. Много копий. Kubernetes самостоятельно управляет количеством копий и распределяет их по всем хостам твоей флотилии, поэтому они [сервисы] всегда доступны.

А: Теперь мне нужен флот?

Б: Да, для надежности. Но Kubernetes всем управляет сам. И знаешь, Kubernetes – рабочее решение, потому что его создала компания Google. Еще он использует etcd.

А: Что такое etcd?

Б: Это реализация RAFT.

А: Что такое Raft?

Б: Что-то вроде Paxos.

А: Господи, где же дно этой чертовой кроличьей норы? Я просто хочу запустить приложение. Ладно, глубокий вдох. Что такое Paxos?

Б: Paxos – это очень старый протокол консенсуса для распределённых систем, придуманный еще в 70-х годах, который никто не понимает и не использует.

А: Отлично, спасибо, что рассказал. А Raft?

Б: Поскольку никто не понимает Paxos, парень Диего…

А: О, ты знаешь его?

Б: Нет, он работает над CoreOS. Так вот, Диего создал Raft для своей докторской диссертации, потому что Paxos был слишком сложен. Умный парень. А затем он написал etcd как реализацию. Aphyr сказал, что это не так уж и плохо.

А: Кто такой Aphyr?

Б: Это тот, кто написал «Call me maybe».

А: Он написал ту песню Кэти Перри?

Б: Нет, он написал серию блог-постов о том, почему любая база данных не соответствует CAP.

А: Что такое CAP?

Б: Теорема CAP. Она гласит, что в реализации распределенных вычислений можно обеспечить выполнение только двух из трех положений: целостность данных, доступность, устойчивость к разделению.

А: Все базы данных не следуют этой теореме? Что это значит?

Б: Это значит, что они полная хрень. Как Mongo.

А: Я думал, что Mongo – это подходящая база данных для web?

Б: Больше никто так не считает.

А: Хорошо, а что с etcd?

Б: Да, etcd – это распределенное хранилище типа «ключ-значение».

А: Как Redis.

Б: Нет, ничего подобного, etcd является распределенным хранилищем. Redis теряет часть записей при нарушении связности сети.

А: Ладно, это распределенное хранилище типа «ключ-значение», но какая в этом польза?

Б: Kubernetes создает стандартный 5-узловой кластер, используя etcd в качестве шины передачи сообщений. Он и несколько собственных сервисов Kubernetes образуют очень устойчивую управляющую систему.

А: 5 узлов? У меня одно приложение. Сколько машин мне понадобится?

Б: Смотри, у тебя будет 12 сервисов, и, разумеется, тебе потребуются несколько копий каждого из них для обеспечения избыточности, несколько балансировщиков нагрузки, кластер etcd, база данных и кластер Kubernetes. Это около 50 контейнеров.

А: WTF.

Б: Это не так уж и много! Контейнеры очень эффективны и не требуют большого количества ресурсов, поэтому тебе должно хватить 8 машин. Это же поразительно!

А: Это еще как посмотреть. Со всем этим я смогу развернуть свое приложение?

Б: Конечно! Правда (в случае с Docker и Kubernetes), остается открытым вопрос с хранилищами, потребуется потратить некоторые усилия на передачу данных между контейнерами, но, по идее, на этом все.

А: Ну и замечательно. Я думаю, что начинаю все понимать.

Б: Отлично.

А: Попробую все повторить, чтобы проверить, правильно ли я все понял.

Б: Давай.

А: Мне нужно разбить мое CRUD-приложение на 12 микросервисов, каждый из которых должен иметь свой собственный API для «общения» и быть устойчивым к ошибкам при вызове API другого микросервиса. Я должен поместить их в контейнеры Docker и запустить флот из 8 машин, которые являются хостами Docker, запущенными под CoreOS.

Управлять всеми контейнерами будет кластер Kubernetes с etcd. Затем мне нужно решить все вопросы с сетью и хранилищами. Когда все это сделано, мне необходимо постоянно следить за наличием избыточных копий каждого миркросервиса из моего флота. Все?

Б: Да! Потрясающе, не правда ли?

А: Пожалуй, я продолжу использовать что-то в духе Heroku.



Парочка материалов об аспектах работы над нашим облачным сервисом 1cloud на Хабре:




К сожалению, не доступен сервер mySQL