Buoni approcci per il confezionamento di applicazioni Web PHP per Debian

Molte applicazioni Web PHP seguono questo modello per l'installazione e l'aggiornamento:

1. Annulla tar una palla tar di origine.
2. Punta Apache alla fonte.
3. Passare un browser Web alla home page.
4. Passare attraverso diverse pagine Web di installazione (ad esempio, verifica l'esistenza di librerie, chiede informazioni sulla connessione al database, crea o aggiorna lo schema del database, ecc.).
5. L'utente rinomina una install/directory in qualcos'altro in modo tale che l'applicazione sappia che è stata installata.

Non vedo alcun modo (semplice) per creare un pacchetto Debian da questo senza che l'utente che installi il pacchetto passi attraverso molti dei passaggi manuali sopra. Si noti che non sono uno sviluppatore dell'applicazione, quindi non sono in grado di apportare modifiche dirette al funzionamento dell'installazione dell'applicazione.

Qual è l'approccio tipico al confezionamento di una tale applicazione?

Ho creato diverse applicazioni web PHP che distribuisco (internamente) tramite pacchetti Debian. Farlo è stato semplice grazie agli script (qui semplificati) per automatizzare il processo:

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

controllo :

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

Tutto questo è abbastanza facile da fare e funziona bene per la distribuzione del pacchetto interno che faccio. Non sono sicuro che sia sufficiente per la distribuzione globale, ma potrebbe essere simile a quello che fanno le persone Ubuntu e Debian quando prendono pacchetti sorgente (probabilmente distribuiti come tarball con script di installazione) e creano pacchetti .deb per loro.

Penso che questo possa affrontare senza problemi i tuoi cinque punti:

1. Il pacchetto Debian si decomprime automaticamente nella posizione corretta sul sistema di destinazione quando viene installato.

2. Puoi avere il pacchetto Debian per configurare Apache automaticamente. Alcuni pacchetti come MySQL e Apache hanno directory "conf.d" in / etc in cui è possibile rilasciare i file di configurazione. Questo è l'ideale Lo script di packaging può creare una directory debian / etc / apache2 / conf.d e copiare un file di configurazione al suo interno. Verrà installato sul sistema di destinazione e puoi riavviare Apache in uno script chiamato postinst che inserisci in debian / DEBIAN.

3. Ciò è probabilmente inevitabile se è necessario immettere informazioni personalizzate, sebbene molti preferiscano sistemi che possono essere eseguiti "out of the box" senza necessità di configurazione.

4. L'esistenza della libreria può essere garantita includendo le dipendenze dei pacchetti appropriate nel file di controllo. Le informazioni sulla connessione al database possono essere installate come predefinite o richieste all'amministratore nelle pagine di configurazione. Una volta immesse, le pagine di configurazione dovrebbero invocare script di migrazione del database idempotenti per aggiornare lo schema del database. Diversi framework web (come Django) lo rendono facile.

5. Il codice dietro le pagine di configurazione dovrebbe contrassegnare il sistema come configurato, non l'amministratore.

Un approccio che a volte uso è quello di separare l'installazione della configurazione dall'installazione dell'app rendendoli pacchetti separati. Posso quindi avere diversi pacchetti di configurazione (versione, sviluppo, ecc.) Che posso installare a piacimento. Questo disaccoppiamento è anche vantaggioso perché la configurazione e l'app possono evolversi separatamente, senza bloccarsi a vicenda una volta reinstallate.