Fórumok
Üdv!
Ha jól olvasom, akkor a Docker-ben nincs olyan bridge lehetőség, mint pl. az LXC-ben?
Tehát a hoszt gépen át kell irányítani portokat, csak úgy érhető el a Docker konténer kívülről?
Üdv!
Ha jól olvasom, akkor a Docker-ben nincs olyan bridge lehetőség, mint pl. az LXC-ben?
Tehát a hoszt gépen át kell irányítani portokat, csak úgy érhető el a Docker konténer kívülről?
Hozzászólások
nem jól olvasod
Alapból a bridge drivert használja, ez ok:
$ sysctl net.ipv4.conf.all.forwarding=1
$ sudo iptables -P FORWARD ACCEPT
Tegnap este kipróbáltam, de kivülről (LAN-ból) nem látszódott a konténer.
De kipróbálom este újból.
LAN: 192.168.1.0/24, docker konténer: 172.17.0.2
Mert így nem is kell neki.
Ha "expose"-olod a portot, azt kiköti a host IP-jére. Ha nem, akkor egy belső, sehova ki nem kötött bridge-en lóg.
Igen, elvileg az is megvolt. Este kipróbálom... köszönöm!
De akkor mégsem úgy kezeli a bridge-t, mint az LXC. Tehát ki kell expose-olni a megfelelő portokat. A konténer IP-je (közvetlen) nem lesz látható a LAN-ban(?).
Alapból egy belső bridge van a docker containerek számára, tehát ők és a host elérik egymást layer2 szinten, de a fizikai hálózatot nem. Azt csak NAT-tal érik el, ezért kell a port forward (expose), ha a container felé akarsz forgalmat irányítani.
Amit te akarsz, arra több lehetőség van:
-host networking (ilyenkor lényegében a container nem container-izálja a network namespace-t, a benne futó processzek a host interfészeit és a host ip-jét látják.)
-macvlan, talán ez áll közelebb ahhoz, amit akarsz
Akkor jól olvastam a doksiban, hogy nem egészen úgy megy a bridge, mint az LXC esetén.
Nem baj, igazából ennek van egy előnye, hogy izoláltan vannak a konténerek a külső hálózattól.
Es ha kulon bridge-t csinalsz a containerekre akiknek nem kell egymast "latniuk" (docker network create ...; docker run --network newnetwork) akkor raadasul meg egymastol is a kulombozo project-ek (persze ha valamit publish-elsz a hostra az elerik majd by default).
Az EXPOSE meg nem "koti ki" a portot a host IP-jere a default bridge network driver-rel. Publish (-p option for docker run) kell hozza.
Jogos, pongyolán fogalmaztam
Nem igazán működik:
docker run -d -p 81:80/tcp --name centos7-srv2 --hostname centos7-srv2 centos7:test
El sem indul a konténer.
docker version
Client:
Version: 1.13.1
API version: 1.26
Package version: docker-1.13.1-62.git9cb56fd.fc29.x86_64
Go version: go1.11beta2
Git commit: accfe55-unsupported
Built: Wed Jul 25 18:54:07 2018
OS/Arch: linux/amd64
Server:
Version: 1.13.1
API version: 1.26 (minimum version 1.12)
Package version: docker-1.13.1-62.git9cb56fd.fc29.x86_64
Go version: go1.11beta2
Git commit: accfe55-unsupported
Built: Wed Jul 25 18:54:07 2018
OS/Arch: linux/amd64
Experimental: false
Dockerfile?
Mi a konténer fő processze? Ha nincs folyamatosan futó valami, akkor jogosan lép ki.
Úgy vettem észre, hogy expose nélkül simán megy: "-p 81:80/tcp"
:(
A play-with-docker.com oldalon is tesztelgettem, de ugyanaz.
A "docker run ..." nem indítja el, mindig kilép. A "docker create ..." szépen működik.
Nem egészen értem hogy miért... :(
Ahhoz hogy segiteni tudjunk szukseg lenne tobb informaciora.
1) Dockerfile publikus? Ha igen megoszthatnad velunk
2) mit latsz, ha -d nelkul inditod?
3) ha elnevezed a containert (--name) es az egyszer megallt anelkul hogy eltorolted volna (--rm a docker run-nal vagy docker rm contanername miutan megallt) akkor nem tudod ugyanazon a neven elinditani amig nem torolted a regit. (bar errol eleg egyertelmu hibauzenetet kapsz)
4) docker log mit ir a containerrol miutan megallt (de meg altszik a docker ps --all kimeneteben)?
Bocs...
# Dockerfile:
# docker build -t centos7:test .
# Base image
FROM centos:7
# Author:
MAINTAINER Demo < demo @ gmail.com >
# expose ports:
EXPOSE 80 443 22
# volume
VOLUME /myvol
# ---- end of Dockerfile ----
$ docker events &
[1] 10393
[gabor@fedoranb docker-centos7]$
[gabor@fedoranb docker-centos7]$
[gabor@fedoranb docker-centos7]$
[gabor@fedoranb docker-centos7]$ docker run -p 81:80/tcp -p 444:443/tcp --name centos7-2 --hostname centos7-2 centos7:test
2018-12-21T18:46:17.072016941+01:00 container create 60a674d2d837a9515504ec00fb522923842cd169eaaa975c8f7c9e8b9f2f96cf (image=centos7:test, name=centos7-2, org.label-schema.build-date=20181205, org.label-schema.license=GPLv2, org.label-schema.name=CentOS Base Image, org.label-schema.schema-version=1.0, org.label-schema.vendor=CentOS)
2018-12-21T18:46:17.080795512+01:00 container attach 60a674d2d837a9515504ec00fb522923842cd169eaaa975c8f7c9e8b9f2f96cf (image=centos7:test, name=centos7-2, org.label-schema.build-date=20181205, org.label-schema.license=GPLv2, org.label-schema.name=CentOS Base Image, org.label-schema.schema-version=1.0, org.label-schema.vendor=CentOS)
2018-12-21T18:46:17.794554591+01:00 network connect 50ebf7168ce82f91ee166310e45c0c13e17626ef657f780a5c43c27397abdc6b (container=60a674d2d837a9515504ec00fb522923842cd169eaaa975c8f7c9e8b9f2f96cf, name=bridge, type=bridge)
2018-12-21T18:46:17.841740468+01:00 volume mount a32e7d6184db0d023db6d403c7ef822967613d88badfc66ad9efdf6912d25d60 (container=60a674d2d837a9515504ec00fb522923842cd169eaaa975c8f7c9e8b9f2f96cf, destination=/myvol, driver=local, propagation=, read/write=true)
2018-12-21T18:46:18.305069579+01:00 container start 60a674d2d837a9515504ec00fb522923842cd169eaaa975c8f7c9e8b9f2f96cf (image=centos7:test, name=centos7-2, org.label-schema.build-date=20181205, org.label-schema.license=GPLv2, org.label-schema.name=CentOS Base Image, org.label-schema.schema-version=1.0, org.label-schema.vendor=CentOS)
2018-12-21T18:46:18.305744139+01:00 container die 60a674d2d837a9515504ec00fb522923842cd169eaaa975c8f7c9e8b9f2f96cf (exitCode=0, image=centos7:test, name=centos7-2, org.label-schema.build-date=20181205, org.label-schema.license=GPLv2, org.label-schema.name=CentOS Base Image, org.label-schema.schema-version=1.0, org.label-schema.vendor=CentOS)
[gabor@fedoranb docker-centos7]$ 2018-12-21T18:46:18.812727324+01:00 network disconnect 50ebf7168ce82f91ee166310e45c0c13e17626ef657f780a5c43c27397abdc6b (container=60a674d2d837a9515504ec00fb522923842cd169eaaa975c8f7c9e8b9f2f96cf, name=bridge, type=bridge)
2018-12-21T18:46:19.402535089+01:00 volume unmount a32e7d6184db0d023db6d403c7ef822967613d88badfc66ad9efdf6912d25d60 (container=60a674d2d837a9515504ec00fb522923842cd169eaaa975c8f7c9e8b9f2f96cf, driver=local)
Hibát nem látok...
A docker create siman megy:
# docker create -t -i -p 81:80/tcp -p 23:22/tcp --name centos7 --hostname centos7 centos7:test
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
20a80ea300df centos7:test "/bin/bash" 7 seconds ago Exited (0) 3 seconds ago centos7-2
4c7546530620 centos7:test "/bin/bash" 41 minutes ago Exited (0) 12 minutes ago centos7
Az a problemad, hogy lenyegeben nincsen service ami folyamatosan futna a containeredben. A default CMD a centos:7 base image-ben a /bin/bash (https://github.com/CentOS/sig-cloud-instance-images/blob/a77b36c6c55559…). Tehat lenyegeben a containered egy bash-t inditana. Viszont ehhez kell tty (-t/--tty) es interactiv mod (-i/--interactive=true) a docker run commandhoz.
$ docker run centos:7
$ docker run -ti centos:7
[root@27cfdc4a352c /]
Aztan, attol, meg hogy te EXPOSE-olod a portokan nem lesz service ami futna a containeren belul. Ezeket neked kell elinditani amikor a container elindul. Latom, hogy szeretnel SSH-t is. Ez nem igazan javasolt. Az indito post-bol ugy gondolom hogy LXC hatterrel josz. A containerekhez teljesen mas szemlelet kell mint az LXC-hez. Gondolj a containerre ugy, hogy egy sima Linux process, ami isolalva van namespace-ek segitsegevel es ami tartalmaz minden dependency-t. Ha ezt mindig eszben tartod akkor konnyebben fogod a best practiceket kovetni.
Az EXPOSE-ok alapjan valami webservert szeretnel csinalni. Ehhez javaslom a kovetkezo image-et amit a RH sracok raknak ossze es igen jol megcsinaltak security best practice szempontbol:
https://hub.docker.com/r/centos/httpd-24-centos7
Köszönöm!
A network már megy, csak a "docker run ..." zavart. A -i hiánya volt a hiba! :) Meg1x thanx!
Nm.
Amennyiben ragaszkodsz hozza, hogy a centos:7 legyen a base imaged, akkor kell valamilyen service-et installalnod a dockerfile-ban (RUN yum install httpd....) es definialni, hogy hogyan inditod el (CMD httpd -D FOREGROUND etc.). Ezek hianyoznak a Dockerfile-odbol.
Az megvan, kösz. De a /bin/bash alapból fut benne.
Nem fut, csak elérhető. Futtathatod.
Gábriel Ákos
Adott egy beágyazott HW eszköz, ami raw ethernet frame-eket (L2) bocsát ki magából. A type mező értéke nem szabványos, mivel házi protokollt használunk (beacon, low level management az eszközökön). Adott a vezérlő SW (linux), ami ezeket a raw ethernet frame-eket veszi, illetve önmaga is ki tud adni ilyeneket (pl. beacon). A HW eszközök által kibocsátott beacon frame-eket látva tud egy listát készíteni az adott switchen lévő eszközökből. Hasznos, bevált.
Ha a vezérlő SW-t (linux) átteszem egy docker konténerbe (linux hoston), akkor ezek a L2 raw ethernet frame-ek nem jutnak el hozzá, így a SW nem tud automatikus felderítést végezni a HW eszközök között. A konténer a docker default bridge networkinget használja. Minden (docker host, HW eszköz) ugyanazon a switchen van.
A cél az lenne, hogy a konténerben futó SW megkapja a raw ethernet frame-eket a konténeren kívüli, de ugyanazon a switchen lévő HW-től.
(A konténerben futó SW által kibocsátott ugyanolyan raw ethernet frame-ek látszódnak a host gépen)
Láttam, hogy szóba jöhet esetleg host vagy macvlan networking használata, de egy kicsit bonyolultnak tűnik a bekonfigurálása. A konfigurálást szerelők fogják végezni, és emiatt nem lehet túl bonyolultra terveznünk.
Valami egyszerű megoldás kéne ;) Amúgy arra is nyitott vagyok, hogy docker helyett más konténerizálót használjak (lxc?), ha azzal ez egyszerűbben oldható meg.
Kösz a segítséget!
Lehet számodra az a legegyszerűbb, ha a host networking-et használsz.
docker run --net=host ...
Így a konténered megkapja a host hálókártyáit, és azt csinál amit akar.
Ha mindenképpen hálózati szétválasztást akarsz, akkor a HW-nek add meg default gw-ként a docker host-ot, és target-nek meg a docker container IP-jét. Ez persze csak akkor fog menni, ha egy subnet-en vannak.
A SW a konténerben ráül bizonyos TCP és UDP portokra; ha host networkinget használok, akkor sejtésem szerint nem fog tudni több példány futni az SW-ből, igaz? Mivel egyszerre nem ülhetnek rá többen ugyanazokra a portokra...
Lehet érdemes lenne szétvágni akkor 2 konténerre (microservices buzzword), 1 aki a hallgatózik a raw ethernet-re, és a több aki meg a docker bridge mögött fut.
Illetve, még mindig ott van a default GW-s megoldás.....
Kiderítettem, milyen üzleti elvárások vannak a szoftver felé, és gyakorlatilag a raw ethernet frame-ek által biztosított többletre szinte sosincs szükség, így ezt a problémát nem is kell annyira megoldani. Ha mégis, akkor a docker run --network=host ... indítással host networkingre vált az adott konténer, így látja ezeket a csomagokat is, viszont így egyszerre csak egy példány futhat a SW-ből, mert az meg ráül bizonyos TCP/UDP portokra.
Ez így nagyjából most meg is felel egy ideig.
Köszönöm a segítséget mindenkinek!
Ha van ilyen követelmény, hogy több instance-nak is kell futnia, akkor ez mégegy érv a macvlan mellett.