Dotaz: Využití Dockeru v domácím serveru.

[Pfemir]

Dobrý den,

protože byl můj domácí server, před nedávnem, napaden, jsem nucen provést kompletní přeinstalaci. Bylo mi doporučeno použít kontejnéry. Začal jsem tedy studovat "Docker" a v součastné době jsem ve stádiu, kdy dokážu kontejner vytvořit, nalikovat kontejnéry mezi sebou, atd. Prostě základy. Ještě předesílám, že nejsem zdatný linuxař, takže mi dost pomáhaji i různé GUI aplikace, tady konkrétně "Portainer".

Nyní bych potřeboval poradit jakým směrem se ubírat a vysvětlit nějaké věci co nechápu:

1) Na netu jsou ke stažení již hotové kontejnéry, např. "poštovní", kde už je vše v kupě, tzn. postfix, dovecot, roundcubemail, ... Je lepší použít takovéto hotové kontejnéry nebo dělat pro každou službu zvláštní kontejnér a nalinkovat je na sebe?

2) Pokud hotové kontejnéry, jak se pak provádí aktualizace? Skoro v každém kontejnéru běží PHP, SQL, atd., to pak budu muset v každém kontejnéru dělat aktualizace zvlášť nebo to lze nějak centrálně, popř. automaticky?

3) Jak jsem psal, hodně si pomáhám přes GUI aplikace a do teď jsem v podstatě celý server jsem nakonfiguroval přes Webmin. Je možné Webmin nějak nakonfigurovat, aby dokázal konfigurovat i aplikace v kontejnérech? Nebo ho musí instalovat do každého kontejnéru?

4) Nerozumím nastavení portů. Vytvořil jsem si kontejnér s Apachem a nastavil porty -p 81:80 -p 444:443, a kontejnér s Joomlou a porty -p 82:80 -p 445:443, atd. Takže když chci an apache, musím zadat ip_adresa:81, když na joomlu, tak ip_adresa:82. Má to být přístupné i z venku, takže bych potřeboval, aby to jelo přes port 80. Co bych měl nastavit, aby mi to fungovalo správně?

Děkuji za pomoc.

Odpovědi

[Pfemir]

Nikdo nedělá s kontejnéry? Nikomu se nechce diskutovat?

[k3dAR]

ja ne :) ale nadhotim ti jen dalsi tip, osobne kdyz bych chtel resit kontejnery, kouknu po LXC a pro naklikavani pouziju virt-manager kterej je podporuje a zaroven ho stejne uz pouzivam pro KVM virtualy :)

[Pfemir]

Na LXC jsem se také díval, ale jestli jsem to dobře pochopil, tak LXC je na virtualizaci celých operačních systémů a to já nechci viz. . Já chci v kontejnérech pouštět jen aplikace.

[dustin]

V dockeru máš také celý stack kromě jádra. Akorát se tam spouští pouze jedna aplikace. Mně osobně vyhovuje LXC podstatně víc, spustím si tam monitorovací procesy, nakonfiguruji aplikace tak, aby spolupracovaly atd. V dockeru musím vše zvenku a vnitřek je stejně Xkrát zduplikovaný v jednotlivých kontejnerech. Upřímně jsem výhodu nepochopil, ale asi jsem stará konzerva...

[chinook]

jak funguje virt-manager? Stale jej nechápu, musím pro něj mít nainstalované i grafické prostředí na server kde mám nainstalováno KVM, abych si vše naklikal, nebo se na něj nějak připojím z desktopového pc třeba virtualizovaného právě na tom KVM?

[OldFrog {Ondra Nemecek}]

Na serveru grafiku nepotřebujete, připojíte se tam vzdáleně pomocí virt-manageru.

[k3dAR]

virt-manager muze byt nainstalovan jen na stanici (teoreticky virtualizovane na Serveru s KVM), krome lokalnich KVM umoznuje pridat pripojeni pres SSH, pak uvidis na stanici virtualy ze serveru, budes je moci konfigurovat, pridavat/odebirat, zpristupnovat plochu/konzoli virtualizovanych OS... akorat nevim co rychlost, normalne pouzivam virt-manager na stejnem stroji kde mi bezi KVM, zkusil sem se pripojit pres internet jinam a rychlost je urcite horsi nez kdyz se pres VNC(v SSH tunelu) pripojim na plochu vzdaleneho serveru a tam pustim virt-manager lokalni...

[Andrej]

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.

[Pfemir]

Používám na serveru Joomlu, PHP, sambu a to, jak jsem se dozvěděl, jsou dost "děravé" aplikace a nedávno se ke mě, přes něco takového "děravého", někdo dostal. Diskutovali jsem o tom tady 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í.

[dustin]

Pokud si pamatuju, přes tu díru dělal něco venku, nespolupracoval s více aplikacemi. To bude fungovat v kontejneru úplně stejně, když bude web dostupný zvenku.

[Pfemir]

Ano spojoval se ven (resp. pořád spojuje, ještě jsem se toho nezbavil), ale nejdříve asi dostal něco dovnitř. Takže nevím kde co mám napadnutého a proto musím přeinstalovat vše (a z toho mám husí kůži, jen si na to vzpomenu). S těmi kontejnéry, by snad vše mělo zůstat čisté a stačilo by jen restartovat onen kontejnér. Což je, co se týká pracnosti a času, 100 a 1. Nebo to vidím moc růžově?

[dustin]

OK, read-only základ je v takové situaci opravdu výhodou.

[Kit]

Ten napadnutý kontejner Dockeru stačí jen restartovat.

[Andrej]

Aby byl za 5 minut napadený znova…

Možná to přece jen vyžaduje víc než kontejnery a restart.

[Juraj]

Jo to je super. Srát na bezpečnost, restarty vyřeší vše. Bliju z devops.

Na domácí server je lepší LXC. Smysl kontejnerů vidím v testování nebo třeba v cloudu, kde chci něco spustit dynamicky podle zátěže na spoustě nodech.

[Pfemir]

Ale já jsem nikde nepasal "srát na bezpečnost". Jenže někdy to prostě neuhlídáte. Např. díra v sambe byla 7 let. A až došlo k masivnímu napadání serverů (včetně mého), tak teprve pak se začaly vydávat patche. Takže v kontejérech vidím plus, že v takovém případě kontejnér se sambou vypnu, vemu čistou image (před napadením), aplikuji patch a znovu spustím. A pokud jde o LXC, mohl by mi někdo stručně říct v čem by byl přínos pro domácí server? Když bych měl server nainstalovaný "klasicky" a nebo v LXC kontejnéru, jaký by v tom byl rozdíl, co by mi to přineslo?

[dustin]

Pro jeden server mi to přijde zbytečné. Ale dělá se na ně perfektně konsolidace stávajících fyzických serverů. Což asi opravdu není problém domácího prostředí

[Pfemir]

Přesně takto jsem to také pochopil, proto jsem LXC zavrhl a začal se zajímat o Docker.

Abych se trochu pohl, protože potřebuji ten server dát co nejrychleji do kupy, mohl by mi někdo odpovědět na ty otázky co jsem uvedl v úvodu? Moc by mi to pomohlo.

Díky.

[Juraj]

Taky to sraní nebylo na tebe. Ty hledáš optimální řešení. Na LXC pohlížej v tvém případě jako na lepší chroot. Má výhodu v tom, že si přesně zvolíš co potřebuješ izolovat. Ale nastavovat si to musíš sám, s většinougui toolů skončíš stejně jako u dockeru, tj. u fat kontejneru.

Takže u tebe bych tam zavřel webový server, nastavil limity na cpu a síť, dal overlayfs nebo aufs nad soucasnym fs a samořejmě monitoring. Server potřebuje administrátora. Když ti tu joomlu někdo naboří, tak ti nesežere zdroje ani nebude řádit po zbytku systému.

Možná ještě lepším a jednoduším řešením pro tebe bude systemd-nspawn, ale s tím nemám zkušenosti.

[svido]

No, až budeš potřebovat na jednom serveru mít několik různých verzí DB, PHP, .NET core atd. Nedokáži si představit, že mám na serveru MySQL 5, MySQL 5.5, k tomu třeba nějakou alfa verzi MySQL, pak třeba PHP 5.4, PHP 5.6, PHP 7.1 a 7.2 apod.

Nehledě na CI, deployment atd. Je mnohem jednodušší použít Docker. Jak řešíš aktualizace? Dost často se stává, že jeden balíček potřebuje novější, ale je blokovaný. Díky kontejneru je plno věcí mnohem jednodušších. Nejsem bezpečnostní expert, ale myslím si, že pokud mi někdo položí jeden kontejner, neovlivní to nijak další - to by musel útok pokračovat. Kdežto, pokud budu mít všechno v primárním systému, položí to celý systém.

Kdyby byla ta "móda" špatně či k ničemu, proč tedy je tedy AWS a obecně cloud řešení s kontejnery tak oblíbené?

[Andrej]

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í.

[xxl]

No já osobně bych nějaké oddělení od základního systému zvolil. Například systemd-container. Dneska je to ve většině distribucí a neznamená to nainstalovat hafo závislostí. A to oddělení umožní tazateli vyzkoušet si ty věci, které ho zajímají, tak nějak nanečisto. Když něco v kontejneru zvoře, tak prostě udělá nový kontejner, zatímco hlavní systém zůstane nezměněný. A netvrdím, že je to zázračné bezpečnostní oddělení, netvrdí to ani hoši od systemd.

[Josef Kufner]

Tak zrovna na domácím serveru se bez kontejnerů neobejdu, neboť spectrum je starý krám a systém chci mít novější. Ono se to nezdá, ale trocha virtualizace se hodí i na docela malých serverech a práci to ušetří.

[2017]

Jo jdi do kontejneru. Docker jsou kontejnery a obalem. Dnesni LXD/LXC 2.x je docela vymakany. Jde ovladat i pres rest api, ale ja to stejne resim pres konzolu.

Kdyz to das na ZFS nebo BTRFS ziskas i levne snapshotovani celych kontejneru zvenku.

Rychlost je jako by to bezelo na tom samym zeleze (sdili se vse a je to oddeleno pres cgroups).

[Pfemir]

Příloha:

• schema.pdf (26475 bytů)

Uff vy mi dáváte. V každém postu hafo zkratek, které si musím vygooglit, abych pochopil, co mi vlastně říkáte. Ale OK, aspoň si rozšiřuji znalosti. Akorát je problém, že se stále posouvám "do šířky" (rozšiřuji si znalosti), ale vůbec ne dopředu.

Proto jsem zkusil namalovat obrázek, kde jsem se snažil znázornit co konkrétně potřebuji. Jestli by jste se tedy na to mrkli a řekli mi, jestli je to dobrá cesta, popř. co bych měl udělat jinak.

Výcházím tedy z toho, že použiji Docker. Na obrázku je:

a) Base systém - to asi nepotřebuje komentář.

b) Kontejnér 1 - poštovní server Postfix. Přes Dovecot stahuje poštu z internetových poštovních schránek a ukládá na disk, proto musí mít přístup na disky. Vlastní SMTP server tam nemám (to jsem nedokázal rozchodit), používám SMTP svého providera.

c) Kontejnér 2 - tady běží Joomla a Phoca (fotogalerie - rozšiřující modul pro joomlu). Konejnér musí být přístupný z internetu. On sám na internet asi nemusí. Musí mít přístup na poštovní kontejnér, protože odesílá e-maily a také musí mít přístup na disky, protože tam běží scripty (v PHP), které na disky ukládají data a také čtou, spracovávají a posílají do Joomly (zobrazují se grafy)

d) Kontejnér 3 - to je webserver na kterém mi běží robot v PHP. Tento kontejnér by neměl být přístupný z internetu, ale on na internet musí. Musí mít přístup na poštovní kontejnér, protože odesílá e-maily.

e) Kontejnér 4 - Samba to je asi jasné.

Nevím jestli v každém kontejnéru musím mít Webmin, proto ty otazníky.

Předem děkuji za trpělivost a za pomoc.

[svido]

Nevím, ale na to co chceš, je Docker k ničemu. Místo toho, aby jsi řešil bezpečnost tvého serveru, tak budeš restarovat kontejnery... To mi opravdu nepřijde správně.

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. Na domácí server je Tvé řešení s prominutím zhovadilost. Ani nechci vědět na co to máš

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.

[Pfemir]

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á?

[Kit]

Ten Webmin je v kontejnerech zbytečný, neboť kontejnery se konfigurují off-line. Jinak bys je musel konfigurovat po každém restartu znovu.

MySQL by mělo stačit v jednom samostatném kontejneru, neboť má vlastní virtualizaci. Takhle jen plýtváš pamětí. Totéž platí i pro Apache s PHP.

Nedej na řeči, že doma virtualizaci nepotřebuješ. Celé by se to sice dalo udělat i bez virtualizace, ale všichni máme potřebu si hrát.

[Pfemir]

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.

[Kit]

Kontejner si vždy poskládáš z jednotlivých komponent a nakonfiguruješ. Když je hotovo, tak si jeho image uložíš. Jakékoli změny za běhu kontejneru se ukládají na vrchol do dalšího kontejneru. Pokud tuto sestavu neuložíš jako nový image, tak jsou tyto změny po restartu původního image zahozeny. Považuj to za výhodu - celá konfigurace se nachází v jednom souboru, který se snadno upravuje.

Můžeš Apache s PHP a MySQL uložit do jednoho kontejneru. Pokud však spustíš dva takové kontejnery současně, databázi sdílet nebudou. Zpravidla však chceme, aby databázový stroj byl sdílený. Je to otázkou volby. Zkus si to nakreslit do vrstev.

[Pfemir]

Diky za vysvětlení. Teď už asi chápu jak to funguje.

[Josef Kufner]

Vybodni se na Docker a na klikátka.

Úplně nejjednodušší je nahodit systemd-nspawn a pomocí debootstrap a btrfs subvolume si vytvořit minimální systémy pro jednotlivé kontejnery (tj. žádné image, jen adresář). Pak do kontejneru nainstalovat dbus, aby fungovalo machinectl a máš vystaráno. Pak prostě jen nainstaluješ tu službu v kontejneru namísto v hostitelském systému, postup však je jinak stejný. Pak už jen uděláš 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ů).

[Pfemir]

No nějaké grafické rozhraní a klikátka bych tam potřeboval. Minimálně na nějaký servis, atd. Konkrétně webmin je pro mě nepostradatelný. Např. s postfixem jsem se trápil hodně dlouho a až přes webmin a videa na youtube se mi konečně zadařilo (nicméně SMTP se mi ani tak nepodařilo).

A nejde jen o nastavení, ale i o provoz, servis, ... Opět uvedu příklad, čas od času potřebuji třeba založit nového uživatele nebo nastavit heslo, protože staré jsem zapomněl, atd. Ano jde to přes příkazovou řádku a ani to není složité, ale protože to potřebuji jednou za čas, tak si to prostě nepamatuji a musel bych to googlit. Takhle nahodím webmin a už jen klikám vytvořit, smazat, změnit, ....

S tím souvisí otázka, jak to tedy s tím webminem vyřešit. Pokud jej chci, musím ho strčit do každého kontejnéru nebo to jde udělat i nějak jinak?

Ještě, co se týká kontenjnérů, tak se pokouším postupovat dle návodů Perfect media 2016 a Perfect media 2017, které jsou pro mě docela srozumitelné, tak uvidím jak to dopadne, jestli se dopracuji k funkčnímu serveru.

[Queria Sa-Tas]

ber tohle spíš jako tipy resp. drobné info ohledně tvých otázek, předesílám že nespravuji žádný kontejnerizovaný server/datacentrum ani nic podobné, a tudíž to může být i celkem mimo, jen můj osobní pohled v tuhle chvíli (a vzhledem k tomu kolik jsem toho napsal už se mi to nechce víc kontrolovat/formátovat tak předem sorry za chyby)

ad1) hotové či vlastní container images:

• hotové mohou ulehčit práci, pokud dostačují tvým potřebám (většinou si projdu jejich Dockerfile apod abych zjistil jak jsou sestaveny a jestli to odpovídá mému nastavení / nebo vypadá i lépe), dále mohou usnadnit 'aktualizaci'
• vlastní máš pod větší kontrolou, můžes si služby přeházet více jak chceš, máš kontrolu nad jednotlivými vrstvami (image fslayers/blobs) tudíž můžes mít rychlejší sestavení, méně zabraného místa na disku ...., musíš si je aktualizovat/sestavit aktualizovanou verzi sám
• hlavně, vlastní můžes postavit nad existujícími hotovými (např. začneš svůj joomla Dockerfile 'FROM joomla:3.8-apache'), a přidáš si za to vlastní modifikaci (např nakopírování vlastních konfig souborů, doinstalování extra pluginů/balíčků ...), čímž získáš jak solidní základ (např. https://hub.docker.com/_/joomla/ ale netuším jestli ten zrovna je vhodný či ne, určitě existují další), tak i trvalý záznam o tebou provedených úpravách pro pozdější aktualizaci/obnovení (uchovej si své složky pro všechny kontejnery, s tvými Dockerfiles a všemi soubory co tam kopírují/spouští atd, někde v repozitáři [git/hg/bzr/svn/...tar.gz/zip/...])
• pro pochopení tohoto způsobu práce viz např. https://github.com/joomla/docker-joomla/tree/master/apache samotný - to je v podstatě vše co popisuje joomla kontejner, zbytek přenechávají na nad/podřazeném image php:5.6-apache
• ohledně nalinkování apod tebou odkazovaný blog 'perfect media' zmiňuje docker-compose, nemám s ním zkušenosti ale mohl by to usnadnit

ad2) aktualizace: docker image mají tagy, nejčastěji asi podle verzí, za předpokladu že máš u každého kontejneru data správně uložená mimo něj (volume, resp volume v jiném [mysql,...] kontejneru) a neprovedl si žádné další ruční úpravy uvnitř kontejneru (tzn nic jako `docker exec joomla echo debug=yes > /etc/neco.cfg), mělo by pouze zastavení kontejneru a spuštění nového používající novější image s využitím stejných parametrů stačit na 'aktualizaci' (zde samozřejmě závisí na změnách v daném sw mezi starou/novou verzí a ve změnách v kontejneru samotném [přejmenování parametrů v dockerfile apod])

ad3) gui:

• ohledně gui/webui nemohu říct vůbec nic, snad jen že osobně se jim snažím vyhnout co to jde, preferuji vlastní sady skriptů/konfigů (a tudíž cli/etc soubory/api/... cokoliv co mohu lehce uchovávat zaznamenané v git repozitáři)
• obzvlášt bych byl opatrný s čímkoliv stylu webadmin, který má vlastně za úkol měnit obsah a nastavení služeb uvnitř běžících kontejnerů (nastavení apache httpd) což v případě kontejnerizace je spíše nežádoucí přístup (Dockerfile pro daný image by to měl řešit, správné nastavení služby příp. umožnit parametrizaci při spouštění kontejneru nebo připojení konfigů jako volume viz. https://hub.docker.com/_/httpd/ kde např. vloží konfiguraci do finálního image `COPY ./my-httpd.conf /usr/local/apache2/conf/httpd.conf` (při sestavení vlastního image odvozeného od httpd:2.4)
• samozřejmě pro účely stylu zaznamenání nového uživatele do db to může být vhodné - umístit do vlastního kontejneru jako kteroukoliv jinou aplikaci

ad4) nastavení portů:

• pre: určitě existují i jiné způsoby, a dost možná i jednodušší, jen je zatím neznám, o tohle jsem se nepokoušel
• na samotný base systém (nebo do jiné kontejneru prolinkovaného s ostatními) bych umístil haproxy/nginx/apache provádějící proxy mapování stylu:

    hostname:80/mail/.* => localhost:82/
    hostname:80/ => localhost:81
    --''--:443 ...
    

• na finálním :80 přístupném z venku mít nějaký velmi jednoduchý/jednoduchý reverse proxy který to rozřadí tam kam to patří, pokud apache či něco takového mocnějšího, dal bych si pozor na minimální&&bezpečnou konfiguraci [žádné moduly jako php apod zde, pouze to nezbytně nutné, raději bych volil některý z jednodušších sw zaměřených a používaných k tomuto účelu]. např. ten docker-compose vypadá že by s tímto mohl pomoci - rychlý google search: https://blog.hypriot.com/post/docker-compose-nodejs-haproxy/#running-multiple-container-with-docker-compose )

--- ještě tipy/názory nakonec:

• možná to není tak důležité, ale v já osobně bych si zvolil jakou distribuci [debian/fedora/centos/suse...] bych chtěl mít jako základ kontejnerů (mohlo by jich být i víc pokud mám aplikace pro které je jiná výrazně vhodnější, ale snažil bych se počet držet co nejblíže 1.), na nich bych postupně vrstveně stavěl: základní distro -> nastavení logování/monitoring/zabezpečení -> extra nástroje pro debug -> hlavní služby [apache či apache_php, mysql, mail*] -> jendotlivé app [joomla, ...]
• tak abych obecně nemusel mít apache zvlášt konfigurován/instalován dvakrát [spuštěn bude vícekrát, ale pouze jeden apache/php/ image, z něj následně vycházející všechny ostatní co ho využívají] ...
• zjednodušsí hromadné změny ve všech službách (jedno místo které upravit, rychlejší rebuild všech apod)
• zmanená to ale víc práce a také mozná více starání o to jak/kdy aktualizovat

ohledně schema.pdf který jsi poslal, služby skládat individuálně do kontejnerů né společně!

• kontejner1: mysql
• kontejner2: apache_php_jedna_web_app
• kontejner3+: --''--_druha_web_app
• kontejner4: apache_php_joomla
• kontejner5: apache_php_phoca // pokud to není pouze plugin/součást té jedné joomla instance, neznám
• kontejner4: roundcubemail
• kontejner5: postfix/...?
• ...

není to zcela nutné pravidlo, ale obecně jeden kontejner==jedna-služba==jedna-aplikace.

samozřejmě máš-li obavu o dostupnost služeb, a mysql by mohl být centrální point-of-failure pro velkou část z nich, tak (kromě zálohování dat) můžes samozřejmě mít pro kazdou službu (či skupiny) vlastní instance mysql, dle potřeby (ale nechával bych ji určitě zvlášt ve vlastních kontejnerech kde pak jediný způsob komunikace z napadené php aplikace je skrz mysql protokol)

mj. obzvlášť si pohlídej to logování, aby logy z jednotlivých služeb běžících v kontejnerech končily mimo ně (ať už na --bind /var/log/cont/sluzba1, nebo přes remote syslog/journald apod) jinak při jejich aktualizaci/restartu atd o to můžeš přijít

a také - aby žádná jiná služba co máš přímo na base systému (nfs, portainer, docker, ...) nebyla vůbec nijak dostupná (max např. pouze localhost, můžeš využít ssh port forward pro sebe, a ověřit aby se k nim nedalo přistoupit ani z kontejnerů, jsou to pouze tvé vlastní pomocné služby), dostupné z venku/kontejnerů pouze kontejnerizované služby, jinak si tím narušíš celou tuto snahu

[Pfemir]

Moc děkuji za obsáhlé info. Sice jsem z toho, zatím, úplně mimo, ale zkusím to nějak zpracovat. Hlavně vygooglit si nějaké tutorialy, konkrétní příklady, abych to pochopil, apod. Určitě mi tento tvůj komentář hodně pomůže.

Ještě jednou díky.