Каков рекомендуемый способ использования / установки веб-приложений в Arch Linux?

Question

Я пытаюсь найти лучший способ надежной настройки веб-приложений на моем сервере Arch Linux + nginx. Я делал это раньше, загружая и распаковывая, например, последнюю версию dokuwiki/wordpress в /srv/http/ , а затем настраивая ее вручную, редактируя конфигурационные файлы в этом месте, после смены владельца каталога на пользователя nginx , Каждый раз, когда выходила новая версия веб-приложения (без встроенного механизма обновления), я повторял эту процедуру, перемещая существующие файлы конфигурации / данных из старого в новое местоположение.

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

У меня есть несколько проблем с этим подходом, а также несколько вопросов, касающихся передовых методов поддержки веб-приложений на сервере:

• файлы, установленные из пакетов в Arch, обычно находятся в /usr/share/webapps/ . Как насчет файлов данных / конфигурации? Я тоже их туда положу? Или я как-то их символически связываю? Как-нибудь автоматически копировать приложения оттуда в /srv/http после каждого обновления?
• при условии, что я буду ссылаться на эти каталоги или настроить nginx для чтения непосредственно из них, как насчет разрешений? Нужно ли вручную запускать chown -R root:nginx /usr/share/webapps/new_webapp после каждого обновления / установки? Или их права собственности автоматически устанавливаются для какой-либо группы www ?
• И последнее, но не менее важное: как насчет конфигурационных файлов этих веб-приложений при обновлении их пакетов? Разве они не будут перезаписаны (в худшем случае) pacman или будут созданы тонны файлов .pacnew (в лучшем случае)?

Как webadmins обычно решают эту проблему? Какие ресурсы описывают лучшие практики в этом вопросе? Я уже использую puppet для управления настройкой различных пакетов, но "правильный" и простой в обслуживании способ установки веб-приложений все же ускользает от меня.

Answer 1

Для приложений, установленных вручную, рассмотрите возможность загрузки репозитория Git или Hg, если он есть. Вы сможете обновиться до последней (стабильной или разрабатываемой) версии с помощью одной команды и отслеживать свои собственные изменения кода, если в итоге вы их сделаете. (И если кто-то найдет способ засорять ваши файлы вредоносным ПО, это также займет несколько минут, чтобы очистить.)

Это ускорило обновление двух наших установок Moodle с 30–60 минут (загрузка; извлечение; создание резервной копии; повторное добавление модулей; повторное применение локальных исправлений) до всего лишь 1-3 минут (git pull).

Кроме того, вы можете создать свои собственные пакеты для pacman, которые затем позаботятся об удалении старых файлов и извлечении новых в нужное место.

---

Пакеты также всегда содержат информацию о владельце, поэтому обычно это не проблема.

Обновления вручную означают, что владение обычно необходимо сбросить, хотя это может быть до некоторой степени автоматизировано: с помощью обновлений на месте (например, Git/Hg или rsync и т.д.) Вы можете установить режим "setgid" в каталогах данных веб-приложения, используя chmod g+s , и группа (часть :nginx ) будет автоматически применена ко всем новым файлам внутри.

Однако, когда вы извлекаете новый tar-архив, вам всегда нужно будет исправить файлы вручную.

---

Для основного местоположения, /usr/share/webapps подходит. Вам не всегда нужны символические ссылки, часто удобнее настроить расположение непосредственно в httpd.conf; например:

Alias /myapp /usr/share/webapps/MyApp/public

Для конфигурации это зависит от вашего метода загрузки. Системные веб-приложения обычно имеют свои файлы конфигурации с символической ссылкой на /etc, в основном для лучшего соответствия с иерархией файловой системы Linux.

При установке из tarball символическая ссылка также более удобна, когда вам необходимо выполнить обновление.

Благодаря обновлениям на основе Git/Hg ваши правки в любом случае сохраняются, поэтому в основном это вопрос предпочтений.