Att ge en container en egen adress i nätverket: vad du vinner, vad du betalar
Du kan publicera en container med egen adress i stället för med ett portnummer. Vinsten är verklig och det är priset också, och det senare upptäcks oftast efter bygget.
AtlasPVE ·
Den här artikeln svarar på
- docker container egen ip-adress
- docker macvlan vad är det
- docker macvlan värden når inte containern
- docker container syns inte i nätverket
- docker ge ip i stället för port
Standarduppställningen är denna: containern delar maskinens adress och du når den via ett portnummer. Det är enkelt, det är säkert, och för det mesta arbetet räcker det.
Det finns fall där det inte räcker, och de går att förutse.
När ett portnummer inte räcker
Två program vill ha samma nummer. Du flyttar det ena till ett annat nummer, och sedan bär inte de länkar som programmet själv skapar det numret, och det blir rörigt.
Programmet annonserar sig i nätverket. Att hitta skrivare, hitta mediespelare, hitta enheter i det smarta hemmet: det fungerar med självannonserande meddelanden. De meddelandena överlever inte portöversättningen. Programmet annonserar sig, men adressen det annonserar är maskinens, och motparten når det inte.
Du vill se programmet i routerns enhetslista. För att ge det en fast adress, skriva en egen brandväggsregel, se dess trafik separat. Med portöversättning finns det programmet inte för nätverket; bara maskinen finns.
Den andra vägen: ge containern en egen identitet
Containern syns i nätverket med sin egen hårdvaruadress, får sin egen adress från routern, och står i enhetslistan som en fysisk apparat.
Första reaktionen är oftast "varför gör inte alla så". Svaret ligger i priset.
Pris ett: maskinen når inte sin egen container
Det här överraskar mest, och upptäcks oftast när arbetet redan är klart.
Alla enheter i nätverket når den containern. Maskinen som kör den gör det inte.
Skälet är rimligt: båda använder samma fysiska gränssnitt, och trafiken kommer inte tillbaka från switchen. Maskinen skickar ut paketet, och paketet återvänder inte till dess eget kort.
Följderna är vardagliga: en hälsokontroll som körs på maskinen når inte programmet, en annan container på samma maskin kan inte ansluta, ett skript du skrivit fungerar inte. Allt detta medan nätverket ser felfritt ut utifrån.
Det finns en lösning, men den är en extra del: öppna ett andra virtuellt gränssnitt på maskinen kopplat till samma kort, och låt vägen till containerns adress gå den vägen. När den är installerad är problemet borta, men eftersom det är ett tillägg förstår ingen någonting om det glöms bort.
Pris två: du förbrukar en riktig adress
Varje container förbrukar en adress ur ditt nätverk. Tio program betyder tio adresser. I ett litet nätverk når du gränsen snabbt.
Dessutom kan adressen ändras om den är ett lån. När den ändras pekar allt som fästs vid den, inklusive en regel du skrivit, tyst på fel ställe.
Pris tre: nätverkskortet och brandväggen
Kortet måste acceptera fler än en hårdvaruadress. De flesta trådlösa förbindelser gör det inte, och vissa virtuella miljöer kommer med det avstängt. Bestäm dig inte utan att testa.
Och din brandvägg ser nu en enhet i nätverket som den inte känner igen. För dig är det en container; för den som skriver reglerna en vanlig apparat. Det är inget problem, men lämnat osagt kommer det en dag att förvirra någon.
Adressen räcker inte, det behövs ett namn också
Ett program med adress och utan namn är halva vinsten. Ingen vill lära sig en adress utantill.
För att namnet ska annonseras i nätverket måste något göra det jobbet. Programmets egen avbild innehåller oftast ingen sådan del, och den behöver inte göra det: en databasavbild har inget att annonsera i ett nätverk.
Regeln
En portöversättning ger en dörr ett nummer. En nätverksidentitet ger medborgarskap.
Ge medborgarskap bara när nätverket verkligen måste behandla programmet som en enhet. Om det inte måste det är ett portnummer både enklare och säkrare.
Vad Atlas gör
När Atlas sätter upp detta rör det inte programmets egen avbild. Det öppnar en liten hjälpare bredvid programmet, och hjälparen delar programmets nätverksstack. Hjälparen ber routern om adressen, och hjälparen annonserar namnet i nätverket.
Den kopplingen är avsiktlig och ger två saker. Programmets avbild behöver varken en adressklient eller en namnannonserare. Och eftersom nätverksstacken tillhör programmet faller hjälparen av sig själv när programmet stannar, utan att lämna en föräldralös container efter sig.
För problemet att maskinen inte når sin egen container installeras bryggan som beskrevs ovan, och den installeras som en tjänst, så att den bygger upp sig själv igen när maskinen startar om.
Det som verkligen är värt att berätta är ett fel som hittades i den bryggan under ett skarpt test.
Bryggan öppnade en väg till containerns adress. Men den tog inte bort vägen till en container som försvunnit. Efter en omstart hade vägen till en tillfällig adress blivit hängande. Följden: om en annan enhet senare tar den adressen leds trafiken avsedd för den enheten in i bryggan. Felet drabbar alltså inte containern, utan en oskyldig tredje part i nätverket.
Rättningen var att sluta låta bryggan bara vara något som lägger till vägar, och göra den till något som tar bort vägar som inte längre motsvarar en levande container.
Den allmänna lärdomen gäller även utanför nätverk: att lägga till är den lätta halvan. En väg, en regel, en översättning är ett påstående du gör om världen. När världen ändras blir ett påstående ingen tagit tillbaka en lögn, och det drabbar oftast inte dig utan någon som inte har med dig att göra.
Källor
Proxmox egen dokumentation. På engelska, och den har sista ordet i den här frågan.