Docker: maršrutējiet vienu konteineri caur VPN un atstājiet otru tiešu

Viens resursdators, divas darba slodzes un prasība, kas tās šķir: lejupielādes klients, kuram jāiznāk caur komerciālu VPN, un pārvaldības saskarne, kurai jāturpina izmantot resursdatora savienojumu. VPN klienta instalēšana resursdatorā prasību uzreiz pārkāpj, jo tad abas slodzes dala vienu izeju. Modelis, kas patiešām darbojas, ir pārvietot tuneli uz savu konteineri un ļaut tikai tām slodzēm, kurām tas nepieciešams, pievienoties šī konteinera tīkla nosaukumu telpai. Viss pārējais saglabā parasto Docker ceļu, un turpmākās detaļas ir sekas tam, kam pieder nosaukumu telpa.

Kāpēc koplietota nosaukumu telpa maina noteikumus

Konteineris, kas pievienojas cita nosaukumu telpai, nesaņem savu tīkla steku. Tas redz tās pašas saskarnes, to pašu maršrutēšanas tabulu un to pašu loopback kā konteineris, kuram tas pievienojās, un tieši tāpēc modelis ir noderīgs: slodze parasti atrisina un savienojas, un tunelis zem tās pārtver datplūsmu, par to nezinot lietotnei. Cena ir tā, ka katram tīkla iestatījumam tagad ir viens īpašnieks, un pievienojošais konteineris nav tas.

Šis īpašumtiesību noteikums atbild uz lielāko daļu konfigurācijas jautājumu pirms to uzdošanas. Ja iestatījums dzīvo tīkla stekā, tas pieder blakus konteinerim. Ja tas apraksta procesu, tas paliek pie slodzes.

Loopback ir tā daļa, kas pārsteidz cilvēkus. Pievienojošā konteinera iekšpusē localhost tiek atrisināts uz blakus konteinera loopback, nevis uz savu privāto, tāpēc pakalpojums, kas piesaistās 127.0.0.1, gaidot izolāciju, tagad dala šo adresi ar tuneļa konteineri.

Publicējiet portus konteinerī, kuram pieder nosaukumu telpa

Portu kartēšana pieder nosaukumu telpas īpašniekam pat tad, ja klausošais process darbojas otrā konteinerī. Deklarējiet kartēšanu blakus konteinerī, un ļaujiet slodzei saglabāt savu procesa konfigurāciju neskartu. Kartēšana pievienojošajā pakalpojumā nevar stāties spēkā, vai nu dzinējs to noraida, vai klusi ignorē atkarībā no tā, kā konteiners tiek palaists, un tāpēc saskarne, kas vēl nesen bija sasniedzama, pazūd, tiklīdz modelis tiek pielietots.

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"]

Lasiet šo bloku kā trīs lēmumus, nevis trīs pakalpojumus. Blakus konteiners pārvalda tuneli un publicēto portu; pievienojošais klients vispār nedeklarē tīklu; tiešais klients saglabā savu kartēšanu noklusējuma tīklā. Iespēja NET_ADMIN ir tas, kas ļauj blakus konteinerim veidot saskarnes un mainīt maršrutus, un tas ir iemesls, kāpēc šim konteinerim vajag vairāk privilēģiju nekā slodzēm, kurām tas kalpo.

Pakalpojums, kas paliek tiešs, saglabā savu tīklu

Slodze, kurai nevajadzētu iet caur tuneli, saglabā noklusējuma tiltu vai savu lietotāja definēto tīklu ar savu publicēto portu un savu izeju. Kārdinoši ir to pievienot blakus konteinera tīklam, lai abi konteineri varētu runāt pēc nosaukuma, bet šis viens solis klusi pārvieto tā datplūsmu tunelī. Ja tiem jāsasniedz viens otru, izveidojiet atsevišķu lietotāja definētu tīklu, pievienojiet abus tam un atstājiet blakus konteineri kā vienīgo ceļu uz āru.

Turiet abus jautājumus atsevišķi: kuri konteineri var sasniegt viens otru un kurš iziet no kurienes. To apvienošana ir visizplatītākais veids, kā šis dizains atkal kļūst par VPN visam resursdatoram.

Kļūmju matrica pirmajai stundai

Lielākā daļa pirmo mēģinājumu neizdodas vienā no četriem veidiem, un katram ir cits iemesls. Pārbaudiet tos šajā secībā, jo pirmie divi izskaidro gandrīz katru ziņojumu.

Ceturtā rinda ir tā, ko cilvēki kļūdaini diagnosticē kā lietotnes kļūdu. Zonde, kas rakstīta pret pašas slodzes loopback, tagad testē tuneļa konteineri, tāpēc tā vai nu neizdodas, vai ziņo par pilnīgi nepareizu pakalpojumu.

Kad vienam resursdatora nosaukumam vajag tuneli

Dažkārt pilns tunelis ir par daudz: vienam iekšējam nosaukumam jāiet caur uzņēmuma VPN, kamēr lokāls ligzda vai displeja savienojums turpina darboties. Pilns tunelis konteinerī salauž šo ceļu un visu, kas adresēts resursdatoram, tāpēc maršrutējiet tikai to prefiksu, kuram tas nepieciešams. Sadalītās maršrutēšanas ietinējs ap klientu to dara, sūtot nosaukto resursdatoru caur tuneli un atstājot iepriekšējo maršrutu neskartu visam pārējam.

Izvēlieties to, kad jums jāsasniedz tikai viens pakalpojums un jūs necenšaties pārvietot visu konteinera datplūsmu. Tas ir cits rīks nekā blakus konteiners, un tas atbild uz citu jautājumu.

Pārbaudiet un pēc tam padariet to izturīgu pret restartēšanu

Pajautājiet katram konteinerim, no kādas adreses tas šķiet nākam. Tunelī esošajam jāizdrukā pakalpojumu sniedzēja adrese, bet tiešajam — resursdatora izeja. Identiskas atbildes nozīmē, ka tiešais pakalpojums ir mantojis nepareizo nosaukumu telpu vai resursdatora līmeņa VPN joprojām pārtver visu, un šie divi labojumi atšķiras. Palaidiet pārbaudi vēlreiz pēc katras compose izmaiņas, jo viens nokopēts pakalpojuma bloks ir pietiekams, lai atgrieztu problēmu.

Trīs lietas mēdz salūzt vēlāk. DNS seko nosaukumu telpas īpašniekam, tāpēc atrisinātāja un meklēšanas domēna iestatījumi pieder blakus konteinerim, nevis resursdatoram. VPN ar portu pāradresāciju maina savu klausīšanās portu atkārtotas savienošanās laikā, tāpēc pakalpojumu sniedzēja pāradresētais ports un konteinera puses klausīšanās ports ir jāieraksta atpakaļ klienta konfigurācijā vai portu kartēšanā, parasti ar nelielu atjauninātāju, kas lasa pakalpojumu sniedzēja API. Un jebkura zonde, kas rakstīta pret localhost, tagad jautā tuneļa konteinerim, nevis slodzei.

Pierakstiet modeli, tostarp to, kurš konteiners pārvalda nosaukumu telpu un kuri porti tam pieder. Nākamais cilvēks pievienos pakalpojumu, nokopēs nepareizo bloku un atkārtos šī raksta pirmo kļūmi.