Какие утилиты и технологии Linux используются под капотом Docker?

А, вот ты хочешь про Docker, да? Ну, слушай, сейчас я тебе так разложу, что ты офигеешь, блядь. Это ж не просто какая-то магия, там под капотом целый ёперный театр из ядра Линукса работает, чтобы твои контейнеры не перегрызлись друг с другом за ресурсы.

Ну, во-первых, Namespaces (Пространства имен). Это, сука, как отдельные квартиры в общаге. Каждому контейнеру — своя хата. Свои процессы, своя сеть, своя файловая система, даже своё имя хоста. Один в своей квартире орёт «я — localhost!», другой тоже «я — localhost!», и они друг друга не слышат, блядь. Идеальная звукоизоляция.

• Пример: unshare --pid --fork --mount-proc — это как взять и отгородить угол в комнате шифоньером, сказать «здесь теперь моя отдельная жизнь».

Дальше, Cgroups (Control Groups). А это, сука, уже не звукоизоляция, а контроль за жратвой и электричеством. Чтобы один прожорливый контейнер не сожрал всю память и процессор, оставив остальных голодными. Тут тебе и лимиты на CPU, и на память, и на дисковый ввод-вывод. Справедливость, мать его!

• Пример: cgcreate -g cpu,memory:/mygroup — это как выдать пайку: «Вот тебе, Вася, два ядра и гигабайт памяти. Больше — ни-ни».

Union File Systems (Объединяющие файловые системы), типа OverlayFS. Вот это вообще гениальная хуйня. Представь: у тебя есть базовый образ — слой только для чтения, как учебник в библиотеке. И поверх него — тонкий слой для записи, куда контейнер пишет свои изменения. А система их хитро объединяет в одну картинку. Экономия места — овердохуища! Все контейнеры делят один базовый образ, а свои костыли пишут сверху.

• Пример монтирования OverlayFS:

  mkdir lower upper work merged
  echo "lower content" > lower/file.txt
  mount -t overlay overlay -o lowerdir=lower,upperdir=upper,workdir=work merged
  # Теперь 'merged' содержит 'file.txt' из 'lower'

А теперь про безопасность, а то ты думал, что всё так просто? Seccomp (Secure Computing Mode). Это такой суровый охранник на входе в клуб. Он смотрит, какие системные вызовы (syscalls) твой процесс хочет сделать. «Туда нельзя, сюда нельзя». Docker по умолчанию даёт довольно строгий список разрешённых вызовов, чтобы какой-нибудь контейнер-выскочка не начал делать что попало с ядром.

Capabilities (Возможности). Это, блядь, раздробление власти. Раньше процесс внутри контейнера был как root — царь и бог. А теперь ему выдают не полную власть, а только нужные «корочки». Хочешь слушать на 80-м порту — вот тебе CAP_NET_BIND_SERVICE. А всякие админские штуки — нахуй, не получишь.

• Пример: capsh --drop=cap_net_raw -- -c "ping 8.8.8.8" — отобрали у процесса право на сырые сокеты, и он уже не может пинговать. Сиди и не рыпайся.

Ну и куда же без сети? iptables/nftables. Это наши верные друзья, которые роют тоннели, ставят мосты и таблички «проезда нет» между контейнерами и внешним миром. NAT, фаерволы, изоляция — всё на них.

И наконец, containerd/runc. Это уже не технологии ядра, а исполнители, пизда. runc — это как простой рабочий, который по нарисованной схеме (OCI-спецификации) собирает и запускает контейнер из всего этого LEGO. А containerd — это уже прораб, который управляет всеми этими рабочими, образами, следит за жизненным циклом.

Вот так вот, сука, всё вместе и работает. Никакой магии, один суровый, грамотно настроенный низкоуровневый трэш, который делает изоляцию, безопасность и управление ресурсами на раз-два. Красота, блядь!