Спустя почти год с момента начала тестирования (http://www.opennet.me/opennews/art.shtml?num=30530) PaaS-платформы OpenShift компания Red Hat анонсировала (https://openshift.redhat.com/community/blogs/announcing-open...) полное открытие связанных с данной платформы исходных текстов и создании открытого варианта платформы - OpenShift Origin (https://openshift.redhat.com/community/open-source). Код не был открыт сразу после начала тестирования, так как платформа базируется на стороннем продукте, полученном после поглощения фирмы Makara, что потребовало дополнительного времени на согласование юридических вопросов. Кроме того, компания Red Hat хотела вначале довести код до готового к промышленной эксплуатации состояния, и открыть код уже полнофункционального и отлаженного продукта. Код открыт под лицензией Apache и размещён на GitHub (https://github.com/openshift).
Примечательно, что OpenShift Origin позиционируется как полностью открытый проект, не только в смысле открытости кода, но и открытости процесса разработки (https://openshift.redhat.com/community/wiki/community-process). Любой желающий может присоединиться к разработке и предоставить свою порцию улучшений в кодовую базу OpenShift. Red Hat выступает лишь спонсором, предоставляя необходимые ресурсы, но участвуя в разработке наравне с другими представителями сообщества в соответствии с принципами меритократии, при которых решения принимают представители сообщества, вносящие наибольший вклад в развитие проекта. Коммерческий PaaS-сервис Red Hat будет строиться непосредственно на открытой кодовой базе OpenShift Origin, без сокрытия кода дополнительной функциональности. Все развиваемые в рамках коммерческого сервиса наработки будут сразу возвращаться в основной открытый проект.
Подобный подход к разработке позволит гарантировать отсутствие привязки к определённому вендору и избежать контроля разработки со стороны одного производителя. В сочетании с либеральной лицензией Apache данные обстоятельства делают проект привлекательным для участия в его развитии сторонних производителей. В этом плане OpenShift напоминает проект OpenStack.
Поясняя (https://openshift.redhat.com/community/blogs/build-an-open-c...) связь между OpenShift и OpenStack компания Red Hat указывает на то, что данные проекты взаимно дополняют друг друга, развиваясь при этом отдельно и нацеливаясь на разные сегменты облачных систем: IaaS (инфраструктура как сервис) работает на уровне обеспечения запуска операционной системы, а PaaS (платформа как сервис) предоставляет сервис на уровне выполнения отдельных приложений). OpenShift Origin не является частью OpenStack, но может работать поверх инфраструктуры поддерживаемой OpenStack, примерно, как Apache и MySQL не являются частью Linux, но могут работать в составе дистрибутивов Linux.Для упрощения знакомства с платформой подготовлен (https://openshift.redhat.com/app/opensource/download) поддерживающий работу в VirtualBox образ LiveCD с преднастроенным (https://openshift.redhat.com/community/wiki/getting-started-...) окружением OpenShift Origin. Используя OpenShift Origin можно легко развернуть PaaS-инфраструктуру, как на ноутбуке разработчика, так и в датацентре предприятия. Использование OpenShift на локальных системах разработчиков позволят упростить отладку и тестирование развёртывания приложений для PaaS-систем, а также проведения адаптации своих фреймворков для PaaS. Создание локальной PaaS-инфраструктуры предприятия даёт возможность избавиться от зависимости от внешних сервисов и сохранить полный контроль над своими данными, обеспечив их полную изоляцию от внешнего мира.
OpenShift предоставляет разработчикам возможность запуска приложений, написанных на языках Java, Python, PHP, Perl, JavaScript и Ruby, с использованием фреймворков JBoss, Spring, Node.js, Seam, Weld, CDI, Rails, Rack, Symfony, Zend Framework, Twisted, Django и Java EE. Из баз данных поддерживаются MySQL, EnterpriseDB (PostgreSQL), SQLite, Couchbase, MongoDB, Membase и Memcache. Для управления доступны как интерфейс командной строки, так и наглядный web-интерфейс. Доступны средства для создания собственных плагинов, расширяющих возможнолсти OpenShift и позволяющих использовать новые фреймворки, языки и СУБД. PaaS-платформа, в отличие от IaaS, избавляет разработчика от необходимости обслуживания ОС и системных компонентов, таких как СУБД, языки программирования, программные фреймворки и т.п. В PaaS от пользователя требуется только загрузка приложения, которое будет запущено в готовом окружении, предоставляемом платформой.Архитектура (https://openshift.redhat.com/community/wiki/architecture-ove...) OpenShift Origin состоит из нескольких взаимосвязанных компонентов, позволяющих создавать окружения, проводить развёртывание приложений и управлять приложениями в облачной PaaS-инфраструктуре. В том числе предоставляются средства для выделения приложениям дискового пространства, ресурсов CPU, памяти, а также доступа к серверам Apache или JBoss. В зависимости от типа размещаемого в PaaS приложения предлагается набор шаблонов, определяющих состав файловой системы окружения (например, шаблоны для php, python, perl).
В состав платформы входят:- Брокер (Broker) - центральный сервис, предоставляющий REST API для пользователей и координирующий работу узлов с контейнерами приложений. Отвечает за выполнение всех действий, связанных с управлением приложениями, в том числе управление логинами, обновлением DNS, контролем за состоянием приложений и размещением приложений;
- Картриджи с реализацией функциональности, необходимой для запуска определённых типов приложений пользователя. Например, картриджи для языков программирования, СУБД, фреймворков и т.п. Из картриджей необходимой функциональности формируются Gear-окружения, в которых непосредственно выполняются приложения (например, Gear может состоять из картриджей PHP и MySQL). В свою очередь, несколько Gear-окружений для совместного использования ресурсов (по аналогии с shared-хостингом) могут запускаться на одной виртуальной машине или физическом хосте, которые в терминологии OpenShift именуются узлом;
- Система обмена сообщениями (Messaging System) - обеспечивает связь между StickShift (https://openshift.redhat.com/community/wiki/architecture-ove...) и каждым узлом;
- Система аутентификации пользователей - подключаемый компонент для обеспечения аутентификации. По умолчанию для хранения параметров аутентификации используется MongoDB;
- Управления доменными именами (Domain Name Management) - сервис регистрации и управления DNS, выполненный на базе сервиса BIND;
- Клиент управления через командную строку (rhc) - позволяет подключиться к OpenShift через REST API;
- Git-репозиторий - код выполняемого в PaaS-приложения помещается в отдельный Git-репозиторий, для помещения проекта в PaaS-окружение или для внесения изменений достаточно выполнить "git push".
URL: https://openshift.redhat.com/community/blogs/announcing-open...
Новость: http://www.opennet.me/opennews/art.shtml?num=33737
Клевая новость =)
Мощно. Это всё, что я могу сказать.
OpenShit? :D:D:D:D Более подходящее название для облачного шита, как мне представляется.
> для помещения проекта в PaaS-окружение или для внесения изменений достаточно выполнить "git push"Очень правильная идея. делаешь git push в центральный репо который одновременно и база континиус билдов и основа тестового стенда, где обкатываются приложения. После стабилизации админы push-ат в продакшен.
Радует что git во все поля.
А кто такая Red Hat?
Опять рекламируете подзаборную шарагу?
мсье конечно способен назвать менее подзаборную шарагу, и обосновать подзаборность данной шараги
Юрий, харош бухать! :)
Как там Ваня? В отпуске еще?
> Как там Ваня? В отпуске еще?Ваня - из конкурирующей организации, M$. А этот из каноникал. Так что не факт, что они знакомы.
Это фанатик Ubuntu.
Вот не крошите батон на фанатиков Убунту, кто ядро пилит убунтоведы в курсе, это красношапофилы любят забыть, что с одним голым ядром железо неюзабельно.:)
> Вот не крошите батон на фанатиков Убунту, кто ядро пилит убунтоведы в
> курсе, это красношапофилы любят забыть, что с одним голым ядром железо
> неюзабельно.
> :)ядро как раз для того чтоб железо было юзабельно. а вообще, вы серьезно считаете что в RHT пишут только ядро? если да, то у вас нет ни малейшего понятия
>> Вот не крошите батон на фанатиков Убунту, кто ядро пилит убунтоведы в
>> курсе, это красношапофилы любят забыть, что с одним голым ядром железо
>> неюзабельно.
>> :)
> ядро как раз для того чтоб железо было юзабельно. а вообще, вы
> серьезно считаете что в RHT пишут только ядро? если да, тоИз чего этот вывод? Сказано лишь то, что сказано, и нигде не сказано, что КрасноШапы только ядро пилят.
> у вас нет ни малейшего понятия
Для вас добавлю ключевое слово "лопата".
"Я понял в чём ваша беда, вы слишком серьёзны"(С)Горин
"Умное лицо ещё не признак ума господа. Все глупости на земле делаются именно с этим выражением лица."(С)Горин
> "Я понял в чём ваша беда, вы слишком серьёзны"(С)Горин
> "Умное лицо ещё не признак ума господа. Все глупости на земле делаются
> именно с этим выражением лица."(С)Гориндобавленный смайл не делает сказанное вами меньшей глупостью
>> "Я понял в чём ваша беда, вы слишком серьёзны"(С)Горин
>> "Умное лицо ещё не признак ума господа. Все глупости на земле делаются
>> именно с этим выражением лица."(С)Горин
> добавленный смайл не делает сказанное вами меньшей глупостьюГлупость это ответы на свои домыслы. Учитесь читать то что написано.
Вы с умным видом не осилили буквально пять слов.
>красношапофилы любят забыть, что с одним голым ядром железо неюзабельно.:)Нормуль, все остальные программы пишет Лёня Потеринг. А те, которые не пишет -- переписывает.
>>красношапофилы любят забыть, что с одним голым ядром железо неюзабельно.:)
> Нормуль, все остальные программы пишет Лёня Потеринг. А те, которые не пишет
> -- переписывает.Нормуль, все пишут программы в консоли и любят по... помучиться с установкой и настройкой оси на археологический раритет, так как это увеличивает производительность труда.
Все правильно, редхат делает только голую консоль. А весь гуй создал лично Марк Космонавт.
> Все правильно, редхат делает только голую консоль. А весь гуй создал лично
> Марк Космонавт.Это домыслы Шапкофилов.
> Это домыслы Шапкофилов.Нет, это историческая правда. Спросите любого убунтовода.
>> Это домыслы Шапкофилов.
> Нет, это историческая правда. Спросите любого убунтовода.Уверены насчет любого убунтовода?
> Уверены насчет любого убунтовода?Любого _честного_ убунтовода.
Лживый убунтовод может и не согласиться с определяющей и направляющей ролью Canonical в разработке линуксового юзерспейса.
> Любого _честного_ убунтовода.
> Лживый убунтовод может и не согласиться с определяющей и направляющей ролью Canonical
> в разработке линуксового юзерспейса.ага, направляющую - дальше некуда. поэтому все дистры внезапно перешли на юнити и окрасили интерфейсы в цвет детской неожиданности
>> Уверены насчет любого убунтовода?
> Любого _честного_ убунтовода.
> Лживый убунтовод может и не согласиться с определяющей и направляющей ролью Canonical
> в разработке линуксового юзерспейса.Вот уж фиг. Как честный убунтовод признаю важную роль каноникла в создании дистра дающего удобную к установке и использованию базу, которую дальше можно настраивать при нужде, но вот насчет определяющей и направляющей роли точно не соглашусь.
Хотя скажу после перехода на 12.04 пробовал гном 3, гном классик и юнити, в результате склоняюсь к юнити. Но что юнити мейнстрим не думаю, просто мне он удобен.
> Вот не крошите батон на фанатиков Убунту, кто ядро пилит убунтоведы в курсе, это красношапофилы любят забыть, что с одним голым ядром железо неюзабельно.Зато убунтофаны явно не в курсе, кто пилит юзерспейс. Они думают, что каноникал :D
> Это фанатик Ubuntu.Фанатик Ubuntu, фанатик Windows - какая нафиг разница? Клоун, он и в Африке клоун :)
А мне вот любопытно (если есть знатоки - ответьте, плиз): я могу как-то работать с публичной и приватной PaaS одновременно? Допустим у меня свой ЦОД и в нем на ряде серверов запущен OpenShift. И, допустим, есть публичный инстанц OpenShift у какого-то (да пусть бы у того же редхата) провайдера услуг. Мне бы хотелось, что бы мое приложение потребляло приватные данные (справочники, статистику), а работало и в моем приватном облаке и в публичном одновременно. Такое возможно?
Судя по описаниям можно заставить приложение работать в своем ЦОД, а в случае необходимости дополнительно поднимать ноды в публичном облаке.Основной вопрос ИМХО это доступность данных. Особенно учитывая то, что OpenShift это PaaS, т.е. целая платформа включая хранение данных, а не только IaaS.
Хы! Они сервер непрерывной интеграции Дженкинс используют как средство для автоматического деплоя. Прикольное решение! Но я так и не понял, что на счет распределенной СУБД? Вот гугль, как известно, такую предоставляет. А в этом продукте как-то не очень понятно есть-нет.
> Хы! Они сервер непрерывной интеграции Дженкинс используют как средство для автоматического
> деплоя. Прикольное решение! Но я так и не понял, что на
> счет распределенной СУБД? Вот гугль, как известно, такую предоставляет. А в
> этом продукте как-то не очень понятно есть-нет.Некоторые изверги от ИТ используют Hudson (даже не Дженкинс) как систему типа cron, которая по таймеру выполняет ETL-операции )))
Распределенная СУБД должна быть. Тот же PostgreSQL в виде EnterpriseDB может быть распределенным. Дальше нужно смотреть на детали реализации ;)))
Смущает, что на иллюстрациях https://openshift.redhat.com/community/wiki/architecture-ove... упоминают MySQL, а уж он-то точно не распределенный никак.
Там ситуация такая, что можно поднять ОДНУ ноду (по ихнему gear) с MySQL к которой цепляться со множества нод (gear-ов) с приложениями.
Хм... звучит так, будто горизонтальное масштабирование СУБД веб-приложениям не светит. И так-то СУБД традиционно самое узкое место почти любого проекта электронной коммерции, а уж при таких раскладах... Как-то все печально это.
В таком раскладе нужно использовать собственное хранилище IaaS или PaaS, а не РСУБД. Собственное (облачное) хранилище - не реляционное, за счет этого и создается линейная масштабируемость по нодам.
Ну так горизонтальное масштабирование не всегда и нужно. Вообще возникает впечатление, что они ориентируются в т.ч. shared хостеров, которые получили бы средства удобного администрирования и миграции клиентов с одной железки на другую. А там, понятное дело, без MySQL/PHP никуда
Насколько приложение будет маштабироваться зависит от разработчиков. Ничто не мешает создать несколько гиров с майсиквелами, настроить репликацию или писать сразу в несколько майсиквелов.