ADM: nejsme stopro jistej, jestli jsem tě dokonale pochopil, tak odpověď podle toho vypadá.

ve swarmu healthcheckuju jen sám sebe (tj. localhost), je tam možnost i delayed healtchecku, než to všechno naběhne.. logika je v tom, že swarm restartuje jen kontejner, který healtcheckuje..

ad nginx a upstream služeb, správné je používat hostnames - defaultně je to název služby v compose definici a pak ještě můžeš přiřadit aliasy..

nejak se nemuzu vymotat ze zavislosti v docker swarm modu, modelovy priklad, fungujici v single docker-compose:

mam v docker-compose 3 sluzby, nginx http frontend a 2 php fcgi backendy. z hlediska komunikace jsou hostnamy jmena tech sluzeb, dejme tomu service-http, service1-php a service2-php, kvuli healtcheckum tech php-fpm sluzeb a taky kvuli tomu ze ty php-fpm mohou komunikovat uvnitr mezi sebou navzajem pres http, ma nginx frontend na sobe jeste network aliasy service1-http a service2-http.

na php-fpm sluzbach je healthcheck jako GET http://service1-http/, tedy taze se sam sebe pres ten nginx fontend (ktery pro service1-http pouzije fcgi backend ten ktery se pta, tedy service1-php:9000). potud vse funguje v single docker-compose, ovsem ve swarm stack modu stejna kompozice nefunguje, protoze service1-php se do interniho dns dostane az v okamziku, kdy projde healthcheck, ktery samozrejme neprojde, protoze nginx na nej nevidi, dokud neni v dns.

neprisel jsem na to co s tim, snad nahradit ten healthcheck necim co pobezi v ramci localhostu pouze pres fastcgi, ale neni to uplne idealni. pouzit v ramdi definice network v docker-compose ip adresy natvrdo taky neni mozny, nginx si pri startu kontroluje vsechny upstream definice a kdyz nebezi, tak uz je neservicuje, proto se jako adresy upstream fastcgi pouziva hostname

WOODMAKER: jo, tak ta poslední věta není tak úplně pravda, fakt doporučuju si přečíst todle: WOODMAKER

URPUTNIK: resp da se v dockerfilu vynutit, aby ten nasledujici prikaz nekesoval? na SO to obchazi pres argument, ktery se vlastne nepouzije, ale je pokazde 'jiny' ..

dobre rano, tak dalsi dotaz .. kontext: mejme aplikaci, ktera potrebuje nejakou konfiguraci (pripojeni na dalsi aplikace, nastaveni poplatne lokalizaci) .. lokalizace jsou 'stejne' (tzn napriklad anglicka lokalizace je stejna, nehlede na prostredi kde se to bude poustet), ale pripojeni dal je prostredi poplatne .. mam v planu udelat image, ktery posklada aplikaci a v poslednim kroku buildeni image se vybere lokalizace podle parametru a vyrobi se konkretni 'lokalizovany' image .. nastaveni poplatne prostredi se pak primountuje ve chvili, kdy se image pousti .. coz ale znamena, ze budu vyrabet napr 5 ruznych variant 1 image (pro kazdou lokalizaci jiny image) .. dotaz: ma smysl, jejich build radit za sebe seriove (tzn ze docker prvni zbuildi, od druhyho vezme z kese vsechno az na lokalizaci (pokud je v buildeni image posunem do pozdnich 'layer')), nebo paralelne (tam se zas zredukuje cas buildu, pac se budou ty image buildit paralelne) .. predpokladam ze obecna odpoved neni, je to asi poplatne obsahu dockerfile .. souhlas?

a dalsi, predpokladam ze klonovani napriklad git repository pri buildu image neni vhodne, coz? protoze nam se to chova tak, ze docker povazuje ten layer za stejny a reusne ho z predchoziho buildu, misto aby naklonoval aktualni repo .. takze 'spravne' bude to klonovani udelat 'vne docker buildu' a vysledek dovnitr nakopirovat?

ADM: snaha se ceni :) ale nemusis se s tim trapit, privatni repo v nexusu + docker hub proxy + group proxy na pull se mi podarilo nakonfigurovat .. a pushuju teda s nasim 'namespace' (funguje i bez)

URPUTNIK: docker-registry-url/namespace/image:tag tak ten namespace se pouziva u nekterych docker-registry jako forma autorizace (namespace tedy spis jako projekt), ale nexus to prave neumi, ten umi udelat vice 'hosted' registry jen na ruznych portech (coz asi pujde nejak skryt za loadbalancerem) ale kazdy projekt ma tedy jiny push url, a aby to jeste vic zamotali tak jde nad tim udelat jednotny pull docker 'group' registry (ktery zaroven jeste muze byt proxy dockerhubu). nikde jsem to nevidel poradne vysvetleny ale docker registry pry nic jako cestu/namespacy neumi (docker login nedelas na url ale na hosta) to delaji ty frontendy nad tim (treba docker-regisry v kubernetes to prave mapuje na namespacy).

URPUTNIK:
ono na contejneny nemusis mit docker, isolovat muzes ruznymi zpusoby - treba na urovni cgroup ... nebo zminenych namespacu. Docker drepi nad tim, dodava tomu hezke pozlatko a velky go-runtime :) -> v tomhle ohledu mi aktualne prijde hezci podman (nema ten go-runtime) ale jeste jsem si neudelal definitivni nazor

URPUTNIK: kazdopadne to teda znamena, ze pro praci s privatni repo bude ta repo vzdycky soucasti cesty :/ mozna bych se dal provest nejaky MitM dns 'workaround', ale uz jsem si to sam zamitnul :)
DEFILA: prijde mi, ze miris nekam do vnitrnosti dockeru, kam moje knowhow nesaha .. rozhodne ne takhle v noci :)

URPUTNIK:
ale vsak pojem namespace je spravny, kernel netusi co je to container - pouziva namespace(s) :)

MARTEN: aha, jasny .. popravde ted nevim, z jakyho clanku to 'namespace' mam, myslel jsem ze to nadepisuje 'docker image(s)' pro sloupec, ale je tam jenom 'repository', co je pro mne teda taky zavadejici, ale to uz vem cert :)

URPUTNIK: ah, staci spravne zformulovat otazku .. tak "b" to jde pres docker CLI manifest, i do privatni repo .. kazdopadne tam teda namespace neni :/

tak prece jen dotazy

a) kde je receno, jaky namespace ma dany image? v manifestu? a z druhe stranu? kdyz klient stahuje image? aka neni mi jasne, proc nekdy fungujou 'zkraceny url' (aka 'docker pull nginx', pritom by to melo byt 'docker pull library/nginx' :/ mozna je to nejakej legacy resolving pro starsi verze?
b) do se nejak do nexusu3 dostat custom image manifest? mozna pres API ..