Зміст
Коротко
AWS Lambda не крутить ваш код у класичному Docker-контейнері — там Firecracker microVM. Багатокористувацький GKE — gVisor, Cloudflare Workers — WASM. На Dev.to автор прогнав один і той самий Go HTTP-сервер (образ 3 МБ) через п’ять ізоляторів і порівняв холодний старт, пам’ять і сценарії, де кожен має сенс.
Що сталося
Базовий варіант — distroless + runc: мінімальний образ без оболонки й пакетного менеджера. Це не змінює модель ізоляції (спільне ядро хоста), але ускладнює життя зловмиснику після злому — нічим достраювати атаку.
gVisor (runsc) перехоплює системні виклики в ядрі Sentry у користувацькому просторі; хост не бачить системні виклики контейнера напряму. Увімкнення — прапор --runtime=runsc. Режим Systrap (з 2023) помітно швидший за ранні версії. Типові сценарії: CI-раннери з чужим кодом, плагіни SaaS, хмарні IDE.
Kata Containers з QEMU піднімає легку VM на контейнер — справжня межа ядра. Холодний старт порядку ~500 ms, пам’ять ~52 МБ поверх застосунку. Потрібен там, де аудит вимагає ізоляції на рівні VM (PCI-DSS, HIPAA, багатокористувацькі БД).
Kata + Firecracker — той самий образ, інший VMM: ~125 ms холодного старту, ~28 МБ накладних витрат. Так влаштовані Lambda, Fly.io Machines, пакетний вивід LLM і оточення попереднього перегляду для PR.
WASM/WASI — окрема ціль компіляції: модель повноважень без системних викликів за замовчуванням. HTTP у WASI preview1 ще обмежений, але WASI 0.2 і wasi-http уже в продакшені на периферійних платформах. Docker Desktop 4.27+ вміє --platform=wasi/wasm.
На прогрітому сервісі медіанна затримка p50 у всіх OCI-рантаймів лишається <1 ms — платите холодним стартом і оперативною пам’яттю, а не пропускною здатністю.
| Рантайм | Холодний старт | Пам’ять (орієнтир) |
|---|---|---|
| runc / distroless | ~20 ms | ~7 МБ |
| gVisor | ~50 ms | ~18 МБ |
| Kata / QEMU | ~500 ms | ~52 МБ |
| Kata / Firecracker | ~125 ms | ~28 МБ |
Чому це важливо
«Який рантайм безпечніший?» — хибне питання. Важлива модель загроз: свої образи в довіреному кластері, довільний код користувачів, регуляторика чи периферія з чужими скриптами — у кожного своя відповідь.
Розмір образу майже не змінюється (~3 МБ) — змінюється лише --runtime. Це знімає страх, що посилення ізоляції зламає пайплайн збірки.
На практиці
- Внутрішні мікросервіси в однокористувацькому кластері → runc + distroless як базова гігієна.
- CI/CD і SaaS з користувацьким кодом → gVisor без KVM і з ізоляцією системних викликів.
- Вимоги відповідності з формулюванням «межа VM» → Kata/QEMU або конфіденційні контейнери.
- Безсерверна платформа, оточення попереднього перегляду, пакетні задачі → Firecracker.
- Периферія, плагіни, один бінарник скрізь → WASM/WASI і фреймворки на кшталт Spin.
Репозиторій copyleftdev/micro-containers містить бенчмарки й install.sh для кожного рантайму.
Підсумок
Екосистема контейнерів ширша за Docker + runc. Вибір — не «максимум безпеки», а відповідність загрозам, холодному старту й операційним витратам. Для інтерактивних платформ Firecracker часто виявляється практичним компромісом між gVisor і повноцінною VM на QEMU.