Naopak tohle řešení mi připadá systémově lepší, řeší se na nižší úrovni a oproti kontejnerům bude mít parně menší overhead a vyšší výkonnost.
Pro větší prostředí je správa stejná jako pro cokoliv jiného - v playbooku budou předem připravená pravidla.
Bohužel poslední dobou často vídám přístup, kdy se vše spouští v dockeru a víc se bezpečnost neřeší, protože to už je přece vše od sebe oddělené :-(
Ne to nebude, overhead bude uplne stejnej ale navic si budete muset resit po vlastni ose spravu a mgmt tech namespacu, cgroup, pripadne selinuxovejch kontextu a to fakt nechcete. Jedina nevyhoda kontejneru je jejich image, overhead s nema spojenej pri startu a jejich mgmt a tam uznavam ze treba vladtni sprava prinasi dalsi level komplexity. Nicmene muj pocit z tohoto reseni je, proc to delat jednoduse, kdyz to jde i slozite. Ale proti gustu... :)
Vsak jsem taky psal, ze pro jeden dva systemy/aplikace to chapu. Nicmene reseni pro mgmt kontejneru je spousta a nemyslim si, ze pouziti treba dockeru nebo podmana je nejaka raketova veda. Naopak i pro par instanci je to vcelku pohoda, spis mi prijde jako cirej masochismus to delat v 21 stoleti rucne. Ale jak pisu, proti gustu zadnej disputat.
pro větší prostředí je to nepodstatné, náklady na automatizaci se rozloží daleko lépe. Doba, kdy se vše udržovalo ručně je pryč.
U konteinerů nemám snadnou možnost jak jednotlivá oprávnění granulovat pro různé aplikace. Zvyšuje to výrazně pak komplexitu, kdy musím provozovat ještě další nástroj nad to. Containerový systémy neřeší skoro vůbec závislosti služeb navzájem a události, kdy která služba může startovat (ne, k8s nechci prozovat na jednom serveru).
> pro větší prostředí je to nepodstatné, náklady na automatizaci se rozloží daleko lépe. Doba, kdy se vše udržovalo ručně je pryč.
Musite ale mit i v ramci automatizace nejakou logiku ktera Vam dela spravu ns pripadne dalsich veci jako cgroupy apod (pokud to chcete).
> U konteinerů nemám snadnou možnost jak jednotlivá oprávnění granulovat pro různé aplikace.
priznam se ze tenhle argument moc nechapu. Kontejner = samdbox. Co potrebujete vic ?
> Containerový systémy neřeší skoro vůbec závislosti služeb navzájem a události, kdy která služba může startovat
ok s tim souhlas.
Systemd přece dělá sám správu ns a cgroup. Mně z pohledu infrastruktury je asi jedno, jestli budu generovat service.unit nebo servise.compose. Větší infrastrukturu je čímdál složitější spravovat bez automatizace.
Podívej se na článek, pod kterým diskutujeme, např. kapitola "Prohlídka konkrétní služby" a features, které tam jsou, o tom mluvím. Tohle stejně potřebuje nastavovat u konteinerů. Nelze prostě jít a vše spustit do rootem v kontaineru.
> Tohle stejně potřebuje nastavovat u konteinerů. Nelze prostě jít a vše spustit do rootem v kontaineru.
s tim souhlas, nicmene imho bude automatizovane prehlednejsi spravovat kontejnery nez systemd. A to co autor clanku tady vytvari je v podstate kontejner, jen tomu tak nerika :).
Ale ok, pokud Vam prijde snazsi spravovat ns pres systemd, pak se proti tomu neda asi nic namitnout :)
:) Dobrej dotaz, asi bych ji mel ulozenou v nakym yamlu jako manifest, pripadne bych tuto konfiguraci vubec neresil a nechal ji na defaultnich hodnotach danyho nastroje nebo jeho politik. Uznavam, ze jsem hodne ovlivnen filosofii k8s.
Jen sem chtel poukazat na to, ze autor dela v podstate kontejner rucne a mozna by stalo za to popremyslet, jestli nejit nejakou standartni cestou nez se pachtit se systemd.
Kontejner má tu nevýhodu, že pro něj potřebujete obraz. Pokud už máte aplikaci v systému a potřebujete ji jenom spustit, je jednodušší ta omezení nastavit pomocí systemd než kvůli tomu vyrábět celý image. Když tu aplikaci chcete spustit rovnou a ne jako službu, použijete systemd-nspwan. Takže máte všechny možnosti, jaké vám pro oddělení procesů dávají kontejnerové technologie, jenom nepotřebujete ty obrazy.
To zalezi na tom jak to prostredi vypada, pokud budete potrebovat treba vice verzi a ruznych instanci jedne aplikace pak se vam imho kontejnery uz vyplati. Jinak ano, image ma svuj overhead pri startu, ale zase jste schopen tu aplikaci rychle a bezpecne spustit, nezavisle na ostatnich
21. 1. 2022, 15:48 editováno autorem komentáře