качество и надёжность с 2008 года

8 (800) 200-25-11

Техническая поддержка support@komtet.ru —

круглосуточно и без выходных дней

load-whois

Онлайн-касса

для интернет-магазина

Подключите ваш интернет-магазин

к онлайн-кассе в соответствии с 54-ФЗ

 

Plone без Buildout

В статье "A Buildout-Free Plone " автор говорит о том, как обойтись без Buildout при инсталляции Plone. Автор: Erik Rose

Предложение сделать инсталляцию 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.

Действия

Существует несколько задач, которые можно использовать в качестве помощи. Я думаю, что большинство из них можно выполнить параллельно:

  1. Динамическая папка плагинов. Достаточно одного шага, чтобы запустить поддержку папки плагинов egg, продукта, и пакета. Я примерно наполовину завершил выполнение этого Plone-продукта под названием Абракадабра, который я выпущу как доказательство данной концепции.
  2. "Не созданные" экземпляры Zope. Надо понять, как передать номер порта и местоположение файла сокета в zopectl через командную строку. Tres Seaver из первоначальной команды Zope, уверяет меня, что эти ключи должны работать, и я вижу, что их запрятали на 5 уровней вглубь, но я ещё не проследил их путь на поверхность и не удостоверился, что они работают. Как только мы это сделаем, нам не нужно будет хранить каждый экземпляр Zope на диске.
  3. Вспомогательные программы. Определите, какие инструменты управления из командной строки могли бы быть полезны. Программа Debian dzhandle является превосходным началом, но в ней конечно же есть несколько ошибок.
  4. Подумать над plone/install. Нужен ли какой-нибудь инструмент для автоматической загрузки зависимостей? Как отменить результаты работы, в тех случаях, где зависимости оказались "сломанными" и привели к сбоям? Как нам избежать полного переписывания aptitude? Это всё было бы полезно без команды plone/install но с ней было бы легче.

Итак, вот мои мысли об упрощении хостинга, и в качестве побочного эффекта, общее распространение опыта Plone. Спасибо за прочтение всего материала до конца! Как всегда, я приветствую ваше мнение и помощь, так как ещё надо проделать большую работу в этом направлении. 

Примечание: Клиентам Zope/Plone-хостинга КОМТЕТ не надо заботиться об установке Plone - всё установлено «под ключ». 

По материалам http://weblion.psu.edu

Перевод КОМТЕТ komtet.ru

Другие документы на эту тему

Клиентам — домены в подарок!
Бесплатный тест виртуального хостинга
Перенос сайта — бесплатно
Все акции
На сайте КОМТЕТ используются cookie-файлы, данные о IP-адресе и местоположении посетителей. Если, прочитав это сообщение, вы остаетесь на нашем сайте, это означает, что вы не возражаете против использования этих технологий.