Содержание этой статьи было первоначально написано Яроном Парасолем в блоге Cloudify Community .
Я хотел бы начать с краткого обзора эволюции облака — и почему я считаю, что необходим новый подход к решениям PaaS — и каковы наилучшие сценарии для этого.
Сначала был IaaS. Облако было создано с точки зрения гибкости ИТ и снижения затрат. Вам нужны серверы? Нет проблем! Забудьте о бюрократизме, забудьте о системных администраторах. Вы создаете учетную запись, и в несколько кликов вы выбираете профиль оборудования и образ ОС, который вам нужен, и вуаля, ваш сервер уже готов и готов к использованию. Никаких хлопот, немедленная благодарность.
Что ж, это так, если изображения, которые вы получаете от своего облачного провайдера, соответствуют вашим потребностям. Если у вас есть особые потребности, вам придется создавать и поддерживать свой собственный образ. Итак, вам нужны знания системного администратора. Тем не менее, мы также видим изменение в методологии — администраторам sys больше не нужно устанавливать серверы, когда они подключены. Вместо этого они предоставляют свои знания, используя утвержденные и поддерживаемые изображения в облаке. Разработчики приложений могут выбрать правильный образ для них и с этого момента создавать виртуальные машины в том количестве и размере оборудования, которое им необходимо для их приложений.
Теперь давайте перейдем к PaaS. Идея no-ops является руководством для многих из существующих предложений PaaS . Их варианты использования и функции — все о разработчиках. Как сказал Майкл Кот :
«Смысл PaaS в том, чтобы сделать жизнь разработчика еще проще: вам не нужно управлять облачными развертываниями на нижнем уровне IaaS или даже соединять вместе ваши сценарии Puppet / Chef. PaaS обещает то же самое, что и серверы приложений Java: просто напишите свои приложения (свою бизнес-логику) и проведите волшебное развертывание на платформе, где обо всем остальном позаботятся ».
Разработчики должны развертывать приложения в облаке. Они не хотят заботиться об ОС, но они также не хотят заботиться о платформах, балансировщиках нагрузки и т. Д. Они хотят сосредоточиться на том, что они знают — написание кода.
Это определенно очень продуктивный подход для некоторых разработчиков и некоторых приложений. Реальность показывает, что большая часть пользователей Cloud не считает эти решения подходящими для своих целей. Эти пользователи продолжают развертывать и управлять своими приложениями в облаках инфраструктуры, как если бы они работали на предпосылке, используя старых добрых людей Ops. Другие выбрали более гибкий подход, используя инструменты управления конфигурацией и автоматизации, такие как Chef.
Эти пользователи решили не использовать PaaS, потому что им нужна гибкость и контроль. PaaS, похоже, не отвечает на многие текущие ИТ-задачи — посмотрите, например, здесь и здесь .
Существующие приложения с различными платформами, некоторые из которых используют чрезвычайно сложные топологии (такие как Hadoop или сегментированная установка MongoDB), являются некоторыми из причин, по которым PaaS не будет сокращать его для многих пользователей.
Они хотели бы установить выбранные версии предпочитаемых платформ, использовать образ своей ОС со своими настроенными группами безопасности, настроить их так, чтобы они соответствовали их приложениям, и развернуть свои приложения с выбранной топологией.
Chef, как и другие инструменты DevOps, проходит долгий путь и помогает достичь гибкости, восстанавливая новые гибкие отношения между Dev и Ops. Операторы приносят свои знания и навыки, но они документируют их и поддерживают как код более структурированным и настраиваемым способом. Это, в свою очередь, дает ребятам приложения гибкость, в которой они нуждаются, позволяя сложному приложению работать в один клик и устраняя «черный ящик» платформы, который им так не нравится.
Приложение против отдельных платформ
Тем не менее, инструменты DevOps по-прежнему не хватает для управления приложениями. Они не знают о внутренних зависимостях приложения. Они не знают, как контролировать приложение, масштабировать его или даже выполнять сложный многоуровневый процесс восстановления. Большинство из этих инструментов не могут даже подготовить целое приложение в облаке.
Так что, если бы вы могли расширить возможности DevOps, чтобы применить их ко всему жизненному циклу приложения?
Что если бы вы могли использовать Chef и подобные для установки, но не останавливаться на достигнутом — автоматизировать такие вещи, как восстановление после сбоя и восстановление, и даже мониторинг и масштабирование? Вы по-прежнему будете иметь всю мудрость Ops, адаптированную к каждому из ваших приложений, и сможете автоматизировать любое из ваших существующих приложений без их повторной архитектуры.
Это наш взгляд на PaaS, процесс в стиле DevOps, который может описать жизненный цикл любого приложения в любой среде выполнения, обеспечивая полную автоматизацию без потери контроля. И это именно то, что мы намеревались сделать с нашей платформой PaaS с открытым исходным кодом — Cloudify, заимствуя идею рецептов, но расширяя ее, чтобы она была ориентирована на приложения, а не на инфраструктуру.
Рецепт описывает внешние зависимости приложения и события жизненного цикла без какого-либо изменения кода или архитектуры.
lifecycle{
init "mongod_install.groovy"
start "mongod_start.groovy"
postStart "mongod_poststart.groovy"
}
Посмотрите, как создать свои собственные рецепты здесь .
Отображение событий, таких как установка, запуск, запуск и остановка, в сценарии или поваренные книги Chef, предоставление интерфейсов groovy и REST для совместного использования контекста и динамического конфигурирования и даже предоставляет способ описания методов мониторинга, правил масштабирования и обнаружения «живучести» процесса.
Так что подумайте об этом следующим образом: хотя большинство услуг PaaS поставляются с каталогом предопределенных чертежей приложений, позволяющих пользователю контролировать только код приложения, этот новый вид стека PaaS позволяет пользователю определять план, то есть любой план. !
Таким образом, рецепты объединяют опыт Ops с мощью автоматизации для разработчиков. Они полностью устраняют риск блокировки с точки зрения стека приложений.
Вы можете прочитать больше рецептов, скачать Cloudify и испытать его самостоятельно или даже присоединиться к сообществу и влиять на план на cloudifysource.org .
Приходите посмотреть, как мы сразимся в
PaaS Death Match на Cloudslam ’12.