Некоторое время я боролся с развертыванием (в основном PHP) веб-сайтов в виде файлов .deb и задаюсь вопросом, есть ли способ лучше, чем мой довольно запутанный метод. Моя цель - непрерывная интеграция на моем промежуточном сервере и развертывание на активный сервер одним щелчком мыши из Jenkins.
Мой вариант использования сейчас:
Я попытался настроить сервер Jenkins CI для просмотра репозитория Git на предмет коммитов и автоматического выполнения сборки. Проблема в том, что Jenkins работает как собственный пользователь, у которого нет разрешения на установку прав доступа к файлам, как указано выше. Я также не вижу очевидного способа запустить сборку Phing в среде fakeroot из Jenkins.
Мои вопросы:
Возможно, я неправильно понял, как работает .debs, но мне кажется довольно неудобным, что права собственности на файл в исходном коде вашей локальной файловой системы должны отражать место назначения!
Я открыт для предложений по любым другим системам сборки и CI, которые люди используют для выполнения аналогичной задачи.
Кажется, что вы создаете двоичный пакет debian почти вручную, используя команду dpkg-deb. Хотя этот подход не так уж плох, вы сможете лучше справляться со многими вещами, если попытаетесь собрать пакеты, создав пакеты с исходным кодом, а затем построив из них двоичные пакеты (даже если это независимые от архитектуры файлы, такие как файлы PHP). . Это требует единовременной настройки нескольких файлов в debian/ каталог.
Есть специальный debian/rules файл, который решает, что запускать для сборки пакетов Debian разных типов (т.е. исходный код, двоичный, независимый от двоичного кода) и поддерживать сам каталог сборки. Вы можете подумать о том, чтобы запустить все свои инструменты сборки из этого файла, а не вызывать их один за другим. Чтобы решить проблему с установкой владельцев / разрешений во время сборки от непривилегированного пользователя, вам нужно будет запустить весь процесс сборки пакетов Debian под fakeroot обертка. Для официальных пакетов debian это можно сделать, запустив fakeroot debian/rules binary. Однако это вызывается из dpkg-buildpackage так что ты просто беги fakeroot dpkg-buildpackage.
Debian великолепен своими инструментами разработчика (см. Пакеты debhelper, devscripts и связанные), и, похоже, вы их тоже не используете (очевидно, потому что вы собираете пакеты в другой операционной системе). Они сэкономят вам много времени. Например, есть dh_fixperms который исправит для вас проблемы с разрешениями и владением, dh_install разместить файлы в нужных местах, dh_link создать необходимые символические ссылки и другие dh_-подобные скрипты. Возможно, вы захотите узнать, как это работает в реальном мире, поэтому вот список программного обеспечения, реализованного на PHP и упакованного в Debian.
Еще одним хорошим инструментом для вас будет git-buildpackage который является оболочкой для инструментов сборки debian, предназначенных для сборки пакетов, поддерживаемых Git DVCS.
Вы можете посмотреть общую информацию о сборке с Git на Вики-страница Debian.
К сожалению, в Debian нет phing, поэтому вы можете попросить кого-нибудь упаковать его для Debian (чтобы ваш полный стек сборки был доступен в Debian) или просто приготовьте chroot Debian с debootstrap и установить в него пинг вручную.
Если вы придерживаетесь пакетов Debian в качестве основного механизма развертывания вместе с некоторой системой CI, вот несколько моментов:
pbuilder или cowbuilder. В противном случае подготовьте коробку Debian для сборки. Возможно, вы захотите создать виртуальную машину и отдать ее другим разработчикам./etc/apt/sources.list.d/my-repository.list Файл конфигурации. Не забудьте импортировать свой ключ. Это даст вам информацию о зависимостях, о которых вы бы не узнали, если бы вы установили пакет только с dpkg -i *.deb до самого этапа установки.sudo invoke-rc.d nginx reload. Если это так, ограничьте выполнение точных команд, изменив /etc/sudoers файл соответственно. Пакет Debian - это архив, состоящий из нескольких частей, который содержит данные и управляющую информацию. /debian. Архив данных в основном извлекается как есть. Контрольный архив извлекается и в основном перемещается в /var/lib/dpkg/info и скрипты pre | post-inst | rm вызываются при необходимости. Если вы хотите что-то изменить после извлечения файлов, сделайте это в своем postinst.
но кажется довольно неудобным, что право собственности на файл в исходном коде вашей локальной файловой системы должно отражать место назначения!
Обычно люди создают chroot или виртуальную машину, которая отражает архитектуру, для которой они создают пакет. Попытка собрать пакет для системы Debian из OSX довольно необычна.
Действительно ли команде dpkg-deb нужно заранее настроить все разрешения для файлов в файловой системе?
Это нормальный способ обработки разрешений. Изменение разрешений после установки является исключением, а не правилом.