Plone без Buildout
Предложение сделать инсталляцию Plone снова надежной
Недавно мое внимание привлёк список обсуждений на plone-hosting. Оказывается, многие системные администраторы ищут более лёгкий и репродуктивный способ развертывания Plone на серверах, не делая каждодневных манипуляций с зависимостями пакета Python. Я являюсь создателем услуги хост-сервера, встретившимся с этими проблемами, но с тех пор, как Plone стал зависеть от buildout, я много сил вложил в эту проблему. Я также наблюдаю, как проблема, связанная с buildout каждый день стучится в дверь Plone. Я думаю, что мы сможем убить двух зайцев одним выстрелом, упростив инсталляцию Plone для новых пользователей так, чтобы можно было установить Plone через менеджер пакетов ОС, не используя PyPI-зеркала и огромные прикрепленные файлы, которые могут "нагрузить" любого человека обязанностями релиз-менеджера.
Предпосылка проблемы
Debian's Plone и пакеты Zope исторически были превосходными. Они увязаны с родным обновлением ОС, загрузкой и настройкой механизмов для обеспечения непротиворечивого административного опыта, и являются чрезвычайно гибкими, даже поддерживая множество экземпляров Zope. Они также более надежны и более отказоустойчивы, чем buildout, который я рассмотрю более подробно в WebLion Hosting: Leverating Laziness, Impatience, и Hubris (убедитесь, что щелкнули небольшую вкладку Notes для отображения заголовков). К сожалению, недавно Fabio Tranchitella покинул пакет Debian Plone, поскольку он почувствовал, что борьба с движущей силой buildout не стоит его времени. Тем временем Zope по-прежнему доступен в Debian Testing.
Plone без Buildout
Несмотря на уход Fabio, мне всё ещё нужен надёжный механизм обновления для управления моим растущим сервером; запуск buildout в середине ночи автоматически заставляет мои надпочечники дергаться. Итак, я сейчас работаю над "переупаковкой" Plone, который не требует buildout и поэтому будет более поддающимся менеджеру пакетов родной ОС. Самая простая форма дистрибутива была бы отправлена как простой tarball, не требуя никакой специальной проверки для установки. Содержание было бы следующим...
plone/ conf/ var/ plugins/
Папка plone содержала бы то, что считается самим Plone: например, содержание текущего (превосходного) Unified Installer. Пользователи не должны ничего менять в этой папке. Plone мог бы быть обновлён только путём замены папки plone более новой версией, и таким же способом мог бы быть осуществлён откат, независимо от сетевой погоды. Менеджер пакетов ОС работал бы главным образом с папкой plone, и возможно была бы вспомогательная утилита, такая как Debian's dzhandle, для создания экземпляров, которые связаны с главным экземпляром.
Несколько экземпляров Zope, работающих с единой базой данных, могли бы работать без их записи на диск: Zope имеет много встроенных, хотя и редко используемых поддержек для принятия таких параметров, как номера портов в командной строке. Я вижу, что plone/start принимает такие параметры, как --instances=4 --port-base=8080 и/или имеет файл plone.conf в папке conf, определяющий конфигурацию нескольких экземпляров. Следует рассмотреть запуск Plone под сервером WSGI (repoze.plone?) и воспользоваться многопроцессорностью.
Папка conf содержит все файлы конфигурации: zope.conf и plone.conf, если он у вас есть. Пользователям не надо изучать новый синтаксис buildout для старых директив конфигурации, и файл zope.conf имеет множество самодокументированных комментариев, как, например, olde.
Папка var очень схожа с тем, как она выглядит сейчас, в ней много таких файлов, как Data.fs и т. п.
В папке плагинов находятся дополнения. Она поддерживает eggs, old-style продукты, пакеты plain-jane. Не надо совершать никаких дополнительных действий для установки плагина: просто поместите его в каталог, и выполните plone/restart. Копирование (Repeatability) достигается с помощью инструментов, которые знает каждый системный администратор: просто упакуйте папку верхнего уровня, и переместите её на другой компьютер. Для пакетов, которые имеют много зависимостей, я также рассматриваю команду plone/install,которая извлечёт плагин и его зависимости в папку плагиновтак же, какzenpack --installв Zenoss. Содержание папки плагинов может быть увеличено пакетами, установленными в системные каталоги: возможно упоминание о них в plone.conf.
Моя цель по отношению к папке плагинов состоит в том, чтобы устранить таинственные конфликты зависимостей и сетевые сбои, что ведёт к "замусориванию" других пакетов buildout-ом. Зависимость пакетов Debian является надежной, потому что она имеет очень формальный, 3-х уровневый QA-процесс; если сравнить, то PyPI является Диким Западом, поэтому buildout никогда не может выполнить свою цель повторяемости. Он также не нарушаем, т. к. aptitude проверяет всё перед выполнением чего-либо, делая его почти полностью отказоустойчивым.
Выполнение
Buildout - это прекрасный инструмент для разработчиков; он в основном создаёт для Вас ваш собственный релиз-менеджер. Это делает его пригодным (хотя всё ещё не безаварийным) для таких действий, как создание и пересмотр PLIP-пакетов, в которых много пользовательских пакетов разных версий. Этот новый дистрибутив вероятно будет проще всего внедрить в виде buildout-рецепт. Можно было бы запустить рецепт для каждой новой версии Plone, разобраться с проблемами скачивания или конфликтами зависимостей окончательно, раз и навсегда, упаковать результат, и зарелизить его. Результат мог бы быть упакован как DEB, RPM-пакет, или любой другой. В случае успеха, мог бы получится новый Unified Installer, который мог бы уменьшить поток испуганных пользователей Инсталлятора в #plone, когда они впервые перезапускают buildout.
Действия
Существует несколько задач, которые можно использовать в качестве помощи. Я думаю, что большинство из них можно выполнить параллельно:
- Динамическая папка плагинов. Достаточно одного шага, чтобы запустить поддержку папки
плагиновegg, продукта, и пакета. Я примерно наполовину завершил выполнение этого Plone-продукта под названием Абракадабра, который я выпущу как доказательство данной концепции. - "Не созданные" экземпляры Zope. Надо понять, как передать номер порта и местоположение файла сокета в
zopectlчерез командную строку. Tres Seaver из первоначальной команды Zope, уверяет меня, что эти ключи должны работать, и я вижу, что их запрятали на 5 уровней вглубь, но я ещё не проследил их путь на поверхность и не удостоверился, что они работают. Как только мы это сделаем, нам не нужно будет хранить каждый экземпляр Zope на диске. - Вспомогательные программы. Определите, какие инструменты управления из командной строки могли бы быть полезны. Программа Debian
dzhandleявляется превосходным началом, но в ней конечно же есть несколько ошибок. - Подумать над
plone/install. Нужен ли какой-нибудь инструмент для автоматической загрузки зависимостей? Как отменить результаты работы, в тех случаях, где зависимости оказались "сломанными" и привели к сбоям? Как нам избежать полного переписывания aptitude? Это всё было бы полезно без командыplone/installно с ней было бы легче.
Итак, вот мои мысли об упрощении хостинга, и в качестве побочного эффекта, общее распространение опыта Plone. Спасибо за прочтение всего материала до конца! Как всегда, я приветствую ваше мнение и помощь, так как ещё надо проделать большую работу в этом направлении.
Примечание: Клиентам Zope/Plone-хостинга КОМТЕТ не надо заботиться об установке Plone - всё установлено «под ключ».
По материалам http://weblion.psu.edu