Saját hálózati cím a konténernek: mit ad, és mi az ára

Az alapértelmezett felállás a következő: a konténer a gazdagép címén osztozik, és portszámon keresztül érhető el. Egyszerű, biztonságos, és a munka nagy részéhez elegendő.

Van, amikor mégsem elég, és ezek az esetek előre láthatók.

Amikor a portszám kevés

Két alkalmazás ugyanazt a számot kéri. Az egyik átkerül másik számra, aztán az alkalmazás által előállított hivatkozások nem viszik magukkal ezt a számot, és összekuszálódik a dolog.

Az alkalmazás hirdeti magát a hálózaton. A nyomtatók, a médialejátszók és az okosotthon eszközök megtalálása önhirdető üzenetekkel működik. Ezek az üzenetek nem élik túl a portleképezést. Az alkalmazás bejelenti magát, de a hirdetett cím a gazdagép címe, és a túloldal nem éri el.

Az alkalmazásnak szerepelnie kell a router eszközlistájában. Azért, hogy fix címet kapjon, hogy külön tűzfalszabály készüljön rá, hogy a forgalma önmagában látszódjon. Portleképezéssel az az alkalmazás a hálózat szemszögéből nem létezik, csak a gazdagép.

A másik út: saját azonosság a konténernek

A konténer saját hardvercímmel jelenik meg a hálózaton, saját címet kap a routertől, és úgy ül az eszközlistában, mint egy fizikai eszköz.

Ezt hallva az első reakció rendszerint az, hogy "akkor miért nem így csinálja mindenki". A válasz az árban van.

Első ár: a gazdagép nem éri el a saját konténerét

Ez lepi meg a legtöbbeket, és rendszerint akkor derül ki, amikor a munka már készen van.

A hálózat minden eszköze eléri azt a konténert. Az a gazdagép, amelyik futtatja, nem.

Az ok logikus: mindkettő ugyanazt a fizikai csatolót használja, és a forgalom nem jön vissza a switchről. A gazdagép kiküldi a csomagot, és a csomag nem tér vissza a saját kártyájára.

A következmények hétköznapiak: a gazdagépen futó állapotellenőrzés nem éri el az alkalmazást, ugyanazon a gépen egy másik konténer nem tud csatlakozni hozzá, egy megírt szkript nem működik. Mindez úgy, hogy kívülről a hálózat hibátlannak látszik.

Van rá megoldás, de az egy külön darab: a gazdagépen nyitni kell egy második virtuális csatolót ugyanarra a kártyára, és a konténer címére szóló forgalmat ezen keresztül kell irányítani. Telepítés után a gond eltűnik, de mivel ráadás elem, ha kimarad, senki nem érti, miért.

Második ár: elfogy egy valódi cím

Minden konténer elhasznál egy címet a hálózatból. Tíz alkalmazás tíz címet jelent. Kis hálózaton gyorsan elfogynak a címek.

Ráadásul ha a cím bérelt, meg is változhat. Változáskor minden, ami rá hivatkozik, köztük egy korábban megírt szabály is, csendben rossz helyre mutat.

Harmadik ár: a hálózati kártya és a tűzfal

A kártyának egynél több hardvercímet kell elfogadnia. A vezeték nélküli kapcsolatok többsége nem fogad el, és néhány virtuális környezetben ez alapból tiltott. Döntés csak tesztelés után.

A tűzfal pedig mostantól olyan eszközt lát a hálózaton, amelyet nem ismer fel. Az üzemeltetőnek ez egy konténer, a szabályokat író embernek egy hétköznapi eszköz. Ez önmagában nem baj, de ha kimondatlan marad, egy nap valakit összezavar.

A cím kevés, név is kell

A címmel rendelkező, de név nélküli alkalmazás csak fél siker. Címet senki nem akar fejben tartani.

Ahhoz, hogy a név megjelenjen a hálózaton, valaminek el kell végeznie ezt a munkát. Az alkalmazás saját image-e általában nem tartalmaz ilyen részt, és nincs is rá ok: egy adatbázis image-e nem arra való, hogy a hálózaton hirdesse magát.

A szabály

A portleképezés számot ad egy ajtónak. A hálózati azonosság állampolgárságot ad.

Állampolgárság csak akkor jár, ha a hálózatnak valóban eszközként kell kezelnie azt az alkalmazást. Ha nem kell, a portszám egyszerűbb is, biztonságosabb is.

Mit csinál az Atlas

Amikor az Atlas ezt beállítja, nem nyúl az alkalmazás saját image-éhez. Az alkalmazás mellé nyit egy kis segédet, és a segéd az alkalmazás hálózati vermén osztozik. A címet a segéd kéri el a routertől, és a nevet is a segéd hirdeti a hálózaton.

Ez az összekapcsolás szándékos, és két dolgot ad. Az alkalmazás image-ének nem kell tartalmaznia sem címkérő klienst, sem névhirdetőt. És mivel a hálózati verem az alkalmazásé, az alkalmazás leállásakor a segéd is vele együtt szűnik meg, így nem marad árva konténer.

A gazdagép nem éri el a saját konténerét problémára a fent leírt híd települ, méghozzá szolgáltatásként, így a gazdagép újraindulása után magától újraépül.

Amit igazán érdemes elmondani, az egy hiba, amely élő tesztelés közben derült ki ebben a hídban.

A híd útvonalat nyitott a konténer címére. De nem törölte az eltűnt konténer útvonalát. Egy újraindítás után egy ideiglenes cím útvonala ottmaradt. A következmény: ha később egy másik eszköz kapja meg azt a címet, az annak szánt forgalom a hídba terelődik. A hiba tehát nem a konténert érinti, hanem a hálózat egy ártatlan harmadik szereplőjét.

A javítás az volt, hogy a híd ne csak útvonalakat hozzáadó elem legyen, hanem olyan is, amely törli azokat az útvonalakat, amelyekhez már nem tartozik élő konténer.

Az általános tanulság, és ez a hálózatokon kívül is áll: a hozzáadás a könnyebbik fele. Egy útvonal, egy szabály, egy leképezés állítás a világról. Ha a világ megváltozik, a vissza nem vont állításból hazugság lesz, és rendszerint nem azt sújtja, aki tette, hanem valakit, akinek semmi köze hozzá.