Docker: bitta konteynerni VPN orqali yoʻnaltiring, boshqasini toʻgʻridan-toʻgʻri qoldiring
Tunnelga oʻz konteynerini bering, faqat unga muhtoj xizmatlarga oʻsha nom maydonini boʻlishishga ruxsat bering, soʻngra egasidan keyin nima kelishini hisobga oling: portlar, localhost, DNS.
Bitta xost, ikkita ish yuklamasi va ularni ajratuvchi talab: tijorat VPN orqali chiqishi kerak boʻlgan yuklab olish mijozi va xost ulanishidan foydalanishda davom etishi kerak boʻlgan boshqaruv interfeysi. VPN mijozini xostga oʻrnatish talabni darhol buzadi, chunki unda ikkala yuklama ham bitta chiqishni boʻlishadi. Haqiqatan ishlaydigan naqsh tunnelni oʻz konteyneriga koʻchirish va faqat unga muhtoj yuklamalarga oʻsha konteynerning tarmoq nom maydoniga qoʻshilishga ruxsat berishdir. Qolgan hamma narsa odatiy Docker yoʻlini saqlaydi va keyingi tafsilotlar nom maydoni kimga tegishli ekanining natijasidir.
Nega umumiy nom maydoni qoidalarni oʻzgartiradi
Boshqasining nom maydoniga qoʻshilgan konteyner oʻz tarmoq stekini olmaydi. U qoʻshilgan konteyner bilan bir xil interfeyslarni, bir xil marshrutlash jadvalini va bir xil loopbackni koʻradi, shuning uchun bu naqsh foydali: yuklama odatdagidek hal qiladi va ulanadi, ostidagi tunnel esa ilova bilmagan holda trafikni ushlab oladi. Narxi — har bir tarmoq sozlamasining endi bitta egasi bor va qoʻshilayotgan konteyner u emas.
Bu egalik qoidasi konfiguratsiya savollarining koʻpchiligiga ular berilishidan oldin javob beradi. Agar sozlama tarmoq stekida yashasa, u yon konteynerga tegishli. Agar u jarayonni tavsiflasa, u yuklama bilan qoladi.
loopback — odamlarni hayratga soladigan qism. Qoʻshilayotgan konteyner ichida localhost yon konteynerning loopbackiga hal qilinadi, oʻzining shaxsiy loopbackiga emas, shuning uchun 127.0.0.1 ga bogʻlanib izolyatsiyani kutgan xizmat endi bu manzilni tunnel konteyneri bilan boʻlishadi.
Portlarni nom maydoniga ega konteynerda eʼlon qiling
Port xaritasi nom maydoni egasiga tegishli, hatto tinglayotgan jarayon boshqa konteynerda ishlayotgan boʻlsa ham. Xaritani yon konteynerda eʼlon qiling va yuklama oʻz jarayon konfiguratsiyasini oʻzgarmas holda saqlasin. Qoʻshilayotgan xizmatdagi xarita kuchga kirishi mumkin emas, dvigatel uni rad etadimi yoki konteyner qanday ishga tushirilishiga qarab jimgina eʼtiborsiz qoldiradimi, shuning uchun bir lahza oldin yetib borish mumkin boʻlgan interfeys naqsh qoʻllanishi bilanoq yoʻqoladi.
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 blokni uchta xizmat emas, uchta qaror deb oʻqing. Yon konteyner tunnel va eʼlon qilingan portga ega; qoʻshilayotgan mijoz hech qanday tarmoq eʼlon qilmaydi; toʻgʻridan-toʻgʻri mijoz standart tarmoqda oʻz xaritasini saqlaydi. Imkoniyat NET_ADMIN yon konteynerga interfeyslar yaratish va marshrutlarni oʻzgartirish imkonini beradigan narsadir va bu konteyner oʻzi xizmat qiladigan yuklamalardan koʻra koʻproq imtiyoz talab qilishining sababi ham shu.
Toʻgʻridan-toʻgʻri qoladigan xizmat oʻz tarmogʻini saqlaydi
Tunneldan oʻtmasligi kerak boʻlgan yuklama standart koʻprikni yoki oʻzining foydalanuvchi belgilagan tarmogʻini oʻz eʼlon qilingan porti va oʻz chiqishi bilan saqlaydi. Ikki konteyner nom bilan gaplasha olishi uchun uni yon konteyner tarmogʻiga ulash vasvasasi bor, ammo oʻsha bir qadam uning trafigini jimgina tunnelga koʻchiradi. Agar ular bir-biriga yetishi kerak boʻlsa, alohida foydalanuvchi belgilagan tarmoq quring, ikkalasini ham unga ulang va yon konteynerni tashqariga chiqadigan yagona yoʻl qilib qoldiring.
Ikki savolni alohida tuting: qaysi konteynerlar bir-biriga yeta oladi va qaysi biri qayerdan chiqadi. Ularni birlashtirish bu dizaynning yana butun xostni qamrab oluvchi VPNga aylanishining eng keng tarqalgan yoʻlidir.
Birinchi soat uchun nosozliklar matritsasi
Birinchi urinishlarning koʻpchiligi toʻrtta usuldan biri bilan muvaffaqiyatsiz tugaydi va har birining sababi boshqacha. Ularni shu tartibda tekshiring, chunki birinchi ikkitasi deyarli har bir hisobotni tushuntiradi.
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
Toʻrtinchi qator — odamlar xato ravishda ilova xatosi deb tashxis qoʻyadigan qator. Yuklamaning oʻz loopbackiga qarshi yozilgan tekshiruv endi tunnel konteynerini sinaydi, shuning uchun u yo muvaffaqiyatsiz boʻladi, yo butunlay notoʻgʻri xizmat haqida xabar beradi.
Bitta xost nomiga tunnel kerak boʻlganda
Baʼzan toʻliq tunnel ortiqcha boʻladi: bitta ichki nom korporativ VPN orqali oʻtishi kerak, mahalliy soket yoki displey ulanishi esa ishlashda davom etadi. Konteyner ichidagi toʻliq tunnel bu yoʻlni va xostga manzillangan hamma narsani buzadi, shuning uchun faqat kerakli prefiksni marshrutlang. Mijoz atrofidagi boʻlingan marshrutlash oʻrami shuni qiladi, nomlangan xostni tunneldan oʻtkazadi va qolgan hamma narsa uchun oldingi marshrutni oʻzgarmas qoldiradi.
Buni faqat bitta xizmatga yetish kerak boʻlganda va konteynerning butun trafigini koʻchirishga urinmayotganingizda tanlang. Bu yon konteynerdan boshqa vosita va boshqa savolga javob beradi.
Tekshiring, soʻngra uni qayta ishga tushirishga chidamli qiling
Har bir konteynerdan qaysi manzildan kelayotgandek koʻrinishini soʻrang. Tunneldagi provayder manzilini, toʻgʻridan-toʻgʻri esa xostning chiqishini chop etishi kerak. Bir xil javoblar toʻgʻridan-toʻgʻri xizmat notoʻgʻri nom maydonini meros olganini yoki xost darajasidagi VPN hali ham hamma narsani ushlab turganini bildiradi, va bu ikki tuzatish har xil. Har bir compose tahriridan keyin tekshiruvni qayta ishga tushiring, chunki bitta nusxalangan xizmat bloki muammoni qaytarish uchun yetarli.
Uch narsa keyin buzilishga moyil. DNS nom maydoni egasiga ergashadi, shuning uchun hal qiluvchi va qidiruv domeni sozlamalari xostga emas, yon konteynerga tegishli. Port yoʻnaltirishli VPN qayta ulanishda tinglash portini oʻzgartiradi, shuning uchun provayderning yoʻnaltirilgan porti va konteyner tomonidagi tinglash porti mijoz konfiguratsiyasiga yoki port xaritasiga qayta yozilishi kerak, odatda provayderning API sini oʻqiydigan kichik yangilagich orqali. Va localhost ga qarshi yozilgan har qanday tekshiruv endi yuklamaga emas, tunnel konteyneriga murojaat qiladi.
Naqshni yozib qoʻying, jumladan qaysi konteyner nom maydoniga ega va qaysi portlar unga tegishli. Keyingi odam xizmat qoʻshadi, notoʻgʻri blokni nusxalaydi va ushbu maqoladagi birinchi nosozlikni takrorlaydi.