Bonnes approches pour empaqueter des applications Web PHP pour Debian

De nombreuses applications Web PHP suivent ce modèle pour l'installation et la mise à niveau:

1. Dé-tarez une boule de goudron source.
2. Pointez Apache à la source.
3. Accédez à un navigateur Web sur la page d'accueil.
4. Parcourez plusieurs pages Web de configuration (par exemple, vérifie l'existence de bibliothèques, demande des informations de connexion à la base de données, crée ou met à jour le schéma de la base de données, etc.).
5. L'utilisateur renomme un install/répertoire en quelque chose d'autre pour que l'application sache qu'il a été installé.

Je ne vois aucun moyen (simple) de créer un paquet Debian à partir de cela sans obliger l'utilisateur à installer le paquet à travers la plupart des étapes manuelles ci-dessus. Notez que je ne suis pas développeur de l'application, je ne suis donc pas en mesure de modifier directement le fonctionnement de l'installation de l'application.

Quelle est l'approche typique de l'empaquetage d'une telle application?

J'ai créé plusieurs applications Web PHP que je distribue (en interne) via des packages Debian. Cela a été simple grâce aux scripts (simplifiés ici) pour automatiser le processus:

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

contrôle :

Package: myapp
Version: 1.2.3
Maintainer: Your Name <[email protected]>
Architecture: all
Depends: apache2, php5
Description: The myapp web application.

Tout cela est assez facile à faire et fonctionne bien pour la distribution de packages interne que je fais. Je ne suis pas sûr que cela soit suffisant pour une distribution mondiale, mais cela pourrait être similaire à ce que font les gens d'Ubuntu et de Debian lorsqu'ils prennent des paquets source (probablement distribués sous forme de fichiers tar avec des scripts d'installation) et créent des paquets .deb pour eux.

Je pense que cela peut répondre à vos cinq points en douceur:

1. Le paquet Debian se décompresse automatiquement au bon endroit sur le système cible lors de son installation.

2. Vous pouvez demander au paquet Debian de configurer Apache automatiquement. Certains packages comme MySQL et Apache ont des répertoires "conf.d" dans / etc dans lesquels vous pouvez déposer des fichiers de configuration. C'est l'idéal. Votre script d'empaquetage peut créer un répertoire debian / etc / apache2 / conf.d et y copier un fichier de configuration. Il sera installé sur le système cible, et vous pouvez redémarrer Apache dans un script appelé postinst que vous placez dans debian / DEBIAN.

3. Ceci est probablement inévitable si des informations personnalisées doivent être saisies, bien que beaucoup préfèrent les systèmes qui peuvent fonctionner "prêts à l'emploi" sans configuration requise.

4. L'existence d'une bibliothèque peut être garantie en incluant les dépendances de package appropriées dans le fichier de contrôle. Les informations de connexion à la base de données peuvent être installées par défaut ou demandées à l'administrateur sur les pages de configuration. Une fois entrées, les pages de configuration doivent appeler des scripts de migration de base de données idempotents pour mettre à jour le schéma de base de données. Plusieurs frameworks web (comme Django) facilitent la tâche.

5. Le code derrière les pages de configuration doit marquer le système comme configuré, pas l'administrateur.

Une approche que j'utilise parfois consiste à séparer l'installation de la configuration de l'installation de l'application en en faisant des packages distincts. Je peux alors avoir plusieurs packages de configuration différents (release, développement, etc.) que je peux installer à volonté. Ce découplage est également avantageux car la configuration et l'application peuvent évoluer séparément, sans s'encombrer lors de la réinstallation.