Внутреннее развертывание приложения python с использованием venv и rpm

Question

Я ищу других, которые имеют опыт работы с python venv и развертывания приложений через rpm.Мои цели:

1. Использовать pip для зависимости от Python
2. Использовать venv для разделения сред приложений / отделов
3. Использовать rpm для развертывания (требуется нашими внутренними компаниями)аудит и т. д.).

У меня есть сервер сборки (jenkins slave) для каждой архитектуры (читай: distro), на которой мы развертываем.Мой первоначальный (и единственный) план для подчиненного jenkins (сервера сборки) через задание jenkins заключался в следующем:

1. Создание venv
2. Активация venv
3. python setup.py build / install (в спецификации rpm)
4. обороты архива как артефакт
5. Радуйтесь

Я никогда не переходил к шагу 2 или 3, поэтому я не знаюдраконы там, однако главная проблема приходит с шагом «Создать вен».Поскольку venvs не «перемещаемы» и RPM использует RPM_BUILD_ROOT, который является автономной файловой системой в tmpdir, из которого мы упаковываем, я не могу установить venv в rpm_build_root.Мне пришлось бы установить venv в фактическое местоположение на сервере сборки, которое должно было быть при развертывании (установить rpm).Это не идеально по многим причинам, которые вы можете догадаться (коллизии с другими приложениями, другие вещи, работающие на серверах сборки и т. Д.).

Я не хочу запускать setup.py на моем производственном компьютереи загружать пакеты во время установки.Я хочу убедиться, что все хорошо, чтобы все загрузилось и было упаковано до того, как произойдет развертывание.

Самое близкое, что я нашел, это dh-virtualenv из этого , поэтому вопрос ,Это выглядит многообещающе и из того, что я могу сказать, устанавливается непосредственно в конечный каталог (не временная сборка).Это убирает за собой, но все еще кажется плохой практикой.Есть ли способ лучше?Я что-то пропустил?Кажется, я застрял, делая это в порядке.

Answer 1

Я не знаю, каков лучший способ, но ваша идея очень близка к тому, что мы делаем в нашей компании:

• создает относительную виртуальность (которая можетбыть перемещен и все еще функционирует).Я сделал общедоступный сценарий в этом gist
• , а затем упаковал весь virtualenv, изменив также сценарий сценария, чтобы они вызывались с правильным virtualenv.

В наших файлах спецификаций было бы что-то вроде этого:

%build
./src/macq-create-relative-virtualenv -p . -v 3.6 -r Pipfile

%install
# Create directories
install -d -m 0755 "${RPM_BUILD_ROOT}/usr/lib/application"

cp -r virtualenv ${RPM_BUILD_ROOT}/usr/lib/application/
cp script.py ${RPM_BUILD_ROOT}/usr/lib/application/
# set the correct shebang for script
sed -i "1s@.*@#\!/usr/lib/application/virtualenv/bin/python3@" ${RPM_BUILD_ROOT}/usr/lib/application/script.py
ln -s /usr/lib/application/script.py ${RPM_BUILD_ROOT}/usr/bin/script

%check
./virtualenv/bin/python3 -m coverage run --branch tests/run_tests.py

%files
/usr/lib/application
/usr/bin/script

Хорошая деталь в том, что тесты выполняются с тем же пакетом virtualenv, что и в пакете.