Dać kontenerowi własny adres w sieci: co zyskujesz, czym płacisz
Kontener można opublikować pod własnym adresem zamiast pod numerem portu. Zysk jest prawdziwy i cena też, a tę drugą zwykle odkrywa się już po zbudowaniu.
AtlasPVE ·
Ten wpis odpowiada na
- docker kontener własny adres ip
- docker macvlan co to jest
- docker macvlan host nie widzi kontenera
- docker kontener niewidoczny w sieci
- docker nadać kontenerowi ip zamiast portu
Domyślny układ jest taki: kontener dzieli adres maszyny, a ty sięgasz do niego przez numer portu. Jest to proste, bezpieczne i do większości pracy wystarcza.
Są przypadki, gdy nie wystarcza, i dają się przewidzieć.
Kiedy numer portu nie wystarcza
Dwie aplikacje chcą tego samego numeru. Przenosisz jedną na inny numer, a potem odnośniki, które ta aplikacja sama generuje, tego numeru nie niosą i robi się zamieszanie.
Aplikacja ogłasza się w sieci. Znajdowanie drukarek, odtwarzaczy multimediów, urządzeń inteligentnego domu: to działa przez komunikaty, które same się ogłaszają. Te komunikaty nie przeżywają mapowania portów. Aplikacja się ogłasza, ale adres, który ogłasza, jest adresem maszyny, i druga strona do niej nie dotrze.
Chcesz widzieć aplikację na liście urządzeń routera. Żeby nadać jej stały adres, napisać osobną regułę zapory, zobaczyć jej ruch osobno. Przy mapowaniu portów ta aplikacja dla sieci nie istnieje; istnieje tylko maszyna.
Druga droga: nadać kontenerowi własną tożsamość
Kontener pojawia się w sieci z własnym adresem sprzętowym, bierze własny adres od routera i stoi na liście urządzeń jak sprzęt fizyczny.
Pierwsza reakcja brzmi zwykle: dlaczego nie wszyscy tak robią. Odpowiedź leży w cenie.
Cena pierwsza: maszyna nie dosięga własnego kontenera
To zaskakuje najbardziej i odkrywa się to zwykle po skończeniu pracy.
Każde urządzenie w sieci dosięga tego kontenera. Maszyna, która go gości, nie.
Powód jest sensowny: oba używają tego samego interfejsu fizycznego, a ruch nie wraca z przełącznika. Maszyna wysyła pakiet na zewnątrz, a pakiet nie wraca na jej własną kartę.
Skutki są codzienne: kontrola kondycji działająca na maszynie nie dosięga aplikacji, inny kontener na tej samej maszynie nie może się połączyć, napisany przez ciebie skrypt nie działa. Wszystko to dzieje się, gdy sieć z zewnątrz wygląda bez zarzutu.
Rozwiązanie istnieje, ale jest dodatkowym elementem: otwórz na maszynie drugi wirtualny interfejs podpięty do tej samej karty i przeprowadź nim ruch do adresu kontenera. Po instalacji problem znika, ale ponieważ jest to dodatek, gdy zostanie zapomniany, nikt nie rozumie dlaczego.
Cena druga: wydajesz prawdziwy adres
Każdy kontener zużywa adres z twojej sieci. Dziesięć aplikacji to dziesięć adresów. W małej sieci szybko dochodzisz do granicy.
Poza tym, jeśli adres jest dzierżawą, może się zmienić. Gdy się zmieni, wszystko do niego przypięte, łącznie z napisaną przez ciebie regułą, po cichu wskazuje złe miejsce.
Cena trzecia: karta sieciowa i zapora
Karta musi przyjmować więcej niż jeden adres sprzętowy. Większość połączeń bezprzewodowych tego nie robi, a część środowisk wirtualnych przychodzi z tym wyłączonym. Nie decyduj bez testu.
A twoja zapora widzi teraz w sieci urządzenie, którego nie rozpoznaje. Dla ciebie to kontener; dla piszącego reguły to zwykłe urządzenie. To nie jest problem, ale przemilczane kiedyś kogoś zmyli.
Adres nie wystarczy, potrzebna jest też nazwa
Aplikacja z adresem i bez nazwy to połowa wygranej. Nikt nie chce zapamiętywać adresu.
Żeby nazwa była ogłaszana w sieci, ktoś musi wykonać tę pracę. Własny obraz aplikacji zwykle takiej części nie ma i nie ma powodu, żeby miał: obraz bazy danych nie ma po co ogłaszać się w sieci.
Reguła
Mapowanie portu nadaje drzwiom numer. Tożsamość sieciowa nadaje obywatelstwo.
Nadawaj obywatelstwo tylko wtedy, gdy sieć naprawdę musi traktować tę aplikację jak urządzenie. Gdy nie musi, numer portu jest zarazem prostszy i bezpieczniejszy.
Co robi Atlas
Ustawiając to, Atlas nie dotyka własnego obrazu aplikacji. Obok aplikacji otwiera niewielkiego pomocnika, a pomocnik dzieli stos sieciowy aplikacji. To pomocnik prosi router o adres i to on ogłasza nazwę w sieci.
To przywiązanie jest celowe i daje dwie rzeczy. Obraz aplikacji nie musi zawierać klienta adresu ani ogłaszacza nazwy. A ponieważ stos sieciowy należy do aplikacji, gdy aplikacja się zatrzymuje, pomocnik odpada razem z nią, nie zostawiając osieroconego kontenera.
Na problem maszyny, która nie dosięga własnego kontenera, instalowany jest opisany wyżej most, i to jako usługa, więc odbudowuje się sam po restarcie maszyny.
Naprawdę warto opowiedzieć o błędzie znalezionym w tym moście podczas testów na żywym systemie.
Most otwierał trasę do adresu kontenera. Ale nie usuwał trasy kontenera, który zniknął. Po restarcie trasa adresu tymczasowego została zawieszona. Skutek: jeśli inne urządzenie weźmie później ten adres, ruch przeznaczony dla niego zostaje przekierowany do mostu. Błąd nie uderza więc w kontener, tylko w niewinną trzecią stronę w sieci.
Poprawka polegała na tym, by most przestał być czymś, co tylko dodaje trasy, i stał się czymś, co usuwa trasy nieodpowiadające już żadnemu żywemu kontenerowi.
Ogólna lekcja, ważna także poza sieciami: dodawanie to łatwa połowa. Trasa, reguła, mapowanie to twierdzenie, które wypowiadasz o świecie. Gdy świat się zmienia, twierdzenie, którego nikt nie wycofał, zamienia się w kłamstwo i zwykle uderza nie w ciebie, tylko w kogoś, kto nie ma z tobą nic wspólnego.
Źródła
Własna dokumentacja Proxmoksa. Po angielsku i to ona ma ostatnie słowo w tej sprawie.