Это будущее
Добрый день.
Предлагаю вашему вниманию перевод юмористического поста, посвященного облачным технологиям: It’s The Future. Всяческие поправки и советы привествуются.
Эй! Привет! Мой босс сказал поговорить с тобой. Сказал, что ты много знаешь про веб приложения.
— Да, сейчас правда, я больше занимаюсь распределенными системами. Я только что вернулся с ContainerCamp и GlueCon, а еще я собираюсь на DockerCon на следующей неделе. Реально впечатлен тем, как двигается бизнес — все становится намного проще и доступнее! Это — будущее!
Здорово… Видишь ли, я сейчас разрабатываю простенькое веб-приложение — обычный CRUD на Rails, собираюсь деплоиться в Heroku. Скажи, Heroku все еще актуальна?
— Ты что! Нет. Это уже старая школа. Heroku — труп. Никто этим больше не пользуется. Теперь тебе нужно познать Docker. Это будущее!
Ах вот как. Ну ок. А что это?
— Docker — новый способ контейнеризации. Это как LXC, только еще включает формат запаковки контейнеров, а еще это распределительная платформа и ряд утилит, чтобы сделать построение распределенной системы реально простым делом.
Консерверезация?… — что за? А что за LXE?
— LXC. Это как chroot на стероидах.
Что за cher-oot?
— Ясно… Смотри… Докер… Контейнеризация… Это будущее… Это как виртуализация, только быстрее и дешевле.
Окей, типа как Вагрант.
— Не, Вагрант — труп. Теперь все готовится к использованию внутри контейнеров, Это Будущее!
Ок, так мне теперь не надо ничего знать о виртуализации?
— Ну… Не, тебе надо понимать виртуализацию, т.к. контейнеры не предоставляют полную защиту данных приложения пока что. Так что, если ты хочешь запускать все в мультиарендном окружении, тебе надо будет убедиться, что пользователи не выберутся из песочницы.
Так, что-то я смальца потерялся. Давай отматаем немного назад. Э… Так вот, есть виртуализация, называемая контейнерами. Я могу использовать это на Хероку?
— Что-ж, Хероку поддерживает Докер, но вспомни, что я говорил тебе. Хероку — труп. Тебе надо запускать контейнеры на CoreOS.
Что это?
— Это та самая крутая Host OS, которую ты сможешь использовать с Докером. Блин, да тебе даже Docker не понадобится! Ты просто можешь использовать rkt!
Rocket?
— Не, rkt.
Правильно, Rocket.
— Не, теперь это называется rkt. Полностью другая штука. Это альтернативный формат контейнеризации, который предоставляется как конкурент Докера.
Дак это выходит круто?
— Конечно, круто. Компонуемость — это будущее!
А ты этим rkt вообще пользуешься?
— Я не знаю. Я не думаю, что кто-то этим пользуется.
Эххх… Так ты что-то там про CoreOS говорил?
— Да… так вот, это Host, который ты используешь с Докером.
А что такое Host?
— CoreOS создана для оптимальной работы с контейнерами. Она настроена на работу с контейнерами.
Работу с контейнерами…?
— Да, у тебя же что-то там есть в твоих контейнерах. Так что, ты типа поднимаешь инстанс вроде Amazon EC2, поднимаешь там CoreOS host, дальше запускаешь демон Докера, и затем ты там уже можешь деплоить Докер образы.
Какая часть из всего этого — контейнер?
— Все из этого. Смотри, ты берешь свое приложение, пишешь докерфайл, делаешь локальный образ, потом пушишь на любой докер хост.
Ааа, типа Хероку?
— Нет… не Хероку. Я ж тебе говорил, что Хероку — труп. Ты запускаешь свое собственное облако используя Докер.
О_о?
— Да, это реально просто. Почитай про #gifee.
Gify?
— GIFEE — это Google Infrastructure For Everyone Else. Ты берешь все эти тулзы и стеки технологий, использующие контейнеры, и у тебя вся та инфраструктура, прямо как у самого Гугла.
Почему просто не использовать сервисы самого Гугла?
— А если через пол года там все полностью поменяется?
Хорошо, разве кто-то еще это все не хостит? Я реально не хочу сам хостить вот это все.
— Ну, AmazonECS, но тебе придется писать какую-то XML херь.
Что скажешь про OpenStack?
— Фу…
Послушай, я не хочу ничего хостить и обслуживать сам.
— Нет, это реально просто. Ты просто настраиваешь Kubernetes кластер.
Так мне нужен кластер?
— Kubernetes кластер. Он управляет деплоями всех твоих сервисов.
У меня только один сервис.
— О чем ты говоришь? Смотри, у тебя же веб-приложение, правильно?… так значит у тебя должно быть 8–12 сервисов.
Что? Нет! У меня одно приложение. Сервис, похервис — пофигу! Всего одно долбаное приложение!
— Нет, смотри в сторону микросервисов. Это будущее. Это то, как мы все вокруг теперь работаем. Ты берешь свое супер-пупер приложение и разделяешь на 12 сервисов. По одному для каждой задачи.
Ну это уже чересчур…
— Это единственный путь убедиться, что конфигурация надежна. Так что, если твой сервис аутентификации грохнется…
Сервис аутентификации? Да е-мае, я просто собирался использовать тот же самый плагин, который использовал много раз до этого!
— Супер. Используй его. Положи его в отдельный проект. Накидай поверх его RestAPI слой. Потом твои другие сервисы будут использовать этот API и будут супер изящно обрабатывать отказы в работе. Положи его в контейнер и производи непрерывный деплой и интеграцию!
Будь по твоему. Теперь у меня на руках сотни неуправляемых сервисов и что дальше???
— Да, так вот я и говорил про Kubernetes… Он позволяет тебе удобно проводить оркестрацию всех твоих сервисов.
Проводить ОРКЕСТРАЦИЮ???
— Да! Вот, у тебя есть эти твои сервисы, и они должны быть отказоустойчивыми, поэтому тебе нужно запускать сразу несколько копий для каждого из твоих сервисов! И Kubernetes гарантирует тебе, что у тебя этих копий будет достаточно и они распределены между хостами в твоем fleet и всегда доступны.
То есть, мне нужен fleet?
— Да, для отказоустойчивости. Но Kubernetes сделает все за тебя. К тому же, ты уверен, что Kubernetes будет работать как надо, потому что его сделал Google, и еще потому что он работает на основе etcd.
Что такое etcd?
— Эта штука сделана на основе RAFT.
OK, что такое RAFT?
— Это как Paxos.
Господи, насколько глубокой будет эта сраная кроличья дыра, куда мы сейчас направляемся? Я просто хочу запустить одно сраное веб приложение!!! Твоюж мать!!! Окей, глубокий вдох, выдох… Ок, что такое Paxos?
— Paxos — это как тот самый старый распределенный протокол из 70х, который никто не понимает и не использует.
Отлично! Я так рад, что ты рассказал мне об этом! Так что такое Raft?
— Так как никто не понимает Paxos… эээ… кроме Диего…
О! Так ты его знаешь?
— Нет конечно, он работает в CoreOS. Так или иначе, Диего придумал Raft для своей кандидатской диссертации, т.к. Paxos был слишком сложен. Чертовски умный чел. И потом он написал etcd в качестве реализации и потом Афир сказал, что это действительно не говно, а круто!!!
Кто такой Афир?
— Афир — ну это тот чел, который написал, «Call Me Maybe», ну… ты же знаешь его? «the distributed systems and BDSM guy»?
Ты только что сказал BDSM?
— Да, BDSM. Это из Сан-Франциско. Все, кто относятся к распределенным системам. BDSM.
И он написал ту песню Кэти Перри?
— Нет, он написал серию блог постов о том что каждая база данных проваливает CAP.
Что за CAP?
— Тероема про CAP (известная также как теорема Брюера). Она говорит, что у тебя может быть только 2 пункта из трех: Консистентности, Доступности и Устойчивости к расщеплению.
И все базы данных заваливают эту CAP? Что блин это все значит?
— Это означает, что все это — отстой. Как Монго.
Я думал, что Монго горизонтально расширяемая.
Ладно. Так что там с etcd?
— Да, так вот, etcd — это распределенное хранилище значений.
Прямо как Redis.
— Нет, совсем не как Redis. etcd — распределенная система. Redis теряет часть информации если сеть временно отказывает.
Хорошо, это распределенное хранилище значений. Чем же эта штука так полезна?
— Кубернетес настраивает стандартный кластер из пяти узлов используя etcd как шину обмена сообщениями. Он комбинируется с парой своих собственных сервисов для предоставления весьма устойчивой оркестровой системы.
5 узлов? У меня одно приложение. Сколько машин мне нужно поднять для этого?
— Что ж, ты же собираешься поднять 12 сервисов, и конечно же тебе понадобиться пара лишних копий для каждого, пара балансировщиков, etcd кластер, твоя база данных и kubernetes кластер. Так что это может быть около 50ти одновременно работающих контейнеров.
ЧЗХ!
— Да ваще не вопрос! Контейреры реально эффективные, так что тебе не составит труда распределить все это дело между 8 машинами! Разве это не потрясающе?
И все-таки это только твое впечатление. И вот взяв вот это все, я смогу просто задеплоить мое приложение?
— Ну конечно. Правда, хранилище данных — все еще открытый вопрос в случае с Docker и Kubernetes, и сети придется прилично поработать, но эти вопросы очень скоро будут решены!
Хмм, понятно. Хорошо, я кажется теперь все понял.
— Супер!
Спасибо за развернутый рассказ.
— Да никаких проблем.
Позволь только мне подытожить все то, о чем мы говорили, чтобы убедиться, что мы друг друга поняли.
— Конечно!
Так вот, мне просто-напросто нужно разделить мое простое CRUD приложение на 12 микросервисов, каждое из которых должно быть обернуто в собственное АПИ, которые должны звать друг друга по этим АПИ, но при этом обрабатывать ошибки каждого из них, положить все это в докер контейнеры, запустить fleet из 8 машин, которые являются Docker хостами на базе CoreOS, «оркестрить на них» используя небольшой Kubernetes кластер на базе etcd, разрешить «пару открытых вопросов» по поводу сетевой нагрузки и хранения информации и затем настроить непрерывный деплой и интеграцию нескольких копий каждого микросервиса за балансировщиками в мой fleet. Все так?
— ДА! Разве это не шикарно?
… Пойду деплоиться в Heroku.