На чем сейчас модно поднимать виртуальные машины?

И еще я с огромным удовольствием выслушаю рассказ, как вы боретесь с багами наподобие этого

Ну кулстори не получится, потому что мы так не используем докер. Управлять айпи руками - мазохизм какой-то. IP для контейнеров управляют оркестратор/регистратор/dns, поэтому с данный багом мы не сталкивались и не столкнемся.

docker info
w

Ты что-то конкретное узнать хочешь? Я могу ответить, только спроси :)

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

Ты читать умеешь? Утечка неймспейсов не зависит от способа работы с сетью. Оркестратор точно так же имеет все шансы привести хост-ноду в это состояние.

Ты что-то конкретное узнать хочешь? Я могу ответить, только спроси :)

Хочу цифры, которые покажут, как вы используете докер.

Как же горит у меня с вас, кажется ему, а разбираться не хочет, любой современный метод контейнеризации использует механизмы ядра (namespaces + cgroups), которые там и так есть.

а почему proxmox никто не советует? и где про kvm что-то толковое почитать можно. А то я на proxmox сижу)

proxmox хорош для маленьких кластеров, если нод больше чем пальцев - обычно берут cloudstack/openstack если используется гипервизор.

Или orchestrator_name (н-р kubernetes) для работы с контейнерами.

были книжки по kvm, гуглятся быстро.

lxd ?

В цитатник и помещать в шапку каждого хипстотопика по докеру :-)

Ретрограды всё что угодно сочтут достойным доводом, вне докера багов нет, а уже изученные концепции лучше новых. Странное отношение к инструментам.

Vagrant

вне докера багов нет

Баги есть везде. Их нужно исправлять.

уже изученные концепции лучше новых

Докер далеко не новая концепция. Это всего лишь набор костылей над малой частью функционала lxc.

Странное отношение к инструментам.

Нормальное скептическое отношение к попытке забивать болт крестовой отвёрткой.

Я первый раз про это слышу, хотя активно пользуюсь kvm'ом уже много лет.

Я вспомнил в чем проблема была. Проблема не с NAT. Я хотел иметь досуп к виртуалке от других сетевых устройств и от хоста в том числе. Это было во времена когда мне надо было быстро поднять виртуалку для небольших нужд, чтобы особо не заморачиваться, тогда я остановился на VirtualBox. Тема вот в чем: Если создавать не NAT устройство, а macvtap (привязанный к конкретному устройству) - то к виртуалке есть доступ от всех компов сети, кроме хоста. В виртуалбоксе с этим проще - тупо вибираешь бридж и имеешь полный доступ.

Ты прав.

kvm

Или тебе нужно что-то типа vzctl enter <VID> ? Насколько я знаю, это умеют только контейнеры. Могу и ошибаться.

Есть virsh console <domain>, но надо в виртуалке tty'ку под это дело настраивать.

docker хорош искоробочностью и минимумом траха. По крайней мере трах этот нереально меньше чем при настройке libvirt.

Короче, гораздо легче закостылить на своих быдлоскриптах qemu с kvm на пару сотен нод чем использовать libvirt. И под kvm нет ни одного открытого оркестратора, которым бы можно было бы пользоваться без мата и больших количеств алкоголя. Вот из этого хозяйства docker самый надёжный. Короче если тебе не кластер городить, бери или докер или виртуалбокс. Или пользуй qemu. Если количество виртуалок/контейнеров большое, лучше брать коммерческий софт.

ээ. лол.а какие проблемы у квм?

я мост создавал

MACVLAN AND MACVTAP

ээ, а зачем всё это?

А что тут конкретнее? При дефолтной установке KVM нельзя обратиться из хоста к гостям по гостевым айпишникам. Только если городить всякие там mavtap'ы и прочую дичь.


ещё раз. мост и проброс адресов за роутер(для ссх) нормально работал.

cgroups != chroot

lxc. или kvm тогда уж.

Докер далеко не новая концепция. Это всего лишь набор костылей над малой частью функционала lxc.

Речь не о докере, а о запуске в отдельном наборе namespace'ов одного процесса, вместо классического дерева.

Этот подход в контексте методологии 12 factor application является более чем разумным.

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

ээ, а зачем всё это?

Как минимум затем что «все это» делается в один клик в VMM