Gute Ansätze zum Packen von PHP-Webanwendungen für Debian

Viele PHP-Webanwendungen folgen bei Installation und Upgrade diesem Modell:

1. Un-tar eine Quelle Teerball.
2. Richten Sie Apache auf die Quelle.
3. Navigieren Sie mit einem Webbrowser zur Homepage.
4. Durchsuchen Sie mehrere Einrichtungswebseiten (z. B. Überprüfen, ob Bibliotheken vorhanden sind, Fragen nach Informationen zur Datenbankverbindung, Erstellen oder Aktualisieren des Datenbankschemas usw.).
5. Der Benutzer benennt ein install/Verzeichnis in ein anderes um, damit die Anwendung weiß, dass es installiert wurde.

Ich sehe keine (einfache) Möglichkeit, daraus ein Debian-Paket zu erstellen, ohne dass der Benutzer, der das Paket installiert, viele der obigen manuellen Schritte durchläuft. Beachten Sie, dass ich kein Entwickler der Anwendung bin und daher keine direkten Änderungen an der Funktionsweise der Anwendungsinstallation vornehmen kann.

Was ist der typische Ansatz zum Verpacken einer solchen Anwendung?

Ich habe mehrere PHP-Webanwendungen erstellt, die ich (intern) über Debian-Pakete verteile. Dies war dank Skripten (hier vereinfacht) zur Automatisierung des Prozesses unkompliziert:

create_package.sh :

# create a clean debian package directory
rm -rf debian
mkdir -p debian/DEBIAN
mkdir -p debian/var/www/myapp

# populate the debian directory
cp control    debian/DEBIAN
cp myapp.php  debian/var/www/myapp
cp index.html debian/var/www/myapp

# finish through fakeroot so we can adjust ownerships without needing to be root    
fakeroot ./finish_package.sh debian .

finish_package.sh :

# $1 is the debian directory, $2 is the output directory

# adjust ownerships
chown -R root:root $1
chown -R nobody:nobody $1/var/www/myapp

# finally build the package
dpkg-deb --build $1 $2

Kontrolle :

Package: myapp
Version: 1.2.3
Maintainer: Your Name <yourname@email.com>
Architecture: all
Depends: apache2, php5
Description: The myapp web application.

All dies ist ziemlich einfach und funktioniert gut für die interne Paketverteilung, die ich mache. Ich bin mir nicht sicher, ob es für die globale Distribution ausreicht, aber es könnte ähnlich sein, wie die Ubuntu- und Debian-Leute es machen, wenn sie Quellpakete (wahrscheinlich als Tarballs mit Installationsskripten verteilt) nehmen und .deb-Pakete für sie erstellen.

Ich denke, das kann Ihre fünf Punkte problemlos ansprechen:

1. Das Debian-Paket wird bei der Installation automatisch an der richtigen Stelle auf dem Zielsystem dekomprimiert.

2. Sie können das Debian-Paket Apache automatisch konfigurieren lassen. Einige Pakete wie MySQL und Apache haben "conf.d" -Verzeichnisse in / etc, in die Sie Konfigurationsdateien ablegen können. Das ist das Ideal. Ihr Paketskript kann ein Verzeichnis debian / etc / apache2 / conf.d erstellen und eine Konfigurationsdatei darin kopieren. Es wird auf dem Zielsystem installiert und Sie können Apache in einem Skript namens postinst neu starten, das Sie in debian / DEBIAN platzieren.

3. Dies ist wahrscheinlich unvermeidbar, wenn benutzerdefinierte Informationen eingegeben werden müssen. Viele bevorzugen jedoch Systeme, die ohne Konfiguration "out of the box" ausgeführt werden können.

4. Das Vorhandensein der Bibliothek kann gewährleistet werden, indem die entsprechenden Paketabhängigkeiten in die Steuerdatei aufgenommen werden. Informationen zur Datenbankverbindung können entweder standardmäßig installiert oder vom Administrator auf den Konfigurationsseiten abgefragt werden. Nach der Eingabe sollten die Konfigurationsseiten idempotente Datenbankmigrationsskripts aufrufen, um das Datenbankschema zu aktualisieren. Mehrere Web-Frameworks (wie Django) machen dies einfach.

5. Der Code hinter den Konfigurationsseiten sollte das System als konfiguriert markieren, nicht den Administrator.

Ein Ansatz, den ich manchmal verwende, besteht darin, die Installation der Konfiguration von der Installation der App zu trennen, indem sie separate Pakete erstellen. Ich kann dann mehrere verschiedene Konfigurationspakete (Release, Entwicklung usw.) haben, die ich nach Belieben installieren kann. Diese Entkopplung ist auch deshalb von Vorteil, weil Konfiguration und App separat weiterentwickelt werden können, ohne dass sie sich bei einer Neuinstallation gegenseitig stören.