Мы работаем над научными вычислениями и регулярно отправляем вычисления в различные вычислительные кластеры. Для этого мы соединяем с помощью оболочки Linux и отправляем задания через SGE, Slurm и т.д. (Это зависит от кластера). Наши коды состоят из скриптов python и bash и нескольких двоичных файлов. Некоторые из них зависят от внешних библиотек, таких как matplotlib. Когда мы начинаем использовать новый кластер, это кошмар, так как нам нужно сообщить администраторам все библиотеки, в которых мы нуждаемся, и иногда они не могут установить их все или у них есть только старые версии, которые невозможно обновить. Поэтому мы задаемся вопросом, что мы можем сделать здесь. Мне было интересно, можем ли мы как-нибудь "упаковать" все библиотеки, которые нам нужны вместе с нашими кодами. Как вы думаете, это возможно? В противном случае, как мы можем перейти к новым кластерам без необходимости добавления каких-либо администраторов?
Как "перемещать" все необходимые библиотеки, которые требуется script при переходе на новую машину
Ответ 1
Ключ состоит в том, чтобы скомпилировать весь необходимый вам код, используя инструментальные средства компилятора/библиотеки/MPI, установленные админами кластеров, чтобы
- ваше программное обеспечение правильно скомпилировано для аппаратного обеспечения кластера и
- Вы не зависите от администратора для установки программного обеспечения.
В этом случае очень полезны следующие:
- Ansible, загружать/управлять конфигурационными файлами, rc файлами, устанавливать разрешения, компилировать ваши двоичные файлы и т.д. и легко развертывать новую среду в новых кластерах
- Easybuild, чтобы установить версию Python со всеми необходимыми зависимостями и установить другое научное программное обеспечение благодаря поддерживаемым сообществом процедурам сборки.
- CDE, чтобы создать пакет со всеми зависимостями для ваших двоичных файлов на вашем ноутбуке и использовать его как есть на кластерах.
Более конкретно для Python вы можете использовать
- virtual envs, чтобы настроить согласованный набор модулей Python для всех кластеров независимо от уже установленных модулей; или
- Anaconda или Canopy использовать научный дистрибутив Python
иметь согласованную установку Python во всех кластерах.
Ответ 2
Не поймите меня неправильно, но я думаю, что вы должны сделать это: перестаньте вести себя как любители.
Значение: целостность вашей "конфигурации системы" является одним из активов основного вашего "бизнеса". И вы просто сказали нам, что вы в основном неспособны легко пересоздать конфигурацию вашей системы.
Итак, реальный ответ здесь не может быть рекомендацией использовать ту или иную технологию. Реальный ответ: вы, а также другие команды, участвующие в управлении вашими операциями, должны собраться вместе и определить серьезную стратегию, как это исправить.
Может быть, тогда вы решите, что путь для вас состоит в том, что ваша команда разработчиков предоставляет сборщики файлов Docker, так что ваша операционная группа может легко создавать образы на новых машинах. Или вы решили, что вам нужно использовать что-то вроде ansible, чтобы обеспечить централизованный контроль над вашей полной средой.
Ответ 3
Что означает venv
, он позволяет легко создавать переносимую настраиваемую среду, точно с тем, что вы нужно и ничего больше.
Ответ 4
Я полностью согласен с https://stackoverflow.com/users/1531124/ghostcat но вот действительно плохой ответ, который вызовет у вас много проблем в ближайшем будущем!!!:
если вам нужна динамическая библиотека, и вы не планируете ее обновлять в будущем, вы можете попробовать скопировать все необходимые библиотеки в папку в вашем приложении и использовать script для запуска приложения:
#!/bin/sh
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/your/lib/folder
./myAPP
но имейте в виду, что это плохая практика.
Ответ 5
Создайте изображение chroot, как здесь - щелкните. Установите все, что вам нужно, а затем вы можете просто вставить его на любую машину.
Ответ 6
Я также работаю над научными кластерами, и вы обнаружите, что куда бы вы ни отправились.
Я бы только полагался на администраторов при установке самых простых вещей. То есть: - Программное обеспечение, необходимое для создания вашего программного обеспечения или запускать самые простые вещи: компиляторы и большинство основных утилит (python, perl, binutils, autotools, cmake и т.д.).
- Библиотеки программного обеспечения, использующие устройства ввода-вывода: MPI, библиотеки ввода-вывода файлов...
- Система очереди (они уже имеют ее большую часть времени).
- Модули среды. Это не обязательно, но он действительно помогает вам выполнить задание, особенно если вы возитесь с разными версиями или версиями библиотек (например, в моем случае).
С этого момента вы можете создавать и устанавливать в своих собственных каталогах все программное обеспечение, которое вы используете большую часть времени.
Это не означает, что вы не можете попросить администратора установить некоторые библиотеки. Если вы чувствуете, что многие люди выиграют от этого, тогда вы должны запросить его установку. Кроме того, вам может потребоваться определенная версия или некоторые специальные функции, которые не используются большую часть времени, но вам они действительно нужны. Очень хороший пример: библиотеки BLAS (базовые подпрограммы линейной алгебры):
- У вас много доступных реализаций BLAS: оригинальные BLAS, Intel MKL, OpenBLAS, ATLAS, cuBLAS
- Если этого недостаточно, версии с открытым исходным кодом обычно предлагают несколько вариантов конфигурации: серийная версия, параллельная версия с PThreads, параллельная версия с OpenMP, параллельная версия с MPI...
В моем конкретном случае большая часть программного обеспечения, которое, как мне казалось, было необходимо для многих пользователей кластера, в конечном итоге было установлено администраторами без каких-либо проблем (либо я, либо другие пользователи запросили его), но вы также должны помните, что в кластере может быть много пользователей, и один человек/команда не сможет посещать конкретные требования, которые вам нужны, особенно если вы в состоянии это сделать.
Ответ 7
Я думаю, что вы хотите каким-то образом контейнеризовать свое приложение. Два основных варианта (потому что docker/rkt и подобные вещи слишком тяжелы для вашей задачи, если я это правильно понимаю), на мой взгляд, runc и мгновенно.
Runc полагается на OCI спецификация времени выполнения, вам нужно для создания среды (которая очень похожа на среду chroot, в которой вам нужно скопировать все, что вы используете в одном каталоге), а затем вы сможете запустить приложение с помощью инструмента runc. Сам Runc - это всего лишь один двоичный код, на данный момент он требует запуска привилегий root (привет, администраторы кластера), но есть патчи, по крайней мере, частично что, если вы создадите свой собственный runc и не будете блокировать все права root, вы можете запустить приложение без каких-либо административных накладных расходов.
Snappy похож на то, что вам нужно подготовить пакет snap для вашего приложения, на этот раз используя snapcraft в качестве помощника. Snappy, вероятно, немного проще в создании образа приложения, и IMO, безусловно, лучше для долгосрочной поддержки, потому что он четко отделяет ваше приложение от данных (kinda W ^ X, образ приложения является файлом squashfs для чтения, и приложение может писать только в ограниченный набор каталогов). Но на данный момент это потребует, чтобы администраторы кластера установили snapd и выполнили некоторые операции, такие как snap-установка, требующая привилегий root. Тем не менее, это должно быть лучше, чем ваша текущая ситуация, потому что это только один неинтрузивный пакет для установки.
Если эти инструменты не подходят по какой-либо причине, всегда есть возможность сделать что-то свое. Это будет непросто, и есть много тонких деталей, которые могут укусить вас при этом, но это можно сделать, скомпилировать все ваши зависимости и приложения в какой-то путь, создать сценарии оболочки для настройки PATH
и LD_LIBRARY_PATH
среду для ваших компонентов, а затем привести этот каталог в новый кластер, запустить сценарии оболочки вместо целевых двоичных файлов и его. Это похоже на то, что делает XAMPP, у них есть довольно много интегрированных вещей, упакованных в один каталог, который работает во многих дистрибутивах.
Обновление
Позвольте также добавить AppImage в теоретическую форму, теоретически это может быть спасителем для вашего случая, поскольку он специально не требует прав root, Это как-то между Snappy и вашим собственным, так как вам нужно подготовить свой каталог приложений самостоятельно (snappy может управлять некоторыми зависимостями с помощью snapcraft, когда вы просто указываете "Мне нужен этот пакет Ubuntu" ), добавлять соответствующие метаданные, а затем его можно упаковать в один исполняемый файл.