Éles környezetben is átirányítjatok a portokat? (NAT alapján lát ki a konténer a külső hálózatba.)
Vagy milyen hálózat beállításokat használtok?
Hozzászólások
Az attól függ mit csinál ez a konténer, pl ha olyan szolgáltatás amit interneten keresztül érnek el más alkalmazások vagy egyenesen a felhasználók akkor a következő működik (aws specifikus):
Egy vpc.
Négy subnet (két privát, két publikus).
Privát subnetek a natgw-n keresztül látnak ki internetre (lehet másképp is, de most egyszerűsítek és ez az ajánlott egyébként is).
Load balancer a publikus hálóba, A és B subnetbe (Application Load Balancer, Network Load Balancer, or Classic Load Balancer).
Privát hálóban futó konténer szolgáltatás (mondjuk ECS, de lehet EC2-n is akár ha nagyon szükséges) regisztráljuk a loadbalancerhez target-group -on keresztül, természetesen itt is két hálózatba osztva az erőforrások.
Health-check -et beállítjuk.
Loadbalancer-re rakunk Route53 bejegyzést A record-al.
Az általam vázolt esetben csak a loadbalancernek van publikus IP-je és privát hálózatban hostolt konténereknek továbbítja a lekérdezéseket.
A konténernek vagy az azt hostoló bárminek publikus IP-je lenne akkor nagyon gyorsan kicsúszna a kezed közül az irányítás mert megkerülnék a loadbalancert és egyenesen a konténerre kapcsolódnának.
Egy ilyen tervezési hiba rengeteg problémához vezetne pl hotspot vagy épp nem tudsz majd frissítést kitolni mert az IP nem változhat, konténer vagy épp azt hostoló gép nem indulhat újra, stb.
Amit fent leírtam az működik virtuális gépek EC2-n futó konténerek vagy AWS ECS esetén is.
Kubernetes -nél hasonló, ott képtféleképp oldhatod:
Ingress -szóval egy pod ami majd L7-en belenyul és tolja a forgalmat a megfelelő szolgáltatás felé.
Load Balancer - ilyenkor a bejövő forgalom a service IP-jére van továbbbítva (AWS és GCP is tud ilyet alapból).
Lényeg a lényeg, tökmindegy milyen porton van a szolgáltatás egészen addig míg van előtte valami ami ezt elrejti a rendszer használói/felhasználói elöl és standard portokról engedi a forgalmat a szolgáltatás felé.
Amit fentebb leírt az nem kubernetes specifikus, docker-compose rendszert is üzemeltetek így, a PHP/Java/Python alapú cucc belül fut, ahogy akar, docker belső hálón kommunikálnak, és kifelé csak egy ngixn kontínernek van expose-olt 80/443 portja, ott terminálja pl a HTTPS-t és továbbítja bentre a forgalmat.
De még sima AWS EC2 instance-ok között is mehet így, privát IP-je van csak, neked van egy custom NAT gw-ed, ami terminál egy mgmt VPN-t, meg vannak ELB/ALB, ami terminálja a HTTP/HTTPS-s kifelé, befelé meg be van lógatva a EC2 gépek VPC-jébe.
Egy kontenernek (Podnak) ket okbol sem szerencses, ha kozvetlenul a host networkhoz csatlakozik:
ket ugyanilyen kontener nem tud egyazon host-on/node-on futni, mert az elso fogja a portot, a masodik mar nem tud bindolni ra
1024 alatti port hasznalatahoz root/elevated jogkor szukseges, ami security szempontbol nem szerencses
Ezert jobb az, ha a kontenerek privat halozatra kapcsolodnak (magas, akar randomizalt porttal) es van egy folottes loadbalancer/ingress, ami a public halozatbol a kontenerek fele iranyitja (proxy-zza) a forgalmat. Ezen a szinten lehetoseg van a TLS terminalasara is, igy a konteneren belul mar nem kell azzal foglalkozni.
Én csak pl. arra gondoltam, hogy van egy squid, httpd, mysql konténer. A squid, httpd látszódik a hálózatból közvetlenül. Igen, ezzel lehetnek biztonsági problémák.
Inkább maradnak a konténerek egy privát hálózatban és a portot irányítjuk át. Tehát közvetlenül nem teszitek ki a konténereket a publikus hálóba.
Nagyban fugg attol, hogy mennyire kritikus a rendszer. Ha van barmilyen redundancia a kontenerek szintjen, akkor mindenkepp kell egy loadbalancer ele, akkor mar lehetnek a kontenerek privat halon.
Ha csak egy szal httpd-t szeretnel kitenni a netre, akkor persze csinalhatsz mindenfele shortcutokat, peldaul nem kell loadbalancer ele, es kirakod public IP-vel, de akkor (ahogy mar fentebb irtak) egy egyszeru kontener restart kiesest fog okozni.
megvan a Dockerfile, egy squid proxy-t tesztelnék. A fizikai gép tartományába tenném a konténer IP címét (192.168.1.0/24).
Létre kellene hoznom egy network-ot? De hogyan?
$ podman network ls
NETWORK ID NAME DRIVER
2f259bab93aa podman bridge
$ podman network create --subnet 192.168.1.0/24 --gateway 192.168.1.254 --driver bridge newnet
Error: subnet 192.168.1.0/24 is already used on the host or by another config
Vagy hogyan kellene a konténert a helyi hálózatba tenni?
Hozzászólások
Az attól függ mit csinál ez a konténer, pl ha olyan szolgáltatás amit interneten keresztül érnek el más alkalmazások vagy egyenesen a felhasználók akkor a következő működik (aws specifikus):
Egy vpc.
Négy subnet (két privát, két publikus).
Privát subnetek a natgw-n keresztül látnak ki internetre (lehet másképp is, de most egyszerűsítek és ez az ajánlott egyébként is).
Load balancer a publikus hálóba, A és B subnetbe (Application Load Balancer, Network Load Balancer, or Classic Load Balancer).
Privát hálóban futó konténer szolgáltatás (mondjuk ECS, de lehet EC2-n is akár ha nagyon szükséges) regisztráljuk a loadbalancerhez target-group -on keresztül, természetesen itt is két hálózatba osztva az erőforrások.
Health-check -et beállítjuk.
Loadbalancer-re rakunk Route53 bejegyzést A record-al.
Itt azért még érdemes elgondolkodni azon hogy a verziókat hogyan fogod kezelni, pl lehet Application Load Balancer esetén request header filter szabály vagy Route 53-al másik loadbalancer mint target.
Tehát a publikus konténer IP címe egy publikus tartományban van ilyenkor.
Az általam vázolt esetben csak a loadbalancernek van publikus IP-je és privát hálózatban hostolt konténereknek továbbítja a lekérdezéseket.
A konténernek vagy az azt hostoló bárminek publikus IP-je lenne akkor nagyon gyorsan kicsúszna a kezed közül az irányítás mert megkerülnék a loadbalancert és egyenesen a konténerre kapcsolódnának.
Egy ilyen tervezési hiba rengeteg problémához vezetne pl hotspot vagy épp nem tudsz majd frissítést kitolni mert az IP nem változhat, konténer vagy épp azt hostoló gép nem indulhat újra, stb.
Ha jól értem, akkor te inkább kubernetes rendszerre gondolsz.
Nem, ez pontosan igy mukodik ECS eseten vagy EC2-n siman kezzel/compose-zal futtatott docker containerekkel is.
Amit fent leírtam az működik virtuális gépek EC2-n futó konténerek vagy AWS ECS esetén is.
Kubernetes -nél hasonló, ott képtféleképp oldhatod:
Ingress -szóval egy pod ami majd L7-en belenyul és tolja a forgalmat a megfelelő szolgáltatás felé.
Load Balancer - ilyenkor a bejövő forgalom a service IP-jére van továbbbítva (AWS és GCP is tud ilyet alapból).
Lényeg a lényeg, tökmindegy milyen porton van a szolgáltatás egészen addig míg van előtte valami ami ezt elrejti a rendszer használói/felhasználói elöl és standard portokról engedi a forgalmat a szolgáltatás felé.
Amit fentebb leírt az nem kubernetes specifikus, docker-compose rendszert is üzemeltetek így, a PHP/Java/Python alapú cucc belül fut, ahogy akar, docker belső hálón kommunikálnak, és kifelé csak egy ngixn kontínernek van expose-olt 80/443 portja, ott terminálja pl a HTTPS-t és továbbítja bentre a forgalmat.
De még sima AWS EC2 instance-ok között is mehet így, privát IP-je van csak, neked van egy custom NAT gw-ed, ami terminál egy mgmt VPN-t, meg vannak ELB/ALB, ami terminálja a HTTP/HTTPS-s kifelé, befelé meg be van lógatva a EC2 gépek VPC-jébe.
Blog | @hron84
via @snq-
nemide
https://docs.docker.com/engine/reference/commandline/network_create/
Ezt még tanulmányozom.
🙂
Egy kontenernek (Podnak) ket okbol sem szerencses, ha kozvetlenul a host networkhoz csatlakozik:
Ezert jobb az, ha a kontenerek privat halozatra kapcsolodnak (magas, akar randomizalt porttal) es van egy folottes loadbalancer/ingress, ami a public halozatbol a kontenerek fele iranyitja (proxy-zza) a forgalmat. Ezen a szinten lehetoseg van a TLS terminalasara is, igy a konteneren belul mar nem kell azzal foglalkozni.
Ez rendben van. Egy portot egy konténer használ.
Én csak pl. arra gondoltam, hogy van egy squid, httpd, mysql konténer. A squid, httpd látszódik a hálózatból közvetlenül. Igen, ezzel lehetnek biztonsági problémák.
Inkább maradnak a konténerek egy privát hálózatban és a portot irányítjuk át. Tehát közvetlenül nem teszitek ki a konténereket a publikus hálóba.
Nagyban fugg attol, hogy mennyire kritikus a rendszer. Ha van barmilyen redundancia a kontenerek szintjen, akkor mindenkepp kell egy loadbalancer ele, akkor mar lehetnek a kontenerek privat halon.
Ha csak egy szal httpd-t szeretnel kitenni a netre, akkor persze csinalhatsz mindenfele shortcutokat, peldaul nem kell loadbalancer ele, es kirakod public IP-vel, de akkor (ahogy mar fentebb irtak) egy egyszeru kontener restart kiesest fog okozni.
Loadbalancer minták (ilyesmire gondoltok):
https://towardsdatascience.com/sample-load-balancing-solution-with-dock…
https://docker-docs.netlify.app/docker-cloud/apps/load-balance-hello-wo…
Public cloudba deployolnad? Mert akkor mindenkepp az ottani LB szolgaltatasok kozul erdemes valasztani.
AWS-re mar fentebb megirtak: https://hup.hu/comment/2859015#comment-2859015
Tesztelném a dolgot:
Létre kellene hoznom egy network-ot? De hogyan?
Vagy hogyan kellene a konténert a helyi hálózatba tenni?
sehogy. a portot kell csak kihúzni amin a service fut, pl: -p 3128:3128
Ezt tudom, hogy a portot expose-oljuk.
De ki lehet tenni közvetlenül a helyi hálózatba.
Mcval network kell hozzá, de csak ezért fölös, jó az a bridge a port mappinggal szerintem.
De ki lehet tenni közvetlenül a helyi hálózatba.
Ki, csak
- nem úgy, ahogy gondolod,
- nincs túl sok értelme.
Csak ki szeretném próbálni
podman run --network host
és máris a hostgép hálózata lesz a konténer hálózata
Aha... a konténerből a fizikai gép interfészeit látom.
--network host esetén értelmetlen a -p, anélkül is eleve a host interfészére fog bindolni, mivel a host interfésze egyben a konténer interfésze is
Ok, jogos.