Добрый день.
Предлагаю вашему вниманию перевод юмористического поста, посвященного облачным технологиям: It's The Future. Всяческие поправки и советы привествуются.
Эй! Привет! Мой босс сказал поговорить с тобой. Сказал, что ты много знаешь про веб приложения.
— Да, сейчас правда, я больше занимаюсь распределенными системами. Я только что вернулся с 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.
Предлагаю вашему вниманию перевод юмористического поста, посвященного облачным технологиям: It's The Future. Всяческие поправки и советы привествуются.
Эй! Привет! Мой босс сказал поговорить с тобой. Сказал, что ты много знаешь про веб приложения.
— Да, сейчас правда, я больше занимаюсь распределенными системами. Я только что вернулся с 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.