ahoj, mam dotaz, jak tagujete image? nemyslim tim vycet tagu, ale jak to provadite? jako parametry do docker build? nebo delate cely scenar, tzn 'docker build, docker images | grep, docker tag'?

ten scenar mi prijde prehlednejsi (misto nekonecnyho docker build radku), ale resim, jak spravne identifikovat ten cerstve vyrobeny image .. ono to totiz muze byt soucast nejaky CI pipeline, takze tam tech imagu bude videt vic, muze se jich nekolik buildit paralelne atp, takze se neda spolehnout na latest .. a tak mne napadlo, ze si pred spustenim docker build vygeneruju unikatni hash, jim to otaguju zaroven s buildem, a pak tenhle hash pouziju pro filtrovani v 'docker images' .. je to nesmysl? da se to udelat jednoduseji? pac takhle mi to bude do privatni repo sypat i ten unikatni tag, ne?

RAGNAROK:
uz asi vim musim pouzit funkci:
ips, err := net.LookupIP("receiver")

ADM
delam to v go:
potrebuju nejak dostat adresu do funkce net.WriteToUDP(b []byte,addr *UDPAddr).
Zkousel vsechno mozny porad mi to psalo write udp [::]:3000->%UDP:2000: sendto: cannot assign requested address"

ADMIX:
tak jsem objevil toto a maka to :-D konecne:
Alejandro Celaya | Blog — Software development, agile methodologies and open source projects
https://blog.alejandrocelaya.com/...c-ip-addresses-to-docker-containers-created-with-docker-compose/

Zdravim nemuzu prijit na to jak nastavit sit pro 2 kontejnery ktere mezi sebou komunikuji pres UDP:
Container sender posila UDP packety ktere by mely dojit k Receiver conteineru. Receiver by mel prijmout packet a odpovedet na adresu ze ktere prijmul UDP packet. Kdyz pustim obe apky bez dokru tak to funguje. Kdyz napisu apku, tak ze receiver a sender jsou v jedne apce tak to funguje. Kdyz je ale poustim zvlaste v dockeru s nasledujicim docker-compose tak sender posila UDP na adresu 127.0.0.1:3000 ale receiver nic neprijme. Nevedel by nekdo prosim?

version: '3'
services:
  receiver:
    image: receiver:latest
    environment:
      Laddr: "127.0.0.1:3000"
    ports:
      - "3000:3000/udp"
    links:
      - sender

  sender:
    image: sender:latest
    environment:
      Laddr: "127.0.0.1:2000"
      Raddr: "127.0.0.1:3000"
    ports:
      - "2000:2000/udp"

ADM: díky za postrčení, byl jsem unavenej a nedošlo mi, že jsou jednodušší cesty jako třeba bind portu... :-)

MLEKAR_STEIN: o co presne ti jde? do kontejneru forwardujes z hosta port, to standardne zajistuje docker-proxy, ktery ten port binduje na hostovi a portforwarduje sluzbe v kontejneru, a muzes si urcit i na jakym IP rozhrani, a nebo si muzes sluzbu v kontejneru rovnou bindnout na host port a obejit docker-proxy, pokud pouzijes network host mode

dotaz k sítím v dockeru v compose.
verzi dockeru mám poslední, compose taky.

dostal jsem za úkol, jako nouzové řešení
udělat aby kontejnery byly vidět na vnější adrese serveru v rozsahu, ve kerém ten vnější adaptér serveru je.
není mi moc jasné, jak na to vytvořit "bridge síť" nebo jak jinak se s tím poprat.

díky moc.

ADM: jj, ve swarmu slouží healthcheck jen jako indikátor, zda má swarm kontejner restartovat. That's all. Žádnou cross container logiku bych tímhle neřešeil.

RUDOLF: jasne, ja tam nakonec dam nejaky shell healthcheck renatomefi/php-fpm-healthcheck (pouziva fastcgi binarku), akorat me zarazilo ze v single docker-compose to funguje (a je to defakto lepsi healthcheck, protoze je to vlastne nadmnozina co do testovanych podminek), ale to je jen takovy vedlejsi efekt.

bohuzel ve swarm mode je pokud to dobre chapu mozny healthcheck jen na localhost (dns name neni zaregistrovan dokud neprojde healthcheck), coz je takovy dost ... no .. ne uplne idealni, oproti kubernetes, kde jsou rovnou 2 typy healthchecku a hlavne jsou z hlediska containeru externi.

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