A Docker alapértelmezett pooljának módosítása nem számozza újra a hálózatokat

A default-address-pools módosítása nem számozza újra a már meglévő hálózatokat, és éppen ennek a várása az, ami egy gondos tervet váratlan kieséssé változtat. A beállítás azoknak a hálózatoknak az automatikus kiosztását szabályozza, amelyek a démon új konfigurációval történő újraindítása után jönnek létre. Minden, ami már fut, megtartja a kapott alhálózatot, mert az az alhálózat a hálózat tárolt definíciójának része. A mítosz kényelmes, mert azt sugallja, hogy egyetlen módosítás minden átfedést megold, a valóság pedig kétrészes munka: válasszon egy valóban szabad tartományt, majd migrálja azokat a hálózatokat, amelyek nem azok.

A mítosz: egy pool-módosítás megoldja az átfedést

A mítosznak meghatározott formája van. Valaki olvassa, hogy a Docker alapértelmezett poolja módosítható, módosítja, újraindítja a démont, és arra a következtetésre jut, hogy a konténerhálózat már nem ütközik az irodai VPN-nel. A régi hálózat még mindig ott van, még mindig csatlakoztatva, és még mindig tartja az ütköző címet.

Ami változott, az a kiosztó jövőbeli viselkedése, ami valóban hasznos és valóban korlátozott. A kifejezett --subnet nélkül létrehozott új hálózatok az új poolból vágódnak ki; a meglévők soha nem voltak abban a poolban. Az újraindítás nem építi újra a hálózatokat, és nem mozgat konténereket közöttük. Ha a tünet a változtatás után is fennáll, a változtatás valódi volt, a diagnózis pedig hiányos.

Alaptartomány és kiosztott előtag

A konfigurációnak két mezője van, amelyeket könnyű összekeverni. A base az a tartomány, amelyből a kiosztó vág, a size pedig az egyes kiosztott hálózatok előtaghossza, így a 10.10.0.0/16 alap 24 mérettel /24-eket oszt ki azon a /16-on belül. A szerepek felcserélése nem szándékolt kiosztási mintát eredményez, általában egyetlen hatalmas hálózatot vagy kimerült poolt.

A pool foglalás, nem bizonyíték. A Docker elkerüli azokat az ütközéseket, amelyeket a gazdagép útválasztási táblázatában lát, és nem lát egy olyan VPN-t, amelyhez még nem csatlakozott.

Ez a korlát az egész oka a szándékos választásnak. Az összehasonlítandó tartományok azok, amelyeket a gazdagépnek el kell érnie: az irodai LAN, a vállalati VPN belső alhálózatai, a labor vagy a staging előtagjai és bármely más konténergazdagép ugyanazon az overlayen. Írja le őket CIDR-ként, mielőtt hozzányúl a démonhoz, mert a fejben tartott lista éppen azt hagyja ki, amelyik számít. Ezután válasszon olyan alapot, amely egyikkel sem fed át, és tartsa a listát a telepítés mellett, hogy a következő ember ne ismételje meg a gyakorlatot emlékezetből.

Vegyen számba, mielőtt választ

Először vegye számba, ami létezik. A docker network ls listázza a hálózatokat, a docker network inspect bridge -f '{{.IPAM.Config}}' pedig kiírja az alhálózatot, amelyet egy adott hálózat használ. Ismételje meg minden felhasználó által meghatározott hálózatra, mert a Compose-projektek sajátot hoznak létre, és a compose-fájlban szereplő kifejezett --subnet teljesen megkerüli a poolt.

Az utolsó pont az, amely túléli a migrációt. A pool módosítása nem akadályozza meg egy kollégát abban, hogy 172.18.0.0/16-ot rögzítsen egy compose-fájlban, és az ütközés más szerzővel tér vissza.

A már létező elemek migrálása

A meglévő hálózatok migrálása külön, támogatott művelet. Minden érintett hálózatot újra kell hozni az új alhálózattal, ami azt jelenti, hogy az azt használó konténereket le kell választani és újra csatlakoztatni, a hálózat újrahozása pedig eltávolítja a konténer-csatlakozásokat ahelyett, hogy átmozgatná őket. Őrizze meg a köteteket és a konfigurációt, és tekintse az újrahozást telepítésnek, nem adat-visszaállításnak. A munkát karbantartási ablakban végezze, mert az újrahozott hálózat konténerei újraindulnak, akár tervezte, akár nem.

Kövesse a dokumentált démonkonfigurációt és újraindítási eljárást, és hangolja össze a megszakítást. Egyetlen démonnal rendelkező gazdagépen a systemctl restart docker az újraindítási szabályzataik szerint indítja újra a konténereket, és ezt a viselkedést érdemes előbb ismerni, mint utóbb.

Ezután ellenőrizze a két dolgot, amelyet a módosításnak meg kellett volna oldania. Vizsgálja meg az új alhálózatot a docker network inspect segítségével, és erősítse meg, hogy a választott alapon belül van, majd ellenőrizze az útvonalat egy reprezentatív VPN-célhoz a ip route get 10.20.30.40 segítségével, és erősítse meg, hogy oda megy, ahová várja, és nem egy hídba. Tesztelje a szolgáltatásfelderítést és a konténerek közötti kommunikációt is, mert egy más címzéssel újrahozott hálózat a névfeloldást olyan módon törheti el, ami alkalmazáshibának látszik.

Mi törik még utána

A tartós rész a nyilvántartás. Tartsa a kiosztási listát, a választott alapot és méretet, valamint az újrahozott hálózatokat ugyanott, ahol a telepítést.

Attól, hogy egy tartomány privát, még nem biztonságos újrahasználni. A 10.0.0.0/8 privát, és egyben a legvalószínűbb dolog, ami már valahol az útvonalon használatban van, ezért a válasz egy konkrét foglalás, nem egy blokk preferálása. A Docker hálózati dokumentációja leírja az automatikus alhálózat-kiosztást és a pool mezőit. A tartományt aszerint válassza, mit kell elérnie, nem aszerint, mi néz ki rendesen.