Эмуляция сети в учебных целях? docker container?

Нафига на слабом железе docker?

Освой ip netns. Это наименее ресурсоёмкое решение.

https://www.devopsschool.com/blog/top-10-network-emulators/

Зачем тебе для этих целей «готовый docker container»?

Изучение сетей я рекомендую начать с освоения того, что такое docker container и почему он тебе в данном случае никак не поможет. Я серьёзно.

Освой ip netns. Это наименее ресурсоёмкое решение.

Боюсь что с учетом вопроса в топике, это будет для ТС более трудоемкое решение.

Вспоминаю 20 лет назад в универе писали эмуляцию сети ну так, понарошку. Как это было глупо наверное. А надо было на самом деле настраивать виртуальные сети с лимитом трафика на каждом сегменте и даже эмулировать потери и реордеринг

Так что респект ТС-у что будет занимать студентов не хренью какой то а реально полезной возней с путь и виртуальной но настоящей сетью!

docker реализует «набор сервисов» в заданном окружении.

Он сам создаёт свою сеть и средствами nftables/iptables обеспечивает сетевой доступ к этим сервисам.

IMHO изучения маршрутизации, мостов, iptables / nftables, NAT там принципиально невозможно.

Кто из них работает на «третьей малинке с одним гигом оперативки» ?

Он сам создаёт свою сеть

верно

и средствами nftables/iptables обеспечивает сетевой доступ к этим сервисам.

это отключаемо cat /etc/docker/daemon.json:

{
  "ipv6": false,
  "iptables": false,

IMHO изучения маршрутизации, мостов, iptables / nftables, NAT там принципиально невозможно.

Возможно, очень удобно настраивать iptables с помощью скрипта Firehol:

define_service ssh2 "tcp/xxx tcp/yyy";
define_service mosh "udp/60000:60010";

version 6

HOME_IP="xxx yyy zzz";

# Accept all client traffic on any interface
interface eth0 INET;
        protection strong;
        client all accept;
#       server4 mosh accept;
#       server4 all accept src "$HOME_IP";
        server4 "ssh2 mosh ping" accept src "$HOME_IP";
        server4 "http https" accept;

C_ifaces="docker0 vwbr0 lxcbr0 lxdbr0 br-+ veth+";

interface "$C_ifaces" CONTs;
        protection strong;
        policy accept;
#        client all accept;
#       server all accept;

#===== Docker container utils  -> Docker virtual switch -> SNAT -> external LANs and Internet
router CONTs_NAT inface "$C_ifaces" outface eth0;
        masquerade;
        route all accept;
        client all accept;
        server all accept;

Этот пример настраивает NAT для работы docker и lxd контейнеров.

Нафига на слабом железе docker?

У него же нет особого оверхеда, что за специфика с железом?

Специфика - «на третьей малинке с одним гигом оперативки»

Сетевой оверхед там минимален т.к. используется netns.

А вот то, как докер собирает образы - меня расстраивало. overlayfs с безумным числом катологов будет жрать память и процессор. В 18 году я смотрел на контейнер с apache+php и меня вытошнило.

Да, возможно простенький контейнер с bash + сетевые утилиты не будут столь толстыми.

PS не люблю докер. Да, я знаю, что там есть разны типы стораджей, но постоянно бороться со встроенным интеллектом докера я не хочу. Возможно с 18 года что-то поменялось, но пока замечательно обхожусь lxc+aufs или ip netns для большинства своих задач.

Кто из них работает на «третьей малинке с одним гигом оперативки» ?

Осмелюсь присоединиться к вопросу, какой из этих десяти эмуляторов в состоянии работать на слабом железе?

overlayfs с безумным числом катологов будет жрать память и процессор. В 18 году я смотрел на контейнер с apache+php и меня вытошнило

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

Самому мне нечего сказать на тему, но Курячий для этого использовал VirtualBox в своём курсе: https://uneex.org/LecturesCMC/LinuxNetwork2023

Берёшь штук пять малинок третьих с гигом оперативки, провода, роутер. Будет прекрасная эмуляция. Для большего количества сетевых карт покупаешь usb сетевухи.

Ну ты ещё Opennebula предложи, на малинке-то )

VirtualBox работает только на x86-64. Если тс возьмёт нормальный комп, тогда да.

VirtualBox работает только на x86-64. Если тс возьмёт нормальный комп, тогда да.

Зато можно освоить Openwrt, RouterOS, pfSense, opnSense и пр. А на малинку только OpenWRT наверно или любой дистр и ручками

Да.

Это значит, что где-то нужно хранить каталоги куда налинкованы файлы.

Идея набирать пакеты через overlayfs - выглядит как очень изящное решение, но вот производительность явно от этого страдает.

Там в ядро сейчас пытаются пропихнуть Composefs в виде «OverlayFS + EROFS»

Возможно после добавления её поддрержки в докер, он (докер) станет более вменяемым.

Это значит, что где-то нужно хранить каталоги куда налинкованы файлы

А исходные слои хранятся в астрале? :)

Насколько мне известно, у каждого слоя, идентифицированного sha256 содержимого, есть строго определённый набор предков (как в git). Почему бы рядом с /path/to/storage/layers/<sha256> не хранить /path/to/storage/layers-squashed/<sha256>, в который налинкованы в правильном порядке файлы из самого этого слоя и всех его предков по очереди?

IMHO каждый пакет хранится 1 раз. Это разумно.

После появления в продакшене Composefs все будет значительно лучше.

IMHO каждый пакет хранится 1 раз. Это разумно

Ну так хардлинки же.

После появления в продакшене Composefs все будет значительно лучше

Не вижу связи.