Pull to refresh

Это будущее

Reading time6 min
Views87K
Добрый день.

Предлагаю вашему вниманию перевод юмористического поста, посвященного облачным технологиям: It's The Future. Всяческие поправки и советы привествуются.


image



Эй! Привет! Мой босс сказал поговорить с тобой. Сказал, что ты много знаешь про веб приложения.

— Да, сейчас правда, я больше занимаюсь распределенными системами. Я только что вернулся с ContainerCamp и GlueCon, а еще я собираюсь на DockerCon на следующей неделе. Реально впечатлен тем, как двигается бизнес — все становится намного проще и доступнее! Это — будущее!

Здорово… Видишь ли, я сейчас разрабатываю простенькое web-приложение — обычный CRUD на Rails, собираюсь деплоиться в Heroku. Скажи, Heroku все еще актуальна?

— Ты что! Нет. Это уже старая школа. Heroku — труп. Никто этим больше не пользуется. Теперь тебе нужно познать Docker. Это будущее!

Ах вот как. Ну ок. А что это?

— Docker — новый способ контейнеризации. Это как LXC, только еще включает формат запаковки контейнеров, а еще это распределительная платформа и ряд утилит, чтобы сделать построение распределенной системы реально простым делом.

Консерверезация?.. — что за? А что за LXE?

— LXC. Это как chroot на стероидах.

Что за cher-oot?

— Ясно… Смотри… Docker… Контейнеризация… Это будущее… Это как виртуализация, только быстрее и дешевле.

Окей, типа как Vagrant.

— Не, Vagrant — труп. Теперь все готовится к использованию внутри контейнеров, Это Будущее!

Ок, так мне теперь не надо ничего знать о виртуализации?

— Ну… Нет, тебе надо понимать виртуализацию, т.к. контейнеры не предоставляют полную защиту данных приложения, пока что. Так что, если ты хочешь запускать все в мультиарендном окружении, то тебе надо будет убедиться, что пользователи не выберутся из песочницы.

Так, что-то я потерялся. Давай отмотаем немного назад. Так вот, есть виртуализация, называемая контейнерами. Я могу использовать это на Heroku?

— Что-ж, Heroku поддерживает Docker, но вспомни, что я говорил тебе. Heroku — труп. Тебе надо запускать контейнеры на CoreOS.

Что это?

— Это та самая крутая host OS, которую ты сможешь использовать с Docker. Блин, да тебе даже Docker не понадобится! Ты просто можешь использовать rkt!

Rocket?

— Не, rkt.

Правильно, Rocket.

— Не, теперь это называется rkt. Полностью другая штука. Это альтернативный формат контейнеризации, который предоставляется как конкурент Docker.

Дак это выходит круто?

— Конечно, круто. Компонуемость — это будущее!

А ты этим rkt вообще пользуешься?

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

Эххх… Так ты что-то там про CoreOS говорил?

— Да… так вот, это host, который ты используешь с Docker.

А что такое host?

— CoreOS создана для оптимальной работы с контейнерами. Она настроена на работу с контейнерами.

Работу с контейнерами...?

— Да, у тебя же что-то там есть в твоих контейнерах. Так что, ты типа поднимаешь инстанс вроде Amazon EC2, поднимаешь там CoreOS host, дальше запускаешь сервис Docker-а, и затем ты там уже можешь деплоить Docker-образы.

Какая часть из всего этого — контейнер?

— Все из этого. Смотри, ты берешь свое приложение, пишешь Dockerfile, делаешь локальный образ, потом пушишь на любой Docker-host.

Ааа, типа Heroku?

— Нет… не Heroku. Я ж тебе говорил, что Heroku — труп. Ты запускаешь свое собственное облако, используя Docker.

О_о?

— Да, это реально просто. Почитай про #gifee.

Gify?

— GIFEE — это Google Infrastructure For Everyone Else. Ты берешь все эти утилиты и стеки технологий, использующие контейнеры, и у тебя вся та инфраструктура, прямо как у Google.

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

— А если через пол года там все полностью поменяется?

Хорошо, разве кто-то еще это все не хостит? Я реально не хочу сам хостить вот это все.

— Ну, AmazonECS, но тебе придется писать какую-то XML херь.

Что скажешь про OpenStack?

— Фу…

Послушай, я не хочу ничего хостить и обслуживать сам.

— Нет, это реально просто. Ты просто настраиваешь Kubernetes cluster.

Так мне нужен кластер?

— Kubernetes cluster. Он управляет деплоями всех твоих сервисов.

У меня только один сервис.

— О чем ты говоришь? Смотри, у тебя же web-приложение, правильно? Так значит у тебя должно быть 8-12 сервисов.

Что? Нет! У меня одно приложение. Сервис, похервис — пофигу! Всего одно долбаное приложение!

— Нет, смотри в сторону микросервисов. Это будущее. Это то, как мы все вокруг теперь работаем. Ты берешь свое супер-пупер приложение и разделяешь на 12 сервисов. По одному для каждой задачи.

Ну это уже чересчур…

— Это единственный путь убедиться, что конфигурация надежна. Так что, если твой сервис аутентификации грохнется…

Сервис аутентификации? Да е-мае, я просто собирался использовать тот же самый плагин, который использовал много раз до этого!

— Супер. Используй его. Положи его в отдельный проект. Накидай поверх его RestAPI. Потом твои другие сервисы будут использовать этот API и будут супер изящно обрабатывать отказы в работе. Положи его в контейнер и делай CI/CD!

Будь по твоему. Теперь у меня на руках десятки неуправляемых сервисов и что дальше?

— Да, так вот, я и говорил про Kubernetes. Он позволяет тебе удобно проводить оркестрацию всех твоих сервисов.

Проводить оркестрацию?

— Да! Вот, у тебя есть эти твои сервисы, и они должны быть отказоустойчивыми, поэтому тебе нужно запускать сразу несколько копий для каждого из твоих сервисов! И Kubernetes гарантирует тебе, что у тебя этих копий будет достаточно и они распределены между хостами в твоем fleet и всегда доступны.

То есть, мне нужен fleet?

— Да, для отказоустойчивости. Но Kubernetes сделает все за тебя. К тому же, ты уверен, что Kubernetes будет работать как надо, потому что его сделал Google, и еще потому что он работает на основе etcd.

Что такое etcd?

— Эта штука сделана на основе RAFT.

OK, что такое RAFT?

— Это как Paxos.

Господи, насколько глубокой будет эта сраная кроличья дыра, куда мы сейчас направляемся? Я просто хочу запустить одно сраное веб приложение!!! Твоюж мать!!! Окей, глубокий вдох, выдох… Ок, что такое Paxos?

— Paxos — это старое семейство распределенных протоколов из 70х, которые никто не понимает и не использует.

Отлично! Я так рад, что ты рассказал мне об этом! Так что такое Raft?

— Так как никто не понимает Paxos… эээ… кроме Диего…

О! Так ты его знаешь?

— Нет конечно, он работает в CoreOS. Так или иначе, Диего придумал Raft для своей кандидатской диссертации, т.к. Paxos был слишком сложен. Чертовски умный чел. И потом он написал etcd в качестве реализации и потом Aphyr сказал, что это действительно не говно, а круто!!!

Кто такой Aphyr?

Aphyr — ну это тот чел, который написал «Call Me Maybe», ну… ты же знаешь его? «The distributed systems and BDSM guy»?

Ты только что сказал BDSM?

— Да, BDSM. Это Сан-Франциско. Здесь все увлечены распределенными системами и BDSM.

И он написал ту песню Кэти Перри?

— Нет, он написал серию статьей о том, что каждая база данных заваливает CAP.

Что за CAP?

— Тероема про CAP (известная также как теорема Брюера). Она говорит, что у тебя может быть только 2 пункта из трех: Консистентности, Доступности и Устойчивости к расщеплению.

И все базы данных заваливают эту CAP? Что блин это все значит?

— Это означает, что все это — отстой. Как MongoDB.

Я думал, что MongoDB горизонтально расширяемая.

— Никто кроме тебя.

Ладно. Так что там с etcd?

— Да, так вот, etcd — это распределенное хранилище значений.

Прямо как Redis.

— Нет, совсем не как Redis. etcd — распределенная система. Redis теряет часть информации если сеть временно отказывает.

Хорошо, это распределенное хранилище значений. Чем же эта штука так полезна?

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

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

— Что ж, ты же собираешься поднять 12 сервисов, и конечно же тебе понадобиться пара лишних копий для каждого, пара балансировщиков, etcd, твоя база данных и Kubernetes cluster. Так что, это может быть около 50-ти одновременно работающих контейнеров.

ЧЗХ!

— Да ваще не вопрос! Контейнеры реально эффективные, так что тебе не составит труда распределить все это дело между 8 машинами! Разве это не потрясающе?

И все-таки, это только твое впечатление. И вот взяв вот это все, я смогу просто развернуть мое приложение?

— Ну конечно! Правда, объемы хранилища данных — все еще открытый вопрос в случае с Docker и Kubernetes, и сетевая нагрузка повышена, но эти вопросы очень скоро будут решены!

Хмм, понятно. Хорошо, кажется, я теперь все понял.

— Супер!

Спасибо за развернутый рассказ.

— Да никаких проблем.

Позволь только мне подытожить все то, о чем мы говорили, чтобы убедиться, что мы друг друга поняли.

— Конечно!

Так вот, мне просто-напросто нужно разделить мое простое CRUD приложение на 12 микросервисов, каждое из которых должно быть обернуто в собственное API, которые должны звать друг друга по этим API, но при этом обрабатывать ошибки каждого из них, положить все это в контейнеры Docker, запустить fleet из 8 машин, которые являются Docker-хостами на базе CoreOS, «оркестрить на них» используя небольшой Kubernetes cluster на базе etcd, решить «пару открытых вопросов» по поводу сетевой нагрузки и хранения информации, настроить CI/CD нескольких копий каждого микросервиса с балансировщиками во fleet. Все так?

— Да! Разве это не шикарно?

… Пойду деплоиться в Heroku.
Tags:
Hubs:
Total votes 129: ↑116 and ↓13+103
Comments37

Articles