Názory k článku
Podpora kontejnerů ve FreeBSD
-
KateStříbrný podporovatelOCI (Open Container Initiative) je projekt který vznikl nějakou dobu po Dockeru z potřeby vytvořit otevřenou specifikaci pro kontejnery a jejich runtime. Stojí za tím Linux Foundation a přispívaly další firmy, zejména Docker. Každý kontejner vyrobený dockerem je tak teď OCI kontejner, a je kompatibilní s konkurenčními projekty jako podman. Stejně tak může Docker spouštět OCI kontejnery vyrobené třeba Podmanem, Buildah...
Správně je tak všechno na DockerHub OCI, ale lidi jsou pořád zvyklí říkat tomu Docker kontejnery.
-
KateStříbrný podporovatel
Co mě ovšem zaujalo je, všechny OCI runtimy pro Linux o kterých vím používají cgroups a namespaces pro oddělení kontejnerů od hostitelského systému. Podman i Docker na Macu a Windows používají pomocný tooling pro instalaci Linuxové virtuálky, a kontejner spouští v ní.
V tomhle případě to ovšem vypadá že OCI runtime Podmanu používá ve FreeBSD jail, takže jsou tam kontejnery spouštěné nativně.
4. 11. 2025, 07:55 editováno autorem komentáře
-
Michal ŠmucrBronzový podporovatel
Ono tam právěže není ani jiná možnost.. ty cgroups a namespaces tam nejsou podporované v linuxové emulační/překladové vrstvě (Linuxulator). Nativní jaily a resource control (rctl) je tomu asi nejblíž.
Takže při spouštění linuxového kontejneru podmanem se vytvoří jail, který použivá Linuxulator.
Větší problém ovšem je ten samotný překlad syscallů, resp. jestli to vůbec jde a v BSD bude existovat nějaký podobný mechanismus, kam se to dá naroubovat. Spousty věcí funguje, ale některé taky ne,
https://cgit.freebsd.org/src/tree/sys/compat/linux/linux_dummy.c -
Michal ŠmucrBronzový podporovatel
Takže z mých předchozích zkušeností to může být trochu procházka minovým polem, jestli něco poběží nebo ne. Takové klasické problematické věci byly např. epoll a inotify. Epool chodil blbě, inotify tam nebylo vůbeb.
Spoustě věcem to bránilo, když jsem třeba zkoušel nějaké reálné služby třeba s Apline.
Na inotify letos sice přistál nějaké patche s nativní implementací, ale ještě jsem neměl příležitos to znova ozoušet.
https://cgit.freebsd.org/src/log/sys/kern/vfs_inotify.c?h=stable/15 -
Michal ŠmucrBronzový podporovatel
Uvidíme.. něco nejde tak jednoduše, viz třeba ten popisek u prvního commitu s tím inotify.
Ale obecně mi dává smysl, že se na to třeba FreeBSD nadace nebo firmy s komerční podporou BSD jako Klara obecně víc zaměřily. Před masivním nástupem kontejnerizace to při nasazování FreeBSD a Linuxu bylo v mnoha oblastech na serveru víceméně podobné (systém jako platforma na Apache, Nginx, Postgres.. Sambu atp.). Jakmile pak přišlo na hotové aplikace (i třeba třetích stran), co se nasazují do kontejnerů, tak se to zásadně změnilo.
I když by třeba teď měl někdo z větší části udělané své věci třeba na jailech, tak pro tyhle OCI kontejnery s linuxovými aplikacemi, co by chtěl spouštět on-prem u sebe, musí mít další server, nebo rozjet celý VM pod Bhyve, což ale také není úplně optimální. Hlavně z hlediska toho, že buď přijde v tom container hostu o přístup k snapshotům, klonům, což se pro ty kontejnery velmi hodí.. Nebo v tom hostu použije další CoW filesystém jako Btrfs (neefektivní další overhead, dvakrát CoW), případně se tam pokusí poslat přímo datasety zvenku přes VirtioFS, což má samozřejmě také režii a navíc to vnější ZFS se nedá ovládat z toho virtuálu. -
No nejlepší je asi k dispozici Bhyve celý fyzický disk nebo dva.
https://forums.freebsd.org/threads/hard-drive-pass-thru-bhyve.66295/Pak tam nebude to dvojité CoW. I v Linuxu lze mít zfs, takže učit se používat méně spolehlivé drdb není úplně nutné. Ale lepší by bylo mít jen FreeBSD.
-
