Einblick in zc.buildout für Zope/Plone Entwickler

Übersicht

Was ist zc.buildout?

Buildout ist ein Python Modul das von Zope Corporation (persönlich Jim Fulton) für das Deployment von vergleichbaren Entwicklungsumgebungen innerhalb der Entwickler-Community entwickelt wurde. Der korrekte Namespace im Cheeseshop lautet "zc.buildout" (zc steht für Zope Corporation). Buildout macht exzessiven Gebrauch von setuptools und eggs, kann aber auch mit klassischen Zope Produkten umgehen.

Die "buildout.cfg" und "parts"

Dreh und Angelpunkt ist die Konfigurationsdatei "buildout.cfg", die in sogenannten "Parts" organisiert ist. DIe Reihenfolge des Aufrufs der Parts im Header der Datei bestimmt auch die Reihenfolge der Abarbeitung. Die Namen der Parts können in Grenzen frei gewählt werden und bestimmen die dynamisch von buildout erzeugten Verzeichnisstrukturen.

Recipes

Innerhalb der parts werden sogenannte "recipes" aufgerufen. Die recipes können sowohl mit buildout mitgeliefert sein, als auch extern aus dritten Quellen nachgeladen werden. Jedes recipe bestimmt einen Installationsvorgang innerhalb des parts. Chance und Risiko dabei ist, dass natürlich auch die Qualität der Installation von der Qualität der Recipes abhängt. (Charlie Clark verweist dazu zu Recht auf die Notwendigkeit zur Qualitätssicherung bei Recipes und Eggs, wenn der verantwortliche Admin keine Risiken eingehen will. Hier fehlt es zur Zeit an Transparenz.

Klassische Installationsmethoden

Überblick über die klassichen Installationmethoden für Zope :

• die Installer von plone.org (für Newbees)
• aus den Sourcen
• mit Tools wie PTools/InstanceManager

An Installationskonzepten Interessierten sei ein Blick auf die vorteilhaften Konzepte des alten Tyrell Installers für MacOSX empfohlen.  Dieser installierte bei jedem Update neue separate Pythons und Zopes und vollzog erst beim forcierten Update der Instanzen ein Umkonfigurieren der Zeiger auf die benötigte Python/Zope Kombination.

Templates für Instanzen

Auch Templates für Instanzen haben als "Skeletton" in Zope Tradition - dies führte aber oft ein Schattendasein.

Planung zu diesem Dokument

Ich plane diesen Text zu einem ausgearbeiteten deutschsprachigen Vortrag zu diesem Thema auszuarbeiten. Bis dahin verweise ich auf die folgenden Seiten auf OpenPlans, die weiterführende Informationen (in englisch) enthalten (das Tutorial ist für User ohne Kenntnis und Zugang zum Buchs von Martin Aspeli gedacht). Die nötigen Kommadozeilenbefehle finden sich alle im Tutorial auf OpenPlans.
http://www.openplans.org/projects/plone3-example-themes/project-home
http://www.openplans.org/projects/plone3-example-themes/theme-development-environment-setup

Die Python Installation

Buildout setzt allein ein aktuelles Python 2.4 und setuptools voraus (2.5 ist derzeit noch nicht für Zope/Plone relevant).
Thema am Rande war die Problematik von gemeinsam benutzten Python-Installationen. Die Standpunkte: "System-Python is Evil" und "Every production Zope Instance loves a standalone Python!" (or a separate "virtualpython") haben ihre Berechtigung!

Die Warnung vor dem Hunde!

Wer also nicht genau weiß was er macht und nur experimentieren möchte sei gewarnt: Ein unüberlegter buildout run kann eine existierende Installation komplett unwiederbringlich durcheinanderbringen. Also Backups ziehen oder am besten in einer Virtual Machine "rummachen".

Lernen am Beispiel "ZopeSkel"

Buildouts "from Scratch" zu erstellen setzt ein Konzept für die Organisation der Ressourcen in Ordnern voraus. Einige werden z.B. durch die "parts" von buildout vorgegeben.

Für den Anfänger eignen sich die von "ZopeSkel" vorgegeben Templates für Plone buildouts (2.5 und 3.x) als Einstieg sehr gut. Es liegt eine konzeptionell durchdachte Verzeichnisstruktur für die Ablage der Ressourcen vor, die in der Lernphase erst einmal nachvollzogen werden kann, ohne bei Null anzufangen. ZopeSkel installiert buildout als Dependency gleich mit.

easy_install ZopeSkel

Kleine Meditation

Festhalten!

Man sollte sich also von vorneherein alte Gewohnheiten loslassen und sich auf neue Ablageorte bekannter Dateien einer Zope-Installation einstellen!

Paster

Mit dem paster Script aus dem ZopeSkel Modul können ein buildout für eine Plone3 Umgebung und Gerüste (Skelettons) für bestimmte zu entwickelnde Produkte relativ einfach erzeugt werden.

Paster erzeugt nach Beantwortung einiger Fragen, ähnlich wie das "mkzopeinstance.py" Script, eine buildout Umgebung für eine Zope/Plone Installation.  Zunächst sollte man sich mit der Verzeichnisstruktur des buildouts in grafischer Form vertraut machen, damit man ein Bild der Teile vor Augen hat (der Begriff "parts" spielt ja bei Buildout eine große Rolle). Das vom Paster Script erzeugte Verzeichnis, und teilweise dessen Unterverzeichnise, enthalten RADME.txt Dateien die wertvolle Hinweise in englischer Sprache enthalten. Es lohnt sich diese Inline Dokumentation zu lesen!

Im nächsten Schritt werden die Quellen für bestehende Produkte / Eggs und ggf. lokal vorhandene Entwicklungsverzeichnisse in der Datei buildout.cfg gesetzt werden. Dies kann grundsätzlich bereits vor dem ersten Installationslauf mit dem Befehl buildout erfolgen. Mit extern zu ladenden "recipes" Rezepten kann die Funktionalität von buildout erweitert werden, um z.B. Produkte aus einem SVN auszuchecken.

Ist die Konfiguration abgeschlossen, werden durch einen buildout run die für die Konfiguration benötigten Ressourcen heruntergeladen. Daher ist ein jungfräuliches buildout in der Regel auf eine funktionierende Verbindung zum Internet angewiesen.

Zugang zum Internet nötig?

Abweichend von kursierenden Gerüchten kann buildout auch problemlos auf lokale Ressourcen zugreifen, wenn diese entsprechend eingebunden werden. In diesem Falle wird ein buildout komplett mit allen Ressourcen geliefert und offline gestartet.

Feedback aus der Runde

Bories von dem Bussche und Charlie Clark gingen auf die die Risiken von buildout beim Deployment ein:

1. Unter Umständen nicht nachvollziehbare Nachinstallation von abweichenden Versionen von Ressourcen durch extern entwickelte Produkte, deren Dependencies nicht sauber aufgelöst werden.
2. Mangelde Dokumentation nicht explizit angegebener, aber installierter Ressourcen.

Exkurs & Konzepte für die Anwendung von buildout

Die Tatsache, dass ein buildout aus ZopeSkel "ohne Option" per "default" alle Ressourcen aus dem Web lädt, halte ich für einen Design-Fehler. Diese Konvention müsste genau umgekehrt werden. Das Nachladen aus dem Web sollte explizit angefordert werden. Ich werde prüfen ob an das Flag in der *.cfg entsprechend setzen kann (dann ist es ein Fehler von ZopeSkel!). Weiterhin machen mehrstufige buildouts Sinn deren .cfg Dateien kaskadiert geladen werden. Ein Beispiel dazu findet sich in der Doku zum SVN recipe "infrae.subversion" im Cheeseshop. (Link dazu im Dokument auf OpenPlans).

http://pypi.python.org/pypi/infrae.subversion

https://svn.infrae.com/buildout/silva/trunk/profiles/base.cfg

buildout.cfg als Protokollformat

Ein Vorschlag von mir dazu ist, zur Dokumentation von buildout runs ein Dateiformat zu verwenden, dass einer regulären buildout.cfg entspricht, allerdings jede Ressource explizit mit Version und Quelle lädt, um eine (soweit mögliche) exakte Reproduktion des erfolgten buildout runs zu ermöglichen.

Nachtrag:
buildout schreibt tatsächlich ein Protokoll des buildout Laufs in einem buildout.cfg kompatiblen Format. Die Datei heißt .installed.cfg und liegt im gleichen Verzeichnis wie die buildout.cfg. Diese entspricht im Prinzip genau dem Feature, dass wir im Termin in Düsseldorf gefordert haben: Eine Dokumentation des erfolgreichen buildout runs im buildout.cfg Format. Diese sollte man vor einem neuen Run archivieren!Inwieweit diese Datei als Ersatz für die buildout.cfg verwendbar ist und was zu beachten ist, um daraus ein sicheres lokales Deployment ohne Webzugriff zu machen ist noch zu testen. Die protokollierten Pfade sind (protokollgerecht!) absolut und müssen für das Deployment in relative Pfade überführt werden. Ob das "on the fly" oder per Konvertierung erfolgen sollte ist zu evaluieren.

Rollout von Plone aus Plone heraus

Ein weiteres Konzept von mir, ist ein Plone Produkt (PloneRollout), dass in der Lage ist ein buildout für das Deployment eines Clones der laufenden Plone Site zu erzeugen bzw. über ein Interface die Konfiguration zu manipulieren bzw. zu dokumentieren. Über die Risiken und Probleme bin ich mir durchaus im Klaren. Durch geschickte Vorgehensweise lassen sich diese Punkte alle in den Griff bekommen. Eine Installation von Linux aus einer Live-CD Session heraus ist auch nichts anderes. Bories zeigte sich an der Produktion von Plone/Zope Life-CD's interessiert. Dies wäre eine mögliche Anwendung.

Fazit

Alles in allem ist buildout für Entwickler ein Muss geworden. Ob der einfache Anwender damit glücklich wird, bzw. wie es ein solides Werkzeug beim Management von Konfigurationen wird, hängt vom Verständnis des Admins und der Qualität zur verantwortungsvollen Einbindung in einen größeren Workflow bzw. Anbindung von Tools wie ZopeSkel ab. Mal eben ist das nicht zu schaffen - dazu ist eine nicht triviale Systemumgebung wie Zope/Plone zu komplex.

Ich habe Jim Fulton während der DZUG-Tagung in Berlin auf, gegenüber Tools wie InstanceManager, fehlende Funktionen angesprochen. Dazu gehörten Dokumentation und Maintanance (Backup etc.). Er sieht diese Funktionen ausserhalb von buildout. So wie ich Ihn verstanden habe, verwendet Zope Corporation dazu eine separate komplexe Zope3 Anwendung die ggf. buildouts erzeugt, managt bzw. aufruft.

Weitere Informationen

Originaldokumentation zu zc.buildout im Cheeseshop http://cheeseshop.python.org/pypi/zc.buildout
Deutsches Script zur buildout Präsentation von Veit Schiele: http://www.veit-schiele.de/dienstleistungen/schulungen/entwicklungswerkzeuge/buildout
Buildout Tutorial von Martin Aspeli etc. auf Plone.org: http://plone.org/documentation/tutorial/buildout
http://www.packtpub.com/article/Setting-up-the-Plone-Development-Environment