At give en container sin egen adresse på netværket: hvad du vinder, hvad du betaler

Standardopstillingen er denne: containeren deler maskinens adresse, og du når den via et portnummer. Det er enkelt, det er sikkert, og til det meste arbejde er det nok.

Der er tilfælde, hvor det ikke er nok, og de kan forudses.

Hvornår et portnummer ikke er nok

To programmer vil have det samme nummer. Du flytter det ene til et andet nummer, og så bærer de links, programmet selv laver, ikke det nummer, og det bliver rodet.

Programmet annoncerer sig selv på netværket. At finde printere, finde medieafspillere, finde enheder i det smarte hjem: det virker med selvannoncerende beskeder. De beskeder overlever ikke portoversættelsen. Programmet annoncerer sig, men den adresse, det annoncerer, er maskinens, og modparten kan ikke nå det.

Du vil se programmet i routerens enhedsliste. For at give det en fast adresse, skrive en særskilt firewallregel, se dets trafik for sig. Med portoversættelse findes det program ikke for netværket; kun maskinen findes.

Den anden vej: giv containeren sin egen identitet

Containeren dukker op på netværket med sin egen hardwareadresse, får sin egen adresse fra routeren og står i enhedslisten som et fysisk apparat.

Den første reaktion er som regel "hvorfor gør alle ikke sådan". Svaret ligger i prisen.

Pris et: maskinen kan ikke nå sin egen container

Det er den del, der overrasker mest, og den opdages som regel, når arbejdet allerede er færdigt.

Alle enheder på netværket kan nå den container. Maskinen, der kører den, kan ikke.

Grunden giver mening: begge bruger den samme fysiske grænseflade, og trafikken kommer ikke tilbage fra switchen. Maskinen sender pakken ud, og pakken vender ikke tilbage til sit eget kort.

Følgerne er hverdagsagtige: et helbredstjek, der kører på maskinen, kan ikke nå programmet, en anden container på den samme maskine kan ikke forbinde, et script, du har skrevet, virker ikke. Alt sammen mens netværket ser fejlfrit ud udefra.

Der findes en løsning, men den er en ekstra del: åbn en anden virtuel grænseflade på maskinen knyttet til det samme kort, og lad vejen til containerens adresse gå der. Når den er installeret, er problemet væk, men da det er en tilføjelse, forstår ingen noget, hvis den glemmes.

Pris to: du bruger en rigtig adresse

Hver container bruger en adresse fra dit netværk. Ti programmer betyder ti adresser. På et lille netværk når du grænsen hurtigt.

Desuden kan adressen skifte, hvis den er et lån. Når den skifter, peger alt, der var fastgjort til den, også en regel du har skrevet, stille det forkerte sted hen.

Pris tre: netværkskortet og firewallen

Kortet skal acceptere mere end én hardwareadresse. De fleste trådløse forbindelser gør ikke det, og nogle virtuelle miljøer kommer med det slået fra. Beslut dig ikke uden at teste.

Og din firewall ser nu en enhed på netværket, den ikke kender. For dig er det en container; for den, der skriver reglerne, et almindeligt apparat. Det er ikke et problem, men usagt vil det en dag forvirre nogen.

Adressen er ikke nok, der skal også et navn til

Et program med adresse og uden navn er halvdelen af gevinsten. Ingen vil lære en adresse udenad.

For at navnet bliver annonceret på netværket, skal noget klare det arbejde. Programmets eget aftryk indeholder som regel ikke sådan en del, og det behøver det heller ikke: et databaseaftryk har ikke noget at annoncere på et netværk.

Reglen

En portoversættelse giver en dør et nummer. En netværksidentitet giver statsborgerskab.

Giv kun statsborgerskab, når netværket virkelig skal behandle det program som en enhed. Hvis ikke, er et portnummer både enklere og sikrere.

Hvad Atlas gør

Når Atlas sætter det op, rører det ikke programmets eget aftryk. Det åbner en lille hjælper ved siden af programmet, og hjælperen deler programmets netværksstak. Hjælperen beder routeren om adressen, og hjælperen annoncerer navnet på netværket.

Den kobling er tilsigtet og giver to ting. Programmets aftryk behøver hverken en adresseklient eller en navneannoncør. Og da netværksstakken tilhører programmet, falder hjælperen af sig selv, når programmet stopper, uden at efterlade en forældreløs container.

Til problemet med, at maskinen ikke kan nå sin egen container, installeres broen beskrevet ovenfor, og den installeres som en tjeneste, så den bygger sig selv op igen, når maskinen genstarter.

Det, der virkelig er værd at fortælle, er en fejl, der blev fundet i den bro under en test i drift.

Broen åbnede en vej til containerens adresse. Men den slettede ikke vejen til en container, der var væk. Efter en genstart var vejen til en midlertidig adresse blevet hængende. Følgen: tager en anden enhed senere den adresse, bliver trafikken bestemt til den enhed ledt ind i broen. Fejlen rammer altså ikke containeren, men en uskyldig tredjepart på netværket.

Rettelsen var at holde op med at lade broen være noget, der kun tilføjer veje, og gøre den til noget, der sletter veje, som ikke længere svarer til en levende container.

Den generelle lære gælder også uden for netværk: at tilføje er den lette halvdel. En vej, en regel, en oversættelse er en påstand, du fremsætter om verden. Når verden ændrer sig, bliver en påstand, ingen har trukket tilbage, til en løgn, og den rammer som regel ikke dig, men nogen der intet har med dig at gøre.