LINUX.ORG.RU

Вирутализация: когда не рекомендуюется использовать контейнеры, а рекомендуют VM

 , , , ,


4

3

Привет.

Практически во всех статьях про сравнение контейнеров и VM, всё сводится к тому, что контейнеры по всем параметрам лучше. И тогда не понятно когда и зачем использовать виртуалки.

В каких случаях противопоказано использовать контейнеры, а следует использовать именно виртуальные машины?

★★★★★

Последнее исправление: Kroz (всего исправлений: 1)

По своему небольшому опыту работы с docker и k8s скажу, что оно нужно только для очень больших проектов, где софтина разбира на несколько сервисов и эти сервисы надо поднимать и гасить динамически в зависимости от нагрузки. В остальных случаях проще esxi/proxmox поднять, будет и нормальный выбор ОС внутри виртуалки и не будет возни с пробросом устройств, когда надо vpn сервер внутри контейнера поднять.

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

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

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

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

docker и systemd несовместимы

А можно поподробней? В чём именно состоит несовместимость?

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

А что, в Docker hub «неполноценные» дистрибутивы предлагаются? В чем их неполноценность?

В «дистрибутивах», которые в Docker hub, нет ядра.

И еще я не знаю как там с GUI. По логике, если у тебя иксы, то wayland ты вряд ли в контейнере запустишь. Может ещё какие-то оганичения есть, тут пусть знатоки прокомментируют.

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

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

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

Чисто теоретически можно на хосте организовать, например, одну виртуалку, в которой гонять обычные контейнеры с софтом, а в другой виртуалке особо ценные приложения, к примеру СУБД с важными данными или содержащие ценные ключи, которые не должны утечь. Я бы порекомендовал для такого юз-кейса вообще разные физические машины, желательно с разными сетями или хотя бы вланами, но если такой возможности нет, а безопасность хочется усилить, то это один из вариантов. Хотя, думаю, мало кто будет таким заморачиваться.

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

«то wayland ты вряд ли в контейнере запустишь»

Xwayland для 20.04 есть остальные посасывают пока к архитектору не обратятся сделать для версии libc выше , так что запустить не проблема если ты теоретик-кукаретик то не пиши того чего не знаешь ок? Если твой контейнер этот сайт и ты за пределы не выходишь и веришь в то что здесь на плетут то не повторяй за ними как попугай что бы не быть таковым , для начала надо попробовать , а не рассуждать и рассусоливать наполняя этот сайт какими то своими выдуманными теориями.

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

Че не понятного человек запустил докерную убунту на телефоне и выдал потому что пятая точка улетучилась в небо

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

Так, что при нормальной архитектуре кода для решения вопросов автоматизации и масштабирования не требуется прятать софт в коробки. Прячут его там, где «денег нет, времени нет, сделайте тяп-ляп как-нить авось заведётся».

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

Мне кажется, что «проще» здесь исходит из того, что виртуалки мы уже знаем, практически все с ними уже так или иначе имели дело. А с контейнерами пока опыта мало. Если убрать это фактор, то ИМХО контейнеры проще.

не будет возни с пробросом устройств

Мне казалось что возни с пробросом устройств в виртуалке не меньше чем в контейнерах. Разве нет?

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

Юз-кейсы действительно нетипичные, но всё равно запишем в копилку. Спасибо.

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

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

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

Так, что при нормальной архитектуре кода для решения вопросов автоматизации и масштабирования не требуется прятать софт в коробки. Прячут его там, где «денег нет, времени нет, сделайте тяп-ляп как-нить авось заведётся».

Уже давно весь просвещённый мир переехал на докеры-кубернетусы. Можно называть всех дураками, но реальность от этого не изменится. Мне тоже нравится идея собирать свой софт в rpm и на сервере ставить из частного репозитория, но убунтята не поймут. А я не пойму dpkg. А так докер-шмокер, всё как-то работает и ладно.

Хотя можно rpm ставить в докер. Кек.

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

Xwayland для 20.04

Погоди, ты хочешь сказать, что я могу запустить два контейнера, в одном поднять X11 сервер, во втором wayland и всё это на AWS (чтобы гарантировать что на хосте X11/wayland нет)? Как это будет работать. Они ж за видяху должны подраться?

И в третьем контейнера я могу запустить GUI приложуху для иксов или Wayland?

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

Нет запускай xwayland потому что он иксовый вариант и wine со steam уже за счет него работают работают , я не вижу смысла в том что ты хочешь вот так вот сделать ? Это что не так с головой и зачем тебе это? Типа я хочу два руля и пол машины будет электрической , а половина бензиновой и я обеими рулями типа буду рулить

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

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

Что такое «изоляция» в твоём понимании?

Фрмально namespaces считаются изоляцией: https://en.wikipedia.org/wiki/Linux_namespaces

В тоже время в виртуальных машинах иногда тоже можно одной VM зааффектить другую.

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

Use Case: хочу протестировать приложуху на Wayland и на X11, сравнить. Я могу это в контейнерах сделать, или только через виртуалки?

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

Изоляция от недоверенного кода = свойство, при котором от запуска произвольного недоверенного кода в одном Х, в другом Х максимум просядет производительность.

«Изоляция» просто так = любое разграничение воображаемой линией в голове говорящего, никаких конкретных технических требований не накладывающее.

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

Помойки переехали. Их много, да.

Касательно «убунтят». Во-первых, можно дальше продолжить: виндузятники не поймут твой линукс-софт и в докере тоже (если что, докер типа для винды существует, но на самом деле это виртуалка с линуксом и линукс-докером в ней). Во-вторых, докер это не часть убунты, если просишь поставить его - с тем же успехом можно попросить поставить rpm или любой другой пакетный менеджер. В-третьих, упаковкой софта в пакет может заниматься не разработчик, упаковать в .rpm и в .deb думаю примерно одинаково по сложности. В-четвёртых, какие ещё убунтята? Если у тебя на одном сервере стоит Debian, на втором - CentOS, на третьем (упаси боже) Ubuntu, просто потому что их ставили разные админы с разными предпочтениями - то это уже помойка. ОС должна быть одна (и везде одной версии), по сути это часть приложения, хотя и не сильно в него интегрированная.

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

Мне кажется, что «проще» здесь исходит из того, что виртуалки мы уже знаем, практически все с ними уже так или иначе имели дело. А с контейнерами пока опыта мало. Если убрать это фактор, то ИМХО контейнеры проще

IMHO контейнеры и виртуальные машины - это инструменты под разные задачи.

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

Изоляция от недоверенного кода = свойство, при котором от запуска произвольного недоверенного кода в одном Х, в другом Х максимум просядет производительность.

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

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

Ты это можешь вообще без ничего сделать.

Не всегда, поскольку мне могут потребоваться спец. версии зависимостей. Да и помойку из системы не хотелось бы делать: всё-таки best practice - огороженные окружения для целей тестирования.

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

Речь о программистах, какие серверы. У одного убунта, у другого убунта, у третьего убунта, один я в федоре стою красивый. А на сервере вообще центось древняя. И у всех должны работать все десятки микросервисов, каждый из которых тащит постгрес рандомной версии (в том числе и всякие 13-е), монги и прочие достижения современного IT.

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

У одного убунта, у другого убунта, у третьего убунта, один я в федоре стою красивый

Ну пусть кодят на убунте, а упаковкой в пакет (раз сервер CentOS - то в rpm) должен заниматься скрипт, компилирующий из репозитория, после чего на серверах можно ввести yum update, сначала на тестовом, потом, после прохождения тестирования, на проде.

каждый из которых тащит постгрес рандомной версии (в том числе и всякие 13-е), монги и прочие достижения современного IT.

Ну помойка и есть, такую и правда хочется спрятать с глаз.

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

Теоретически это достижимо средствами любого *nix ядра, с древних времён. Расстановкой правильных owner/group/mode на файлы и процессы и квотами на ресурсы.

Практически - регулярно находятся дыры, в том числе и в гипервизорах виртуалок. Так что спасёт только железная изоляция, причём желательно с электромагнитными экранами, а то некоторые научились уже стримить утечки данных по радио шинами материнки.

firkax ★★★★★
()

Смотри: ты когда-нибудь задумывался почему можно загрузить только одну операционную систему, а не несколько сразу? - BIOS, Загрузчик, Линукс или Винду… Вообщем проц может запускать только одно приложение и это приложения - Операционная система. Все остальные приложения - это процессы твоей операционки. Ну как в интерпретаторе с зелеными потоками, есть основной цикл и в нем контекст потоков переключается, выполняются разные опкоды… Ну так у тебя и операционка по очереди выполняет, например, по 10 инструкций каждого процесса… Там, конечно, все сложнее, процессоры стали многоядерными с реальной многозадачностью, но в приницпе оно верно… Так вот дальше с виртуалками. Твоя запущенная виртуалка - это всего лишь процесс, причем процесс этот будет с существенным оверхедом, потому как запускается ядро, оно там рулит своими процессами и это все рулится хостом. Оверхед этот где-то в виде большего расхода процессорного времени на 20-40%. С докером все несколько иначе, так как контейнеры используют ядро хоста, те это обычные процессы, а не эмуляция. Если ты когда-либо, например, при установке арча делала чрут чтобы потом обновить пакеты… ну все так же и работает. Оверхед в этом случае маленький. Все накладные расходы по сути в сотне другой мегабайт (в среднем около 30-60 без учета самого приложения, которое может жрать память гигами), загружаемых в оперативку. Тут и плюсы докера нарисовываются: ты можешь иметь раличные версии пакетов в системе, каких-то либ и тп (но не ядра). Какой вывод? - Докер использовать предпочтительнее всегда, а виртуалки нужны только чтобы запускать бздю илт венду

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

а кубер - это уже кластер. у тебя мастер-нода и куча рабов (я это слово намеренно использую чтобы оскорбить негров и 14-летних лесбиянок). что оно дает? - ты можешь запускать кучу копий своего приложения, кубер сам распределит между ними нагрузку (речь про вебню)… короче, если у тебя один сервак, то тебе про это можно и не думать

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

так-то балансировку можно и через nginx делать, но с кубером кошернее… и если знаешь его можно просить зарплату 300.000 в месяц будучи полным днищем и типичным нытиком-смузихлебом на самокате (простите, но если я не буду изливать свою желчь, то умру от собственной отксичности)

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

Тебе просто нужен неимпотентный менеджер пакетов, это другое.

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

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

Расстановкой правильных owner/group/mode на файлы и процессы и квотами на ресурсы.

Еще бывает нужно чтобы каждое приложение видело только свою таблицу маршрутизации, и ядро тоже так видело для этого приложения. И чтобы приложение был ограничено куском файловой системы - даже chroot это не обеспечивает (их него легко выбраться). Как раз это пример сценария для namespaces.

Вот по-русски как выбираться из chroot’а: https://www.youtube.com/watch?v=6XlqSfOEiGU

Практически - регулярно находятся дыры, в том числе и в гипервизорах виртуалок. Так что спасёт только железная изоляция, причём желательно с электромагнитными экранами, а то некоторые научились уже стримить утечки данных по радио шинами материнки.

Дыры - да, согласен. В контейнеризации намного больше векторов атаки. Но это важно только если ты систему для Пентагона строишь. Обычным приложениям уровня безопасности контейнеров обычно достаточно.

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

Спасибо за ответ.

Но теорию я и сам могу рассказать. Уже несколько недель изучаю эту тему.

Моя проблема в том, что практически везде ограничиваются поясненями принипа работы, концепций и т. п. А вот конкретных примеров не дают.

Я благодарен каждому комменту, но то, что я действтиельно ищу, это конктерные примеры, когда бы мне следовало отговаривать команду/клиента от использовавания контейнеров в пользу виртуалок.

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

Оверхед этот где-то в виде большего расхода процессорного времени на 20-40%

около 3% оверхед по процессору (при использовании KVM/QEMU)
а вот с дисковым IO всё сильно печальнее бывает.

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

Прячут его там, где «денег нет, времени нет, сделайте тяп-ляп как-нить авось заведётся».

Абсолютно точно сформулировано. Все эти контейнеры появились не как средство повышения производительности труда и скорости работы софта, а как инструмент для уменьшения финансовых затрат сраных капиталистов. Весь этот весёлый сраный паровозик выезжает только за счёт того, что железо выстрелило и позволяет жевать говнокод с примлемой скоростью. Но история, как известно, идёт по спирали, все эти ваши микросервисы в докерах внедряют и админят дорогостоящие эникеи, гордо зовущие себя drvops-ами, так вот эти жалкие руконогие приматы, совместно с безграмотными разрабами, не знающими таблицу умножения, доведут таки идею до абсурда и уродливая конструкция из дерьма и палок рухнет, погребя под собой её адептов. И снова настанет время чистого кода и уважения к ресурсам железа. Очень хорошо, что в полупроводниковой отрасли намечается серьёзный дефицит, железо должно подорожать в 10 раз, а лучше больше, и это только к лучшему.

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

конктерные примеры, когда бы мне следовало отговаривать команду/клиента от использовавания контейнеров в пользу виртуалок.

почтовый сервер, скажем.

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

Вот по-русски как выбираться из chroot’а: https://www.youtube.com/watch?v=6XlqSfOEiGU

Ааааааа!

«эксплоит»

«получаем права суперпользователя если у нас их нет» (c)

это про setuid(0) там так говорят

Не обязательно было целое 18-минутное видео кидать ради такого. Это не эксплоит, это общеизвестный факт, описанный в man 2 chroot больше 20 лет назад. Разумеется, никакого «если нет прав суперпользователя» там не прокатит, чтобы такое сделать надо быть рутом (и где-то кажется в почтовой рассылке разработки ядра писали по сути «да, руту можно всё, в том числе выходить из чрута, тут нечего исправлять»).

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

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

Вот в FreeBSD сделано намного удобнее: всего одним системным вызовом (jail_set, и никакого доп. софта, никаких сложных настроек итд) можно оказаться в «контейнере» с chroot (защищённым от рута тоже), ограниченном заданными айпи-адресами интерфейсов сетью и с запрещёнными опасными syscall’ами.

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

ещё бы знать, как заставить виртуальную винду видеть все 12 ядер и 24 потока

annerleen ★★★★☆
()
Ответ на: удаленный комментарий

Ты на версии 7z посмотри. К тому же, версия под линух - неофициальная.

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

почтовый сервер

Почему?

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

Как то мне коллега демонстировал на примере теста гилева что 1с под proxmox тормозит больше.

сначала он сравнивал боевой сервер с пустым (с одной базой), потом сравнивал проксмокс на hdd против вмвари на ssd, а потом показывал как интол рвет амд.

пока я расковал все это он неделю жужал начальству что проксмокс говно

хорошо что я был настойчив

признания своей нетрадиционности с его стороны не последовало

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

«эксплоит»

Дело не в эксплоите, а в том, что chroot легко обходится. И вообще, chroot это не изоляция, точнее слишком примитивная изоляция, и оно не для этого был сделано.

Свою таблицу маршрутизации - это что-то очень специфичное.

Почему же? У тебя есть база данных, к которой нужен доступ только с определенных приложений, при том они на разных нодах. Можно, конечно, наворотить правил в iptables. Но проще создать оверлейную сеть, а всё что касается физической сети и выхода в Интернет - маршруты, интерфейсы - просто сделать чтобы приложуха их не видела. Это просто и удобно.

Kroz ★★★★★
() автор топика
Последнее исправление: Kroz (всего исправлений: 2)
Ответ на: комментарий от tz4678

+ @annerleen

Ребята, вы не договоритесь. Потому что есть 100500 ручек в виртуализации, начиная от поддержки железа (и включена ли она в BIOS), использовании мезанизмов паравиртуализации, как используется Binary Translation и т. п. Пока эти детали не прояснить, нельзя сравнивать apple-to-apple.

Вот лучшая на мойвзгляд (хотя и не совсем точная) статья на эту тему. Рекомендую к прочтению.

https://blogs.oracle.com/ravello/nested-virtualization-with-binary-translation

Да будет мир.

Kroz ★★★★★
() автор топика
Последнее исправление: Kroz (всего исправлений: 2)
Ответ на: комментарий от firkax

почему ты решил, что код в «коробке» спрятан?

Я тебе рассказываю совсем о другом, но у тебя какая-то своя волна, ты доказываешь мне вообще что-то другое. Так что предлагаю закончить.

constin ★★★★
()

Здесь есть донные админы с зачаточными навыками написания хелловордов на баше и питоне, кои девопсами себя именуют?

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

Это просто и удобно.

Это сложно и избыточно. И маршруты тут всё равно ни при чём, речь про ограничение приложения неким айпи-адресом (в данном случае - адресом оверлейной сети).

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