George
Обидели его чем-то ?
Ваня
Был тут @nodekra (уже нет) который говорил что у него в винде всё работает. Может он что подскажет тебе.
Да, который раз уже) Смущает то, что у меня фронт на nuxt.js с хот релоадом работает почти также быстро как без докера. А это ведь прямая связь с volume, т. е., в теории, с шаред папками все ок.
Ваня
Попробовать нарушить "традиции" и пихнуть laravel и php в один контейнер))
LEXASOFT
Можно еще systemd и cron
LEXASOFT
Чо уж давайте весь линукс в докер затащим)
Igor
всем доброго вечеру!
есть скрипт, запускающий в образе докера некоторые действия, промежуточные результаты которых кэшируются в директорию Х
скрипт запускается на CI, работает долго, результаты кэширования хотелось бы сохранять между запусками - вот только интересующая директория находится сугубо внутри докера, соответственно CI её игнорирует
нашёл что можно при docker run передавать ему --mount на нужную директорию, но это влечёт редактирование скрипта, чего хотелось бы избежать в силу различных причин
можно ли как-то организовать "предварительный" запуск контейнера так, чтобы последующий docker run подхватывал уже запущенный инстанс с нужным маунтом?
Никита
баньте, на всякий
George
всем доброго вечеру!
есть скрипт, запускающий в образе докера некоторые действия, промежуточные результаты которых кэшируются в директорию Х
скрипт запускается на CI, работает долго, результаты кэширования хотелось бы сохранять между запусками - вот только интересующая директория находится сугубо внутри докера, соответственно CI её игнорирует
нашёл что можно при docker run передавать ему --mount на нужную директорию, но это влечёт редактирование скрипта, чего хотелось бы избежать в силу различных причин
можно ли как-то организовать "предварительный" запуск контейнера так, чтобы последующий docker run подхватывал уже запущенный инстанс с нужным маунтом?
Дай больше данных. Пока идея - подключать volume и кэшировать его между запусками ci
Igor
Дай больше данных. Пока идея - подключать volume и кэшировать его между запусками ci
скрипт сборки пакета, прилетающий по сути через pip и периодически обновляющийся; хотя потенциально изменение с mount можно попробовать оформить как PR
скрипт стягивает вначале одну кучу зависимостей, потом другую; процесс скачки может занимать позорно больше времени, чем сама сборка; зависимости меняются раз в столетие
ci - опенсорсный халявный travis, но потенциально пригодится и для локального jenkins
George
скрипт сборки пакета, прилетающий по сути через pip и периодически обновляющийся; хотя потенциально изменение с mount можно попробовать оформить как PR
скрипт стягивает вначале одну кучу зависимостей, потом другую; процесс скачки может занимать позорно больше времени, чем сама сборка; зависимости меняются раз в столетие
ci - опенсорсный халявный travis, но потенциально пригодится и для локального jenkins
Тревис - не знаю. Дженкинс - ок. И гитлаб-си ок
Igor
ок - в смысле volume подойдёт? про него достаточно инфы в доке докера, или есть рекомендация что-то отдельно раскурить?
George
Вариант сделать докер, в котором есть все необходимое для сборки. И билдить в нем
George
Докер обновлять согласно обновлению зависимостей раз в месяц. Можно автоматизированно
George
George
У меня в гитлаб си аналогичная задача решается именно так. Собирается служебный образ. В него маунтится исходный код, кэш зависимостей и поехали. В отдельном вольюме - артефакты
Igor
Вариант сделать докер, в котором есть все необходимое для сборки. И билдить в нем
думал о таком, но не совсем вариант - требуемых образов с десяток, они прилетают с докерхаба, а результаты кеширования могут отличаться для разных проектов - получается какой-то комбинаторный взрыв
можно конечно настроить отдельные задачки по автоматической модификации и публикации таких образов, но это уже как будто поворот не туда ¯\_(ツ)_/¯
George
думал о таком, но не совсем вариант - требуемых образов с десяток, они прилетают с докерхаба, а результаты кеширования могут отличаться для разных проектов - получается какой-то комбинаторный взрыв
можно конечно настроить отдельные задачки по автоматической модификации и публикации таких образов, но это уже как будто поворот не туда ¯\_(ツ)_/¯
Комбинаторный взрыв. Декартова матрица. Ну, да, жопа, но жить можно
Igor
//во избежание #xy_problem, задача - проверять проекты на куче компиляторов
George
Просто ты специфику не рассказал полностью , поэтому я фантазирую
Sun
https://github.com/codercom/code-server
Все уже потрогали?
Я полчаса бегаю по квартире и ору :)
Ильдар
думал о таком, но не совсем вариант - требуемых образов с десяток, они прилетают с докерхаба, а результаты кеширования могут отличаться для разных проектов - получается какой-то комбинаторный взрыв
можно конечно настроить отдельные задачки по автоматической модификации и публикации таких образов, но это уже как будто поворот не туда ¯\_(ツ)_/¯
А в чем вопрос тогда? "Как мне решить проблему ничего не меняя?"?
Ильдар
https://github.com/codercom/code-server
Все уже потрогали?
Я полчаса бегаю по квартире и ору :)
Типа "консоль не нужна"?
Denis
https://github.com/codercom/code-server
Все уже потрогали?
Я полчаса бегаю по квартире и ору :)
У гитлаба тоже своя web-ide есть)
Igor
А в чем вопрос тогда? "Как мне решить проблему ничего не меняя?"?
Тип того, да, "можно ли сделать так, чтобы docker run не запускал новый контейнер, а подключался к ужезапущенному"
Ильдар
Алиас настроить 🤔
Алексей
Всем привет. Подскажите новичку в докере пару моментов:
Стоит задача обеспечить переносимость проекта и окружения под различные OS(windows/linux), под различные версии OS(ubuntu 16/18) и под различное железо.
1) Подходит ли докер для обеспечения работы кроссплатформенно? (ubuntu/windows, стэк технологий - python+библиотеки, CUDA, CUDNN, и др. нативные либы). Т.е. я хочу создать один образ и запускать его как на linux, так и на Windows как можно меньшими усилиями.
2) В рамках только linux - как обеспечить работоспособность на разных версиях операционной системы?(например убунту 16 и 18). - сейчас я вижу так, что придется создавать отдельный образ с всей нативной частью с поддержкой конкретной версии, а это получается, что переиспользование образов будет только в очень малом количестве - а тогда какой профит)
3) Как работать с либами, собранными под конкретное железо?(соответственно нужно обеспечить работу на различном железе (GPU, CPU)).
Заранее спасибо
Jürgen
Докер имиджу все равно где запускаться
Алексей
Как я себе это вижу - в доке пишут, что windows не поддерживает контейниризацию - и тогда какие накладные расходы будут при работе с windows? и второе, я упаковал нативную библиотеку (SO-либы) в образ и хочу теперь запустить на windows их, где они не будут работать. соответственно докер мне сам с этим разберется и таки запустит ее?
George
Как я себе это вижу - в доке пишут, что windows не поддерживает контейниризацию - и тогда какие накладные расходы будут при работе с windows? и второе, я упаковал нативную библиотеку (SO-либы) в образ и хочу теперь запустить на windows их, где они не будут работать. соответственно докер мне сам с этим разберется и таки запустит ее?
Если это то, что я думаю, то у тебя докер внутри линукса под виндой
Jürgen
Как я себе это вижу - в доке пишут, что windows не поддерживает контейниризацию - и тогда какие накладные расходы будут при работе с windows? и второе, я упаковал нативную библиотеку (SO-либы) в образ и хочу теперь запустить на windows их, где они не будут работать. соответственно докер мне сам с этим разберется и таки запустит ее?
в винде можно запустить линукс контейнеры
Jürgen
https://github.com/NVIDIA/nvidia-docker/wiki/CUDA
Алексей
Хорошо - значит докер таки разберется с линукс образом и запустит его под виндой. Спасибо за ответ.
но дальше все еще нюансы - у некоторых нативных либ есть зависимости на версию ОС, соответственно как это будет разруливаться на windows?
Jürgen
Jürgen
Вы образ строите на базе какой-то ос, то есть за основу идет к примеру убунту и на него уже накатывается все что нужно
George
У тебя докер под линуксом только шарит ядро основной оси между контейнерами
Алексей
вооот, это полезное замечание - значит я могу ОС упаковать прямо в образ и запуститься где угодно? тогда все немного понятнее.
George
вооот, это полезное замечание - значит я могу ОС упаковать прямо в образ и запуститься где угодно? тогда все немного понятнее.
Нет. Ты не ос пакуешь, а ее среду
Jürgen
вооот, это полезное замечание - значит я могу ОС упаковать прямо в образ и запуститься где угодно? тогда все немного понятнее.
так оно и работает любой образ строится на базовом образе
Алексей
под средой понимается просто наличие стандартных библиотек ОС?
George
Повторюсь, что ядро общее. Внутри контейнера может вообще один исполняемый файл лежать (почитай про from scratch)
George
под средой понимается просто наличие стандартных библиотек ОС?
Да, и соответствующих настроек
George
Надо понять, что докер - это не виртуальная машина
Jürgen
Не путаем вм и контейнерезацию
Jürgen
Докер ближе в chroot или jail
George
Или zones, или lxc
Алексей
да, все материалы уже вычитаны, но все еще не понятно, если на windows на уровне ядра нет контейнеров - как он релизуется тогда?
Jürgen
да, все материалы уже вычитаны, но все еще не понятно, если на windows на уровне ядра нет контейнеров - как он релизуется тогда?
там виртуальная машина будет в кишках докера как и в маке
Jürgen
https://docs.docker.com/docker-for-windows/
Алексей
и тут вспоминаем "не надо путать ВМ с Контейнерами")
получается что на винде контейнеры запускаются под ВМ и мы получаем те же проблемы с ресурсами и скоростью, так?
Jürgen
Алексей
и больше с CPU и GPU - выделить полностью все мощности в ВМ
Sergey
в том и суть
Jürgen
и больше с CPU и GPU - выделить полностью все мощности в ВМ
там вм немного по другому используется нежеле классические
George
и тут вспоминаем "не надо путать ВМ с Контейнерами")
получается что на винде контейнеры запускаются под ВМ и мы получаем те же проблемы с ресурсами и скоростью, так?
Ну, в маке - да. Ты там в явном виде пишешь сколько рам и сколько диска дать вм
George
Если не хватило, то ой
Jürgen
Для начала бы документацию прочитать бы
Jürgen
Ну, в маке - да. Ты там в явном виде пишешь сколько рам и сколько диска дать вм
в винде так же там почти такой же тулл кит
Алексей
просто все выглядит, что докер пилили под linux - все шикарно все классно, а потом захотели ну хотя бы запустить хоть как то все на винде - и довольствуйтесь тем, что вышло.
Алексей
вопрос частично и сводится к тому, что если критично производительность поддержать, то стоит ли использовать удобство докера для кроссплатформенной работы, или на винде все будет очень плохо?
Jürgen
так и было
Jürgen
докер нативный только в линухе
Jürgen
George
Я докеры под Линукс с куда гонял. Но там неудобно. Нужно правильно ресурсы распределять
Илья
Сорри