Portál AbcLinuxu, 6. května 2025 06:42
Bylo mi doporučeno použít kontejnéry.
Proč? K čemu? Není lepší udržovat si server aktuální a rozumně zabezpečený?
Kontejnery se hodí v případě, že chce člověk používat víc různých operačních systémů (KVM) nebo víc různých userspace a distribucí téhož systému (LXC). Třeba pro vývoj, testování a tak podobně. Nevidím ale důvod, proč něco takového používat na domácím serveru. Operační systém je víceúlohový a víceuživatelský právě proto, aby například celý LAPP stack mohl v pohodě běžet na jednom stroji.
Před několika lety se rozmohla taková móda, ba možná přímo choroba, která se projevovala cpaním všeho do kontejnerů. Ještě bych asi vyhrabal tu debatu, kde jsem se ptal na něco ohledně hostapd a hned se vyrojilo několik kecalů, kteří se ptali, jak je vůbec možné, že můj domácí server s LAPP stackem, XMPP serverem, mail serverem a cca 10 dalšími službami má DNS server jinde než v "kontejneru" a jak je vůbec možné, že na tomtéž serveru běží hostapd. Inu, protože Linux je víceúlohový a víceuživatelský systém. Proto. Není důvod kvůli nějaké módní vlně předstírat, že je tomu jinak. Pokud jde o využití procesoru nebo RAM, izolace tohoto druhu se dá zajistit velmi jednoduše přímo na úrovni systému, opět bez kontejnerů.
Naštěstí už ta módní vlna zmizela a dnes už se tady moc neobjevují "rady" typu "všechno musíš mít v kontejneru nebo rovnou v popelnici".
Nejdůležitější úvaha asi je, že pokud je napadnutelný kterýkoliv z "kontejnerů", je situace ve srovnání s napadením celého systému sice lepší, ale jenom o malý fous. Horší naopak je, že pokud má člověk několik "kontejnerů", udržovat je všechny rozumně nastavené, aktuální a zabezpečené může být oříšek. To k bezpečnosti zrovna dvakrát nepřispívá. Jeden pravidelně aktualizovaný systém (například se SELinuxem) může být nakonec bezpečnější než deset zanedbaných kontejnerů a popelnic.
Předpřipravené docker kontejnery, na kterých se dá vyzkoušet třeba nějaký zajímavý software, jsou samozřejmě bezva; nic proti nim. Tohle už je spíš věcí osobní volby. Já preferuju jednoduché povolení démona v systemd, nastudování konfigurace a úpravu konfigurace do podoby, které rozumím. Předpřipravený kontejner nikdy nebude fungovat navlas přesně tak, jak chci/potřebuju, a jakmile bych do něj musel vrtat, už se mi (časově) mnohem víc vyplatí spustit si službu prostě rovnou na serveru.
21.9.2017 15:53
http://www.abclinuxu.cz/poradna/linux/show/428435. A bylo mi doporučeno tyto potenciálně nebezpečné aplikace pouštět izolovaně v kontejnérech, že pak ten útočník napáchá škody jen v tom kontejnéru a ne v celém systému. A je pak jednodušší napadnutý kontejnér odstavit nebo obnovit nebo přeinstalovat a nemusím přeinstalovávat celý server, tak jak to musím udělat nyní.
Aby byl za 5 minut napadený znova…
Možná to přece jen vyžaduje víc než kontejnery a restart.
Původní tazatel hovoří o domácím serveru. To je asi nejjednodušší odpověď na všechny uvedené námitky a otázky.
Aktualizace neřeším. Řeší je za mě balíčkovací mazažer a maintaineři balíčků, podle gusta a potřeby buď každou hodinu, každý den nebo každý týden.
Nezažil jsem nikdy, opravdu ani jednou, že by nějaký balíček (na Archu, Fedoře, Tumbleweedu) byl "blokovaný". Vlastně ani nevím, co si mám pod tím pojmem představit.
Samozřejmě, že pro vývoj a testování jsou kontejnery velice užitečné, přesně z těch důvodů, které zmiňuješ — například potřebuju něco narychlo vyzkoušet s několika různými verzemi knihoven, různými distribucemi, několika verzemi různých stacků a databází a podobně. Přesně tam se kontejnery skvěle hodí. Nebo chci někomu předvést nějakou složitou aplikaci a nechci se zoufale snažit podporovat balíčky pro všechny dostupné aplikace — přesně na to se hodí docker kontejner, protože pak stačí, aby to fungovalo v jedné distribuci (a neočekávalo něco neobvyklého od kernelu).
Ale pokud jde o kontejnery na domácím serveru … řekl bych, že je celá řada mnohem užitečnějších věcí, do kterých se dá na domácím serveru investovat čas a úsilí.
4.10.2017 01:58
Josef Kufner | skóre: 70
Pokud se i tak chceš zaobírat Dockerem, zauvažuj nad docker compose. Kontejner by měl obashovat ideálně jednu službu. Taky bych se díval na nějakou orchestraci.
Osobně používám Docker na serverech pro testing a produkční servery. Ale doma, bych ho asi nepoužil.
Místo toho, aby jsi řešil bezpečnost tvého serveru, tak budeš restarovat kontejnery...Nechápu proč mi pořád předhazujete, že nechci nebo že neřeším bezpečnost. Vždyť to je to, o co mi tady celou dobu jde. Jen nevím, jak to udělat, protože nejsem linux expert.
Nehledě na to, že nějak postrádám vstupní hrdlo, do Tvé sítě, tj. třeba revezní proxy. Rozhodně bych nevystavoval kontejnery s přímou viditelností na net.To jsem tam nekreslil. Před tím vším mám ještě router.
Na domácí server je Tvé řešení s prominutím zhovadilost. Ani nechci vědět na co to mášCo bych tam měl mít? Mám tam přesně to co jsem napsal. Co se ti na tom nezdá?
Ten Webmin je v kontejnerech zbytečný, neboť kontejnery se konfigurují off-line. Jinak bys je musel konfigurovat po každém restartu znovu.Toto bych potřeboval trochu vysvětlit. Co to znamená, že se konfigurují off-line? A proč bych je musel po restartu konfigurovat znovu? Konfigurace v kontejnéru nezůstane?
MySQL by mělo stačit v jednom samostatném kontejneru ... Totéž platí i pro Apache s PHP.Na toto jsem se ptal hned v úvodu, protože nevím co je lepší, jestli kontejnéry úplně na vše a prolinkovávat je nebo dělat kontejnerové "balíčky". Tak jsem zvolil balíčky, protože mě přišlo, že takto to bude všechno nakonfigurované unitř balíčku a hotovo. Že to prostě bude snazší, ale asi je to blbost, takže raději samostatné kontejnéry.
4.10.2017 02:08
Josef Kufner | skóre: 70
machinectl shell kontejner a máš shell v daném kontejneru. Nebo systemctl -M postovni_kontejner restart postfix. Ta integrace je velice příjemně udělaná.
Btw, v kombinaci s btrfs se pak dají dělat pěkná kouzla (ephemeral kontejnery pomocí snapshotů).
5.10.2017 10:16
Queria Sa-Tas | skóre: 8
| Brno
hostname:80/mail/.* => localhost:82/ hostname:80/ => localhost:81 --''--:443 ...
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.