Dobre podejście do pakowania aplikacji internetowych PHP dla Debiana

Wiele aplikacji PHP używa tego modelu do instalacji i aktualizacji:

1. Rozpakuj tarę źródłową.
2. Skieruj Apache na źródło.
3. Przejdź w przeglądarce internetowej do strony głównej.
4. Przejrzyj kilka stron internetowych konfiguracji (np. Sprawdza istnienie bibliotek, prosi o informacje o połączeniu z bazą danych, tworzy lub aktualizuje schemat bazy danych itp.).
5. Użytkownik zmienia nazwę install/katalogu na inny, aby aplikacja wiedziała, że ​​został zainstalowany.

Nie widzę żadnego (prostego) sposobu na utworzenie z tego pakietu Debiana bez zmuszania użytkownika instalującego pakiet do wykonania wielu powyższych instrukcji. Pamiętaj, że nie jestem programistą aplikacji, więc nie jestem w stanie dokonać bezpośredniej zmiany w sposobie instalacji aplikacji.

Jakie jest typowe podejście do pakowania takiej aplikacji?

Stworzyłem kilka aplikacji internetowych PHP, które dystrybuuję (wewnętrznie) za pośrednictwem pakietów Debiana. Jest to proste dzięki skryptom (tutaj uproszczonym) do automatyzacji procesu:

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

kontrola :

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

Wszystko to jest dość łatwe do zrobienia i działa dobrze w przypadku wewnętrznej dystrybucji pakietów, którą robię. Nie jestem pewien, czy to wystarcza do globalnej dystrybucji, ale może być podobne do tego, co robią ludzie Ubuntu i Debian, kiedy biorą pakiety źródłowe (prawdopodobnie dystrybuowane jako tarballi ze skryptami instalacyjnymi) i tworzą dla nich pakiety .deb.

Myślę, że może to sprawnie rozwiązać twoje pięć kwestii:

1. Pakiet Debian automatycznie dekompresuje się we właściwe miejsce w systemie docelowym, gdy jest zainstalowany.

2. Możesz mieć pakiet Debiana automatycznie konfigurujący Apache. Niektóre pakiety, takie jak MySQL i Apache, mają katalogi „conf.d” w / etc, do których można upuścić pliki konfiguracyjne. To jest ideał. Twój skrypt do pakowania może utworzyć katalog debian / etc / apache2 / conf.d i skopiować do niego plik konfiguracyjny. Zostanie on zainstalowany w systemie docelowym i możesz ponownie uruchomić Apache w skrypcie o nazwie postinst, który umieścisz w debian / DEBIAN.

3. Jest to prawdopodobnie nieuniknione, jeśli trzeba wprowadzić niestandardowe informacje, choć wielu woli systemy, które mogą działać „po wyjęciu z pudełka” bez konieczności konfiguracji.

4. Istnienie biblioteki można zagwarantować poprzez włączenie odpowiednich zależności pakietów w pliku kontrolnym. Informacje o połączeniu z bazą danych można zainstalować domyślnie lub zapytać administratora na stronach konfiguracji. Po wprowadzeniu strony konfiguracji powinny wywoływać idempotentne skrypty migracji bazy danych w celu zaktualizowania schematu bazy danych. Wiele frameworków internetowych (takich jak Django) ułatwia to.

5. Kod za stronami konfiguracji powinien oznaczać system jako skonfigurowany, a nie administratora.

Podejście, którego czasami używam, to oddzielenie instalacji konfiguracji od instalacji aplikacji poprzez utworzenie oddzielnych pakietów. Mogę wtedy mieć kilka różnych pakietów konfiguracyjnych (wydanie, programowanie itp.), Które mogę zainstalować do woli. To oddzielenie jest również korzystne, ponieważ konfiguracja i aplikacja mogą ewoluować osobno, bez zatykania się nawzajem podczas ponownej instalacji.