Хороші підходи до упаковки веб-додатків PHP для Debian

Багато веб-додатків PHP дотримуються цієї моделі для встановлення та оновлення:

1. Зняти смолу на кульок з дьогтем.
2. Наведіть на джерело Apache.
3. Перейдіть у веб-браузер на домашню сторінку.
4. Перейдіть через декілька веб-сторінок налаштування (наприклад, перевірки на наявність бібліотек, запитів інформації про підключення до бази даних, створення або оновлення схеми бази даних тощо).
5. Користувач перейменовує install/каталог на щось інше, щоб програма знала, що він встановлений.

Я не бачу жодного (простого) способу створити пакет Debian з цього без того, щоб змусити користувача встановити пакунок, пройти через багато вищезазначених кроків вручну. Зауважте, що я не є розробником програми, тому не можу безпосередньо змінити спосіб роботи програми.

Який типовий підхід до упаковки такої програми?

Я створив кілька веб-додатків PHP, які я поширюю (внутрішньо) через пакети Debian. Це було просто завдяки скриптам (спрощеним тут) для автоматизації процесу:

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

контроль :

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

Все це досить легко зробити, і добре працює для внутрішнього розповсюдження пакунків, який я роблю. Я не впевнений, що цього достатньо для глобального розповсюдження, але це може бути подібним до того, що роблять люди Ubuntu та Debian, коли вони беруть вихідні пакети (можливо, розподіляються у вигляді тарболів зі скриптами встановлення) та створюють для них пакети .deb.

Я думаю, що це може вирішити ваші п’ять пунктів плавно:

1. Пакет Debian автоматично декомпресується в потрібне місце на цільовій системі при його встановленні.

2. Ви можете мати пакет Debian, який автоматично налаштовує Apache. Деякі пакети, такі як MySQL та Apache, мають "conf.d" каталоги в / etc, в які можна скидати конфігураційні файли. Це ідеал. Ваш сценарій упаковки може створити каталог debian / etc / apache2 / conf.d і скопіювати там файл конфігурації. Він буде встановлений у цільовій системі, і ви зможете перезапустити Apache у сценарії під назвою postinst, який ви розміщуєте в debian / DEBIAN.

3. Це, мабуть, неминуче, якщо потрібно вводити власну інформацію, хоча багато хто віддає перевагу системам, які можуть працювати "поза коробкою" без необхідної конфігурації.

4. Існування бібліотеки можна гарантувати, включивши відповідні залежності пакету у керуючий файл. Інформація про з'єднання бази даних може бути встановлена ​​як за замовчуванням, або запитуватися у адміністратора на сторінках конфігурації. Після введення сторінки конфігурації повинні викликати ідентифікаційні сценарії міграції бази даних для оновлення схеми бази даних. Кілька веб-рамок (як Django) полегшують це.

5. Код, що знаходиться за сторінками конфігурації, повинен позначати систему як налаштовану, а не адміністратора.

Я іноді використовую підхід, щоб відокремити встановлення конфігурації від установки програми, зробивши їх окремими пакетами. Тоді я можу мати кілька різних конфігураційних пакетів (випуск, розробка тощо), які я можу встановити за бажанням. Ця розв'язка є також вигідною, оскільки конфігурація та додаток можуть розвиватися окремо, не перестаючи один одного при перевстановці.