Podman (docker) hálózat éles környezetben

Virtualizáció

Üdv,

É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?

  • 573 megtekintés

( Rt711 v | 2022. 12. 04., v – 15:33 )

Szerkesztve: 2022. 12. 04., v – 15:36

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.

 

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.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( igor | 2022. 12. 04., v – 21:09 )

Szerkesztve: 2022. 12. 04., v – 21:19

nemide

( asm v | 2022. 12. 04., v – 22:32 )

Szerkesztve: 2022. 12. 04., v – 22:33

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.

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.

( makgab v | 2022. 12. 18., v – 21:13 )

Tesztelném a dolgot:

  • létrehoztam az image-t kedvenc disztribemmel
  • 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?