Комментарии 6
Спасибо за статью. А можете написать минимальный/ рекомендуемый сайзинг для данной платформы?
Для того чтобы просчитать рекомендуемый сайзинг нужно отталкиваться от каких-то входных данных, самое большое, наверное, это размеры моделей и дата-сетов. Возможно тут одним minio не обойтись. Тут описан только прототип платформы.
У меня все было развернуто на трех нодах кластера, но по факту уместилось бы и на одной (16 cpu, 64GB ram). Но если накручивать отказоустойчивость - минимум три ноды. Ну и повторюсь, объем дисков зависит от итоговых объемов моделей и датасетов.
Пожалуйста!
норм туториал, сохранил. а как в плане безопасности - модельки и данные остаются внутри закрытого контура или есть какой-то выход наружу? интересует именно вопрос утечек при тренировке, когда данные гоняются через внешние сервисы
В моей парадигме - все остается во внутреннем контуре. Наружу ничего не выходит, если вы сами это не выставите. Внешних сервисов никаких нет.
Но если, например, у вас нет GPU, и вы взяли ее в аренду в облаке - тут конечно все зависит уже от этого облака и организации канала связи до GPU. Но у больших облаков все сертифицировано в этом плане.
Привет. Интересная статья. Есть пара вопросов:
1) Почему используется ingress, в не GatewayApi?
2) Почему прикрыли кейклоком юпитер, но не стали им прикрывать MLFlow? У nginx есть аннотация для редиректа на стороннюю аутентификацию
3) Не совсем понял, как при помощи ExteralSecret вы добились подстановки секретов в пользовательские Юпитер сереверы? У вас же креды для каждого юпитер пользователя разные? Если да, то как вы генерите ExternalSecret для каждого пользователя уникальный?
Здравствуйте! Спасибо за ваши вопросы! Отвечу по пунктам:
1) Исторически. Контур приватный, кубер уже существующий. Ingress уже стоял и соответствовал принятым стандартам. На новые решения еще не переехали.
2) Как сказано в резюме статьи: платформа не идеально и это прототип. Все сделано максимально просто. В том числе для упрощенной автоматизации. В моем варианте MLflow вообще ничего не знает об аутентификации/авторизации и не требует ручных шагов по выдаче прав.
Это позволяет дать представление DevOps инженерам об MLOps и даже локально провести эксперименты при наличии технической возможности.
3) Собственно по этой же причине (упрощения) все креды в юпитер проливаются одинаковые, и я даже не смотрел в сторону разных кредов для ноутбуков разных пользователей. Соображения, как это сделать у меня есть, и задача мне видится крайне занимательной!, но сейчас я временно безработный - поле для экспериментов отсутствует :-) Если не забуду - обязательно вернусь с обратной связью :-)
Видно, что вы статью прочитали внимательно, спасибо вам за это :-)
Все ваши вопросы справедливы и ответы на них - это скорее следующий шаг в развитии этой платформы, либо переход на более сложный стек.
Спасибо!

MLOps для DevOps-инженера: как построить платформу машинного обучения в закрытом контуре