Kontena tidak dapat mencapai API khusus VPN? Proksi di hos

Perkhidmatan Compose anda tamat masa terhadap API yang pelayar pada mesin sama membuka tanpa sebarang aduan. Perbezaan itulah petunjuknya: permintaan yang berjaya keluar dari hos dengan terowong VPN, dan permintaan yang tergantung keluar dari kontena dengan tindanan rangkaiannya sendiri. Tiada apa pun di dalam kontena mengetahui laluan terowong, jadi destinasi persendirian kekal tidak dapat dicapai bagaimana pun nama dieja. Pembaikan ialah lompatan yang disengajakan melalui hos, bukan jadual laluan yang lebih pintar.

Mulakan dengan sebab kedua-dua laluan berbeza, kemudian tentukan di mana terowong patut tinggal.

Mengapa hos berfungsi dan kontena tidak

Menghidupkan terowong memberi hos antara muka, satu set laluan dan, biasanya, entri penyelesai yang dibekalkan VPN. Kontena tidak mewarisi apa pun daripadanya: ia bermula dengan satu antara muka pada jambatan enjin dan laluan lalai yang menunjuk ke jambatan itu. Laluan yang dipasang pada hos tidak kelihatan kepada apa pun yang berjalan di dalam ruang nama itu.

Sebab itulah gejalanya kelihatan tidak konsisten, bukan sekadar rosak. Hos menyelesaikan nama persendirian dan menyambung, kerana nama dan laluan kedua-duanya wujud di sana. Kontena menghantar paketnya ke alamat persendirian yang tiada apa pun di laluan jambatan dapat capai, dan permintaan tamat masa. Menambah nama ke fail hosts kontena tidak mengubah apa pun, kerana alamat itu sendiri tidak dapat dicapai dari tempat kontena berada.

Capai hos dari dalam kontena

Proses di dalam kontena yang mendail localhost sedang mendail kontena. Docker Desktop menerbitkan host.docker.internal sebagai nama yang menunjuk kembali ke mesin yang menjalankan enjin; enjin Linux membiarkannya tidak ditentukan melainkan perkhidmatan memintanya, dan itulah yang dilakukan pemetaan di bawah. Dengan itu aplikasi menyasarkan nama dan port dan bukannya alamat persendirian.

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

Terowong kekal di sisi hos bagi lompatan itu, dan port dalam pemboleh ubah itu ialah port yang akan didengar proksi. Kontena yang kehilangan terowong kini gagal pada satu lompatan yang diketahui dan bukannya mencuba laluan yang tidak pernah dimilikinya.

Pilih di mana terowong tinggal

Tiga bentuk mungkin bagi perkhidmatan Compose yang memerlukan API persendirian, dan ia berbeza dari segi proses mana yang memiliki terowong. Klien VPN boleh berjalan di dalam imej kontena, yang memerlukan pendedahan peranti terowong dan pemberian keupayaan pentadbiran rangkaian yang menyertainya. Aplikasi boleh berkongsi ruang nama rangkaian kontena terowong berasingan, supaya kedua-dua proses melihat satu tindanan dan satu jadual laluan. Atau terowong boleh kekal di hos, dengan pemaju sempit dari hos ke dalam kontena.

Dua yang pertama menarik fail profil, tingkah laku sambung semula dan dasar penyelesai ke dalam projek, dan menjadikan setiap perkhidmatan dalam fail bergantung pada kesihatan terowong. Itu terlalu banyak gandingan untuk satu panggilan API. Bagi tindanan pembangunan yang membaca satu titik akhir dalaman, pemaju di sisi hos ialah perubahan terkecil yang masih menyimpan kelayakan di tempat pasukan platform menguruskannya.

Terbitkan satu laluan sempit di hos

Mulakan dengan apa yang diwarisi pemaju: jalankannya dengan akaun yang memiliki terowong dan soket keluarnya akan mengambil laluan hos serta penyelesai hos. Satu blok location nginx meliputi satu laluan.

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

Anggap alamat dan port sebagai pengganti dan masukkan pasangan yang API benar-benar dengar. Setiap upstream tambahan berhak mendapat blok location sendiri, dan setiap blok patut hanya menerima laluan yang dipanggil perkhidmatan ini, supaya proksi tidak menjadi pintu umum ke rangkaian persendirian. Ikat pendengar pada alamat jambatan untuk klien yang datang melalui host-gateway, pada loopback hanya apabila klien berkongsi ruang nama rangkaian hos, dan jangan sekali-kali pada 0.0.0.0. Pilih juga port yang masih bebas: nombor yang sudah diambil membiarkan proksi tidak mendengar sementara kontena terus tamat masa, yang tidak dapat dibezakan daripada kerosakan rangkaian yang anda mulakan.

Port, nama dan keputusan TLS

Penyelesaian nama berpecah sama seperti penghalaan. Carian awam kontena melalui penyelesai enjin, jadi nama persendirian yang diselesaikan pada hos tidak akan diselesaikan di dalam kontena. Proksilah komponen yang menyelesaikan nama persendirian itu, kerana ia mewarisi penyelesai hos.

TLS ialah keputusan yang ditangguhkan dan kemudian menjelaskan kegagalan seterusnya. Jika proksi memajukan bait tanpa disentuh, kontena melihat sijil API itu sendiri dan memerlukan CA dalaman dalam stor kepercayaannya. Jika proksi menamatkan TLS, kepercayaan itu berpindah ke hos dan aplikasi mula membina pautan daripada pengepala hos yang diterimanya. Pilih satu susunan dan gunakannya pada setiap sumber, kerana ubah hala yang dikeluarkan oleh susunan lain menunjuk ke nama hos yang tidak dapat diselesaikan oleh kontena.

Sahkan dari dalam perkhidmatan

Hantar permintaan dari kontena, bukan dari hos: curl biasa ke laluan proksi, kemudian pemeriksaan kesihatan aplikasi itu sendiri. Apabila proksi menjawab tetapi aplikasi masih gagal, bandingkan tiga perkara: URL asas yang dibinanya, sebarang pemboleh ubah proksi dalam persekitarannya, dan CA yang dipercayainya. Semuanya berada dalam persekitaran dan log kontena, dan membaiki mana-mana satu daripadanya membiarkan VPN tenang.

Tulis susunan yang dipilih ke dalam README projek selagi ia segar. Jika tidak, orang seterusnya yang menemui tamat masa ini akan menghabiskan petang yang sama menemui semula bahawa terowong tinggal di hos.