Хорошие подходы для упаковки PHP веб-приложений для Debian

15

Многие веб-приложения PHP используют эту модель для установки и обновления:

  1. Разархивируйте исходный тарный шар.
  2. Укажите Apache на источник.
  3. Перейдите в веб-браузере на домашнюю страницу.
  4. Просмотрите несколько веб-страниц настроек (например, проверяет наличие библиотек, запрашивает информацию о подключении к базе данных, создает или обновляет схему базы данных и т. Д.).
  5. Пользователь переименовывает install/каталог во что-то другое, чтобы приложение знало, что оно установлено.

Я не вижу никакого (простого) способа создания пакета Debian из этого, не заставляя пользователя, устанавливающего пакет, пройти через многие из описанных выше шагов вручную. Обратите внимание, что я не являюсь разработчиком приложения, поэтому я не могу вносить прямые изменения в способ установки приложения.

Каков типичный подход к упаковке такого приложения?

rlandster
источник
1
Я не уверен, что вы подразумеваете под пакетом Debian, но изучали ли вы Composer? getcomposer.org
CamelBlues,

Ответы:

19

Я создал несколько веб-приложений 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, когда они берут исходные пакеты (вероятно, распространяемые как tarballs со скриптами установки) и создают для них пакеты .deb.

Я думаю, что это может решить ваши пять вопросов гладко:

  1. Пакет Debian автоматически распаковывается в нужное место в целевой системе при его установке.

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

  3. Это, вероятно, неизбежно, если необходимо ввести пользовательскую информацию, хотя многие предпочитают системы, которые могут работать «из коробки» без необходимости настройки.

  4. Существование библиотеки может быть гарантировано включением соответствующих зависимостей пакета в контрольный файл. Информация о подключении к базе данных может быть установлена ​​по умолчанию или запрашиваться администратором на страницах конфигурации. После ввода страницы конфигурации должны вызывать идемпотентные сценарии миграции базы данных для обновления схемы базы данных. Несколько веб-фреймворков (например, Django) делают это легко.

  5. Код за страницами конфигурации должен помечать систему как настроенную, а не администратора.

Подход, который я иногда использую, заключается в том, чтобы отделить установку конфигурации от установки приложения, сделав их отдельными пакетами. После этого у меня может быть несколько разных пакетов конфигурации (релиз, разработка и т. Д.), Которые я могу установить по своему усмотрению. Такое разъединение также является преимуществом, поскольку конфигурация и приложение могут развиваться отдельно, не мешая друг другу при переустановке.

Рэндалл Кук
источник