Ottimi approcci per il confezionamento di applicazioni web PHP per Debian

13

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

  1. Un-tar una sorgente tar.
  2. Punto Apache all'origine.
  3. Spostare un browser Web sulla home page.
  4. Passare attraverso diverse pagine Web di set-up (ad es. verifica la presenza di librerie, richiede informazioni sulla connessione al database, crea o aggiorna lo schema del database, ecc.)
  5. L'utente rinomina una directory install/ in qualcos'altro, in modo che l'applicazione sappia che è stata installata.

Non vedo alcun modo (semplice) per creare un pacchetto Debian al di fuori di questo senza che l'utente che installa il pacchetto passi attraverso molti dei precedenti passaggi manuali. Nota 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 per confezionare un'applicazione di questo tipo?

    
posta rlandster 21.04.2013 - 20:48
fonte

1 risposta

19

Ho creato diverse applicazioni web PHP che distribuisco (internamente) attraverso pacchetti Debian. Farlo è stato semplice grazie agli script (semplificati qui) 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 <[email protected]>
Architecture: all
Depends: apache2, php5
Description: The myapp web application.

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

Penso che questo possa risolvere tranquillamente 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 automaticamente Apache. 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. Verrà installato sul sistema di destinazione, e puoi riavviare Apache in uno script chiamato postinst che inserisci in debian / DEBIAN.

  3. Questo è probabilmente inevitabile se è necessario inserire informazioni personalizzate, anche se molti preferiscono sistemi che possono essere eseguiti "immediatamente" senza alcuna configurazione richiesta.

  4. L'esistenza della libreria può essere garantita includendo le appropriate dipendenze del pacchetto 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 inseriti, le pagine di configurazione dovrebbero richiamare script di migrazione del database idempotente per aggiornare lo schema del database. Diversi framework web (come Django) rendono questo facile.

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

Un approccio che a volte utilizzo è separare l'installazione della configurazione dall'installazione dell'applicazione 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 sbavare l'un l'altro quando vengono reinstallati.

    
risposta data 23.04.2013 - 00:55
fonte

Leggi altre domande sui tag