Administrace komentářů

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