Konteyner faqat VPN orqali ochiladigan API’ga yetmayaptimi? Uni hostda proksilang

Compose xizmatingiz o‘sha mashinadagi brauzer bemalol ochadigan API oldida vaqt tugashiga uchraydi. Ana shu farq — ishora: ishlaydigan so‘rov VPN tunneli bor hostdan chiqadi, osilib qoladigan so‘rov esa o‘z tarmoq stekiga ega konteynerdan chiqadi. Konteyner ichida hech narsa tunnel yo‘llarini bilmaydi, shuning uchun nom qanday yozilmasin, xususiy manzil yetib bo‘lmaydigan bo‘lib qoladi. Yechim — host orqali ataylab qilingan sakrash, aqlliroq marshrut jadvali emas.

Ikki yo‘l nima uchun farq qilishidan boshlang, so‘ng tunnel qayerda yashashi kerakligini hal qiling.

Nima uchun host ishlaydi, konteyner esa yo‘q

Tunnelni ko‘tarish hostga interfeys, marshrutlar to‘plami va odatda VPN beradigan rezolver yozuvini beradi. Konteyner bundan hech narsani meros olmaydi: u dvigatel ko‘prigida bitta interfeys va shu ko‘prikka qaragan standart marshrut bilan boshlanadi. Hostda o‘rnatilgan marshrutlar shu nom maydoni ichida ishlayotgan hech narsaga ko‘rinmaydi.

Shu sababli alomatlar shunchaki buzilgan emas, nomuvofiq ko‘rinadi. Host xususiy nomni hal qilib ulanadi, chunki u yerda ham nom, ham marshrut bor. Konteyner paketini ko‘prik yo‘lida hech narsa yeta olmaydigan xususiy manzilga yuboradi va so‘rov vaqt tugashi bilan yakunlanadi. Nomni konteynerning hosts fayliga qo‘shish hech narsani o‘zgartirmaydi, chunki manzilning o‘zi konteyner turgan joydan yetib bo‘lmaydigan.

Konteyner ichidan hostga yeting

Konteynerdagi jarayon localhostni chaqirsa, konteynerni chaqirayotgan bo‘ladi. Docker Desktop host.docker.internalni dvigatel ishlayotgan mashinaga qaytib qaratilgan nom sifatida e’lon qiladi; Linux dvigatellari xizmat so‘ramasa, uni aniqlanmagan holda qoldiradi, quyidagi xaritalash esa aynan shuni qiladi. Shu bilan dastur xususiy manzil o‘rniga nom va portni nishonga oladi.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

Tunnel sakrashning host tomonida qoladi, o‘sha o‘zgaruvchidagi port esa proksi tinglaydigan port. Tunnelni yo‘qotgan konteyner endi hech qachon bo‘lmagan marshrutni sinash o‘rniga bitta ma’lum sakrashda ishdan chiqadi.

Tunnel qayerda yashashini tanlang

Xususiy API kerak bo‘lgan Compose xizmati uchun uch shakl mumkin va ular tunnel qaysi jarayonga tegishli ekani bilan farq qiladi. VPN mijozi konteyner obrazining ichida ishlashi mumkin, bu tunnel qurilmasini ochish va u bilan birga keladigan tarmoq ma’muriyati imkoniyatini berishni talab qiladi. Dastur alohida tunnel konteynerining tarmoq nom maydonini bo‘lishishi mumkin, shunda ikkala jarayon ham bitta stek va bitta marshrut jadvalini ko‘radi. Yoki tunnel hostda qolishi mumkin, hostdan konteynerga tor uzatgich bilan.

Birinchi ikkitasi profil fayllari, qayta ulanish xatti-harakati va rezolver siyosatini loyihaga tortadi va fayldagi har bir xizmatni tunnel salomatligiga bog‘liq qiladi. Bitta API chaqiruvi uchun bu juda ko‘p bog‘lanish. Bitta ichki oxirgi nuqtani o‘qiydigan ishlab chiqish steki uchun host tomonidagi uzatgich — hisob ma’lumotlarini platforma jamoasi boshqaradigan joyda saqlaydigan eng kichik o‘zgarish.

Hostda bitta tor yo‘l e’lon qiling

Uzatgich meros oladigan narsadan boshlang: uni tunnelga ega hisob ostida ishga tushiring, shunda uning chiquvchi soketlari host marshrutlarini va host rezolverini oladi. nginxning bitta location bloki bitta yo‘lni qamrab oladi.

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

Manzil va portni vaqtinchalik deb biling va API haqiqatan tinglaydigan juftlikni qo‘ying. Har bir qo‘shimcha upstream o‘z location blokiga loyiq, va har bir blok faqat shu xizmat chaqiradigan yo‘llarni qabul qilishi kerak, shunda proksi xususiy tarmoqqa umumiy eshik bo‘lib qolmaydi. Tinglovchini host-gateway orqali keladigan mijozlar uchun ko‘prik manziliga, mijoz hostning tarmoq nom maydonini bo‘lishgandagina loopbackka bog‘lang va hech qachon 0.0.0.0 ga bog‘lamang. Hali bo‘sh portni ham tanlang: allaqachon olingan raqam proksini tinglamay qoldiradi, konteyner esa vaqt tugashida davom etadi, buni siz boshlagan tarmoq nosozligidan ajratib bo‘lmaydi.

Portlar, nomlar va TLS qarori

Nomlarni hal qilish marshrutlash kabi bo‘linadi. Konteynerning ommaviy so‘rovlari dvigatel rezolveridan o‘tadi, shuning uchun hostda hal bo‘ladigan xususiy nom konteyner ichida hal bo‘lmaydi. Proksi xususiy nomni hal qiladigan komponent, chunki u host rezolverini meros oladi.

TLS — keyinga qoldiriladigan va keyin navbatdagi nosozlikni tushuntiradigan qaror. Agar proksi baytlarni tegmasdan uzatsa, konteyner APIning o‘z sertifikatini ko‘radi va ishonch omboriga ichki CA kerak bo‘ladi. Agar proksi TLSni tugatsa, bu ishonch hostga o‘tadi va dastur olgan host sarlavhasidan havolalar qurishni boshlaydi. Bitta tartibni tanlang va uni har bir resursga qo‘llang, chunki ikkinchisining chiqargan qayta yo‘naltirishi konteyner hal qila olmaydigan host nomiga ishora qiladi.

Xizmat ichidan tekshiring

So‘rovni hostdan emas, konteynerdan yuboring: proksi yo‘liga oddiy curl, so‘ng dasturning o‘z salomatlik tekshiruvi. Proksi javob bersa-da dastur hali ishdan chiqsa, uch narsani solishtiring: u quradigan asosiy URL, muhitidagi har qanday proksi o‘zgaruvchisi va u ishonadigan CA. Hammasi konteyner muhiti va jurnallarida, va ulardan birini tuzatish VPNga tegmaydi.

Tanlangan tartibni loyihaning README fayliga hali yangi paytida yozing. Aks holda bu vaqt tugashiga duch kelgan keyingi odam tunnel hostda yashashini qaytadan kashf qilish bilan o‘sha tushdan keyinni o‘tkazadi.