Docker konténereknek ip cím windows alatt

Virtualizáció

Sziasztok!

Egy kis ideje szenvedek már a dockerrel. Az lenne a célom, hogy a konténerek külön ip címet kapjanak amit a windows alól el is érek, tehát nem portokkal játszogatnék.

A linux hyper-v alól fut. Sokat vacakoltam, próbálkoztam mindenféle hálózati beállítással, de egyik esetben se sikerült külön ip címeken elérni a konténereket. Egymást se látták rendesen.

Végül próbaként megnéztem ezt linux alól. Ott minden varázslás nélkül működött minden. Olvasgattam is dockeres fórumokat ahol a linuxosok körberöhögték a windows-os meg mac-es felhasználókat, de csak most tapasztaltam konkrétan, hogy tényleg linux alatt megy jól.

Tud valaki valami megoldást a problémára? Gondolom itt az okozza a bajt, hogy beékelődik egy VM gép is a játékba, míg linux alatt nincs rá szükség.

  • 449 megtekintés

gondolom ezért nem
https://docs.docker.com/docker-for-windows/networking/#there-is-no-docker0-bridge-on-windows

de van valami régebbi komment, hogy windows alatt az ott létrejövő docker-es hálózatot kézzel piszkálva lehet valamit javítani rajta
https://forums.docker.com/t/bridge-with-docker-for-windows/30936/3

( rascy | 2019. 11. 24., v – 18:03 )

Mit szeretnél a külön IP címekkel megoldani?
Éles rendszerről vagy fejlesztői környezetről van szó?
Utóbbi esetben én nginx proxy-t használok és local-ban felvett külön domain-eket.
 

Fejlesztői környezetről lenne szó. Én is gondoltam erre amit írtál, csak kicsit nyakatekert egy megoldás lenne, mert rendszeresen frissíteni kell a proxy konténer alatt a domaineket és forward-okat. (ez mondjuk egyszerűbb ha egy git repóból kéri le mindig az init folyamán, van is ilyen rendszerem, csak akkor szopó ha épp nem érhető el a git repó)

Mondjuk eddig a konténerek között se sikerült megtalálni egymás ip-jét (pl egy apache szervert), bár valszeg én csináltam rosszul valamit.

nem értem miért kellene mindig frissíteni, illetve hogy miért kellenek az ip-k továbbra is mikor az adott konténer neve alapján elérhetőek a szolgáltatások
pl. az nginx konténer alól a php-t az adott konténer neve alapján: "fastcgi_pass phpfpm7:9000;"

használsz docker-compose.yml fájlt?

Egyeztessünk elsőnek, hogy tuti egy dologról beszélünk e.

Én arra gondoltam, hogy van egy proxy konténerem. 1.2.3.4 ip címmel ami müxik winfos alól is.

hosts alatt belövöm a domaineket az 1.2.3.4 -re. Azon belül pedig a domain alapján átirányítom a kérést egy másik konténerbe port-on keresztül.

Erre gondoltál te is?

Noh, de ehhez kell egy mapping, ami nálad az nginx alatt megy. Ha azt ki akarod bővíteni, akkor újra kell "forgatnod" az imagedat vagy kommitolsz egyet.

Nálam repo-ban vannak az image-k amiket mások is le tudnak tölteni. A cél, hogy rajtam kívül más kollégák is könnyedén lőhessenek be egy környezetet ami folyamatosan bővülhet, változhat.

Eddig erre a git-es megoldás volt a megfelelő. Pl egy konténerben az apache vhost-okat git-ből töltöm be az induláskor. Ezt lenne jó kiváltani. Ha bővültek a vhost-ok, csak a git-be kellett push-olni, nem kellett az image-t változtatni.

igen, ha új projekt jön be, akkor lemásolom egy korábbi projekt nginx beállítását (1 fájl) és átírom benne a host-ot
majd "docker-compose build", de mivel a Dockerfile-ban a config fájlok konténerbe másolása a legvégén van így az előtte lévő dolgokat cache-ből tölti be és a teljes build lefut 2-3 másodperc alatt

értem amit írsz, de nekem fura hogy teljes image-eket teszel repóba fejlesztői környezetben
nálam a docker-es környezethez tartozó fájlok külön repo alatt vannak és az egyes projektek megint külön repóban
és a projects mappa gitignore-olva van

docker
 - projects (.gitignore-olt, de így könnyen lehet hivatkozni rá a docker-compose.yml fájlban és mindenkinél egységes lesz)
    - project1
 - nginx
    - config
       - project1.conf
    - Dockerfile
 - .gitignore
 - docker-compose.yml

nem tudom mennyire érthető így, illetve mennyire beszélünk ugyanarról :)

Nálad mindig az aktuális fejlesztő létrehozza magának a konténert.

Az én esetemben ezt én teszem meg és a többi fejlesztő csak letölti és már futtatja is. Sajnos nem mindenki ért a dockerhez, vagy nem akar ilyenekkel foglalkozni, a cél, hogy tényleg 1 kattintással vagy pár paranccsal pillanatok alatt le lehessen húzni bármelyik fejlesztő gépére a környezetet és nem utolsó sorban teszt környezeteket is fel lehet majd így állítani belőle szervereken is.

Igen, az én esetemben:

  • lehúzza a "docker fejlesztői környezet" repot
  • aztán futat "docker-compose build" -et (ez nyilván sokáig tarthat, de csak az első alkalommal)
  • utána a project mappába lehúzza amivel dolgozik
  • végül "docker-compose up"

Ez csak két docker parancs.
És a docker build-et csak akkor kell újra futtatnia ha változik valami a környezet kapcsán.

Éles környezetben, pl. kubernetes esetén nyilván már más a helyzet, mivel ott bele kell másolni a kódokat az image-be, mert az kerül deploy-olásra, de azt a Gitlab CI-ban elég jól meg lehet oldani. Ott az image-k tárolására a Gitlab Container Registry -t lehet használni.

Fejlesztői környezetben szerintem nem kell hogy így legyen. Ott volume-ként fel lehet csatolni a host gép bármelyik folderét.
Nekünk volt olyan image ami 7-800Mbyte -os lett a sok php vendor miatt, amit azért egy git repo-ba feltolni elég sok és felesleges, mivel a composer install -al leszedi mindenki a saját gépére.

De persze az egész projekt és csapat függő is, szóval nektek lehet úgy jó ahogy most van :)