Docker: halakan satu kontena melalui VPN dan biarkan satu lagi terus
Beri terowong kontena sendiri, benarkan hanya perkhidmatan yang memerlukannya berkongsi ruang nama itu, kemudian ambil kira apa yang mengikut pemilik: port, localhost, DNS.
Satu hos, dua beban kerja dan satu keperluan yang memisahkan keduanya: klien muat turun yang mesti keluar melalui VPN komersial, dan antara muka pengurusan yang mesti terus menggunakan sambungan hos. Memasang klien VPN pada hos terus menggagalkan keperluan itu, kerana kedua-dua beban kerja kemudian berkongsi satu jalan keluar. Corak yang benar-benar berkesan ialah memindahkan terowong ke kontena sendiri dan hanya membenarkan beban kerja yang memerlukannya menyertai ruang nama rangkaian kontena itu. Semua yang lain kekal pada laluan Docker biasa, dan butiran seterusnya ialah akibat daripada siapa yang memiliki ruang nama itu.
Mengapa ruang nama dikongsi mengubah peraturan
Kontena yang menyertai ruang nama kontena lain tidak mendapat tindanan rangkaiannya sendiri. Ia melihat antara muka yang sama, jadual penghalaan yang sama dan loopback yang sama seperti kontena yang disertainya, dan itulah sebabnya corak ini berguna: beban kerja menyelesaikan dan menyambung seperti biasa, dan terowong di bawahnya menangkap trafik tanpa diketahui aplikasi. Kosnya ialah setiap tetapan berunsur rangkaian kini mempunyai satu pemilik, dan kontena yang menyertai bukanlah pemilik itu.
Peraturan pemilikan ini menjawab kebanyakan soalan konfigurasi sebelum ia ditanya. Jika tetapan hidup dalam tindanan rangkaian, ia milik kontena sampingan. Jika ia menerangkan proses, ia kekal dengan beban kerja.
Loopback ialah bahagian yang mengejutkan orang. Di dalam kontena yang menyertai, localhost diselesaikan kepada loopback kontena sampingan, bukan kepada loopback peribadi sendiri, jadi perkhidmatan yang mengikat pada 127.0.0.1 sambil mengharapkan pengasingan kini berkongsi alamat itu dengan kontena terowong.
Terbitkan port pada kontena yang memiliki ruang nama
Pemetaan port milik pemilik ruang nama walaupun proses yang mendengar berjalan dalam kontena lain. Isytiharkan pemetaan itu pada kontena sampingan, dan biarkan beban kerja mengekalkan konfigurasi prosesnya sendiri tanpa diusik. Pemetaan pada perkhidmatan yang menyertai tidak boleh berkuat kuasa, sama ada enjin menolaknya atau diam-diam mengabaikannya bergantung pada cara kontena dimulakan, dan itulah sebabnya antara muka yang boleh dicapai sebentar tadi hilang sebaik sahaja corak ini digunakan.
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"]Baca blok itu sebagai tiga keputusan, bukan tiga perkhidmatan. Kontena sampingan memiliki terowong dan port yang diterbitkan; klien yang menyertai tidak mengisytiharkan sebarang rangkaian; klien terus mengekalkan pemetaannya sendiri pada rangkaian lalai. Keupayaan NET_ADMIN itulah yang membolehkan kontena sampingan mencipta antara muka dan mengubah laluan, dan itulah sebabnya kontena ini memerlukan lebih banyak keistimewaan daripada beban kerja yang dilayaninya.
Perkhidmatan yang kekal terus mengekalkan rangkaiannya sendiri
Beban kerja yang tidak boleh melalui terowong mengekalkan jambatan lalai atau rangkaian yang ditentukan pengguna miliknya sendiri, dengan port yang diterbitkan dan jalan keluarnya sendiri. Menggoda untuk menyambungkannya ke rangkaian kontena sampingan supaya kedua-dua kontena boleh bercakap mengikut nama, tetapi satu langkah itu diam-diam memindahkan trafiknya ke dalam terowong. Jika mereka perlu saling mencapai, bina rangkaian berasingan yang ditentukan pengguna, sambungkan kedua-duanya kepadanya, dan biarkan kontena sampingan sebagai satu-satunya jalan keluar.
Pisahkan kedua-dua soalan: kontena mana yang boleh saling mencapai, dan mana yang keluar dari mana. Menggabungkannya ialah cara paling biasa reka bentuk ini kembali menjadi VPN untuk seluruh hos.
Matriks kegagalan untuk jam pertama
Kebanyakan percubaan pertama gagal melalui salah satu daripada empat cara, dan setiap satu mempunyai punca berbeza. Periksanya dalam urutan ini, kerana dua yang pertama menjelaskan hampir setiap laporan.
| 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 |
Baris keempat ialah yang orang salah diagnosis sebagai pepijat aplikasi. Pemeriksaan yang ditulis terhadap loopback beban kerja sendiri kini menguji kontena terowong, jadi ia sama ada gagal atau melaporkan perkhidmatan yang sama sekali salah.
Apabila satu nama hos memerlukan terowong
Kadangkala terowong penuh terlalu banyak: satu nama dalaman mesti melalui VPN korporat sementara soket tempatan atau sambungan paparan terus berfungsi. Terowong penuh di dalam kontena memecahkan laluan itu dan semua yang dialamatkan kepada hos, jadi halakan hanya awalan yang memerlukannya. Pembalut penghalaan berpecah di sekeliling klien melakukan itu, menghantar nama hos yang dinamakan melalui terowong dan membiarkan laluan sebelumnya tidak diusik untuk semua yang lain.
Pilih ini apabila anda hanya perlu mencapai satu perkhidmatan dan tidak cuba memindahkan seluruh trafik kontena. Ia alat yang berbeza daripada kontena sampingan dan menjawab soalan yang berbeza.
Sahkan, kemudian jadikannya tahan permulaan semula
Tanya setiap kontena dari alamat mana ia kelihatan datang. Yang di dalam terowong sepatutnya mencetak alamat penyedia dan yang terus mencetak jalan keluar hos. Jawapan yang sama bermakna perkhidmatan terus mewarisi ruang nama yang salah atau VPN peringkat hos masih menangkap semuanya, dan kedua-dua pembaikan itu berbeza. Jalankan pemeriksaan semula selepas setiap suntingan compose, kerana satu blok perkhidmatan yang disalin sudah cukup untuk mengembalikan masalah.
Tiga perkara cenderung rosak kemudian. DNS mengikut pemilik ruang nama, jadi tetapan penyelesai dan domain carian milik kontena sampingan, bukan hos. VPN dengan pemajuan port menukar port mendengarnya semasa menyambung semula, jadi port yang dimajukan penyedia dan port mendengar di sebelah kontena mesti ditulis semula ke dalam konfigurasi klien atau pemetaan port, biasanya oleh pengemas kini kecil yang membaca API penyedia. Dan apa-apa pemeriksaan yang ditulis terhadap localhost kini bertanya kepada kontena terowong, bukan beban kerja.
Tuliskan corak itu, termasuk kontena mana yang memiliki ruang nama dan port mana yang menjadi miliknya. Orang seterusnya akan menambah perkhidmatan, menyalin blok yang salah dan menghasilkan semula kegagalan pertama dalam artikel ini.