Vlákno názorů k článku Debian se musí znovu vážně zabývat přístupem k init systémům od LD - Mám na to dva pohledy. První je pohled člověka,...

Mám na to dva pohledy.

První je pohled člověka, který potřebuje počítač k práci a zábavě. Tam mi je jedno jestli skripty spouští systemd nebo malí skřítci. Chci aby počítač fungoval a umožnil mi dokončit práci.

Druhý pohled je ze strany admina/iťáka kdy chci mít plnou kontrolu nad tím, co v systému mám a co se tam děje, na úkor všeho ostatního. To je třeba proč jsem měl dlouhá léta gentoo a vyhýbal se systemd jako čert kříži.

V dnešní době je trend dělat vše pro první případ. Je to vidět na systemd, nebo i windows 10, androidu a třeba apple to razí téměř od začátku.

Abych neutekl od tématu, co je nejlepší pro debian...těžko říct, mám debian už všude se systemd a přes pár problémů co jsem s tím měl to holt funguje.
Možná by se mohli vydat cestou forku na debian-systemd a debian-openrc, ale nevím jak by se pak daly udržovat balíčky mezi jednotlivými odnozemi. Jedině mít mezivrstvu s nějakým init-generic api, do kterého by se zapojil init jaký chceme? Ale jak by to pak fungovalo...?

SystemD, narozdil od cehokoliv jineho, nasadil predevsim v plnem rozsahu cgroups spolu se spravnou inicializaci MAC. Ty jsou nutne pro containery a chteji je velci hraci, takze se z toho neuhne. Bohuzel si s nimi chteji hrat i male deti, ktere nevidi bezpecnostni rizika a spoustu dalsich dusledku. Takze na Linuxu proste systemd bude a prevalcuje vse ostatni - to je (budouci) realita. Jak to zdegeneruje/zah­lti/otravi zacatecniky, kteri s Unix-like systemy teprve prijdou do styku si nedovolim odhadovat.

Sam se primlouvam za to, aby na svete zustal aspon jeden Unix-like system, ktery se tomuhle kontejnerovemu silenstvi vyhne, anebo ho zrealizuje jinym, lepsim zpusobem. Linux to ale uz nebude.

Bohuzel si s nimi chteji hrat i male deti, ktere nevidi bezpecnostni rizika a spoustu dalsich dusledku. Takze na Linuxu proste systemd bude a prevalcuje vse ostatni - to je (budouci) realita. Jak to zdegeneruje/zah­lti/otravi zacatecniky, kteri s Unix-like systemy teprve prijdou do styku si nedovolim odhadovat.

To jste popsal velmi přesně. Linux byl dlouhoju dobu atraktivní pro jednu sortu adminů / uživatelů, kteří neměli trpělivost se naučit správně spravovat Windows. Se systemd přišla podobná komplikovanost do linuxu a je tedy logické, že tomuto segmentu uživatelů se ten posun nelíbí. S trochou nadsázky, pro tyto "ortodoxní" unix(-like) adminy je systemd podobné zlo, jako je nutit učit se Active Directory, NTLM, GPO a další komplikované (pokročilé) technologie.

Spravovat správně a bezpečně holý systém není úplně jednoduché. Mnoho lidí si pod pojmem "bezpečnost" představuje to, že mají zapnutý firewall, mnohdy ještě "bezpečnostně posílený" NATEM na routeru. (Mimochodem, na IPv6 spousta adminů používá znovu NAT, ačkoliv IPv6 vzniklo od toho se NATU vyhnout - ale nikdo si netroufne do zoufale nezabezpečených koncových uzlů pouštět ostrý internet). Bezpečnost ale taky znamená celky segmentovat, segregovat uživatele a oprávnění (ne, že všechny servicy běží pod rootem nebo je vše nivelizováno sudem). Software je potřeba aktualizovat (dávno neplatí, že co funguje, na to se nesahá). ..., ..., ... Dobře zabezpečený systém aby člověk pohledal.

Kontejnery jsou v tomto ohledu opravdu šílenství. Dnes si kontejnery instalují programátoři a skoro-ne-admini podle kuchařek na internetu. Vzniká tu obrovská bezpečnostní díra. Co základní operační systémy roky pilují - aby bezpečnost byla výchozím stavem, aby aktualizace bylo možné provádět bez osypek, že se vše rozpadne, ..., to vše nám kontejnery znovu vzaly. A my tomu ještě tleskáme. Děsím se doby, až do nějakého populárního image někdo vpašuje backdoor - víme z praxe, že i velké bezpečnostní chyby zůstávají léta nepovšimnuty. Kdo by pitval image až do posledního atomu?

Takže za mě, kontejnery do produkce nepatří, nebo jsou tak drahé na údržbu, že to většinou setře tu původní motivaci je používat (v praxi se setkávám s kontejnery vnímanými jakožto rychlé, levné cesty). Většinou dokážu najít nekontejnerové řešení téhož problému levněji (při zachování stejné bezpečnosti).

Na druhou stranu, kontejnery jsou super pro vývojáře. Rychlý deploy určité verze a prostědí se hodí při práci na různých projektech. Tam je jejich přínos opravdu velký.

Boj admina je pak uvnitř firmy. Umět vysvětlit, že opravdu nelze jen vzít kontejner od programátora, někam ho nahrát a do hodiny běžet v produkci. Vždyť ten programátor tvrdí, že to takhle dělá a funguje mu to, tak proč nějaký admin říká, že takto to nejde?

Jak jste psal, kontejnery jsou super pro velké hráče, kteří dokáží bezpečnost zajistit hromadně, hromadně nasazovat a udržovat. Tam mohou přicházet zajímavé úspory z rozsahu, aniž by byla bezpečnost narušena. Ale kolika promilím z nás se podaří do takového prostředí dostat?

21. 9. 2019, 08:07 editováno autorem komentáře

Jsou kontejnery a kontejnery. To, co popisujete, se týká hype kolem dockeru a ano, máte pravdu. Ale i docker se dá dělat dobře a automatizovaně, včetně bezpečnostních update.

Osobně doporučuju používat kontejnery (lxc, systemd-nspawn, freebsd jaily) jak jen je to možné. Tedy mít na HW jen nezbytné minimum a všechny služby provozovat v kontejnerech výše uvedeného typu.

Proč. Už jen z důvodu oddělení konfigurace. MX server přece jen vyžaduje jiné nastavení než webserver a moloch typu gitlab sice lze nainstalovat po balíčcích a umístit společně s dalšími 50 službami na stejný server, ale pravděpodobně z toho admin zešílí.

Kontejnery umožňují jednoduché oddělení konfigurace pro to které nasazení. Navíc takto velmi snadno a elegantně můžete oddělit skupiny služeb a IP, na kterých budou poslouchat (tj webserver z MX serveru bude na jiné IP než webserver pro obecné weby - ano, lze v každé jednotlivé službě nastavit listen a bind apod. ale uzavření do kontejneru je jednodušší a zřejmé).

Další věcí je oddělené zálohování. Stačí udělat snapshot toho kterého kontejneru a dumpnout jej na zálohovací server. Každý kontejner lze zálohovat jinak často. Obnova jednoho kontejneru nijak nezasáhne ostatní služby v jiných kontejnerech.

Velmi snadno se to přenáší na jiný server. V případě systemd-nspawn stačí udělat btrfs send na jiný stroj (případně použít příslušný machinectl příkaz), překopírovat jeho konfigurák a spustit. (jaily totéž v bledě modrém, zfs send, jail.conf a je to). Opět, zkuste si zmigrovat jednu službu ze serveru, kde jich máte 50. Musíte udělat dump konkrétní db, konfig pro vhosta, bind na ip apod. Když je to v kontejneru, tak jej prostě pustíte jinde a je to.

Takto by se dalo pokračovat dál. Ano, je to víc práce z hlediska třeba update. Místo jednoho stroje jich updatujete 20 a to už chce třeba nějakou automatizaci. Na druhou stranu, pokud se update jednoho kontejneru nepovede a je nutné jeho služby nastavit pro novou verzi, tak se lze opět zaměřit jen na jeden kontejner a dalších 19 je v klidu.

Každý admin musí zvážit výhody a nevýhody. Pro mě výhody převažují.

Jsou kontejnery a kontejnery. To, co popisujete, se týká hype kolem dockeru (...)
Každý admin musí zvážit výhody a nevýhody. Pro mě výhody převažují.

Naprostý souhlas, dělám to tak stejně. Mě se třeba týká to ZFS a jail, to používám.

Moje kritika směřovala k tomu, že (jak jste správně poznamenal) docker zažívá hype a lidé si to ztotožňují s tím, že něco-kliknu-ejhle-ono-to-jede.

Nastavit např. FreeBSD jail taky není jen tak, minimálně než si na to zavedete pravidla. Docela zajímavé je na base system zavést deduplikaci, protože base files jsou opravdu totožné napříč všemi jaily. Musíte se rozhodnout, jak bude fungovat síťový stack, jestli bude v jailu společný s hostem, nebo jestli bude nezávislý. Podle toho se musí správně nakonfigurovat pf, které se konfiguruje NAD jailem, ne v něm.

...a to všechno, a mnohé další, už je práce admina a ne nějakého klikoše, který si stáhne docker a pak vám vykládá, že admin už není potřeba...

Osobne bych doporucoval nasazovat kontejnery (na Linuxu) jen po zrale uvaze a za prihodnych podminek, nikoliv jak jen to je mozne. Mnozstvi brutalnich bezpecnostnich der v poctu az desitek rocne, minimalne na urovni der Intelskych procesoru, fakticka eliminace SELinuxovych ohradek pro bezici sluzby a pridani dalsi vrstvy do sitove trasy by mi za to v produkci nikde nestalo. Zisk v podobe swarm modu je pro mne bagatelni, protoze zaklad (veskere diskove overlay i snapshoty) zvladnu se SAN a HW virtualizaci, pricemz swarm mod vlastne vubec nikde nepotrebuji. Prinos kontejneru vidim tedy minimalne v mem prostredi jako zanedbatelny, radsi mam HW virtualizaci.