Ein einfaches und flexibles Deployment für Applikationen auf Basis von PHP, dass schnell zu installieren und zu konfigurieren ist. Dabei kann es als Standalone Applikation, aber auch in Verbindung mit Phing genutzt werden.
Hintergrund zum Jity Deployment
Die initiale Verion des Jity Deployment entstand aus der Not heraus, die Jity CMS Applikation an meinen Server auszuliefern und dabei einige Verwaltungstechnische Schritte auszuführen. Darunter fällt zum Beispiel der Neustart von Varnish, das leeren aller Caches und das vorübergehende Anzeigen einer Maintenance Meldung. Das alles sollte natürlich so einfach wie möglich geschehen, denn aufwendige Prozesse die händisch ausgeführt werden, sind fehleranfällig. Aus diesem Grund ist es notwendig den besagten Prozess einmal zu definieren und danach immer wieder automatisch abarbeiten zu lassen. Aus dieser Motivation entstand eine Phing Erweiterung die, diesen Gedanken aufgriff und dabei alle Vorzüge von Phing beibehielt.
Version 1.0 hatte so gut wie keine Abhängigkeiten zu anderen Projekten, was es sehr klein machte. Was jedoch zum Funktionsumfang gehörte, war eine umfangreiche Konfiguration die über YAML realisiert wurde, eine Vielzahl an Teilschritten die zusammen einen Workflow abbildeten und ein rudimentärer Log. Installiert wurde die Software vorzugsweise als Git Submodule, was rückblickend die schlechteste Entscheidung darstellte. In Svn Projekten wurde einfach eine Kopie der jeweils letzten Version fest eingepflegt, was Updates vom Projektstamm aufwendig einzuspielen machte.
In einigen Situationen erwiesen sich die einfachen Basis-Installer Hooks als unzulänglich, da sie zu wenige Einstiegspunkte bereitstellten. So war nur schwerlich möglich ein paar spezielle Befehle für einen einzigen Slave im Environment abzusetzen. Zum Beispiel ist es nicht ungewöhnlich ausschließlich den Master eines Clusters eine Maintenance Meldung ausgeben zu lassen, während die Slaves Updates erhalten. An das debuggen von Installer Skripten war nicht zu denken, geschweige denn diese zu validieren bevor sie tatsächlich auf den Slaves ausgeführt wurden.
Neues in Version 2.0
Version 2.0 ist ein kompletter Rewrite des Projektes auf Symfony2-Basis. Die Applikation kann nun als Standalone oder, wie schon bekannt, als Phing Extension genutzt werden. Die Konfigurationsmöglichkeiten sind stark gewachsen, haben aber die Vorteile einer semantischen Konfiguration erhalten, bei der man nur noch die Optionen angeben muss die vom Standard abweichen. Außerdem ist eine allumfassende Konfigurationsvalidierung hinzugekommen, die Fehler auswendig macht bevor die Applikation darauf zugreift und möglichen Schaden anrichtet. Des Weiteren werden alle konfigurierten Pfade normalisiert. Generell alle Optionen werden nach Parametern in dieser Schreibweise durchsucht: %parameter%. Sobald ein Parameter erkannt wurde wird er durch den Wert ersetzt den er darstellt. Es können ausschließlich Parameter verwendet werden die skalar sind. Nicht auflösbare Parameter in Optionen führen zum kontrollierten Programmabbruch. Eine Übersicht über mögliche Konfigurationsoptionen kann durch ein Kommando angezeigt werden.
Eine weitere Neuerung ist die Standardisierung aller Steps die den Workflow bilden. Als Ergebnis dieses Prozesses entstanden kleine, einfache und dadurch besser wartbare Einzellschritte. Somit war es ein leichtes Source-Distribution ab.">Fetcher für die gängigen VCS‘s (Git, Svn, Lokale Kopie) zu verfassen.
Das Konzept der Fixtures ist in Version 2.0 nicht neu, trotzdem möchte ich dieses Feature kurz vorstellen. Bei Fixtures handelt es sich im Sinne von Deployment um eine Sammlung von strukturierten statischen Inhalten, die je nach Umgebung ausgeliefert werden. Dabei werden diese Strukturen über die eigentliche Source-Distribution kopiert, wobei sie bereits existierende Dateien überschreiben. Mit diesem mächtigen Werkzeug lassen sich zum Beispiel Konfigurationen für verschiedene Umgebungen vorhalten und bei bedarf einspielen.
Viel Zeit in der sechswöchigen Entwicklung floss in den Installer Compiler, ein Werkzeug, dass aus den einzelnen Installer Hooks (Partials) einen vollständigen Installationsskript erstellt. Zusätzlich zu dieser Aufgabe beherrscht der Installer Compiler die Validierung und Anzeige der erstellten Skripte. Was vorher fast unmöglich war im ganzen zu betrachten und zu debuggen, lässt sich nun mit einem einfachen Befehl durchführen. Die Hooks die vom Installer Compiler gefunden werden, werden in dieser Reihenfolge ausgeführt:
- base/pre
- base
- environment/pre
- environment
- environment/post
- base/post
- environment/slaves/slave
Der Einzelschritt der Paketerstellung kann nun umfangreicher konfiguriert werden. Im Zuge dessen besteht nun die Möglichkeit den Algorithmus der Kompression zu wählen. Dabei stehen folgende Verfahren zu Auswahl: gzip, bzip2, xz.
Abschließend sind die Neuerungen im Auslieferungsprozess zu nennen. Alle Pakete werden parallel verarbeitet, was die Dauer des Prozesses bei vielen Slaves deutlich reduziert. Kommt es bei der Installation eines Paketes auf einem Slaves zu Fehlern wird die Verarbeitung auf diesem Slave gestoppt und die Fehler werden geloggt. Der Fehlerfall auf einem einzelnen Slave hat keinerlei Auswirkungen auf die Verarbeitung auf den anderen Slaves.
Beispiel anhand eines neuen Projektes
Um meine Aussagen zur Leichtigkeit der Installation des Jity Deployments zu untermauern stelle ich im Folgenden einen Arbeitsablauf vor, der als Resultat ein funktionsfähiges und auslieferungsbereites Symfony2 Projekt hat.
# Anlegen eines neuen Projektverzeichnisses
$ mkdir example-project && cd example-project
# Klonen des Symfony2 Git Repositories
$ git clone 'git://github.com/symfony/symfony-standard.git' .
# Wir benötigen die Versionsverwaltung von Symfony2 nicht,
# da wir ein eigenes Projekt aufsetzen
$ rm -rf .git
# Installieren von Composer
$ mkdir bin && curl -s 'https://getcomposer.org/installer' | php -- --install-dir=bin
# Installieren von Jity Deployment
$ curl -s 'https://deployment.jity.de/installer' | php
# Einrichten einer minimalen Deployment Konfiguration
$ ./bin/deployment-console.phar prepare
# Installation aller Abhängigkeiten durch Composer
$ ./bin/composer.phar update
In nur sieben Schritten haben wir ein neues Projekt angelegt und können sofort anfangen daran zu arbeiten. Sobald wir soweit sind, können wir die Früchte unserer Arbeit auf die von uns konfigurierten Server spielen, mit nur einem Fingerschnips.
Was dem interessierten Leser aufgefallen sein wird, ist die Tatsache, dass die Installation vom Jity Deployment der Installation vom Composer ähnelt. Dieses Merkmal ist nicht ohne Grund so gewählt worden, denn auch der Composer lässt sich schnell und einfach nutzen.
Weiterführende Links
Ich hoffe der interessierte Leser konnte etwas mitnehmen, in diesem Sinne: Happy deployment! 😃