Was ist phar und wie nutze ich es?
Phar ist ein Applikations-Archiv-Format genauso wie Jar es für Java ist. Ein Phar-Archiv enthält Dateien und Ordnerstrukturen, und diese Dateien können dann genutzt werden ohne die Phar-Datei zu entpacken. Man kann so seine ganze Applikation oder auch Frameworks in Phar-Dateien packen und verteilen. Phar ist seit 5.2 als PECL Erweiterung verfügbar, seit 5.3 ist es fest eingebaut.
Die Tatsache dass es dann nur noch eine Datei ist hat mehrere Vorteile. Einerseits ist der Upload auf einen FTP schneller, aber auch beispielsweise der Download ist einfacher, anstatt einer zip/tar.gz Datei die danach noch entpackt werden muss lädt man einfach die Phar-Datei und kann loslegen. Viele kleine Dateien bedeuten auch viele Dateisystem-Zugriffe, und wie wir alle wissen ist die Festplatte langsam, Phar bringt also Performance. Wenn man bereits einen Byte-Code-Cache aktiviert hat ist der Performance-Vorteil nur noch gering, aber vorhanden.
Wenn ich beispielsweise in einer phar-Datei meine komplette Applikation habe, starte ich diese folgendermaßen:
php application.phar
Wenn ein Phar-File auf diese Weise gestartet wird, wird das sogenannte Stub-File aufgerufen, quasi der Einstiegspunkt. Das Stub-File ist eine normale PHP-Datei innerhalb des Phar-Archives.
Alternativ kann ich auch aus einem PHP-Script heraus ein Phar-Archiv inkludieren:
<!--?php<br /-->include 'library.phar';
oder aber einzelne Dateien:
<!--?php<br /-->include 'phar://library.phar/App/Class.php';
Phar bietet noch eine Menge weiterer Features, dazu zählt zum Beispiel die Möglichkeit der Signierung, einer Versionierung, Komprimierung, dem Ablegen von Meta-Daten und Manifest-Daten und vielem mehr.
Wie genau man selbst ein Phar-Archiv erstellen kann liest man sich am besten im PHP Manual zum Thema Phar durch. Im aktuellen Zend Studio gibt es dafür eine Export-Möglichkeit.
Ich selbst habe noch keine praktischen Erfahrungen sammeln können die über ein paar kleine Tests hinausgehen. Ich warte nach wie vor darauf dass z.B. das Zend Framework als Phar-Archiv verfügbar wird, vielleicht ja mit Version 2.0? Es gab schon einige Bemühungen auf Benutzerseite, aber es scheint sich nicht durchzusetzen, ich weiß nicht genau warum nicht.
Wo Licht ist, ist auch Schatten, beispielsweise scheint die komplette Phar-Datei in den Speicher geladen zu werden, auch wenn nur eine Datei benötigt wird. Alles bereits im Arbeitsspeicher zu haben kann ein Vorteil sein, bei wenigen Zugriffen auf Phar-Inhalte ist es aber (etwas) unnötiger Speicherverbrauch. Bei einem Test hatte beispielsweise das Zend Framework auf der Festplatte als komprimiertes Phar-Archiv 4MB, nach dem inkludieren wurden 20MB RAM verbraten.
Man muss natürlich aufpassen dass danach der Autoloader und die require_once() Aufrufe nicht ins Leere laufen. Man lädt die erstellte zf.phar dann so:
require_once dirname(__FILE__).'/zf.phar';
set_include_path('phar://zf.phar');
Nachdem der include-Path so angepasst wurde sollte alles funktionieren.
Beim Einbinden von Silex (http://silex-project.org/) hatte ich einige Probleme mit der PHAR-Datei, dass ich sie nicht laden konnte und nur eine weiße Seite bekam. Da keinerlei Fehlermeldung erschien (error_reporting=E_ALL, display_errors=on, …) war die Fehlersuche etwas mühsam, aber ich habe letztendlich eine Information gefunden, woran es lag. Daher sollte man sich auf die Pittfalls beim Silex-Micro-Framework anschauen. Die können einige Stunden Fehlersuche sparen:
http://silex-project.org/doc/usage.html#pitfalls
Arvid Bergelmir
26 Mai 11 at 09:22
Das Verpacken einer Applikation in ein phar würde doch damit die Applikation gegenüber Angreifern sicher machen, oder sehe ich das falsch?
Für den Angreifer gestaltet es sich doch viel schwieriger, Dateien innerhalb des Archivs zu manipulieren, insbesondere, wenn man das Archiv signieren kann. Automatisierte Scripte, die das Dateisystem durchsuchen und Dateien verändern, würde in diesem Falle doch ins Leere laufen, und selbst wenn eine Manipulation stattfindet, wäre es leichter, das kompromittierte Archiv zu erkennen und wieder auszutauschen. Was innerhalb einer nicht als Archiv vorliegenden Ordner/Dateistruktur viel aufwendiger ist.
Sehe ich das so richtig?
dokape
26 Mai 11 at 09:32
Achso, noch was, was ich die Tage von einem Bekannten gesagt bekommen habe: PHAR-Archive sind scheinbar super, wenn man einen Opcode-Cache laufen hat.
Arvid Bergelmir
26 Mai 11 at 10:16
Beschäftige mich schon ne Weile immer mal wieder mit Phar und bin zu dem Schluß gekommen, dass es eigentlich nur nützlich ist für portable CLI-Anwendungen und zur Übertragung. Ich habe einfach nie einen schlüssigen Grund gefunden, wieso die Anwendung gepackt bleiben sollte, wenn sie (ab dem Punkt) eh immer an der gleichen Stellen liegen bleiben soll/muss, dagegen sprechen allerdings die Einschränkung, dass eine Phar immer komplett geladen wird.
KingCrunch
26 Mai 11 at 10:27
Noch so als Randbemerkung: Inkludiert man eine Phar
include ‚xy.phar‘;
wird der Stub ganz normal aufgerufen. Inkludiert man allerdings eine einzelne Datei über den ‚phar://‘-StreamWrapper
include ‚phar://xy.phar/datei.php‘;
Dann _umgeht_ das den Stub. Man sollte sich also nicht wundern 🙂
Parallel zur Phar-Klasse existiert noch die PharData-Klasse. Die macht quasi das Selbe, bringt aber keinen Stub mit. Vorteil ist, dass dadurch die erzeugte Datei wieder ein reguläres Archiv wird, was man mit handelsüblichen Packing-Tools bearbeiten kann. Oder anders herum: Man kann damit sehr sehr einfach (tar, tar.gz, zip) Archive erzeugen 😉
KingCrunch
26 Mai 11 at 10:36
Danke, toller Artikel und sehr verständlich erklärt.
Zur Zend-Frage habe ich dir Screenshots geschickt, also: „Ja, es geht“ … Import übrigens auch 😉
Sascha Presnac
26 Mai 11 at 10:51
Ich hab noch nie davon gehört muss ich zugeben und bin im Inneren tief gespalten. Zum einen ist es ja schon verlockend zu sagen, wir haben da eine Datei und die lädst Du hoch und dann funktioniert das, Sowas wäre z. B. für WordPress eine Riesenvereinfachung oder für die Installation anderer „fertiger“ Scripte.
Aber ich seh eigentlich mehr Nachteile. Die Dateien können nicht mehr so problemlos geändert werden, der Speicherverbrauch ist ja schon erwähnt worden und wie verträgt sich das mit APC oder ähnlichen Sachen? Ich eher skeptisch, ob sich das wirklich durchsetzen kann, weil es ausser der Vereinfachung eigentlich nur Nachteile hat.
Oliver
26 Mai 11 at 23:42
@Oliver: Aktuelle Versionen von APC können mit phar-Dateien umgehen.
Genutzt wird zum Beispiel schon phpMyAdmin als Phar-Datei, die einzige Datei außerhalb des Phar-Archivs ist dann die config.inc.php.
Dass man Dateien nicht mehr so einfach editieren kann stimmt. Ein einfaches Update von WordPress wie es aktuell gemacht wird ist dann nicht mehr möglich, man müßte die komplette wordpress.phar ersetzen. Dann muss jedoch drauf geachtet werden wohin temporäre Dateien, Uploads, Konfigurationsdateien etc. geschrieben werden, das muss dann außerhalb des phar gemacht werden. Dann trennt man vernünftig variable und statische Dateien.
Man kann diese Nicht-Veränderbarkeit auch als Vorteil ansehen, z.B. beim Zend Framework kommt man nicht in Versuchung am Framework Änderungen zu machen sondern wird gezwungen, die Klassen schön abzuleiten wenn man etwas erweitern oder ändern möchte. dokape sagte ja auch schon etwas dazu.
Michael Kliewe
27 Mai 11 at 08:57
Das ist nun nur ein „Benchmark“, wo es auch keine Sourcen zu gibt, aber schaut mal hier: http://marc.info/?l=php-internals&m=121394601217048&w=2 PHAR scheint nicht unbedingt schlecht zu sein.
Arvid Bergelmir
27 Mai 11 at 09:03
@Michael:
Wordpress komplett zu ersetzen wäre ja kein Problem. Das passiert ja jetzt auch schon. Die Userdateien liegen ja in wp-content, von daher wäre eine Trennung schon vorhanden.
Signaturen sind eine schöne Sache, ja – aber das funktioniert halt auch nur, wenn man eine eigene Versionierung hat und/oder wenn man „massenkompatible“ Lösungen schreibt. Für den „Hausgebrauch“ alles weniger geeignet. Den gleichen Effekt würde man auch erreichen, wenn man (so mach ich das eigentlich immer) den Webserver in eine chroot packt und ihm die Schreibrechte auf fast alle Dateien entzieht. Per sftp nutze ich dann einen anderen User, der Schreibrechte hat.
Die Stärke von PHP ist ja eigentlich, dass man ein Script ändert und die Änderungen sind abrufbar, ohne Kompilierung oder packen, hochladen und fertig.
Oliver
27 Mai 11 at 16:05
[…] Was ist phar und wie nutze ich es? […]
Linkhub – Woche 21-2011 | PehBehBeh
30 Mai 11 at 23:09
Hallo,
ich habe die Tage auf PHAR umgestellt und ich muss sagen gerade auf Debian ist das echt noch ein bißchen stressig.
Erstmal blockt suhosin den phar wrapper – meinetwegen aber man sieht nichts im syslog oder error_log oder sonstwo – einfach eine weiße Seite.
Dann scheint es so als müsste man im PHAR einige Sachen beachten, damit APC auch alles richtig macht. Zumindest mit der letzten Debian version auf Squeeze mit APC scheint PHAR noch nicht kompatibel zu sein. Ich bekomme (sehr schwierig zu debuggende) weiße Seiten beim includen von PHARs oder beim AutoLoading von Klassen.
Letzendlich half nur abc.cache_by_default = 0 und warten bis ne neue Version rauskommt.
Also alleinstehend find ichs super – das Build Script ist auch in 4 Minuten gebaut und Deployment macht wieder Bock. (Mein ganzes Framework ist ~ 146KB zum hochladen)
Stress mit Debian (ich hoffe es findet wer, per Google), sonst super 🙂
Philipp Scheit
25 Okt 11 at 11:19
lorex security cam app
wireless outdoor camera
7 Jun 18 at 05:57
[…] PHPGangsta – Der praktische PHP Blog […]
Lesefunde – Ingram Braun
5 Jul 24 at 15:52