Комментарии 8
а почему не подошел какой-нибудь TLJH? емнип, там для каждого пользователя свое окружение сразу "из коробки"
Одной из "фишек" данного похода, как я понял, является децентрализованное обновление пакетов и компонетов. это отдано на откуп пользователя, дата-саентисту. А если что-то пошло не так? Система предусматривает автоматическое резервное хранение прошлый ядер-кернелов? И вопрос по версионности, есть ли какой-то единый регламент, хотя бы на уровне рекомендаций? Например, я могу создавать и сохранять хоть ежеминутно новые докер-образы или я апеллирую условными 100 ГБ. закончилось место - удаляю старые, неактуальные.
1. А если что-то пошло не так? Система предусматривает автоматическое резервное хранение прошлый ядер-кернелов?
Во первых, если билд кернела не проходит, старый кернел на машинах с юпитером не удаляется.
Откатить можно! Все ведется в гите, любое изменение можно откатить и запустить CI\CD снова, кернел соберётся и запушиться на сервера.
2.И вопрос по версионности, есть ли какой-то единый регламент, хотя бы на уровне рекомендаций?
Когда мы не контролировали использование тегов, место в регистри быстро кончилось.
Для кернелов юзеров используйте тег latest, самое верное решение на текущий момент.
Версионность образов используем только для продуктивных процессов.
А poetry вместо pip не рассматривали?
Для ограничения ресурсов лучше использовать z2jh. Можете использовать сущность профилей и выдавать/освобождать ресурсы через kubespawner_override. Для организации профилей можете взять идею проекта jupyter-docker-stacks. На такую конструкцию можно легко навесить ролевую модель по ldap... Пакеты лучше ставить conda(mamba..) в сборке - будет меньше проблем с unix зависимостями. Для пользователя оставить возможность установки пакетов из репозиториев в сам контейнер. Я не думаю что вам нужно много кернел сборок, скорее всего есть золотой список используемых пакетов, оставьте возможность пользователю менять его в самом контейнере, а решение unix зависимостей и cuda оставьте на админов.
"Для ограничения ресурсов лучше использовать z2jh. Можете использовать сущность профилей и выдавать/освобождать ресурсы через kubespawner_override. Для организации профилей можете взять идею проекта jupyter-docker-stacks. На такую конструкцию можно легко навесить ролевую модель по ldap..."
Большое спасибо, уже изучаю возможности.
"Пакеты лучше ставить conda(mamba..) в сборке - будет меньше проблем с unix зависимостями."
Проблем с зависимостями уже нету :)
"Для пользователя оставить возможность установки пакетов из репозиториев в сам контейнер."
Дело в том что для пользователя не так много способов сделать это без бюрократии, CI/CD один из этих способов сделать это без головной боли для всех, образ собирается там где есть доступы.
Спасибо за советы и предложения по оптимизации процесса!
JupyterHub или как перестать бояться pip install