Здравствуйте, Masterspline, Вы писали:

M>RPATH вполне себе используется. Как и статика. Но ты, давай, предложи алгоритм, как "нужные библиотеки просто класть в папку рядом с программой". Руками их туда копировать? И как узнать, какие надо, а какие нет. И чтобы надежно, т.е. нужные библиотеки находились в этой папке и работали как надо. Внезапно обнаружишь, что сделать это надежно не так просто. Проще собрать статикой, а еще проще в docker запаковать.

А как у тебя докер узнает, какие пихать в контейнер, а какие нет? Вот так же.

Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, Masterspline, Вы писали:

M>>RPATH вполне себе используется. Как и статика. Но ты, давай, предложи алгоритм, как "нужные библиотеки просто класть в папку рядом с программой". Руками их туда копировать? И как узнать, какие надо, а какие нет. И чтобы надежно, т.е. нужные библиотеки находились в этой папке и работали как надо. Внезапно обнаружишь, что сделать это надежно не так просто. Проще собрать статикой, а еще проще в docker запаковать.

Ops>А как у тебя докер узнает, какие пихать в контейнер, а какие нет? Вот так же.

Docker Image собирается из минимального базового image.

У разработчика же уже нашпигованная система со всякими библиотеками, *make и прочим добром. Можно запросто пропустить нужный шаг

Таким образом, можно вчистую выделить только то, что нужно для конечного приложения. И разбить это на 2 стадии для multi stage image. На компилляции одни библиотеки (somelib-dev), на рантайме же можно другой, не dev. Собираешь один раз и потом пользуешь. Не возвращаясь снова и снова к уже сделанному. Пример моего Docker image для FreeSwitch — телефония для личного пользования

То есть, сама сборка это уже чистящий процесс, скрипт и "документация" на сборку в одном флаконе. Который потом не надо воспроизводить снова и снова

Здравствуйте, Sharov, Вы писали:

S>Здравтсвуйте.

S>Вроде не обсуждалась данная тема. Вот регулярно во всяческих дискуссия на ods, где начинающие ds всюду где попало лепят docker. Т.е. у них на выходе
S>простенькая программа\сервис в кол-ве одной штуки и тут же к нему цепляется docker. А какой в этом смысл? Т.е. если нам нужна инфра-ра k8, ну ок.
S>Но стоит ли ради масштабирования и управления одним процессом завязываться на такие вещи?

S>Нужно ли для одного процесса\сервиса использовать докер, или он нужен для изоляции >=2 сервисов в одном докере?

Добавлю к вышенаписанному: когда нужно запустить какую-то программу, а захламлять компьютер не хочется. В том числе, чтобы без конфликтов версий запустить эту же, но обновленную, программу в будущем

Ведь удалив контейнер, image и volumes от программы точно ничего не остается

Пример: для семейного видео иногда пережимаю с ffmpeg. Он здоровый, с кучей зависимостей и доп библиотек

Запускаешь контейнер, давая доступ только к файлам на пережатие (host mount).

В результате, обработав видео, все лишнее уходит в небытие, включая логи, temp files, всякий мусор.

Обновил image — я точно знаю что новый ffmpeg не подцепит ни одной старой библиотеки

Здравствуйте, vsb, Вы писали:

vsb>Причём Linux даже гарантирует стабильный ABI ядра, т.е. можно статически линковать libc. По-моему это единственная ОС, которая даёт такие гарантии. Что Windows, что macOS, что FreeBSD таких гарантий не дают (т.е. нужно динамически линковаться с их libc или аналогами).

Ште?

Здравствуйте, vsb, Вы писали:

vsb>Причём Linux даже гарантирует стабильный ABI ядра, т.е. можно статически линковать libc. По-моему это единственная ОС, которая даёт такие гарантии.
vsb>Что Windows, что macOS, что FreeBSD таких гарантий не дают (т.е. нужно динамически линковаться с их libc или аналогами).
В винде нет никаких libc Есть WinAPI и он стабилен.

Здравствуйте, CreatorCray, Вы писали:

vsb>>Причём Linux даже гарантирует стабильный ABI ядра, т.е. можно статически линковать libc. По-моему это единственная ОС, которая даёт такие гарантии.
vsb>>Что Windows, что macOS, что FreeBSD таких гарантий не дают (т.е. нужно динамически линковаться с их libc или аналогами).
CC>В винде нет никаких libc Есть WinAPI и он стабилен.

Ну я и написал "аналогами". WinAPI стабилен, но это требует динамически загружать user32.dll и аналоги. Ты не можешь написать программу для Windows, которая будет дёргать системные вызовы инструкцией syscall и работать на всех виндах. А для линукса можешь.

Здравствуйте, Ops, Вы писали:

Ops>А как у тебя докер узнает, какие пихать в контейнер, а какие нет? Вот так же.
Ты сам собираешь что тебе нужно.

Вообще при желании можно в отдельной папке создать окружение и запустить в чруте что надо.
Но это надо будет руками делать.
А если это надо отдать кому-то?
А если это надо делать много раз?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Буравчик, Вы писали:


Б>>Стоит ради упрощение развертывания и поддержки (обновления контейнера). Даже в простом DS-проекте куча зависимостей, в том числе к библиотекам на C.
Б>>С докером этими зависимостями занимается разработчик контейнера, а не конечный пользователь.

S>Если ds это data science, то я как раз писал под впечатлением от дискуссий в ods. Вы все что написали выше вполне решается venv или conda. Зачем тут докер? Разве что для дистрибуции...

Нет, тут я двумя руками за докер.
Не познав всю боль компиляции новой версии TF под новую CUDA с bazel вместо CMake на виндовой машине, сложно понять, зачем этот докер вообще нужен.

M>>RPATH вполне себе используется. Как и статика. Но ты, давай, предложи алгоритм, как "нужные библиотеки просто класть в папку рядом с программой". Руками их туда копировать? И как узнать, какие надо, а какие нет. И чтобы надежно, т.е. нужные библиотеки находились в этой папке и работали как надо. Внезапно обнаружишь, что сделать это надежно не так просто. Проще собрать статикой, а еще проще в docker запаковать.

Ops>А как у тебя докер узнает, какие пихать в контейнер, а какие нет? Вот так же.

В докере у тебя будет все, включая libc. А в папку нужно сложить только прямые зависимости и зависимости зависимостей... исключая libc.

Твой ответ свидетельствует, что ты плаваешь в вопросе, потому твои ответы такие поверхностные. Дилетант ты, короче.

Здравствуйте, vsb, Вы писали:

vsb>Ты не можешь написать программу для Windows, которая будет дёргать системные вызовы инструкцией syscall и работать на всех виндах.
А нафига?

Здравствуйте, CreatorCray, Вы писали:

vsb>>Ты не можешь написать программу для Windows, которая будет дёргать системные вызовы инструкцией syscall и работать на всех виндах.
CC>А нафига?

Ну например чтобы делать полностью статический бинарник. Нафига это делать, я точно не знаю, но товарищи из Go долго пытались это делать для macOs, в конце концов правда стали грузить libc. Предполагаю, что без поддержки динамических библиотек проще делать компилятор.

Здравствуйте, Sharov, Вы писали:

S>Вроде не обсуждалась данная тема. Вот регулярно во всяческих дискуссия на ods, где начинающие ds всюду где попало лепят docker. Т.е. у них на выходе
S>простенькая программа\сервис в кол-ве одной штуки и тут же к нему цепляется docker. А какой в этом смысл? Т.е. если нам нужна инфра-ра k8, ну ок.
S>Но стоит ли ради масштабирования и управления одним процессом завязываться на такие вещи?
S>Нужно ли для одного процесса\сервиса использовать докер, или он нужен для изоляции >=2 сервисов в одном докере?
Кстати. Ещё не упомянули, что у докера есть layers. При правильном использовании позволяет значительно экономить место, т.к. одинаковые layers шарятся между разными images.
Создаём layer-ы со всеми зависимостями и layer собственно с самой программой. Скажем, с той же java у тебя есть JDK на 300мб, зависимости на 100мб, и программа на 10мб. Если у тебя 10 версий твоей программы, то в докере это будет в сумме 300+100+10*10=500мб. А если собирать по-старинке, то (300+100+10)*10=4100мб.
Та же петрушка со статически линкованными программами натива.

·>Кстати. Ещё не упомянули, что у докера есть layers. При правильном использовании позволяет значительно экономить место, т.к. одинаковые layers шарятся между разными images.
·>Создаём layer-ы со всеми зависимостями и layer собственно с самой программой. Скажем, с той же java у тебя есть JDK на 300мб, зависимости на 100мб, и программа на 10мб. Если у тебя 10 версий твоей программы, то в докере это будет в сумме 300+100+10*10=500мб. А если собирать по-старинке, то (300+100+10)*10=4100мб.
·>Та же петрушка со статически линкованными программами натива.

Ой. Тут нужно быть очень грамотным и замороченным. После обновления слоя с JDK, придется обновить все образы, использующие этот JDK. Т.е. нужна автоматизация, а это не тот случай, когда собирают образ для работы, чтобы там были все нужные библиотеки нужных версий (т.е. docker как chroot + использование docker, как способа распространения пакетов).

И другая неприятность. Каждый слой создает накладные расходы на файловой системе, т.е. если нужно обратиться к верхнему слою — это обычная операция на файловой системе + X накладных расходов. Для нижнего слоя это уже + 3*X. Так что скорее commit после apt upgrade более популярен, чем общие слои. Хотя, это возможно, зависит от файловой системы.

Здравствуйте, Sharov, Вы писали:

S>Нужно ли для одного процесса\сервиса использовать докер, или он нужен для изоляции >=2 сервисов в одном докере?

Нужно. Докер — очень удобное средство деплоймента. Настолько удобное что его используют даже там где не нужны масштабирование/управление/изоляция и прочее.
Учитывая что накладных расходов кроме места на диске от докера практически нет (для случая линукс на линуксе, конечно), не вижу причин не пихать докер везде где только можно.

Здравствуйте, Masterspline, Вы писали:

M>·>Кстати. Ещё не упомянули, что у докера есть layers. При правильном использовании позволяет значительно экономить место, т.к. одинаковые layers шарятся между разными images.
M>·>Создаём layer-ы со всеми зависимостями и layer собственно с самой программой. Скажем, с той же java у тебя есть JDK на 300мб, зависимости на 100мб, и программа на 10мб. Если у тебя 10 версий твоей программы, то в докере это будет в сумме 300+100+10*10=500мб. А если собирать по-старинке, то (300+100+10)*10=4100мб.
M>·>Та же петрушка со статически линкованными программами натива.
M>Ой. Тут нужно быть очень грамотным и замороченным. После обновления слоя с JDK, придется обновить все образы, использующие этот JDK. Т.е. нужна автоматизация, а это не тот случай, когда собирают образ для работы, чтобы там были все нужные библиотеки нужных версий (т.е. docker как chroot + использование docker, как способа распространения пакетов).
А какая альтернатива-то? Так же придётся обновлять все .zip (или чего ещё) дистрибутивы с новой версией JDK. Или вообще классика — емыл: "ребята, мы тут на новую версию JDK переходим, скачайте, обновитесь там у себя, не забудьте".

M>И другая неприятность. Каждый слой создает накладные расходы на файловой системе, т.е. если нужно обратиться к верхнему слою — это обычная операция на файловой системе + X накладных расходов. Для нижнего слоя это уже + 3*X. Так что скорее commit после apt upgrade более популярен, чем общие слои. Хотя, это возможно, зависит от файловой системы.
Возможно, не сталкивался с заметным проседанием производительности.

M>>Ой. Тут нужно быть очень грамотным и замороченным. После обновления слоя с JDK, придется обновить все образы, использующие этот JDK. Т.е. нужна автоматизация, а это не тот случай, когда собирают образ для работы, чтобы там были все нужные библиотеки нужных версий (т.е. docker как chroot + использование docker, как способа распространения пакетов).
·>А какая альтернатива-то? Так же придётся обновлять все .zip (или чего ещё) дистрибутивы с новой версией JDK. Или вообще классика — емыл: "ребята, мы тут на новую версию JDK переходим, скачайте, обновитесь там у себя, не забудьте".

А я и не утверждаю, что docker плох для распространения пакетов. Как раз наоборот. Docker — удобный инструмент для распространения пакетов и это одна из причин его популярности.

В предыдущем сообщении я утверждал, что для пользования слоями нужно достаточно хорошо разбираться в docker, довольно сильно все автоматизировать, а также серьезная потребность в такой организации. Такое бывает, но не у людей, для которых docker — способ распространения 1-2 пакетов.

Здравствуйте, Masterspline, Вы писали:

M>>>Ой. Тут нужно быть очень грамотным и замороченным. После обновления слоя с JDK, придется обновить все образы, использующие этот JDK. Т.е. нужна автоматизация, а это не тот случай, когда собирают образ для работы, чтобы там были все нужные библиотеки нужных версий (т.е. docker как chroot + использование docker, как способа распространения пакетов).
M>·>А какая альтернатива-то? Так же придётся обновлять все .zip (или чего ещё) дистрибутивы с новой версией JDK. Или вообще классика — емыл: "ребята, мы тут на новую версию JDK переходим, скачайте, обновитесь там у себя, не забудьте".
M>А я и не утверждаю, что docker плох для распространения пакетов. Как раз наоборот. Docker — удобный инструмент для распространения пакетов и это одна из причин его популярности.
Ну да, по сути это следующий шаг за статической линковкой, тарболлами и self-contained unzip-дистрибутивами.

M>В предыдущем сообщении я утверждал, что для пользования слоями нужно достаточно хорошо разбираться в docker, довольно сильно все автоматизировать, а также серьезная потребность в такой организации. Такое бывает, но не у людей, для которых docker — способ распространения 1-2 пакетов.
Фигня, не rocket science. Это всё вопрос наличия одного грамотного человека в команде или хороших тулзов. Скажем, jib умеет билдить любое типичное java-приложение, всё как надо, по слоям, достаточно просто воткнуть плагин в билд-проект.

Здравствуйте, Ops, Вы писали:

3V>>https://en.wikipedia.org/wiki/Rpath#GNU_ld.so

Ops>Ты можешь словами пояснить? Оно не умеет искать рядом с программой? Так в чем проблема научить? А если умеет, то почему так не делать?

Потому что ты обычно не хочешь менять локацию библиотек, что может означать пересборку или использования всяких нетривиальных штук вроде patchelf, в какой-нибудь анаконде.

Здравствуйте, novitk, Вы писали:

N>Потому что ты обычно не хочешь менять локацию библиотек, что может означать пересборку или использования всяких нетривиальных штук вроде patchelf, в какой-нибудь анаконде.

Ну т.е. докер нужен только для того софта, где криворукие разработчики захардкодили абсолютные пути, вместо того чтобы брать их из переменных окружения или сделать относительными?

Здравствуйте, Ops, Вы писали:

Ops>Ну т.е. докер нужен только для того софта, где криворукие разработчики захардкодили абсолютные пути, вместо того чтобы брать их из переменных окружения или сделать относительными?

Это нужно для любого софта который обязан "просто работать". Без дополнительной настройки и тестирования именно под вот эту систему с тремя с половиной подключенными репозиториями и вон той библиотекой собранной из исходников. Софт поставляеться сразу вместе с операционной системой которая обновляеться разработчиком по мере необходимости. Бонусом идет легкое развернывание и обновление однострочной коммандой.