LINUX.ORG.RU

Ответ на: комментарий от t184256

Полная виртуализация или ничего.

Контейнеры - это НЕ виртуализация от слова - СОВСЕМ. Их, вообщет, надо еще и уметь применять - контейнеры эти. Как нормальный пример использования - web-hosting, когда кучи клиентов надо дать однотипное решение. А вот когда стадо яйцеголовых идиотов начинает сувать в контейнер свою «гениальную» программу, чтоб таким образом раздавать ее пользователям, под соусом «безопасности» и моды: «Мы круты, мы умеем контейнер» - это маразм и идиотизм.

DrRulez ()
Последнее исправление: DrRulez (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Или, как вариант, запускать контейнеры не от рута. В новости пишут, что можно получить рута, если воспользоваться уязвимостью, чтобы вылезти из контейнера. А что если взломщик получит только юзера с пустым home directory и access denied к другим директориям?

Тут согласен, но гложет червячок: а зачем тогда контейнер? :) sudo -u пустой-юзер, и вперёд. :)

dimgel ★★★ ()
Ответ на: комментарий от Desmond_Hume

А я не ругал, я чисто разговора ради, и честно признался что не юзал. :)

dimgel ★★★ ()
Ответ на: комментарий от Legioner

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

Интересно, в лялих-ядре виртуализация реализована проще чем контейнеризация? Хотя бы тупо по количеству строк кода на то и на другое. По ощущениям (точнее, по количеству нужных докеру CONFIG-опций), виртуализация должна быть проще. Так что возможный минус только в скорости.

dimgel ★★★ ()
Ответ на: комментарий от anonymous_sama

А я и не писал про lxc. Это самодеятельность модератора.

Miha ()
Ответ на: комментарий от DrRulez

Контейнеры - это НЕ виртуализация

Он этого и не говорил.

чтоб таким образом раздавать ее пользователям

Никто так не делает.

Как нормальный пример использования - web-hosting

Ничего нормального в этом нет, ты, похоже, совсем не врубаешься зачем нужны контейнеры.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

При нынешнем развитии выч. мощностей теряет всякий смысл, поскольку разница в производительности с настоящей vm (x86) составлет меньше 10%, при существенной потере в безопасности и прочих возможностей.

Miha ()
Ответ на: комментарий от Miha

Считаю практически идеальной реализацию контейнера в солярис в виде концепции «зона». В ней можно запустить полную систему линукс с ядром или соларис 8, а можно использовать т.н. «линуксятор» и использовать в зоне окружение RedHat 7 работающее на ядре соларис. При этом интерфейс настройки унифицирован через утилиты zonecfg и zoneadm.

Miha ()
Ответ на: комментарий от WitcherGeralt

Он этого и не говорил.

Он сказал «Или полная виртуализация, или ничего». Как я понимаю - ты специально вырезал это при цитировании, что «попередергивать».

Никто так не делает.

Даааа????? А вот у меня в практике таких примеров - масса. Иначе я не стал бы писать об этом. Куча даунов именно так и поступает.

И кстати. Че это нет ничего нормально в применении докера на веб-хостинге? А то такие твои голословные высказывания я смотрю весьма так совпадают с вырезанием неудобной тебе цитаты. Тут мне нравиться - я оставлю. А вот тут - нет, поэтому вырежу.

DrRulez ()
Ответ на: комментарий от Miha

По сути легкая vm

До этого момента было верно. Но если говорить конкретно про докер, то это — не вм ни в каком виде, вышеназванное — не цель, а средство. Главная фича Докера, благодаря которой он взлет, — удобная дистрибуция софта.

WitcherGeralt ★★ ()
Ответ на: комментарий от DrRulez

Как я понимаю

Не понимаешь, под виртуализацией он подразумевал, внезапно, виртуализацию, а не контейнеры, которым он её и противопоставляет.

Куча даунов именно так и поступает

Дауны много чего делают, ты лучше дай примеры чего-нибудь значимого, которое поставляется исключительно в виде контейнера и под представленным тобой «соусом». Dockerfile вместо тысячи слов и скриптов позволяет лаконично описать окружение, а Docker Hub — удачное следствие и не более того. Раздают обычно исходники, а контейнер — лишь один из сценариев сборки.

Че это нет ничего нормально в применении докера на веб-хостинге?

Потом, что контейнер это не образ виртуалки, а stateless окружение (в идеале).

WitcherGeralt ★★ ()
Ответ на: комментарий от Miha

В том, что это не вм. Оверхед есть только на io, а разворачивание мгновенное. И это гораздо проще и универсальней чем ansible.

WitcherGeralt ★★ ()
Ответ на: комментарий от Miha

Угу, интеловским багам расскажите. Да и потом когда у вас 10 серверов 10% это уже целый сервак, который греет атмосферу просто так вместо того чтобы что-то полезное делать

anonymous ()
Ответ на: комментарий от commagray

Ошибочное мнение. Отдельные возможности podman работаю без root, но не все.

anonymous ()

Странно читать агрессивные комменты от некоторых по поводу Докера. У вас так бомбит из-за того, что не осилили? Юзаю контейнер для локальной разработки, в нем же у меня в гитлабе в пайплайнах запускаются тесты, на сервере проект тоже разворачивается в контейнерах с помощью docker-compose. Просто? Да, но почему бы и нет. Везде одинаковое окружение - одни плюсы. Не понимаю, почему это кому-то может не нравиться.

Способов заюзать данную уязвимость при таком использовании Докера я не вижу вообще.

dimuska139 ★★ ()
Ответ на: комментарий от dimuska139

У вас так бомбит из-за того, что не осилили?

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

1. Он также замечательно облегчает жизнь малограмотным людям. Раньше они бездумно запускали скрипты копипастили инструкции из интернета, а теперь точно так же не задумываясь запускают образы из хаба докера.

2. Неизменяемый контейнер концептуально отличается от привычных серверов или виртуальных машин. Нужно думать, менять свои привычки, а этого никто не любит. А если этого не сделать и применять докер в привычной парадигме, то получаются проблемы вроде той, про которую написано в новости.

ugoday ★★★★★ ()
Ответ на: комментарий от Miha

Можно, конечно. Для хранения данных в контейнер монтируется внешнее хранилище.

Вообще, у докера контейнеры на самом деле не sateless, они могут сохранять состояние, но так делать не нужно.

WitcherGeralt ★★ ()
Ответ на: комментарий от Miha

Для баз данных следует прокидывать файловую систему хоста внутрь контейнера (обычный mount --bind, никакой магии). Или не прокидывать. Например, можно (и нужно) использовать один и тот же контейнер в проверочном и рабочем окружении, но в одном случае запускать его как-есть и бесплатно получать чистое развёртывание на каждом тесте, а в другом — монтировать файлы с данными.

ugoday ★★★★★ ()
Ответ на: комментарий от Legioner

Ух ты! Нашёлся добрый человек, который бесплатно соберёт мне «тонюсенькое ядрышко с каким-нибудь зарезанным init-ом»! Когда закончишь?

anonymous ()

All problems in computer science can be solved by another level of indirection

sartakov ()
Ответ на: комментарий от Legioner

Наверняка ведь можно собрать тонюсенькое ядрышко с каким-нибудь зарезанным init-ом, которое будет стартовать за миллисекунды и жрать мегабайт своей памяти.

Можно.

И в чём тогда будет преимущество контейнеров?

Давайте лучше поговорим в чём будет преимущество вашего «тонюсенького ядрышка»?

ugoday ★★★★★ ()
Ответ на: комментарий от dimuska139

Странно читать агрессивные комменты от некоторых по поводу <того, чего они не понимают>

Добро пожаловать на ЛОР!

theNamelessOne ★★★★★ ()
Ответ на: комментарий от dimuska139

на сервере проект тоже разворачивается в контейнерах с помощью docker-compose

Это разве не для локалхоста?

WitcherGeralt ★★ ()
Ответ на: комментарий от dimgel

а зачем тогда контейнер?

Ты не понимаешь, как это работает. В большинстве случаев нет вообще никакой необходимости в соответствии рута в контейнере руту на хосте. Докер это умеет, но по умолчанию не использует, предпочитая только сброс capabilities и seccomp + AppArmor. Нормальные реализации LXC (LXD, PCT) по умолчанию создают контейнеры «бесправными».

anonymous ()

Я тут убрал неуместное упоминание LXC. С тех пор, как докер от LXC полностью отклеился, в терминах хипстопрограммизма говоря, прошла уже геологическая эра.

shimon ★★★★★ ()
Ответ на: комментарий от ugoday

При отказе узла, контейнер умеет автоматически мигрировать на другой узел без остановки процессов внутри себя?

Miha ()
Ответ на: комментарий от Miha

Сам не пользовался, но на конференции про CRIU рассказывали очень убедительно.

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

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

Процесс свое состояние сохраняет, например пул открытых коннектов к бд и продолжает работу или перезапускается?

Miha ()
Ответ на: комментарий от WitcherGeralt

Вовсе нет. Современные разработчики пишут такое ПО, что его сразу кладут в контейнеры.

anonymous ()
Ответ на: комментарий от Miha

Процесс свое состояние сохраняет, например пул открытых коннектов к бд и продолжает работу

Да. Там внутри довольно сложная машинерия для этого.

Если просто перезапускать процесс на новом хосте, то это лучше в кубернетес идти.

ugoday ★★★★★ ()

Мне уже одно только название нравится - звучит как название музыкального альбома или группы. ЧСХ от докеров и прочего отказался года три как, хотя поначалу контйнероводство казалось выходом.

wst ★★★★ ()
Последнее исправление: wst (всего исправлений: 1)
Ответ на: комментарий от ugoday

в чём будет преимущество вашего «тонюсенького ядрышка»?

В том, что оно будет использовать более надёжную виртуализацию.

Legioner ★★★★★ ()
Ответ на: комментарий от praseodim

Похоже действительно нужна какая-то совсем другая архитектура и железа и ОС, чтобы дыры чуть не каждый день не вылазили.

Или совсем другие погромисты.

cipher ★★★★★ ()
Ответ на: комментарий от Miha

Кого ты собрался переносить и откуда, если у тебя сервак сдох? Память азотом жидким полить что-ли?

anonymous ()
Ответ на: комментарий от Miha

Живая миграция процессов не особо нужна. Девятки после запятой в availability достигаются не за счёт того, что ты что-то можешь перенести с трупа, а за счёт того, что если кто-то сдохнет по мере обработки твоего запросы, то ты это совсем не заметишь. Потому что есть десятки клонов, которые подхватят обработку (да, при этом надо систему дизайнить соответствующим образом, и контейнеры в этом сильно помогают)

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.