Docker: bir konteyneri VPN ilə yönləndirin, digərini birbaşa saxlayın

Bir host, iki iş yükü və onları ayıran bir tələb: kommersiya VPN-dən çıxması lazım olan endirmə müştərisi və hostun bağlantısından istifadə etməyə davam etməli olan idarəetmə interfeysi. VPN müştərisini hostda quraşdırmaq tələbi dərhal pozur, çünki sonra hər iki iş yükü bir çıxışı paylaşır. Həqiqətən işləyən nümunə tuneli öz konteynerinə köçürmək və yalnız ona ehtiyacı olan iş yüklərinin həmin konteynerin şəbəkə ad məkanına qoşulmasına icazə verməkdir. Qalan hər şey adi Docker yolunu saxlayır və sonrakı detallar ad məkanına kimin sahib olduğunun nəticələridir.

Paylaşılan ad məkanı qaydaları niyə dəyişir

Başqasının ad məkanına qoşulan konteyner öz şəbəkə yığınına sahib olmur. O, qoşulduğu konteynerlə eyni interfeysləri, eyni marşrutlaşdırma cədvəlini və eyni loopback-i görür və nümunənin faydalı olmasının səbəbi də elə budur: iş yükü adi qaydada həll edir və qoşulur, altındakı tunel isə trafiki tətbiqin xəbəri olmadan tutur. Qiyməti budur ki, hər şəbəkə xarakterli parametrin artıq bir sahibi var və qoşulan konteyner o deyil.

Bu sahiblik qaydası əksər konfiqurasiya sualını verilməzdən əvvəl cavablandırır. Parametr şəbəkə yığınında yaşayırsa, yan konteynerə aiddir. Prosesi təsvir edirsə, iş yükü ilə qalır.

Loopback insanları təəccübləndirən hissədir. Qoşulan konteynerin içində localhost yan konteynerin loopback-inə həll olunur, özünün şəxsi ünvanına deyil, yəni 127.0.0.1-ə bağlanaraq təcrid gözləyən xidmət artıq bu ünvanı tunel konteyneri ilə paylaşır.

Portları ad məkanına sahib olan konteynerdə yayımlayın

Port xəritələnməsi dinləyən proses digər konteynerdə işləsə belə, ad məkanının sahibinə aiddir. Xəritələnməni yan konteynerdə elan edin və iş yükü öz proses konfiqurasiyasını toxunulmaz saxlasın. Qoşulan xidmətdə xəritələnmə qüvvəyə minə bilməz, istər mühərrik onu rədd etsin, istərsə də konteynerin necə başladılmasından asılı olaraq səssizcə nəzərə almasın, və buna görə bir an əvvəl əlçatan olan interfeys nümunə tətbiq edilən kimi yox olur.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Bu bloku üç xidmət kimi deyil, üç qərar kimi oxuyun. Yan konteyner tunelə və yayımlanmış porta sahibdir; qoşulan müştəri heç bir şəbəkə elan etmir; birbaşa müştəri standart şəbəkədə öz xəritələnməsini saxlayır. NET_ADMIN qabiliyyəti yan konteynerə interfeyslər yaratmağa və marşrutları dəyişməyə imkan verir və bu konteynerin xidmət etdiyi iş yüklərindən daha çox imtiyaz tələb etməsinin səbəbi də budur.

Birbaşa qalan xidmət öz şəbəkəsini saxlayır

Tuneldən keçməməli olan iş yükü standart körpünü və ya öz istifadəçi təyin etdiyi şəbəkəni, öz yayımlanmış portu və öz çıxışı ilə saxlayır. İki konteynerin adla danışa bilməsi üçün onu yan konteynerin şəbəkəsinə qoşmaq cazibədardır və bu bir addım onun trafikini səssizcə tunelə köçürür. Bir-birinə çatmalı olsalar, ayrı bir istifadəçi təyin etdiyi şəbəkə qurun, hər ikisini ona qoşun və yan konteyneri yeganə xaricə yol kimi buraxın.

İki sualı ayrı saxlayın: hansı konteynerlər bir-birinə çata bilər və hansı haradan çıxır. Onları birləşdirmək bu dizaynın yenidən host miqyaslı VPN-ə çevrilməsinin ən geniş yayılmış yoludur.

İlk saat üçün nasazlıq matrisi

İlk cəhdlərin əksəriyyəti dörd yoldan biri ilə uğursuz olur və hər birinin fərqli səbəbi var. Onları bu sıra ilə yoxlayın, çünki ilk ikisi demək olar ki, hər hesabatı izah edir.

Dördüncü sətir insanların tətbiq xətası kimi səhv diaqnoz qoyduğu sətirdir. İş yükünün öz loopback-inə qarşı yazılmış yoxlama artıq tunel konteynerini sınayır, yəni ya uğursuz olur, ya da tamamilə yanlış xidmət barədə məlumat verir.

Tək bir host adı tunelə ehtiyac duyanda

Bəzən tam tunel həddindən artıqdır: bir daxili ad korporativ VPN-dən keçməlidir, yerli soket və ya ekran bağlantısı isə işləməyə davam etməlidir. Konteynerin içindəki tam tunel bu yolu və hosta ünvanlanan hər şeyi pozur, ona görə yalnız ehtiyacı olan prefiksi marşrutlaşdırın. Müştərinin ətrafında bölünmüş marşrutlaşdırma sarğısı bunu edir: adlandırılmış hostu tuneldən göndərir və qalan hər şey üçün əvvəlki marşrutu toxunulmaz qoyur.

Bunu yalnız bir xidmətə çatmaq lazım olduqda və konteynerin bütün trafikini köçürməyə çalışmadığınızda seçin. Bu, yan konteynerdən fərqli bir alətdir və fərqli bir suala cavab verir.

Yoxlayın, sonra yenidən başlatmaya davamlı edin

Hər konteynerdən hansı ünvandan gəldiyini soruşun. Tuneldə olan provayderin ünvanını, birbaşa olan isə hostun çıxışını çap etməlidir. Eyni cavablar birbaşa xidmətin yanlış ad məkanını miras aldığını və ya host səviyyəli VPN-in hələ də hər şeyi tutduğunu bildirir və bu iki düzəliş fərqlidir. Hər compose redaktəsindən sonra yoxlamanı yenidən aparın, çünki bir kopyalanmış xidmət bloku problemi geri qaytarmağa kifayətdir.

Sonradan üç şey sınmağa meyllidir. DNS ad məkanının sahibini izləyir, ona görə həlledici və axtarış domeni parametrləri hostda deyil, yan konteynerdə olmalıdır. Port yönləndirilən VPN yenidən qoşulanda dinləmə portunu dəyişir, ona görə provayderin yönləndirdiyi port və konteyner tərəfindəki dinləmə portu müştəri konfiqurasiyasına və ya port xəritələnməsinə geri yazılmalıdır, adətən provayderin API-ni oxuyan kiçik bir yeniləyici ilə. Və localhost-a qarşı yazılmış istənilən yoxlama artıq iş yükündən deyil, tunel konteynerindən soruşur.

Nümunəni yazın: hansı konteynerin ad məkanına sahib olduğunu və hansı portların ona aid olduğunu da daxil edin. Növbəti şəxs bir xidmət əlavə edəcək, səhv bloku kopyalayacaq və bu məqalədəki ilk nasazlığı təkrar istehsal edəcək.