Dotaz: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?

[xsouku04]

Léta jsme používali vserver a později openvz. S openvz jsme plně spokojeni, ale jeho jádro začíná být příliš staré. Hledáme tedy něco co by nahradilo openvz s nejmenší námahou. Raději jen kontejnerovou virtualizaci, jsme na to zvyklí a také věřím že pro VoIP je lepší být blíže hardware.

Co se ale tak rozhlížíme tak nic podobně dobrého jako openvz nebo alespoň vserver není k dispozici? Nanašel jsem nic co by se blížilo tomu co umí openvz. Téma čím nahradit openvz nikdo neřeší? Nyní testujeme systemd-nspawn. Proti vserver i openvz se ale zdá konfigurace sítě složitá. Nestačí jen spustit virtuál s ip adresou, ale musíme upravit ručně i routování. Používáme macvlan. Nechceme žádné specialitky, jen na jednom fyzickém stroji chceme více kontejnerů a každý aby měl svoji veřejnou statickou ip adresu. Virtuály se mají vidět navzájem.

Vypadá jako by neexistoval jednoduchý způsob jak nastavit síť. Dokumentace pro nás špatně srozumitelná, jako by dnes už všichni používali docker nebo cloud od amazonu a tyto věci vůbec neřešili.

Je vůbec možné nastavit ip adresy zvenku při startu virtuálu,a by se nenastavovala uvnitř virtuálu? Vždyť je to bezpečnostní riziko. Kdyby se útočník zmocnil kontejneru, může si změnit ip adresu tak aby s něčím kolidovala a vyřadit tak z provozu i další služby.

Zatím to vypadá, že budeme muset šudlat s nastavením systemd konfiguráků, kdy bude nutné přidat skript při spuštění i vypnutí virtuálu aby změní routování. Tu ip adresu asi bude muset číst z nějakého místa, které si sami určíme. Jako kdyby to nikdo před námi neřešil.

Nebo jsme jen něco nepochopili?

Odpovědi

[DarkKnight]

LXC/LXD nevyhovuje? Existuji i navody na migraci OpenVZ kontejneru do LXC.

[ttt]

Na vpsfree to řeší. Moc tomu nerozumím, třeba odkazy pomohou: https://lists.vpsfree.cz/pipermail/community-list/2017-December/009315.html nebo https://github.com/vpsfreecz/vpsadminos.

[Josef Kufner]

Výhoda systemd-nspawn je v tom, že pokud je na hostitelském systému i v kontejnerech systemd, nejlépe ve stejné/blízké verzi, je do kontejnerů hezky vidět a je to integrované dohromady. Přináší to trochu pohodlí při správě.

Když jsem to zkoušel, tak mi nějaké nastavování IP adresy v systemd-nspawn složité vůbec nepřipadalo. Naopak mi to přišlo úplně triviální. A ty jejich návody jsou, řekl bych, na dost vysoké úrovni.

[xsouku04]

Děkuji všem za rady. Chvilku mi trvalo, než jsem si vše přečtl. Opravdu to vypadá, že nejbližší a nejpoužívanější náhrada za OpenVZ je lxc.

systemd-nspawn jako by byl jen pro pár systemd nadšenců. On sice funguje relativně jednoduše out of the box, pokud vám nevadí, že ip adresa virtuálu bude za NATem a DHCP, které bude za tím účelem vytvořen a vy si pak můžete přesměrovat porty. Na jiné použití zdá se chybí dokumentace. Pravděpodobně má celý projekt řádově méně uživatelů než lxc. Tedy lxc nabízí lépe prošlapanou cestu navíc podobnější tomu na co jsme z OpenVZ zvyklí. A dokumentace se zdá být dost. Např. o síti: http://containerops.org/2013/11/19/lxc-networking/

Co jsem se díval tam zajímavě vypadá také projekt proxmox. Je to klikátko které umožňuje spravovat virtuály na jednom nebo více fyzických strojích se vším co s tím souvisí. Dříve podporovalo openVZ nyní přešlo na lxc.

U proxmox mne ale zaráží, že s každým novým containerem se vytvoří podivný soubor *.raw, který obsahuje celý virtuál v jediném souboru. Proč je to tak? Na co vytvářet další souborový systém v již existujícím souborovém systému? Tedy úplně zbytečnou abstrakci. Píší o tom zde. https://forum.proxmox.com/threads/proxmox-4-lxc-chroot-instead-of-raw-images.22881/ Co je vedlo k této podivnosti a plýtvání? Mám např. obavy kdo se postará o integritu souborového systému když dojde k výpadku elektřiny? Totiž hrozí, že vnitřní souborový systém bude poškozen jiným způsobem než kdyby běžel přímo na hardware. Jak moc je ale tohle nebezpečí běžné netuším.

Vypadá to, že by to mohl být důvod proč se proxmoxem rozloučit a zůstat jen u lxc + zfs. I když některé jeho postupy a skripty asi budou dobré.

[Vantomas]

Pokud jde o klikací správu, tak LXC umí spravovat libvirt a jde to naklikat ve virt-manageru.

Sám jsem si do LXC asi před dvěma měsíci přesunul Nextcloud, který mi předtím běžel v KVM, právě kvůli vnitřnímu filesystému a můžu tedy potvrdit, že vnitřek kontejneru lze nakonfigurovat tak, aby byl přímo na hostově filesystému.

[Heron]

systemd-nspawn jako by byl jen pro pár systemd nadšenců

Nejsem systemd nadšenec, ale nspawn používám několik let (i s veřejnými adresami) a nevidím problém.

pokud vám nevadí, že ip adresa virtuálu bude za NATem a DHCP

Proč to?

Na jiné použití zdá se chybí dokumentace.

Popis, jak v dané distribuci nastavit síť, snad existuje. Pokud používáte systemd-networkd (což bych pro nspawn kontejner doporučoval), tak máte pěknou dokumentaci přímo od autorů systemd.

Jinak to, že v některých projektech lze IP kontejneru (používám třeba i FreeBSD jaily) nastavit zvenčí, nepovažuji za bůh ví jakou výhodu. Pokud mám fyzický stroj nebo plnou virtualizaci, také nenastavuji IP "zvenčí". Proto nevidím u nspawn problém, naopak, sít nastavuji úplně stejně jako na fyzickém stroji nebo plné virtualizaci. V mém případě tedy pomocí systemd-networkd.

[xsouku04]

U nás byl problém v tom, že aby se jednotlivé virtuální servery a hlavní stroj viděli mezi sebou na síti, muselo se změnit routování vždy po spuštění nějakého containaru. Na fyzickém stroji tak přidám routování příkazem "ip route add 192.168.2.136/32 dev macvlan0", který říká že s touto konkrétní ip adresou mám komunikovat přes rozhraní macvlan0, protože běží na stejném stroji a ne přes rozhraní směrem do internetu.

Jinak všechen provoz mezi virtuály navzájem nebo mezi virtuálem a hlavním strojem chodil přes výchozí bránu, protože stroje nevěděli, které ip adresy je třeba posílat lokálně a nikdo se v lokální síti k oné adrese nehlásil. A ne každá výchozí brána tuhle podivnost pochopí a pakety pošle zpět i když, jen se tím prodlužuje ping.

Tedy pokud jsme ručně přidali routovací pravidlo pomocí ip route add, vše fungovalo jak má. Kvůli špatné dokumentaci ale není zřejmé kam dát přidávání a odebrání pravidla tak, aby se přidalo/odebralo vždy po startu či vypnutí containaru. Že by se tohle řešilo také zevnitř virtuálu nějakým systemd způsobem? Nejspíš tedy ano. Pak ale nejspíš nebude problém ze vnitř virtuálu od sítě odpojit celý fyzický stroj a to třeba i omylem. Což není dvakrát moudrá vlastnost pokud jeden z hlavních důvodů proč dělám containery je kvůli bezpečnostnímu oddělení jednotlivých činností. Nebo má každý container vlastní routovací pravidla stejně jako má možnost mít vlastní firewall nastavovaný zevnitř?

[Heron]

Nevím, zda jsem pochopil, v čem máte problém. Pokud mají mít kontejnery veřejnou ip a hostitel privátní ip (třeba z 192.168.0.0/16), tak tohle jednak může zařídit router (default gateway toho fyzického stroje i kontejnerů), ale já to raději řeším tak, že ten kontejner má více ip, veřejnou a tu privátní.

Z hlediska síťování je to jedno, ale já chci v konfiguraci uvést, že daný kontejner má krom adresy z lokální sítě, také ještě adresu veřejnou (na které je dostupný z internetu). Stačí mu sice jen ta veřejná (router to propustí i do lokální sítě), ale já rád explicitní konfiguraci.

macvlan0

Proč macvlan? Já používám veth (--network-veth, resp. VirtualEthernet=yes) a na hostitelském systému tu příslušnou veth síťovku jen strčím do bridge na příslušnou fyzickou síťovku. To mi umožňuje připojit daný kontejner do dané fyzické sítě, jen přiřazením do konkrétního bridge.

Tj konfig v /etc/systemd/nspawn/stroj.nspawn:

[Exec]
Boot=on

[Network]
VirtualEthernet=yes
Bridge=br0

Tohle je jediné nastavení kontejneru na straně hostitele a v kontejneru je jen nastavení sítě (systemd-nspawn) a je to.

Pak ale nejspíš nebude problém ze vnitř virtuálu od sítě odpojit celý fyzický stroj a to třeba i omylem.

Řekl bych, že podobný, jako z kteréhokoliv jiného stroje na síti. Rozhodně nemusíte kontejnery připojovat na stejnou fyzickou sít, na které máte adresu fyzického stroje. Případně fyzický stroj může mít servisní ip, která bude jiná (z jiného rozsahu), než ip pro komunikaci s kontejnery. Atp.

Nebo má každý container vlastní routovací pravidla stejně jako má možnost mít vlastní firewall nastavovaný zevnitř?

Ano, může mít vlastní routy.

[Vantomas]

Pokud se nebude používat macvlan a síťovky se strčí do bridge, tak kontejnery na sebe normálně uvidí bez jakéhokoliv nastavování na hostovi nebo někde jinde.

[xsouku04]

Vypadá to, že jediná špatně dokumentovaná finta je v tom, že je nutné fyzické síťovce adresu kterou měla doposud odejmout a místo toho ji dát té uměle záhadně vytvořeně bridgové, která se ať chcete nebo ne vždy vytvoří s novým bridgem.
Tedy alespoň to píší zde.
Vypadá to na univerzální podivnost linuxových bridgů, která se týká veškeré virtualizace co používá bridge. Stále mne nešlo totiž do hlavy proč bridge potřebuje mít ip adresu (i když někdo občas tvrdí, že ji nemá, nebo samé nuly a stejně mu to funguje). Bridge = switch na druhé vrstvě. Ten by mít ip adresu neměl. A přesto zdá se musí, aby to fungovalo. Zítra to otestujeme.

[Vantomas]

Bridge nemusí mít IP adresu, ale musí být up, to je možná to, co se s tím zaměňuje.

[Vantomas]

A jinak ano, interfacy, které jsou v bridge na hostovi, nesmí mít žádnou IP adresu. Pokud nějakou IP adresu mají mít, tak se ta adresa musí nastavit na bridge.

[xsouku04]

Co se záhady se souborovým systémem proxmox, tak je má záhada vysvětlena. Proxmox používá zfs (čehož jsme si nevšimli) a ten řeší vše. S každým virtuálem je vytvořen ZFS volume, který jde vytvářet a měnit díky zfs bez problému kdykoli i během chodu. Tedy RAW image je tam jen jako berlička pro ty co odmítají použít zfs a že je to berlička nedokonalá nikoho moc trápit nemusí, protože naprostá většina jeden na zfs. Proxmox tedy vypadá na velmi dobré řešení, kde se dá vše naklikat ale má to příkazovou řádku. Je to postaveno na debianu a lxc.

[bukowski]

Co používáte na správu LXC? Nejlépe webový.

[xsouku04]

Zatím dvě možnosti na které jsem narazil jsou proxmox - dlouhodobě existující a stabilní projekt s aktivním uživatelským fórem - hodně možností, nebo jak tady někdo zmiňuje výše libvirt s klikacím virt-managerem (nezkoušel jsem).

[xsouku04]

Děkuji všem za příspěvky s inspirací, všechny problémy už jsou objasněny. Jsou to věci společné pro všechny virtualizace ne jen pro systemd-nspawn.

Pokusím se je shrnout pro sebe i ostatní, co byl náš problém a na čem jsem se "nachytal". Možná bude mít někdo tendenci udělat stejnou/podobnou chybu a tak mu to pomůže.

1) Důvod proč nám nefungoval obyčejný bridge byl ten, že pokud vytvořím bridge a dám do něj nějakou fyzickou síťovku, tato fyzická síťovka nesmí mít nastavenu ip adresu. S každým bridgem mi vznikne pojmenovaná virtuální síťovka na hlavním stroji právě pro tento účel. Tedy ip adresu fyzického stroje nenastavuji na fyzické síťovce (např. se jménem eth0) ale na virtuální síťovce (např. se jménem br0). Tohle jsem nechápal, protože přece bridge=switch vrstva 2 tak jakápak ip adresa? Ale prostě to tak je a je potřeba na to myslet.

2) Macvlan- Macvlan vytváří více virtuálních podsíťovek na jedné fyzické síťovce. Pokud přiřadím i fyzické síťovce ip adresu, tato ip adresa není přímo dostupná z podsíťovek, což je známá vlastnost macvlan. Nejlepší řešení asi bude hlavnímu stroji nekonfigurovat síťovku, ale jen virtuální podsíťovku, která je v režimu bridge (nejedná se o stejný bridge jako výše) dostupná i z virtuálních strojů. Jiné řešení může být přidávat obskurní routovací pravdla se spuštěním každého virtuálu, jak popisuji ve svých příspěvcích. Macvlan moc lidí nepoužívá, protože obyčejný bridge je univerzálnější a asi méně problémový a lépe laditelný, proto pro macvlan není tolik zmínek a návodů na internetu jako u obyčejného bridge. Bridge je zase tak jednoduchý, že o něm není skoro co psát a pokazit, snad kromě vysvětlení k čemu slouží jeho virtuálnímu síťovému rozhraní na které jsem bohužel nenarazil. Údajná výhoda macvlan je vyšší rychlost - menší zatížení procesoru.

Jinak nyní to vypadá, že budeme používat proxmox se zfs a v něm lxc virtualizaci. Na síťování bridge.