/ cc @aluzzadi @mrjana bertanya

@PanJ dapatkah Anda membagikan beberapa detail tentang bagaimana debugging-simple-server menentukan ip ? Juga apa harapan jika layanan diskalakan ke lebih dari 1 replika di beberapa host (atau mode global)?

@mavenugo itu adalah objek permintaan koa yang menggunakan remoteAddress node dari modul net . Hasilnya harus sama untuk perpustakaan lain yang dapat mengambil alamat jarak jauh.

Harapannya adalah bahwa bidang ip harus selalu menjadi alamat jarak jauh terlepas dari konfigurasi apa pun.

@PanJ Anda masih menggunakan solusi Anda atau menemukan solusi yang lebih baik?

@PanJ Ketika saya menjalankan aplikasi Anda sebagai wadah mandiri ..

docker run -it --rm -p 80:3000 --name test panj/debugging-simple-server

dan akses port yang diterbitkan dari host lain saya mendapatkan ini

vagrant@net-1:~$ curl 192.168.33.12
{"method":"GET","url":"/","header":{"user-agent":"curl/7.38.0","host":"192.168.33.12","accept":"*/*"},"ip":"::ffff:192.168.33.11","ips":[]}
vagrant@net-1:~$

192.168.33.11 adalah IP dari host tempat saya menjalankan curl. Apakah ini perilaku yang diharapkan?

@sanimej Ya, itu adalah perilaku yang diharapkan yang harus ada dalam mode swarm juga.

@marech Saya masih menggunakan wadah mandiri sebagai solusi, yang berfungsi dengan baik.

Dalam kasus saya, ada 2 instance nginx, instance mandiri dan swarm. Pengakhiran SSL dan proxy terbalik dilakukan pada nginx mandiri. Instance gerombolan digunakan untuk merutekan ke layanan lain berdasarkan host permintaan.

@PanJ Cara port yang diterbitkan dari wadah diakses berbeda dalam mode swarm. Dalam mode swarm, layanan dapat dijangkau dari node mana pun di cluster. Untuk memfasilitasi ini, kami merutekan melalui jaringan ingress . 10.255.0.x adalah alamat antarmuka jaringan ingress pada host di cluster tempat Anda mencoba mencapai port yang dipublikasikan.

@sanimej Saya agak melihat cara kerjanya ketika saya menggali masalah ini. Tetapi kasus penggunaan (kemampuan untuk mengambil IP pengguna) cukup umum.

Saya memiliki pengetahuan terbatas tentang bagaimana perbaikan harus diterapkan. Mungkin jenis jaringan khusus yang tidak mengubah alamat IP sumber?

Rancher mirip dengan mode gerombolan Docker dan tampaknya memiliki perilaku yang diharapkan. Mungkin ini adalah tempat yang baik untuk memulai.

@sanimej ide bagus bisa menambahkan semua IP ke header X-Forwarded-For jika memungkinkan maka kita dapat melihat semua rantai.

@PanJ hmm, dan bagaimana wadah mandiri nignx Anda berkomunikasi dengan swarm instance, melalui nama layanan atau ip? Mungkin dapat membagikan bagian konfigurasi nginx tempat Anda meneruskannya ke instance swarm.

@marech standalone container mendengarkan port 80 dan kemudian memproksi ke localhost:8181

server {
  listen 80 default_server;
  location / {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;
    proxy_pass          http://localhost:8181;
    proxy_read_timeout  90;
  }
}

Jika Anda harus melakukan penghentian SSL, tambahkan blok server lain yang mendengarkan port 443 , kemudian lakukan penghentian SSL dan proxy ke localhost:8181 juga

nginx mode Swarm menerbitkan 8181:80 dan merutekan ke layanan lain berdasarkan host permintaan.

server {
  listen 80;
  server_name your.domain.com;
  location / {
    proxy_pass          http://your-service:80;
    proxy_set_header Host $host;
    proxy_read_timeout  90;
  }
}

server {
  listen 80;
  server_name another.domain.com;
  location / {
    proxy_pass          http://another-service:80;
    proxy_set_header Host $host;
    proxy_read_timeout  90;
  }
}

Dalam kasus kami, API RateLimit kami dan fungsi lainnya tergantung pada alamat ip pengguna. Apakah ada cara untuk melewati masalah dalam mode swarm?

Saya juga mengalami masalah ketika mencoba menjalankan logstash dalam mode swarm (untuk mengumpulkan pesan syslog dari berbagai host). Bidang "host" logstash selalu muncul sebagai 10.255.0.x, bukan IP sebenarnya dari host penghubung. Ini membuatnya benar-benar tidak dapat digunakan, karena Anda tidak dapat mengetahui dari host mana pesan log itu berasal. Apakah ada cara agar kita tidak menerjemahkan IP sumber?

+1 untuk solusi untuk masalah ini.

Tanpa kemampuan untuk mengambil IP pengguna mencegah kami menggunakan solusi pemantauan seperti Prometheus.

Mungkin kapabilitas IPVS kernel linux akan berguna di sini. Saya menduga bahwa perubahan IP terjadi karena koneksi sedang diproksi di ruang pengguna. IPVS, di sisi lain, dapat mengarahkan dan memuat permintaan keseimbangan di ruang kernel tanpa mengubah alamat IP sumber. IPVS juga dapat digunakan untuk membangun fungsionalitas yang lebih canggih, seperti algoritme penyeimbangan beban yang berbeda, alamat IP mengambang, dan perutean langsung.

Bagi saya, itu akan cukup jika saya entah bagaimana bisa mengetahui hubungan antara IP virtual dan IP server tempat titik akhir berada. Dengan begitu, ketika Prometheus mengirim peringatan terkait dengan beberapa IP virtual, saya bisa mengetahui server apa yang terpengaruh. Itu tidak akan menjadi solusi yang baik tetapi akan lebih baik daripada tidak sama sekali.

@vfarcic Saya tidak berpikir itu mungkin dengan cara kerjanya sekarang. Semua koneksi klien berasal dari IP yang sama, jadi Anda tidak dapat menerjemahkannya kembali. Satu-satunya cara yang akan berhasil adalah jika apa pun yang dilakukan proxy/nat koneksi menyimpan log koneksi dengan stempel waktu, ip sumber, dan port sumber. Meski begitu, itu tidak akan banyak membantu dalam sebagian besar kasus penggunaan di mana IP sumber diperlukan.

Saya mungkin tidak menjelaskan dengan baik kasus penggunaan.

Saya menggunakan Prometheus yang dikonfigurasi untuk membuang eksportir yang berjalan sebagai layanan global Swarm. Ini menggunakan tugas.untuk mendapatkan IP dari semua replika. Jadi, itu tidak menggunakan layanan tetapi titik akhir replika (tanpa penyeimbangan beban). Yang saya perlukan adalah entah bagaimana mencari tahu IP node dari mana masing-masing IP replika itu berasal.

Saya baru menyadari "pemeriksaan jaringan buruh pelabuhan" memberikan informasi tentang wadah dan alamat IPv4 dari satu node. Bisakah ini diperluas sehingga ada informasi cluster-lebar jaringan bersama-sama dengan node?

Sesuatu seperti:

       "Containers": {
            "57bc4f3d826d4955deb32c3b71550473e55139a86bef7d5e584786a3a5fa6f37": {
                "Name": "cadvisor.0.8d1s6qb63xdir22xyhrcjhgsa",
                "EndpointID": "084a032fcd404ae1b51f33f07ffb2df9c1f9ec18276d2f414c2b453fc8e85576",
                "MacAddress": "02:42:0a:00:00:1e",
                "IPv4Address": "10.0.0.30/24",
                "IPv6Address": "",
                "Node": "swarm-4"
            },
...

Perhatikan penambahan "Node".

Jika informasi tersebut akan tersedia untuk seluruh cluster, tidak hanya satu node dengan tambahan argumen --filter , saya akan memiliki semua yang saya perlukan untuk mengetahui hubungan antara alamat IPv4 container dan simpul. Itu tidak akan menjadi solusi yang bagus tetapi masih lebih baik daripada tidak sama sekali. Saat ini, ketika Prometheus mendeteksi masalah, saya perlu menjalankan "pemeriksaan jaringan buruh pelabuhan" pada setiap node sampai saya menemukan lokasi alamatnya.

Saya setuju dengan @dack , mengingat jaringan masuk menggunakan IPVS, kita harus menyelesaikan masalah ini menggunakan IPVS sehingga IP sumber dipertahankan dan disajikan ke layanan dengan benar dan transparan.

Solusinya perlu bekerja di tingkat IP sehingga layanan apa pun yang tidak berbasis HTTP masih dapat berfungsi dengan baik juga (Tidak dapat mengandalkan header http ...).

Dan saya tidak dapat menekankan betapa pentingnya hal ini, tanpanya, ada banyak layanan yang tidak dapat beroperasi sama sekali dalam mode swarm.

Begitulah cara HaProxy memecahkan masalah ini: http://blog.haproxy.com/2012/06/05/preserve-source-ip-address-despite-reverse-proxies/

@kobolog mungkin dapat menjelaskan masalah ini mengingat ceramahnya tentang IPVS di DockerCon.

Hanya menambahkan diri saya ke daftar. Saya menggunakan logstash untuk menerima pesan syslog, dan semuanya didorong ke elasticsearch dengan IP host disetel ke 10.255.0.4, yang membuatnya tidak dapat digunakan, dan saya harus kembali ke penerapan logstash non-kontainer saya jika tidak ada perbaikan untuk ini.

@mrjana dapatkah Anda menambahkan saran yang Anda miliki untuk mengatasi masalah ini?

IPVS bukan proxy terbalik ruang pengguna yang dapat memperbaiki berbagai hal di lapisan HTTP. Itulah perbedaan antara proxy ruang pengguna seperti HAProxy dan ini. Jika Anda ingin menggunakan HAProxy, Anda dapat melakukannya dengan meletakkan HAProxy di cluster dan meminta semua instance layanan dan HAProxy Anda untuk berpartisipasi dalam jaringan yang sama. Dengan begitu HAProxy dapat memperbaiki HTTP header.x-forwarded-for . Atau jika penyeimbang beban L7 berada di luar cluster, Anda dapat menggunakan fitur mendatang (dalam 1.13) untuk PublishMode disebut Host PublishMode yang akan mengekspos masing-masing instance layanan individual di port individualnya sendiri dan Anda dapat mengarahkan penyeimbang beban eksternal Anda ke sana.

@mrjana Seluruh ide menggunakan IPVS (alih-alih apa pun yang dilakukan buruh pelabuhan saat ini dalam mode swarm) adalah untuk menghindari menerjemahkan IP sumber untuk memulai. Menambahkan X-Forwarded-For mungkin membantu untuk beberapa aplikasi HTTP, tetapi tidak ada gunanya sama sekali untuk semua aplikasi lain yang rusak oleh perilaku saat ini.

@dack pemahaman saya adalah jaringan masuk Docker sudah menggunakan IPVS.

Jika Anda ingin menggunakan HAProxy, Anda dapat melakukannya dengan meletakkan HAProxy di cluster dan meminta semua instance layanan dan HAProxy Anda untuk berpartisipasi dalam jaringan yang sama. Dengan begitu HAProxy dapat memperbaiki HTTP header.x-forwarded-for

Itu tidak akan berhasil @mrjana , satu-satunya cara bagi HAProxy untuk mendapatkan ip klien adalah dengan menjalankan di luar jaringan masuk menggunakan docker run atau langsung di Host tetapi kemudian Anda tidak dapat menggunakan layanan apa pun karena mereka berada di jaringan yang berbeda dan Anda tidak dapat mengaksesnya.

Sederhananya, sama sekali tidak ada cara sejauh yang saya tahu untuk menangani ini segera setelah Anda menggunakan layanan buruh pelabuhan dan mode swarm.

Akan menarik jika penulis jaringan masuk buruh pelabuhan dapat bergabung dalam diskusi karena mereka mungkin memiliki wawasan tentang bagaimana IPVS dikonfigurasi/dioperasikan di bawah tenda (ada banyak mode untuk IPVS) dan bagaimana kami dapat memperbaikinya masalah.

@tlvenn Apakah Anda tahu di mana ini di kode sumber? Saya bisa saja salah, tetapi saya tidak percaya itu menggunakan IPVS berdasarkan beberapa hal yang saya amati:

• Port sumber diterjemahkan (seluruh alasan untuk masalah ini). IPVS tidak melakukan ini. Bahkan dalam mode NAT, itu hanya menerjemahkan alamat tujuan. Anda perlu menggunakan rute default atau perutean kebijakan untuk mengirim paket kembali ke host IPVS.
• Ketika sebuah port diterbitkan dalam mode swarm, semua instance dockerd di swarm mendengarkan pada port yang diterbitkan. Jika IPVS digunakan, maka itu akan terjadi di ruang kernel dan buruh pelabuhan tidak akan mendengarkan di port.

Hai @dack ,

Dari blog mereka:

Secara internal, kami membuat ini bekerja menggunakan Linux IPVS, penyeimbang beban multi-protokol Layer 4 dalam kernel yang telah ada di kernel Linux selama lebih dari 15 tahun. Dengan paket perutean IPVS di dalam kernel, mesh perutean swarm menghadirkan penyeimbang beban yang sadar-kontainer berkinerja tinggi.

Sumber kode harus hidup di proyek swarmkit jika saya tidak salah.

Saya ingin tahu apakah @stevvooe dapat membantu kami memahami apa masalah mendasar di sini.

Oke, saya telah melihat sekilas kodenya dan saya pikir saya memiliki pemahaman yang sedikit lebih baik tentangnya sekarang. Memang tampaknya menggunakan IPVS seperti yang dinyatakan di blog. SNAT dilakukan melalui aturan iptables yang diatur di service_linux.go. Jika saya mengerti dengan benar, logika di baliknya akan menjadi seperti ini (dengan asumsi node A menerima paket klien untuk layanan yang berjalan pada node B):

• Swarm node A menerima paket klien. IPVS/iptables menerjemahkan (src ip)->(node ​​a ip) dan (dst ip)->(node ​​B ip)
• Paket diteruskan ke node B
• Node B mengirimkan balasannya ke node A (karena itulah yang dilihatnya sebagai ip src)
• Node A menerjemahkan src dan dst kembali ke nilai asli dan meneruskan balasan ke klien

Saya pikir alasan di balik SNAT adalah bahwa balasannya harus melalui node yang sama dengan permintaan asli (karena di situlah status NAT/IPVS disimpan). Karena permintaan dapat datang melalui node mana pun, SNAT digunakan sehingga node layanan mengetahui node mana yang akan merutekan kembali permintaan tersebut. Dalam pengaturan IPVS dengan node penyeimbang beban tunggal, itu tidak akan menjadi masalah.

Jadi, pertanyaannya adalah bagaimana menghindari SNAT sambil tetap mengizinkan semua node menangani permintaan klien yang masuk. Saya tidak sepenuhnya yakin apa pendekatan terbaiknya. Mungkin ada cara untuk memiliki tabel status di node layanan sehingga dapat menggunakan perutean kebijakan untuk mengarahkan balasan alih-alih mengandalkan SNAT. Atau mungkin semacam enkapsulasi dapat membantu (VXLAN?). Atau, metode perutean langsung IPVS dapat digunakan. Ini akan memungkinkan simpul layanan untuk membalas langsung ke klien (bukan melalui simpul yang menerima permintaan asli) dan akan memungkinkan penambahan IP mengambang baru untuk layanan. Namun, itu juga berarti bahwa layanan hanya dapat dihubungi melalui IP mengambang dan bukan IP node individual (tidak yakin apakah itu masalah untuk kasus penggunaan apa pun).

Penemuan yang cukup menarik @dack !

Semoga solusi akan ditemukan untuk melewati SNAT itu bersama-sama.

Sementara itu, mungkin ada solusi yang telah dilakukan belum lama ini yang memperkenalkan penerbitan port tingkat host dengan PublishMode , yang secara efektif melewati jaringan ingress.

https://github.com/docker/swarmkit/pull/1645

Hai, terima kasih atas banyak masukannya - kami akan membahas masalah ini secara mendalam setelah akhir pekan.

Beberapa info sementara:

@tlvenn : @mrjana adalah penulis utama di balik fitur jaringan masuk. Sumber tinggal di buruh pelabuhan/libnetwork sebagian besar, beberapa di SwarmKit

@dack : memang didukung oleh IPVS

@tlvenn sejauh yang saya tahu, Docker Swarm menggunakan penyamaran, karena ini adalah cara yang paling mudah dan dijamin untuk bekerja di sebagian besar konfigurasi. Plus ini adalah satu-satunya mode yang benar-benar memungkinkan untuk menyamarkan port juga [re: @dack], yang berguna. Secara teori, masalah ini dapat diselesaikan dengan menggunakan mode enkapsulasi IPIP – aliran paket akan seperti ini:

• Sebuah paket tiba di server gateway – dalam kasus kami setiap node dari swarm – dan IPVS pada node tersebut menentukan bahwa itu sebenarnya sebuah paket untuk layanan virtual, berdasarkan alamat IP dan port tujuan.
• Paket dienkapsulasi ke dalam paket IP lain dan dikirim ke server sebenarnya yang dipilih berdasarkan algoritma load balancing.
• Server sebenarnya menerima paket terlampir, mendekapsulasinya dan melihat IP klien nyata sebagai sumber dan IP layanan virtual sebagai tujuan. Semua server nyata seharusnya memiliki alias antarmuka non-ARPable dengan IP layanan virtual sehingga mereka akan menganggap bahwa paket ini sebenarnya ditujukan untuk mereka.
• Server sebenarnya memproses paket dan mengirimkan respons kembali ke klien secara langsung. IP sumber dalam hal ini akan menjadi IP layanan virtual , jadi tidak ada balasan Mars yang terlibat, yang bagus.

Ada, tentu saja, banyak peringatan dan hal-yang-bisa-salah, tetapi umumnya ini mungkin dan mode IPIP banyak digunakan dalam produksi.

Berharap solusi dapat segera ditemukan untuk ini, karena fiksasi IP dan pemeriksaan keamanan lainnya harus dapat menerima IP eksternal yang benar.

Menonton. Produk kami memanfaatkan informasi IP sumber untuk keamanan dan analitik.

@aluzzadi adakah pembaruan untuk kami?

benjolan, kami membutuhkan ini untuk bekerja untuk proyek yang sangat besar yang kami mulai awal tahun depan.

Memeriksa aliran, tampaknya saat ini berfungsi seperti ini (dalam contoh ini, simpul A menerima lalu lintas masuk dan simpul B menjalankan wadah layanan):

• node A melakukan DNAT untuk mengarahkan paket ke namespace jaringan ingress_sbox (/var/run/docker/netns/ingress_sbox)
• ingress_sbox pada node A menjalankan IPVS dalam mode NAT, yang melakukan DNAT untuk mengarahkan paket ke container pada node B (melalui ingress overlay network) dan juga SNAT untuk mengubah IP sumber ke node A ingress overlay network IP
• paket dirutekan melalui overlay ke server nyata
• paket kembali mengikuti jalur yang sama secara terbalik, menulis ulang alamat sumber/tujuan kembali ke nilai aslinya

Saya pikir SNAT dapat dihindari dengan sesuatu seperti ini:

• node A meneruskan paket ke ingress_sbox tanpa NAT (iptables/policy routing?)
• node A ingress_sbox menjalankan IPVS dalam mode perutean langsung, yang mengirimkan paket ke node B melalui jaringan overlay ingress
• container pada node B menerima paket yang tidak berubah (container harus menerima paket untuk semua IP publik, tetapi tidak mengirim ARP untuk mereka. Ada beberapa cara untuk melakukannya, lihat dokumen IPVS).
• paket kembali dikirim langsung dari node B ke klien (tidak perlu kembali melalui jaringan overlay atau node A)

Sebagai bonus tambahan, tidak ada status NAT yang perlu disimpan dan lalu lintas jaringan overlay berkurang.

@aluzzardi @mrjana Adakah pembaruan tentang ini? Sedikit umpan balik dari Docker akan sangat dihargai.

Menonton. tanpa informasi IP sumber, sebagian besar layanan kami tidak dapat berfungsi seperti yang diharapkan

Bagaimana itu bisa terjadi ?

@tlvenn sepertinya bug di Github ?

@PanJ @tlvenn @vfarcic @dack dan lainnya, PTAL #27917. Kami memperkenalkan kemampuan untuk mengaktifkan mode publikasi layanan = host yang akan menyediakan cara bagi layanan untuk mem-bypass IPVS & mengembalikan perilaku seperti docker run -p dan akan mempertahankan ip sumber untuk kasus yang Membutuhkannya.

Tolong coba 1.13.0-rc2 dan berikan umpan balik.

ya cukup aneh @mavenugo ..

Mengenai mode publikasi, saya sudah menautkan ini dari swarm kit di atas, ini bisa menjadi solusi tetapi saya sangat berharap solusi yang tepat hadir dengan Docker 1.13 untuk mengatasi masalah ini selamanya.

Masalah ini dapat dikategorikan sebagai bug karena mempertahankan ip sumber adalah perilaku yang kami harapkan dari pengguna dan merupakan batasan yang sangat serius dari layanan buruh pelabuhan saat ini.

Saya percaya @kobolog dan @dack telah menemukan beberapa petunjuk potensial tentang cara mengatasi ini dan sudah hampir 2 minggu tanpa tindak lanjut dari pihak Docker.

Bisakah kami memiliki visibilitas tentang siapa yang melihat masalah ini di Docker dan pembaruan status? Terima kasih sebelumnya.

Selain #27917, tidak ada solusi lain untuk 1.13. Fungsionalitas pengembalian langsung perlu dianalisis untuk berbagai kasus penggunaan dan tidak boleh dianggap enteng sebagai perbaikan bug. Kita bisa melihat ini untuk 1,14. Tapi, ini juga termasuk dalam kategori perilaku LB yang dapat dikonfigurasi, yang mencakup algoritme (rr vs 10 metode lain), Jalur data (LVS-DR, LVS-NAT & LVS-TUN). Jika seseorang bersedia berkontribusi untuk ini, tolong dorong PR dan kita bisa membuatnya bergerak.

Cukup adil saya kira @mavenugo mengingat kami memiliki alternatif sekarang.

Paling tidak, dapatkah kita mengubah dokumen untuk 1.13 sehingga dengan jelas menyatakan bahwa saat menggunakan layanan buruh pelabuhan dengan mode penerbitan ingress default, ip sumber tidak dipertahankan dan mengisyaratkan penggunaan mode host jika ini merupakan persyaratan untuk menjalankan layanan ?

Saya pikir itu akan membantu orang-orang yang bermigrasi ke layanan untuk tidak terbakar oleh perilaku tak terduga ini.

Tentu dan ya pembaruan dokumen untuk menunjukkan perilaku ini dan solusi menggunakan publish mode=host akan berguna untuk kasus penggunaan yang gagal dalam mode LVS-NAT.

Hanya memeriksa kembali untuk melihat apakah tidak ada perkembangan baru dalam mendapatkan hal yang nyata ini? Itu tentu saja merupakan batasan besar bagi kami juga

Apakah solusi pada peta jalan untuk buruh pelabuhan 1.14? Kami tertunda menerapkan solusi kami menggunakan buruh pelabuhan sebagian karena masalah ini.

Akan senang melihat tajuk khusus ditambahkan ke permintaan http/https yang mempertahankan ip klien. Ini seharusnya mungkin, bukan? Saya tidak keberatan ketika X_Forwarded_for ditimpa, saya hanya ingin memiliki bidang khusus yang hanya disetel saat pertama kali permintaan memasuki swarm.

Akan senang melihat tajuk khusus ditambahkan ke permintaan http/https yang mempertahankan ip klien. Ini seharusnya mungkin, bukan? Saya tidak keberatan ketika X_Forwarded_for ditimpa, saya hanya ingin memiliki bidang khusus yang hanya disetel saat pertama kali permintaan memasuki swarm.

Penyeimbangan beban dilakukan pada L3/4. Menambahkan header http tidak dimungkinkan.

Perbaikan akan melibatkan penghapusan penulisan ulang alamat sumber.

@mavenugo Saya memperbarui ke docker 1.13 hari ini dan menggunakan mode=host pada layanan proxy saya. Saat ini berfungsi, IP Klien dipertahankan, tetapi saya berharap solusi yang lebih baik :) Terima kasih atas pekerjaan Anda!

Maaf double post...
Bagaimana saya bisa menggunakan file tumpukan (yml v3) untuk mendapatkan perilaku yang sama seperti ketika saya akan menggunakan --publish mode=host,target=80,published=80 melalui pembuatan layanan buruh pelabuhan?

Saya mencoba

...
services:
  proxy:
    image: vfarcic/docker-flow-proxy:1.166
    ports:
      - "80:80/host"
      - "443:443/host" 
...

tapi itu tidak berfungsi (menggunakan pola yang sama seperti di https://docs.docker.com/docker-cloud/apps/stack-yaml-reference/#/ports)

Bagaimana saya bisa menggunakan file tumpukan (yml v3) untuk mendapatkan perilaku yang sama seperti ketika saya akan menggunakan --publish mode=Host,target=80,published=80 melalui pembuatan layanan buruh pelabuhan?

@hamburml - awasi https://github.com/docker/docker/issues/30447 ini adalah masalah/fitur terbuka.

Sayangnya saya tidak dapat menggunakan mode=host sebagai solusi karena saya memerlukan layanan saya untuk berkomunikasi ke jaringan swarm dan juga mendengarkan di semua node, bukan hanya antarmuka host...

@tkeeler33 Saya pikir Anda harus dapat menggunakan layanan sebagai layanan global (yang menyebarkan instance pada setiap node di swarm), dan menghubungkannya ke jaringan swarm untuk berkomunikasi dengan layanan lain di swarm

@thaJeztah - Ya, tetapi saya tidak dapat menghubungkan wadah ke jaringan overlay/swarm dan Host mode=host bersamaan. Itu adalah batasan terbesar saya saat ini.

@tkeeler33 tampaknya bekerja untuk saya;

$ docker network create -d overlay swarm-net

$ docker service create \
  --name web \
  --publish mode=host,published=80,target=80 \
  --network swarm-net \
  --mode=global \
  nginx:alpine

$ docker service create --name something --network swarm-net nginx:alpine

Uji apakah layanan web dapat terhubung dengan layanan something pada jaringan yang sama;

docker exec -it web.xczrerg6yca1f8ruext0br2ow.kv8iqp0wdzj3bw7325j9lw8qe sh -c 'ping -c3 -w1 something'
PING something (10.0.0.4): 56 data bytes
64 bytes from 10.0.0.4: seq=0 ttl=64 time=0.251 ms

--- something ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.251/0.251/0.251 ms

@thaJeztah - Terima kasih! Setelah menggali lebih dalam, saya menyadari masalah saya adalah bahwa saya membuat jaringan buruh pelabuhan saya menggunakan opsi --opt encrypted , yang menyebabkan wadah gagal koneksi dari Host. Setelah saya mencoba langkah Anda, saya dapat dengan cepat mempersempit akar penyebabnya. Opsi ini mungkin merupakan solusi sementara yang baik, saya hanya perlu memikirkan implikasi keamanan apa pun.

Sangat menghargai infonya!

@tkeeler33 --opt encrypted seharusnya tidak mempengaruhi pemetaan host-port. Satu-satunya tujuan dari opsi terenkripsi adalah untuk mengenkripsi lalu lintas terowongan vxlan antara node. Dari dokumen : "Jika Anda berencana membuat jaringan overlay dengan enkripsi (--opt terenkripsi), Anda juga perlu memastikan lalu lintas protokol 50 (ESP) diizinkan." Bisakah Anda memeriksa konfigurasi Anda untuk memastikan ESP diizinkan?
Selain itu, opsi --opt encrypted murni enkripsi bidang data. Semua lalu lintas bidang kontrol (pertukaran perutean, distribusi Service Discovery, dll...) semuanya dienkripsi secara default bahkan tanpa opsi.

@mavenugo Anda benar. Ketika saya membuat jaringan baru dengan --opt encrypted itu bekerja dengan baik. Ketika saya membandingkan jaringan yang baru dibuat dengan jaringan saya yang sudah ada, saya perhatikan bahwa "Internal": true telah disetel. Itu kemungkinan masalahnya dan merupakan kesalahan selama pembuatan jaringan awal ... Terima kasih atas bantuan & klarifikasi Anda, Ini hari yang panjang ...

@dack @kobolog Dalam penerapan khas mode LVS-Tunnel dan LVS-DR, IP tujuan dalam paket yang masuk akan menjadi layanan VIP yang juga diprogram sebagai IP non ARP di server sebenarnya. Routing mesh bekerja dengan cara yang berbeda secara fundamental, permintaan yang masuk bisa ke salah satu host. Agar server nyata menerima paket (dalam mode LVS apa pun), IP tujuan harus diubah ke IP lokal. Tidak ada cara untuk paket balasan dari wadah backend untuk kembali dengan alamat sumber yang benar. Alih-alih pengembalian langsung, kita dapat mencoba mengembalikan paket balasan ke host ingress. Tetapi tidak ada cara bersih untuk melakukannya kecuali dengan mengubah IP sumber yang membawa kita kembali ke titik awal.

@thaJeztah Saya pikir kita harus mengklarifikasi ini dalam dokumentasi, sarankan menggunakan mod host jika IP klien harus dipertahankan dan tutup masalah ini.

@sanimej Saya masih tidak mengerti mengapa tidak mungkin melakukan ini tanpa NAT. Tidak bisakah kita memiliki opsi untuk menggunakan, misalnya, aliran LVS-DR biasa? Docker menambahkan vip non-arp ke node yang sesuai, LVS mengarahkan paket masuk ke node, dan paket keluar kembali secara langsung. Mengapa penting bahwa paket yang masuk dapat mengenai host mana pun? Itu tidak berbeda dari LVS standar dengan beberapa server frontend dan beberapa backend.

@thaJeztah terima kasih atas solusinya :)
Jika Anda menggunakan proxy Anda dengan compose versi 3 sintaks publikasi baru tidak didukung sehingga kami dapat menambal layanan yang diterapkan menggunakan perintah ini (ganti nginx_proxy dengan nama layanan)

docker service update nginx_proxy \
    --publish-rm 80 \
    --publish-add "mode=host,published=80,target=80" \
    --publish-rm 443 \
    --publish-add "mode=host,published=443,target=443"

@dack Dalam aliran LVS-DR reguler, IP tujuan akan menjadi layanan VIP. Jadi LB dapat mengirim paket ke backend tanpa perubahan IP tujuan. Ini tidak terjadi dengan routing mesh karena IP tujuan paket yang masuk akan menjadi salah satu IP host.

@sanimej ada umpan balik pada proposal di atas untuk menggunakan mode enkapsulasi IPIP untuk menyelesaikan masalah ini?

@tlvenn LVS-IP tunnel bekerja sangat mirip dengan LVS-DR, kecuali bahwa backend mendapatkan paket melalui IP di IP tunnel daripada mac-rewrite. Jadi memiliki masalah yang sama untuk kasus penggunaan mesh perutean.

Dari proposal yang Anda rujuk..
The real server receives the enclosing packet, decapsulates it and sees real client IP as source and virtual service IP as destination.

IP tujuan paket akan menjadi IP host tempat klien mengirim paket dan bukan VIP. Jika tidak ditulis ulang, server sebenarnya akan menghapusnya setelah menghapus header IP luar. Jika IP tujuan ditulis ulang, balasan server sebenarnya ke klien akan memiliki IP Sumber yang salah yang mengakibatkan kegagalan koneksi.

Terima kasih atas klarifikasinya @sanimej. Bisakah Anda menerapkan protokol PROXY ? Itu tidak akan memberikan solusi yang mulus tetapi setidaknya itu akan menawarkan layanan solusi untuk menyelesaikan IP pengguna.

Ada cara yang sulit untuk mencapai pelestarian IP sumber dengan membagi rentang port sumber menjadi blok dan menetapkan blok untuk setiap host di cluster. Kemudian dimungkinkan untuk melakukan pendekatan NAT+DR hybrid, di mana ingress host melakukan SNAT biasa dan mengirimkan paket ke server nyata. Pada host tempat server sebenarnya berjalan, berdasarkan IP sumber lakukan SNAT untuk mengubah port sumber ke port dalam rentang yang ditetapkan untuk host ingress. Kemudian pada paket kembali dari wadah cocok dengan rentang port sumber (dan port target) dan ubah IP sumber menjadi host ingress.

Secara teknis ini akan berhasil Tetapi tidak praktis dan rapuh dalam penerapan nyata di mana anggota cluster ditambahkan dan dihapus dengan cepat. Ini juga mengurangi ruang port secara signifikan.

Pendekatan NAT+DR yang saya sebutkan tidak akan berfungsi karena IP sumber tidak dapat diubah di host ingress. Dengan mengubah hanya port sumber menjadi satu dalam jangkauan untuk host tertentu dan menggunakan kebijakan perutean dari host backend untuk mengembalikan paket ke host ingress mungkin menjadi pilihan. Ini masih memiliki masalah lain yang saya sebutkan sebelumnya.

@thaJeztah
Apakah ada solusi saat ini untuk meneruskan alamat IP asli dari wadah Nginx ke wadah web?
Saya memiliki wadah Nginx yang berjalan dalam mode global dan dipublikasikan ke host , sehingga wadah Nginx mendapatkan alamat IP yang benar. Kedua wadah saling melihat dengan baik, namun wadah web mendapatkan alamat IP wadah Nginx, bukan alamat klien.
Nginx adalah proxy terbalik untuk web, dan web menjalankan uwsgi pada port 8000:

server {
    resolver 127.0.0.11;
    set $web_upstream http://web:8000;

    listen 80;
    server_name domain.com;
    location / {
        proxy_pass $web_upstream;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

@lpakula Silakan periksa jawaban saya di atas + konfigurasi nginx yang berfungsi ini

@pi0 Terima kasih atas balasannya

Saya menggunakan konfigurasi nginx dari tautan, tetapi alamat IP masih salah, saya pasti memiliki sesuatu yang hilang dalam konfigurasi saya

Saya memiliki swarm cluster docker ( 17.03.0-ce ) dengan jaringan overlay dan dua layanan

    docker service create --name nginx --network overlay_network --mode=global \
        --publish mode=host,published=80,target=80 \
        --publish mode=host,published=443,target=443 \
        nginx:1.11.10

    docker service create --name web --network overlay_network \
        --replicas 1 \
        web:newest

Kontainer Nginx menggunakan kontainer resmi terbaru https://hub.docker.com/_/nginx/
Wadah web menjalankan server uwsgi pada port 8000

Saya menggunakan global nginx.conf dari tautan dan conf.d/default.conf terlihat sebagai berikut:

   server {
       resolver 127.0.0.11;
       set $web_upstream http://web:8000;

       listen 80;
       server_name domain.com;
       location / {
        proxy_pass $web_upstream;
      }
  }

Dan kemudian log kontainer nginx:

  194.168.X.X - - [17/Mar/2017:12:25:08 +0000] "GET / HTTP/1.1" 200

Log penampung web:

  10.0.0.47 - - [17/Mar/2017 12:25:08] "GET / HTTP/1.1" 200 -

Apa yang hilang di sana?

Alamat IP masih akan salah. Tapi itu akan menambahkan header HTTP yang
berisi alamat IP asli. Anda harus mengonfigurasi server web pilihan Anda
untuk mempercayai proxy (gunakan tajuk alih-alih IP sumber)
Pada Jumat, 17 Mar 2560 jam 19:36 Lukasz Pakula [email protected]
menulis:

@pi0 https://github.com/pi0 Terima kasih atas balasannya

Saya menggunakan konfigurasi nginx dari tautan, tetapi alamat IP masih
salah, saya pasti memiliki sesuatu yang hilang dalam konfigurasi saya

Saya memiliki klaster gerombolan buruh pelabuhan ( 17.03.0-ce ) dengan jaringan overlay dan dua
jasa

docker service create --name nginx --network overlay_network --mode=global \
    --publish mode=host,published=80,target=80 \
    --publish mode=host,published=443,target=443 \
    nginx:1.11.10

docker service create --name web --network overlay_network \
    --replicas 1 \
    web:newest

Kontainer Nginx menggunakan kontainer resmi terbaru
https://hub.docker.com/_/nginx/ http://url
Wadah web menjalankan server uwsgi pada port 8000

Saya menggunakan nginx.conf global dari tautan dan tampilan conf.d/default.conf
sebagai berikut:

server {
penyelesai 127.0.0.11;
set $web_upstream http://web :8000;

   listen 80;
   server_name domain.com;
   location / {
    proxy_pass $web_upstream;
  }

}

Dan kemudian log kontainer nginx:

194.168.XX - - [17/Mar/2017:12:25:08 +0000] "GET / HTTP/1.1" 200

Log penampung web:

10.0.0.47 - - [17/Mar/2017 12:25:08] "GET / HTTP/1.1" 200 -

Apa yang hilang di sana?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/25526#issuecomment-287342795 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABtu97EFaCmLwAZiOrYT4nXi4oXPCbLQks5rmn43gaJpZM4Jf2WK
.

>

PanJ,
Panjamapong Sermsawatsri
Telp. (+66)869761168

@lpakula Ah ada hal lain yang juga harus dihormati oleh gambar web:newest X-Real-IP . nginx tidak akan secara otomatis mengubah IP pengirim itu hanya mengirim header petunjuk.

@pi0 @PanJ
Itu masuk akal, terima kasih teman-teman!

Ikat port menggunakan mode host.

nginx mendukung Transparansi IP menggunakan modul kernel TPROXY .

@stevvooe Bisakah Docker melakukan hal seperti itu juga?

nginx mendukung Transparansi IP menggunakan modul kernel TPROXY.
@stevvooe Bisakah Docker melakukan hal seperti itu juga?

Tidak mungkin, karena entri perlu dilacak di seluruh node. Saya akan membiarkan @sanimej atau @mavenugo.

Bisakah swarm menyediakan REST API untuk mendapatkan alamat IP klien?

@tonysongtl yang tidak terkait dengan masalah ini

Hal lain yang perlu dipertimbangkan adalah bagaimana lalu lintas Anda dikirimkan ke node Anda dalam pengaturan yang sangat tersedia. Sebuah node harus bisa turun tanpa membuat kesalahan untuk klien. Rekomendasi saat ini adalah menggunakan penyeimbang beban eksternal (ELB, F5, dll) dan keseimbangan beban di Layer 4 ke setiap node Swarm, dengan pemeriksaan kesehatan Layer 4 yang sederhana. Saya percaya F5 menggunakan SNAT, jadi kasus terbaik dalam konfigurasi ini adalah menangkap IP tunggal F5 Anda, dan bukan IP klien sebenarnya.

Referensi:
https://docs.docker.com/engine/swarm/ingress/#configure -an-external-load-balancer
https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Docker_EE_Best_Practices_and_Design_Considerations
https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Universal_Control_Plane_2.0_Service_Discovery_and_Load_Balancing

mencerminkan komentar di atas - dapatkah protokol proxy tidak digunakan? Semua penyeimbang beban cloud dan haproxy menggunakan ini untuk pelestarian ip sumber.

Calico juga memiliki mode ipip - https://docs.projectcalico.org/v2.2/usage/configuration/ip-in-ip - yang merupakan salah satu alasan mengapa github menggunakannya. https://githubengineering.com/kubernetes-at-github/

Hai.

Demi pemahaman dan kelengkapan, izinkan saya meringkas dan mohon koreksi saya jika saya salah:

Masalah utamanya adalah container tidak menerima src-IP asli tetapi swarm VIP. Saya telah mereplikasi masalah ini dengan skenario berikut:

create docker swarm
docker service create --name web --publish 80:80 nginx
access.log source IP is 10.255.0.7 instead of client's browser IP

Kelihatannya:

Ketika layanan dalam swarm menggunakan mesh (default), swarm apakah NAT untuk memastikan lalu lintas dari asal yang sama selalu dikirim ke layanan yang dijalankan oleh host yang sama?
Oleh karena itu, ia kehilangan src-IP asli dan menggantinya dengan layanan VIP swarm.

Sepertinya @kobolog https://github.com/moby/moby/issues/25526#issuecomment -258660348 dan @dack https://github.com/moby/moby/issues/25526#issuecomment -260813865 proposal dibantah oleh @sanimej https://github.com/moby/moby/issues/25526#issuecomment -280722179 https://github.com/moby/moby/issues/25526#issuecomment -281289906 tetapi, TBH, argumennya tidak sepenuhnya jelas untuk saya belum, saya juga tidak mengerti mengapa utas belum ditutup jika ini benar-benar tidak mungkin.

@sanimej tidakkah ini akan berhasil?:

1. Swarm menerima pesan dengan src-IP=A dan destination="my-service-virtual-address"
2. Paket dikirim ke swarm node yang menjalankan layanan itu, merangkum pesan asli.
3. Node meneruskan ke tugas yang mengubah tujuan ke container-running-that-service-IP
   Swarm dan node dapat memelihara tabel untuk memastikan lalu lintas dari asal yang sama diteruskan ke node yang sama bila memungkinkan.

Bukankah opsi untuk mengaktifkan "proxy terbalik alih-alih NAT" untuk layanan tertentu menyelesaikan semua masalah ini yang memuaskan semua orang?

Di sisi lain, IIUC, satu-satunya pilihan yang tersisa adalah menggunakan https://docs.docker.com/engine/swarm/services/#publish -a-services-ports-directly-on-the-swarm-node, yang -lagi IIUC- sepertinya tidak menggunakan mesh sama sekali, maka saya tidak melihat manfaat menggunakan mode swarm (vs compose). Faktanya, sepertinya swarm pra-1.12, membutuhkan _Consul_ dan sebagainya.

Terima kasih atas bantuan dan kesabaran Anda.
Salam

@sanimej
Terlebih lagi ... mengapa Docker tidak hanya melakukan port forwarding NAT (hanya mengubah IP/port tujuan)?

1. Swarm menerima pesan "dari A ke layanan saya"
2. Swarm meneruskan pesan ke host yang menjalankan layanan itu, mengatur dest=node1
3. Node1 menerima pesan "dari A ke node1", dan meneruskan pengaturan dest=container1
4. Container1 menerima pesan "dari A ke container1"
5. Untuk membalas, kontainer menggunakan rute gateway default

Saya hanya ingin berpadu; sementara saya mengerti bahwa tidak ada cara mudah untuk melakukan ini, tidak mempertahankan alamat IP asal dengan cara tertentu sangat menghambat sejumlah kasus penggunaan aplikasi. Berikut adalah beberapa yang dapat saya pikirkan dari atas kepala saya:

• Mampu memiliki metrik yang merinci dari mana pengguna Anda berasal sangat penting untuk rekayasa jaringan/layanan.

• Dalam banyak aplikasi keamanan, Anda perlu memiliki akses ke alamat IP asal untuk memungkinkan daftar hitam dinamis berdasarkan penyalahgunaan layanan.

• Layanan kesadaran lokasi seringkali harus dapat mengakses alamat IP untuk menemukan lokasi umum pengguna ketika metode lain gagal.

Dari pembacaan saya tentang utas masalah ini, tampaknya solusi yang diberikan tidak berfungsi dengan baik ketika Anda ingin memiliki layanan yang dapat diskalakan dalam Docker Swarm. Membatasi diri Anda pada satu instans per node pekerja sangat mengurangi fleksibilitas penawaran. Selain itu, mempertahankan pendekatan hibrid untuk menjalankan LB/Proxy di tepi sebagai wadah yang diatur non-Swarm sebelum dimasukkan ke dalam wadah yang diatur Swarm sepertinya akan kembali ke masa lalu. Mengapa pengguna perlu mempertahankan 2 paradigma berbeda untuk orkestrasi layanan? Bagaimana dengan kemampuan menskalakan LB/Proxy di edge secara dinamis? Itu harus dilakukan secara manual, bukan?

Bisakah tim Docker mempertimbangkan komentar ini dan melihat apakah ada cara untuk memperkenalkan fungsi ini, sambil tetap mempertahankan kualitas dan fleksibilitas yang ada di ekosistem Docker?

Sebagai tambahan, saya saat ini terkena ini sekarang. Saya memiliki aplikasi web yang meneruskan permintaan yang diotorisasi/diautentikasi ke server web hilir. Teknisi layanan kami harus dapat memverifikasi apakah orang telah mencapai server hilir, yang mereka sukai untuk menggunakan log akses web. Dalam skenario saat ini, tidak ada cara bagi saya untuk menyediakan fungsionalitas itu karena server proxy saya tidak pernah melihat alamat IP asal. Saya ingin aplikasi saya mudah diskalakan, dan sepertinya saya tidak bisa melakukan ini dengan solusi yang disajikan, setidaknya tanpa membuang VM baru untuk setiap instans yang diskalakan.

@Jitsusama dapatkah Kubernetes menyelesaikan masalah Anda?

@thaJeztah apakah ada cara untuk melakukan pekerjaan menggunakan docker-compose?

Saya mencoba

`services:
  math:
    build: ./math
    restart: always
    ports:
    - target: 12555
      published: 12555
      mode: host

Tapi sepertinya menggunakan 172.xx1 sebagai IP sumber

@trajano , saya tidak tahu. Apakah Kubernetes entah bagaimana berhasil mengatasi masalah ini?

@Jitsusama
Ya, mereka memiliki dokumentasi yang mengacu pada bagaimana mereka mempertahankan IP sumber . Ini fungsional, tetapi tidak begitu cantik jika Anda tidak menggunakan Load Balancer karena paket dijatuhkan pada node tanpa titik akhir tersebut. Jika Anda berencana menggunakan Rancher sebagai Penyeimbang Beban yang di-host-sendiri, sayangnya saat ini belum mendukungnya .

@trajano

Tapi sepertinya menggunakan 172.xx1 sebagai IP sumber

Jika Anda mengakses aplikasi Anda secara lokal, IP itu harus benar (jika Anda menggunakan swarm) karena docker_gwbridge adalah antarmuka yang berinteraksi dengan wadah proxy Anda. Anda dapat mencoba mengakses aplikasi dari komputer lain dalam jaringan IP Anda untuk melihat apakah aplikasi menangkap alamat yang benar.

Adapun solusi penulisan, itu mungkin. Di sini, saya menggunakan image jwilder/nginx-proxy sebagai frontend reverse-proxy saya (untuk menyederhanakan konsep) bersama dengan image build resmi nginx sebagai layanan backend. Saya menyebarkan tumpukan dalam Mode Swarm Docker:

version: '3.3'

services:

  nginx-proxy:
    image: 'jwilder/nginx-proxy:alpine'
    deploy:
      mode: global
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro

  nginx:
    image: 'nginx:1.13.5-alpine'
    deploy:
      replicas: 3
    ports:
      - 80
      - 443
    environment:
      - VIRTUAL_HOST=website.local

$ echo '127.0.0.1 website.local' | sudo tee -a /etc/hosts

$ docker stack deploy --compose-file docker-compose.yml website

Ini akan membuat jaringan website_default untuk tumpukan. Titik akhir saya didefinisikan dalam variabel lingkungan VIRTUAL_HOST dan mengakses http://website.local memberi saya:

website_nginx-proxy.0.ny152x5l9sh7<strong i="30">@Sherry</strong>    | nginx.1    | website.local 172.18.0.1 - - [08/Sep/2017:21:33:36 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36"

website_nginx.1.vskh5941kgkb<strong i="33">@Sherry</strong>    | 10.0.1.3 - - [08/Sep/2017:21:33:36 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36" "172.18.0.1"

Perhatikan bahwa akhir header untuk website_nginx.1.vskh5941kgkb memiliki petunjuk tentang IP asli ( 172.18.0.1 ). X-Forwarded-For & X-Real-IP diatur dalam nginx.tmpl dari jwilder/nginx-proxy secara default.

Untuk port 443 , saya tidak dapat menambahkan kedua port di file docker-compose, jadi saya hanya menggunakan:

docker service update website_nginx-proxy \
    --publish-rm 80 \
    --publish-add "mode=host,published=80,target=80" \
    --publish-rm 443 \
    --publish-add "mode=host,published=443,target=443" \
    --network-add "<network>"

sambil juga menambahkan jaringan yang ingin saya proksi balik dengan aplikasi yang berisi variabel lingkungan VIRTUAL_HOST . Opsi yang lebih terperinci dimungkinkan dalam dokumentasi untuk jwilder/nginx-proxy , atau Anda dapat membuat pengaturan sendiri.

Kontroler ingress di Kubernetes pada dasarnya melakukan hal yang sama, karena grafik ingress (biasanya) memiliki dukungan X-Forwarded-For dan X-Real-IP dengan sedikit lebih banyak fleksibilitas dengan pilihan dan jenis ingress dan juga replika penerapannya.

Jadi dokumentasi kubernetes tidak lengkap. Cara lain yang sedang
cukup umum sebenarnya adalah protokol ingress+proxy.

https://www.haproxy.com/blog/haproxy/proxy-protocol/

Protokol proxy adalah protokol yang diterima secara luas yang mempertahankan sumber
informasi. Haproxy hadir dengan dukungan bawaan untuk protokol proxy. Nginx
dapat membaca tetapi tidak menyuntikkan protokol proxy.

Setelah protokol proxy disiapkan, Anda dapat mengakses informasi tersebut dari mana saja
layanan hilir seperti
https://github.com/nginxinc/kubernetes-ingress/blob/master/examples/proxy-protocol/README.md

Bahkan openshift memanfaatkan ini untuk informasi IP sumber
https://docs.openshift.org/latest/install_config/router/proxy_protocol.html

Ini adalah ingress haproxy terbaru untuk k8s yang menyuntikkan protokol proxy.

IMHO cara untuk melakukan ini di swarm adalah membuat ingress dapat membaca proxy
protokol (jika menerima lalu lintas dari LB hulu yang memiliki
sudah menyuntikkan protokol proxy) serta menyuntikkan protokol proxy
informasi (jika semua lalu lintas benar-benar mencapai ingress terlebih dahulu).

Saya tidak mendukung untuk melakukannya dengan cara lain terutama ketika ada
standar yang diterima secara umum untuk melakukan ini.

Traefik memang menambahkan dukungan proxy_protocol beberapa minggu yang lalu dan tersedia mulai dari v1.4.0-rc1 dan seterusnya.

Ini perlu dilakukan pada tingkat masuknya kawanan buruh pelabuhan. Jika masuknya
tidak menyuntikkan data protokol proxy, tidak ada layanan hilir
(termasuk traefix, nginx, dll) akan dapat membacanya.

Pada 10-Sep-2017 21:42, "monotykamary" [email protected] menulis:

Traefik memang menambahkan dukungan proxy_protocol
https://github.com/containous/traefik/pull/2004 beberapa minggu yang lalu dan sekarang
tersedia dari v1.4.0-rc1 dan seterusnya.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-328352805 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU3jj5dJcpMDysjIyGQK7SGx8GwWbks5shApqgaJpZM4Jf2WK
.

saya juga bingung tentang hubungan bug ini dengan infrakit. misalnya https://github.com/docker/infrakit/pull/601 dapatkah seseorang mengomentari arah yang akan diambil kawanan buruh pelabuhan?

Akankah swarm rollup menjadi infrakit ? Saya terutama tertarik pada sisi masuknya itu.

Kami juga sedang menghadapi masalah ini. Kami ingin mengetahui ip klien dan IP yang diminta untuk koneksi masuk. Misalnya jika pengguna melakukan koneksi TCP mentah ke server kami, kami ingin tahu apa IP mereka dan ip mana di mesin kami yang mereka hubungkan.

@blazedd Seperti yang dikomentari sebelumnya dan di utas lain, ini sebenarnya dimungkinkan menggunakan publishMode. yaitu: layanan tidak ditangani oleh jaringan mesh.

IIUC, ada beberapa kemajuan menuju peningkatan cara ingress menangani ini, tapi itu sebenarnya satu-satunya solusi.

Kami telah menerapkan layanan nginx kami menggunakan publishmode dan mode:global , untuk menghindari konfigurasi LB eksternal

@mostolog Terima kasih atas balasan Anda. Hanya beberapa catatan:

1. publishMode tidak menyelesaikan masalah sama sekali. Koneksi soket masuk masih diselesaikan ke jaringan lokal yang disiapkan oleh gerombolan. Setidaknya ketika Anda menggunakan daftar port mode: host
2. nginx sebenarnya bukan solusi yang baik. Aplikasi kami berbasis TCP, tetapi bukan server web. Tidak ada header yang dapat kami gunakan tanpa mengkodekannya secara manual.
3. Jika saya menggunakan docker run --net=host ... semuanya berfungsi dengan baik.
4. Satu-satunya solusi yang saya lihat sejauh ini berfungsi adalah dengan menggunakan: https://github.com/moby/moby/issues/25873#issuecomment -319109840

@blazedd Di tumpukan kami, kami memiliki:

    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host

jadi, saya berani bertaruh kami mendapatkan IP asli di log kami.

@mostolog Setidaknya tidak berfungsi di Windows. Saya masih mendapatkan alamat 172.0.0.x sebagai sumbernya.

@mostolog mode: host tidak mengekspos wadah Anda ke jaringan Host. Ini menghapus wadah dari jaringan masuk, yang merupakan cara Docker biasanya beroperasi saat menjalankan wadah. Ini akan mereplikasi --publish 8080:8080 digunakan dalam perintah docker run. Jika nginx mendapatkan ips nyata, itu bukan hasil dari soket yang terhubung ke ip tersebut secara langsung. Untuk menguji ini, Anda harus secara serius mempertimbangkan untuk menggunakan implementasi TCP mentah atau server HTTP, tanpa kerangka kerja, dan memeriksa alamat yang dilaporkan.

Mengapa tidak menggunakan jaringan rute IPVS ke kontainer secara langsung? ikat semua ips antarmuka overlay swarm node sebagai ips virtual, gunakan ip rule from xxx table xxx untuk membuat multi-gateway, kemudian swarm node dapat merutekan klien ke wadah secara langsung (DNAT), tanpa daemon proxy jaringan userspace (dockerd)

@blazedd Sudahkah Anda mencobanya? Saya mendapatkan alamat ip eksternal saat mengikuti contoh @mostolog .

Saya menghadapi masalah ini lagi.

Pengaturan saya adalah sebagai berikut:

• ipvs load balancer dalam mode DR (eksternal ke kawanan buruh pelabuhan)
• 3 node buruh pelabuhan, dengan IP tujuan ditambahkan ke semua node dan arp dikonfigurasi dengan tepat untuk perutean IPVS DR

Saya ingin menyebarkan tumpukan ke kawanan dan membuatnya mendengarkan pada port 80 pada IP virtual tanpa merusak alamat.

Saya hampir bisa sampai di sana dengan melakukan ini:
port:
- target: 80
diterbitkan: 80
protokol: tcp
modus: tuan rumah

Masalahnya di sini adalah bahwa itu tidak memungkinkan Anda untuk menentukan alamat IP mana yang akan diikat - itu hanya mengikat ke semua. Ini menimbulkan masalah jika Anda ingin menjalankan lebih dari satu layanan menggunakan port tersebut. Itu perlu untuk mengikat hanya ke satu IP. Menggunakan port yang berbeda bukanlah pilihan dengan load balancing DR. Tampaknya para pengembang membuat asumsi bahwa IP yang sama tidak akan pernah ada di banyak node, yang tidak terjadi saat menggunakan penyeimbang beban DR.

Selain itu, jika Anda menggunakan sintaks pendek, itu akan mengabaikan IP pengikatan dan masih mengikat semua alamat. Satu-satunya cara yang saya temukan untuk mengikat ke satu IP adalah dengan menjalankan wadah yang tidak berkerumun (bukan layanan atau tumpukan).

Jadi sekarang saya kembali harus menggunakan wadah mandiri dan harus mengelolanya sendiri alih-alih mengandalkan fitur layanan/tumpukan untuk melakukan itu.

Kami memiliki masalah yang sama.
Saya akan memilih solusi transparan dalam masuknya buruh pelabuhan yang memungkinkan semua aplikasi (beberapa menggunakan UDP/TCP mentah, tidak terutama HTTP) berfungsi seperti yang diharapkan.

Saya dapat menggunakan solusi "mode=host port publishing" karena layanan saya digunakan secara global.
Namun, tampaknya ini tidak kompatibel dengan penggunaan driver jaringan macvlan, yang saya perlukan karena beberapa alasan lain.
Kami mendapatkan log seperti "driver macvlan tidak mendukung pemetaan port".
Saya mencoba menggunakan beberapa jaringan, tetapi tidak membantu.

Saya membuat tiket khusus di sini: https://github.com/docker/libnetwork/issues/2050
Itu membuat saya tidak ada solusi untuk saat ini :'(

Halo kawan-kawan
Apakah ada solusi untuk saat ini? Tanpa menerbitkannya sebagai port host
Pelabuhan ?

Pada 11-Jan-2018 00:03, "Olivier Voortman" [email protected] menulis:

Kami memiliki masalah yang sama.
Saya akan memilih solusi transparan dalam masuknya buruh pelabuhan yang memungkinkan semua
aplikasi (beberapa menggunakan UDP/TCP mentah, tidak terutama HTTP) untuk berfungsi sebagai
mengharapkan.

Saya dapat menggunakan solusi "mode=host port publishing" karena layanan saya
dikerahkan secara global.
Namun, tampaknya ini tidak sesuai dengan penggunaan macvlan
driver jaringan, yang saya perlukan untuk beberapa alasan lain.
Kami mendapatkan log seperti "driver macvlan tidak mendukung pemetaan port".
Saya mencoba menggunakan beberapa jaringan, tetapi tidak membantu.

Saya membuat tiket khusus di sini: docker/libnetwork#2050
https://github.com/docker/libnetwork/issues/2050
Itu membuat saya tidak ada solusi untuk saat ini :'(

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-356693751 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsUzlM-BMbEsDYaiYH6hKLha-aRqerks5tJQJngaJpZM4Jf2WK
.

Sangat disayangkan bahwa tidak mungkin untuk mendapatkan IP klien. ini membuat sebagian besar fitur bagus kawanan buruh pelabuhan tidak dapat digunakan.

Pada pengaturan saya, satu-satunya cara untuk mendapatkan IP klien adalah dengan menggunakan network_mode:host dan tidak menggunakan swarm sama sekali.

menggunakan mode=host port publishing atau docker run -p "80:80" ... tradisional tidak berhasil

Beberapa solusi disarankan di https://github.com/moby/moby/issues/15086 tetapi satu-satunya solusi yang berhasil bagi saya adalah jaringan "Host" ...

Masalah lain dengan tidak memiliki IP yang benar adalah bahwa pembatasan laju nginx tidak berfungsi dengan benar dan oleh karena itu tidak dapat digunakan dengan penyeimbang beban kawanan buruh pelabuhan, karena permintaan dibatasi laju dan ditolak karena nginx menghitung semuanya karena berasal dari pengguna tunggal/IP. Jadi satu-satunya solusi adalah menggunakan mode=Host, tetapi cara ini saya kehilangan kemampuan penyeimbangan beban dan harus mengarahkan DNS ke instance tertentu.

Mungkin buruh pelabuhan bukan alat yang ideal untuk pekerjaan ini, saya mencari gelandangan untuk mengatur server HTTP yang menghadap ke depan dan menempatkan IP klien sebagai bagian dari header permintaan HTTP.

Sampai Docker mampu meneruskan informasi klien melalui jaringan overlay, seseorang dapat menggunakan proxy seperti Docker Flow Proxy atau Traefik, mempublikasikan port yang diinginkan dalam mode host di layanan itu dan menghubungkan layanan aplikasi ke sana. Bukan solusi lengkap tetapi bekerja dengan cukup baik dan memungkinkan penyeimbangan beban layanan aplikasi/pengambilan IP klien.

@deeky666 Traefik dan pekerjaan serupa hanya jika tidak di-docker

Saya tidak melihat dukungan udo di traefik

dikirim dari iPhone saya

Akhirnya kami menyerah pada wadah buruh pelabuhan. Ini belum siap produksi!

Pada Rabu, 24 Januari 2018 pukul 5:43 pagi, Efrain [email protected] menulis:

Saya tidak melihat dukungan udo di traefik

dikirim dari iPhone saya

>

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-360091189 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AHf7rvMcH2iFBxcExfO_Ol0UttCspuTnks5tNwlkgaJpZM4Jf2WK
.

Masalahnya tampaknya sebagian diselesaikan dalam 17.12.0-ce dengan menggunakan mode=host .

docker service create --publish mode=host,target=80,published=80 --name=nginx nginx

Ini memiliki beberapa batasan (tidak ada mesh perutean) tetapi berfungsi!

@goetas mode=host bekerja untuk sementara waktu sebagai solusi, jadi saya tidak akan mengatakan masalah terpecahkan. Menggunakan mode=host memiliki banyak batasan, port terbuka, tidak dapat menggunakan swarm load balancing, dll.

@darklow saya tahu batasannya, tetapi untuk usecase saya baik-baik saja (jika tidak lebih baik!). Di 17.09.1-ce tidak berfungsi sama sekali, jadi bagi saya sudah ada peningkatan!

Kelemahan besar dari solusi itu adalah tidak mungkin untuk menghindari waktu henti selama pembaruan.
Saat ini, kita harus memilih untuk menyerah apakah stabilitas atau alamat IP sumber.

Saya setuju. Swarm membutuhkan cara ketersediaan tinggi untuk mempertahankan IP sumber.

Mungkin menggunakan protokol proxy. Saya tidak berpikir itu adalah upaya besar untuk menambahkan
dukungan protokol proxy untuk kawanan buruh pelabuhan.

Apakah ada yang mencari ini?

Pada 28-Jan-2018 22:39, notifikasi "Genki Takiuchi"@github.com menulis:

Kelemahan besar dari solusi itu adalah tidak mungkin untuk menghindari down
waktu selama pembaruan.
Saat ini, kita harus memilih untuk menyerah apakah stabilitas atau sumber IP
alamat.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-361078416 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU-or7fnhKTg7fhjtZYjGYHBFRE7Dks5tPKnYgaJpZM4Jf2WK
.

@sandys saya setuju. Protokol proxy akan menjadi ide bagus.
@thaJeztah @aluzzardi @mrjana bisakah masalah ini mendapat perhatian? Sudah lama tidak ada tanggapan dari tim. Terima kasih.

Protokol Proxy terdengar seperti solusi terbaik bagi saya. Mudah-mudahan tim akan mempertimbangkannya.

@goetas berhasil pada satu titik setidaknya saya melihatnya berfungsi tetapi tampaknya telah kembali ke perilaku 172.xxx lagi di buruh pelabuhan 1.12.6

Ini SANGAT buruk, ini mengurangi pembatasan tarif, pencegahan penipuan, pencatatan, login aman, pemantauan sesi, dll.!
Mendengarkan dengan mode:host berfungsi, tetapi bukan solusi nyata karena Anda kehilangan loadbalancing mesh dan hanya perangkat lunak loadbalanacer pada host yang memiliki ip publik yang harus menangani semua lalu lintas sendirian.

ini adalah bug yang sangat kritis dan penting bagi kami dan ini menghalangi go-live kami dengan Swarm. Kami juga percaya protokol proxy adalah solusi yang tepat untuk ini. Masuknya Docker harus melewati ip sumber pada protokol proxy.

Di twitter salah satu solusi yang telah diusulkan adalah menggunakan Traefik sebagai ingress yang dikelola di luar Swarm . Ini sangat suboptimal bagi kami - dan bukan overhead yang ingin kami kelola.

Jika pengembang Swarm ingin memeriksa cara menerapkan protokol proxy di Swarm-ingress, mereka harus memeriksa semua bug yang dibahas di Traefik (mis. https://github.com/containous/traefik/issues/2619)

Saya membuat ini bekerja secara konsisten menggunakan "compose" daripada mode swarm. Mungkin sesuatu untuk dipikirkan.

Beberapa masalah dengan protokol proxy:

Apakah itu diterjemahkan oleh buruh pelabuhan itu sendiri, atau oleh aplikasi? Jika kita mengandalkan aplikasi untuk mengimplementasikan protokol proxy, maka ini bukan solusi umum untuk semua aplikasi dan hanya berfungsi untuk server web atau aplikasi lain yang menerapkan protokol proxy. Jika buruh pelabuhan membuka bungkus protokol proxy dan menerjemahkan alamat, maka buruh pelabuhan juga harus melacak status koneksi dan melakukan terjemahan terbalik pada paket keluar. Saya tidak mendukung solusi khusus web (mengandalkan protokol proxy dalam aplikasi), karena buruh pelabuhan juga berguna untuk banyak aplikasi non-web. Masalah ini harus diatasi untuk kasus umum aplikasi TCP/UDP apa pun - tidak ada hal lain di buruh pelabuhan yang spesifik untuk web.

Seperti metode enkapsulasi lainnya, ada juga masalah ukuran paket/MTU. Namun, saya pikir ini mungkin akan menjadi perhatian dengan hampir semua solusi untuk masalah ini. Jawabannya kemungkinan akan memastikan jaringan swarm Anda mendukung MTU yang cukup besar untuk memungkinkan overhead. Saya pikir sebagian besar swarm dijalankan di jaringan lokal, jadi itu mungkin bukan masalah besar.

@trajano - Kami tahu ini berfungsi dengan jaringan Host (yang kemungkinan besar dilakukan oleh solusi penulisan Anda). Namun, itu membuang semua keuntungan jaringan cluster dari swarm (seperti load balancing).

@dack Backends harus mengetahui protokol proxy.
Saya pikir ini memecahkan sebagian besar kasus dan setidaknya Anda dapat meletakkan proxy tipis seperti passthrough yang memproses header protokol di depan backend Anda di dalam wadah.
Karena kurangnya informasi adalah masalah yang mematikan, saya percaya perlu untuk menyelesaikannya secepat mungkin sebelum solusi rapi lainnya.

protokol proxy memiliki penerimaan yang luas. periksa jumlah alat yang didukung - https://www.haproxy.com/blog/haproxy/proxy-protocol/
itu bahkan tidak mencakup penyeimbang beban cloud (ELB, Google LB) dan alat yang lebih baru seperti Traefik.

Juga - ini cukup standar di kubernetes: https://github.com/kubernetes/ingress-nginx#proxy -protocol

Pada titik ini, protokol proxy adalah standar yang paling diterima secara luas dalam memecahkan masalah ini. Saya tidak melihat nilai besar dalam menciptakan kembali ini dan melanggar kompatibilitas dengan nginx dunia.

Ini adalah protokol L7. Swarm masuknya adalah L4. Tidak ada yang diciptakan kembali di sini, itu semua IPVS menggunakan DNAT.

@ cpuguy83 tidak bisa mengerti apa yang Anda maksud.

Protokol proxy adalah lapisan 4.
http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

Tujuan protokol PROXY adalah untuk mengisi struktur internal server dengan
informasi yang dikumpulkan oleh proxy yang bisa didapatkan oleh server
dengan sendirinya jika klien terhubung langsung ke server alih-alih melalui a
proxy. Informasi yang dibawa oleh protokol adalah informasi yang akan diberikan oleh server
gunakan getockname() dan getpeername() :

• keluarga alamat (AF_INET untuk IPv4, AF_INET6 untuk IPv6, AF_UNIX)
• protokol soket (SOCK_STREAM untuk TCP, SOCK_DGRAM untuk UDP)
• lapisan 3 sumber dan alamat tujuan
• lapisan 4 sumber dan port tujuan jika ada

http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#5.1 -accept-proxy

terima-proksi

Menerapkan penggunaan protokol PROXY melalui koneksi apa pun yang diterima oleh salah satu dari
soket dideklarasikan pada baris yang sama. Versi 1 dan 2 dari protokol PROXY
didukung dan dideteksi dengan benar. Protokol PROXY menentukan lapisan
3/4 alamat dari koneksi masuk untuk digunakan di mana pun sebuah alamat berada
digunakan, dengan satu-satunya pengecualian aturan "tcp-request connection" yang akan
hanya melihat alamat koneksi yang sebenarnya. Log akan mencerminkan alamat
ditunjukkan dalam protokol, kecuali jika dilanggar, dalam hal ini yang sebenarnya
alamat tetap akan digunakan. Kata kunci ini dikombinasikan dengan dukungan dari eksternal
komponen dapat digunakan sebagai alternatif yang efisien dan dapat diandalkan untuk
X-Forwarded-For mekanisme yang tidak selalu dapat diandalkan dan bahkan tidak selalu
dapat digunakan. Lihat juga "tcp-request connection expect-proxy" untuk detail yang lebih baik
pengaturan klien mana yang diizinkan untuk menggunakan protokol.

Apakah maksud Anda ada cara yang lebih baik daripada protokol proxy? itu sepenuhnya mungkin dan ingin tahu lebih banyak dalam konteks pelestarian ip sumber di kawanan buruh pelabuhan. Namun, Protokol Proxy lebih banyak didukung oleh alat lain (seperti nginx, dll) yang akan menjadi hilir ke swarm-ingress... serta alat seperti AWS ELB yang akan upstream ke swarm-ingress. Itu hanya $0,02 saya

@sandys Protokol proxy terlihat seperti enkapsulasi (setidaknya pada inisiasi koneksi), yang membutuhkan pengetahuan tentang enkapsulasi dari penerima sampai ke tumpukan. Ada banyak trade-off untuk pendekatan ini.

Saya tidak ingin mendukung ini pada intinya, tetapi mungkin membuat ingress pluggable akan menjadi pendekatan yang bermanfaat.

@sandys https://github.com/sandys Protokol proxy terlihat seperti
enkapsulasi (setidaknya pada inisiasi koneksi), yang membutuhkan pengetahuan
enkapsulasi dari penerima sampai ke tumpukan. Di sana
banyak trade-off untuk pendekatan ini.

Itu benar. Itu sebabnya itu standar dengan RFC. ada
momentum di balik ini - hampir semua komponen penting
mendukungnya. IMHO itu bukan keputusan yang buruk untuk mendukungnya.

Saya tidak ingin mendukung ini pada intinya, tetapi mungkin membuat ingress
pluggable akan menjadi pendekatan yang berharga.

Ini adalah diskusi yang lebih besar - namun saya dapat menambahkan bahwa satu-satunya yang terbesar
keuntungan dari Docker Swarm dibandingkan yang lain adalah ia memiliki semua baterai
built-in.

Saya masih akan meminta Anda untuk mempertimbangkan protokol proxy sebagai solusi yang bagus untuk
masalah ini yang memiliki dukungan industri.

Apakah tidak mungkin untuk mensimulasikan router L3 di Linux dan LxCs (tidak secara khusus buruh pelabuhan)

@trajano Simulasi tidak diperlukan tetapi enkapsulasi untuk menyelesaikan masalah ini.
Misalnya, opsi (mis: --use-proxy-protocol ) dapat disediakan untuk layanan yang memerlukan alamat IP klien dan mengetahui cara menangani paket yang dienkapsulasi seperti nginx.

Saat ini berfungsi, node buruh pelabuhan yang menerima paket melakukan SNAT dan meneruskan paket ke node dengan wadah aplikasi. Jika beberapa bentuk tunneling/enkapsulasi digunakan sebagai pengganti SNAT, maka paket asli yang tidak diubah seharusnya dapat diteruskan ke aplikasi.

Ini adalah masalah yang diselesaikan di proyek lain. Misalnya, dengan OpenStack Anda dapat menggunakan terowongan seperti GRE dan VXLAN.

Apakah ada orang di bagian terakhir dari utas ini di sini untuk mewakili tim buruh pelabuhan dan setidaknya mengatakan bahwa 'kami mendengar Anda'? Tampaknya fitur yang Anda harapkan 'out of the box' dan menarik bagi komunitas masih belum terselesaikan setelah pertama kali dilaporkan 9 Agustus 2016, sekitar 18 bulan yang lalu.

Apakah ada orang di bagian terakhir dari utas ini di sini untuk mewakili tim buruh pelabuhan dan setidaknya mengatakan bahwa 'kami mendengar Anda'?

/cc @GordonTheTurtle @thaJeztah @riyazdf @aluzzardi

@bluejaguar @ruudboon Saya bagian dari Docker. Ini adalah masalah yang terkenal. Saat ini tim jaringan fokus pada bug lama dengan stabilitas jaringan overlay. Inilah sebabnya mengapa belum ada fitur jaringan baru dalam beberapa rilis terakhir.

Saran saya adalah mengajukan proposal konkret yang bersedia Anda kerjakan untuk menyelesaikan masalah atau setidaknya proposal yang cukup bagus sehingga siapa pun dapat menerimanya dan menjalankannya.

@ cpuguy83 saya telah mengikuti beberapa fitur protokol proxy yang masuk di k8s. Misalnya https://github.com/kubernetes/kubernetes/issues/42616 (PS menariknya protokol proxy di sini mengalir dari Google Kubernetes Engine, yang mendukung protokol proxy secara native dalam mode HTTPS).

Selain itu, ELB telah menambahkan dukungan untuk Proxy Protocol v2 pada November 2017 (https://docs.aws.amazon.com/elasticloadbalancing/latest/network/doc-history.html)

Openstack Octavia LB-as-a-service (mirip dengan ingress kami) menggabungkan protokol proxy April lalu - http://git.openstack.org/cgit/openstack/octavia/commit/?id=bf7693dfd884329f7d1169eec33eb03d2ae81ace

Berikut beberapa dokumentasi seputar protokol proxy di openstack - https://docs.openshift.com/container-platform/3.5/install_config/router/proxy_protocol.html
Beberapa nuansa ada di sekitar protokol proxy untuk https (baik dalam kasus ketika Anda menghentikan sertifikat saat masuk atau tidak).

Adakah pembaruan/solusi terkait masalah ini? kita benar-benar perlu mengetahui ip klien dalam mode swarm buruh pelabuhan.
Bantuan apa pun akan sangat dihargai.

Versi Saya:

Klien:
Versi: 18.02.0-ce
Versi API: 1.36
Pergi versi: go1.9.3
Git komit: fc4de44
Dibangun: Rab 7 Feb 21:16:33 2018
OS/Arch: linux/amd64
Eksperimental: salah
Orkestra: swarm

Server:
Mesin:
Versi: 18.02.0-ce
Versi API: 1.36 (versi minimum 1.12)
Pergi versi: go1.9.3
Git komit: fc4de44
Dibangun: Rab 7 Feb 21:15:05 2018
OS/Arch: linux/amd64
Eksperimental: salah

@adijes , dan pengguna lain yang menghadapi masalah ini. Anda dapat mengikat wadah ke jaringan bridge (seperti yang disebutkan oleh seseorang di utas ini).

version: "3.4"

services:
  frontend:
    image: nginx
    deploy:
      placement:
        constraints:
          - node.hostname == "prod1"
    networks:
      - default
      - bridge
  # backed services...
  # ...

networks:
  bridge:
    external:
      name: bridge

frontend terikat ke bridge dan selalu berada di host yang tepat, yang IP-nya terikat ke domain publik kami. Ini memungkinkannya menerima IP pengguna nyata. Dan karena itu juga mengikat ke jaringan default , itu akan dapat terhubung ke layanan yang didukung.

Anda juga dapat menskalakan frontend , selama Anda tetap menjalankannya di satu-satunya host itu. Ini membuat Host adalah Titik Kegagalan Tunggal, tetapi (saya pikir) tidak apa-apa untuk situs kecil.

Diedit untuk menambahkan lebih banyak informasi:

Wadah nginx saya ada di belakang https://github.com/jwilder/nginx-proxy , saya juga menggunakan https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion untuk mengaktifkan SSL. Proxy nginx dijalankan melalui perintah docker run , bukan layanan kawanan buruh pelabuhan. Mungkin, itu sebabnya saya mendapat IP asli dari klien. Jaringan bridge diperlukan untuk memungkinkan wadah nginx saya berkomunikasi dengan nginx-proxy.

FWIW, saya menggunakan:

Client:
 Version:      17.09.1-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:23:40 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.1-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:25:03 2017
 OS/Arch:      linux/amd64
 Experimental: false

Pengaturan di atas juga berfungsi pada pengaturan lain, yang sedang berjalan:

Client:
 Version:      17.09.1-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:23:40 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.1-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:25:03 2017
 OS/Arch:      linux/amd64
 Experimental: false

@letientai299 itu tidak berfungsi untuk saya, saya mengerti

jaringan "jembatan" dinyatakan sebagai eksternal, tetapi tidak dalam cakupan yang tepat: "lokal" alih-alih "kerumunan"

saya memiliki master dan tiga node pekerja

@trajano , lihat pembaruan saya.

@letientai299 sebenarnya saya bertanya-tanya bagaimana Anda membuat bridge bekerja dalam mode swarm . yaitu Anda tidak mendapatkan kesalahan yang saya miliki.

@dack ketika Anda mengatakan jaringan host, saya kira maksud Anda memiliki

ports:
- target: 12555
  published: 12555
  protocol: tcp
  mode: host

Sayangnya, ketika dijalankan dalam mode docker stack deploy itu tidak berfungsi dan masih kehilangan IP sumber sedangkan docker-compose up berfungsi dengan benar.

Saya juga telah mencoba yang berikut ini berdasarkan @goetas

docker service create --constraint node.hostname==exposedhost \
  --publish published=12555,target=12555,mode=host \
  trajano.net/myimage

Masih belum berhasil mendapatkan IP sumber ini ada di Server Version: 17.12.0-ce

Sepertinya sesuatu yang diinginkan semua orang di beberapa titik, dan karena menggunakan jaringan overlay bersama dengan jaringan jembatan/host tidak benar-benar mungkin, ini adalah pemblokiran jika Anda benar-benar membutuhkan IP klien karena berbagai alasan.

Klien:
Versi: 17.12.0-ce
Versi API: 1.35
Pergi versi: go1.9.2
Git komit: c97c6d6
Dibangun: Rab 27 Des 20:03:51 2017
OS/Arch: darwin/amd64

Server:
Mesin:
Versi: 17.12.1-ce
Versi API: 1.35 (versi minimum 1.12)
Pergi versi: go1.9.4
Git komit: 7390fc6
Dibangun: Sel 27 Feb 22:17:54 2018
OS/Arch: linux/amd64
Eksperimental: benar

Ini tahun 2018. Ada yang lebih baru tentang masalah ini?
Dalam mode swarm, saya tidak dapat menggunakan batas nginx req. $remote_addr selalu menangkap 10.255.0.2.
Ini adalah masalah yang sangat serius tentang kawanan buruh pelabuhan.
Mungkin saya harus mencoba kubernetes sejak hari ini.

@Maslow saya memposting di mana kami hanya beberapa komentar di atas.

Bisakah kita melonggarkan cek untuk

networks:
  bridge:
    external:
      name: bridge

atau perpanjang seperti

networks:
  bridge:
    external:
      name: bridge
      scope: local

dan jaringan scope: local hanya diperbolehkan jika mode jaringan adalah host

jaringan "jembatan" dinyatakan sebagai eksternal, tetapi tidak dalam cakupan yang tepat: "lokal" alih-alih "kerumunan"

atau izinkan

networks:
  bridge:
    driver: bridge

Agar tidak gagal dengan

gagal membuat layanan trajano_serv: Tanggapan kesalahan dari daemon: Trajano_bridge jaringan tidak dapat digunakan dengan layanan. Hanya jaringan yang dicakup ke swarm yang dapat digunakan, seperti yang dibuat dengan driver overlay.

ketika memiliki mode: host pada port yang diterbitkan.

ports:
- target: 32555
  published: 32555
  protocol: tcp
  mode: host

@trajano Anda dapat menggunakan jaringan

version: '3.4'

services:
  test:
    image: alpine
    command: top
    ports:
      - target: 32555
        published: 32555
        protocol: tcp
        mode: host
    networks:
      - bridge

networks:
  bridge:
    external:
      name: bridge

Apakah Anda menguji ini pada segerombolan dengan lebih dari satu pekerja dengan penyebaran tumpukan buruh pelabuhan. Saya tahu ini berfungsi dengan compose.

Pada 18 Maret 2018, pukul 20:55, Brian Goff [email protected] menulis:

@trajano Anda dapat menggunakan jaringan

versi: '3.4'

jasa:
tes:
gambar: alpine
perintah: atas
port:
- target: 32555
diterbitkan: 32555
protokol: tcp
modus: tuan rumah
jaringan:
- menjembatani

jaringan:
menjembatani:
luar:
nama: jembatan
—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

Ya, saya melakukan ini melalui swarm...

Pada Senin, 19 Mar 2018 pukul 09:12, Archimedes Trajano <
[email protected]> menulis:

Apakah Anda menguji ini pada segerombolan dengan lebih dari satu pekerja dengan tumpukan buruh pelabuhan
menyebarkan. Saya tahu ini berfungsi dengan compose.

Pada 18 Maret 2018, pukul 20:55, Brian Goff [email protected]
menulis:

@trajano Anda dapat menggunakan jaringan
misalnya ini berfungsi:

versi: '3.4'

jasa:
tes:
gambar: alpine
perintah: atas
port:

• sasaran: 32555
  diterbitkan: 32555
  protokol: tcp
  modus: tuan rumah
  jaringan:
• menjembatani

jaringan:
menjembatani:
luar:
nama: jembatan
—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-374206587 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAwxZsm3OohKL0sqUWhlgUNjCrqR0OaVks5tf67YgaJpZM4Jf2WK
.

--

• Brian Goff

+1

Mengalami masalah ini dengan penyeimbangan beban kawanan buruh pelabuhan berikut dengan 3 node:

jaringan overlay <-> nginx proxy jwilder docker <-> nginx web head docker

Saya mengikuti saran dan log terus mengembalikan ip jaringan buruh pelabuhan 10.255.0.3 alih-alih IP Klien Nyata.

+1

@ cpuguy83 ini sudah mulai menjadi pemblokir untuk pengaturan swarm kami yang lebih besar. saat kami mulai memanfaatkan lebih banyak cloud (di mana protokol proxy digunakan secara de facto oleh penyeimbang beban), kami kehilangan info ini yang sangat penting bagi kami.

Apakah Anda punya ide tentang ETA? ini akan sangat membantu kami.

@sandys Sebuah ETA untuk apa sebenarnya?

@cpuguy83 hai, terima kasih atas balasan Anda. saya sadar tidak ada kesepakatan luas tentang bagaimana Anda ingin menyelesaikannya. Saya agak berkomentar tentang bagaimana tim telah sibuk dengan masalah stabilitas dan tidak dibebaskan untuk masalah ini.
Kapan Anda berpikir bahwa masalah ini akan diangkat (jika ada)?

Perhatikan bahwa Anda dapat mengatasi masalah ini dengan menjalankan layanan global dan port penerbitan menggunakan PublishMode=host. Jika Anda tahu simpul mana yang akan terhubung dengan orang, Anda bahkan tidak memerlukannya, cukup gunakan batasan untuk memperbaikinya ke simpul itu.

@kleptog Sebagian Anda tidak bisa. Itu tidak dapat menghindari waktu henti saat memperbarui layanan.

Skenario pengujian - lihat lebih dekat ke lvs/ipvs.

• nsenter ke wadah ingress tersembunyi dan hapus aturan snat
• nsenter ke layanan dengan port yang diterbitkan, hapus default gw dan tambahkan rute default ke ip container ingress.

Sekarang ip sumber akan dipertahankan.

Saya masih mencoba memahami implikasi dari overhead, mempertahankan perutean berbasis kebijakan dalam setiap wadah layanan alih-alih hanya memiliki aturan snat di wadah masuk.
Akan sangat melegakan, jika ini berhasil.

Maaf atas permainan saya yang naif, tetapi dapatkah seseorang ( @dack ? ) mengarahkan saya ke kode buruh pelabuhan, di mana ini dilakukan?

Ah, sekarang aku mengerti. Dalam gerombolan multinode, IP harus menjadi direktur lvs, untuk menemukan jalan kembali ke simpul yang benar, permintaan masuk ...

Akan menarik untuk melihat kodenya. Itu bisa menghemat waktu saya jika ada yang tahu. Terima kasih

Setiap pembaruan tentang ini, memiliki tiga cluster di negara yang berbeda, dan bahkan Azure Traffic Manager memerlukan IP pengguna nyata jika tidak, ia tidak akan mengarahkan pengguna ke cluster yang baik, dll. Siapa saja, segera atau akan memeriksa ini? Terima kasih

Juga perlu pembaruan tentang ini - ini adalah gotcha besar - satu-satunya cara yang saya temukan di sekitar ini adalah dengan menambahkan proxy lain di depan dan mengirim x-forwarded-for ke stack, semacam berarti Swarm adalah non-opsi untuk publik menghadapi lalu lintas untuk banyak skenario.

@cpuguy83 @trajano
Saya dapat mengonfirmasi bahwa yang berikut ini tidak berfungsi:

version: '3.4'
services:
  nginx:
    ports:
      - mode: host
        protocol: tcp
        published: 80
        target: 80
      - mode: host
        protocol: tcp
        published: 443
        target: 81
networks:
  bridge:
    external:
      name: bridge

Gagal dengan network "bridge" is declared as external, but it is not in the right scope: "local" instead of "swarm" .

versi buruh pelabuhan

Client:
 Version:       18.03.0-ce-rc4
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    fbedb97
 Built: Thu Mar 15 07:33:59 2018
 OS/Arch:       windows/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:        Wed Mar 21 23:08:31 2018
  OS/Arch:      linux/amd64
  Experimental: false

@Mobe91
Cobalah untuk membuat ulang kawanan. Saya juga punya kesalahan. Setelah kawanan re-init, semuanya bekerja untuk saya.
File docker-compose.yml :

version: "3.6"

services:
    nginx:
        image: nginx:latest
        depends_on:
            - my-app
            - my-admin
        ports: 
            - target: 80
              published: 80
              protocol: tcp
              mode: host
            - target: 443
              published: 443
              protocol: tcp
              mode: host
            - target: 9080
              published: 9080
              protocol: tcp
              mode: host
        volumes:
            - /etc/letsencrypt:/etc/letsencrypt:ro
            - /home/project/data/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
            - /home/project/data/nginx/conf.d:/etc/nginx/conf.d
            - /home/project/public:/var/public
        networks:
            - my-network
            - bridge
        deploy:
            placement:
                constraints: [node.role == manager]

    my-app:
        image: my-app
        ports:
            - 8080:8080
        volumes:
            - /usr/src/app/node_modules
            - /home/project/public:/usr/src/app/public
        networks:
            - my-network

    my-admin:
        image: my-admin
        ports:
            - 9000:9000
        networks:
            - my-network

networks:
    my-network:
    bridge:
        external: true
        name: bridge

docker version :

Client:
 Version:   18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24
 Built: Wed Mar 21 23:10:01 2018
 OS/Arch:   linux/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:  18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:    Wed Mar 21 23:08:31 2018
  OS/Arch:  linux/amd64
  Experimental: false

Maaf untuk bahasa Inggris saya.

@Mobe91 ini yang saya gunakan tetapi saya gunakan dari "portainer" atau di mesin Linux. Saya tidak bisa menerapkannya dengan benar dari Windows.

version: '3.4'
services:
  hath:
    image: trajano.net/hath
    deploy:
      placement:
        constraints:
        - node.hostname==docker-engine
    networks:
    - host
    ports:
    - target: 12555
      published: 12555
      protocol: tcp
      mode: host
    secrets:
    - hath_client_login
    volumes:
    - hath:/var/lib/hath
volumes:
  hath:
    name: 'noriko/s/hath'
    driver: cifs
networks:
  host:
    external:
      name: host
secrets:
  hath_client_login:
    external:
      name: hath_client_login

Perbedaan utama adalah saya menggunakan host daripada bridge Dalam kasus saya, saya juga menjalankan host saya sebagai VM VirtualBox dan saya menggunakan router yang melakukan perutean NAT dan yang mempertahankan IP masuk sepenuhnya ke wadah.

Tentu saja tidak ada kemampuan load balancing Saya pikir jika Anda ingin load balancing Anda harus memiliki sesuatu di depan seperti router L3 yang akan melakukan load balancing

@trajano benar, klien Windows adalah masalahnya, penyebaran dengan klien Linux berhasil.

Tetapi saya tidak mengerti mengapa Anda membutuhkan jaringan host atau bridge ?
Berikut ini berfungsi dengan baik untuk saya, yaitu saya mendapatkan alamat IP klien nyata di nginx:

version: '3.4'
services:
  nginx:
    ports:
      - mode: host
        protocol: tcp
        published: 80
        target: 80

@Mobe91 terima kasih saya bermaksud membuka masalah untuk itu. Pada dasarnya ikat dengan https://github.com/moby/moby/issues/32957 karena masih terjadi dengan klien 18.03-ce untuk Windows.

ada yang pernah pake cilium? http://cilium.readthedocs.io/en/latest/gettingstarted/docker/ .

Sepertinya mungkin dapat memperbaiki ini tanpa mengikat layanan ke Host.

@sandys good find - Saya akan mulai mengujinya, apakah itu berhasil untuk Anda? Saya baru saja akan menarik nginx keluar dari kawanan saya jika saya tidak dapat memperbaikinya.....

Kami mencapai ini dalam mendesain ulang penyebaran kami untuk menghindari menyematkan proxy ke masing-masing host (yang, dalam produksi, mengikat ke antarmuka karena alasan lain dan oleh karena itu "mengambil" IP klien sebagai produk sampingan).

Dalam lingkungan pengujian kami, kami hanya dapat meningkatkan dengan menerapkan ke manajer dengan batasan dan menyetel mode = global untuk memastikan setiap manajer mendapatkan instance yang berjalan. Masih ada overhead ekstra yang harus diperhatikan, terutama jika kita kehilangan node manajer dan ada sesuatu yang mengarahkan lalu lintas kita ke sana. Namun, ini lebih baik daripada disematkan ke satu host.

@sandys apakah Anda mencoba Cilium? Terlihat mirip dengan Weave, yang tampaknya mengalami masalah yang sama setidaknya dengan k8s: https://github.com/kubernetes/kubernetes/issues/51014

Saya belum bisa menggunakan Cilium, tetapi saya telah menjangkau Cilium
devs untuk membantu dalam konfigurasi swarm. Tapi saya cukup senang dengan Cilium
karena ingress adalah masalah yang ingin dipecahkan (tidak seperti menenun)

Pada Kamis 10 Mei 2018, 17:24 James Green, [email protected] menulis:

Kami mencapai ini dalam mendesain ulang penerapan kami untuk menghindari menyematkan proxy ke
host individu (yang, dalam produksi, mengikat ke antarmuka untuk lainnya
alasan dan karena itu "mengambil" IP klien sebagai produk sampingan).

Di lingkungan pengujian kami, kami hanya dapat meningkatkan dengan menerapkan ke manajer dengan
kendala dan mode pengaturan = global untuk memastikan setiap manajer mendapat
menjalankan contoh. Ini masih overhead ekstra yang harus diperhatikan,
terutama jika kita kehilangan simpul manajer dan ada sesuatu yang mengarahkan
lalu lintas ke sana. Namun, ini lebih baik daripada disematkan ke satu host.

@sandys https://github.com/sandys apakah Anda mencoba Cilium? Terlihat mirip dengan
Weave, yang tampaknya mengalami masalah yang sama setidaknya dengan k8s:
kubernetes/kubernetes#51014
https://github.com/kubernetes/kubernetes/issues/51014

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-388032011 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsUzQCgIeTenQIHIERxOfHKCzn1O6Aks5txCpogaJpZM4Jf2WK
.

Pada 10-Mei-2018 17:24, "James Green" [email protected] menulis:

Kami mencapai ini dalam mendesain ulang penerapan kami untuk menghindari menyematkan proxy ke
host individu (yang, dalam produksi, mengikat ke antarmuka untuk lainnya
alasan dan karena itu "mengambil" IP klien sebagai produk sampingan).

Di lingkungan pengujian kami, kami hanya dapat meningkatkan dengan menerapkan ke manajer dengan
kendala dan mode pengaturan = global untuk memastikan setiap manajer berjalan
contoh. Ini masih overhead ekstra yang harus diperhatikan, terutama jika
kita kehilangan node manajer dan ada sesuatu yang mengarahkan lalu lintas kita ke sana.
Namun, ini lebih baik daripada disematkan ke satu host.

@sandys https://github.com/sandys apakah Anda mencoba Cilium? Terlihat mirip dengan
Weave, yang tampaknya mengalami masalah yang sama setidaknya dengan k8s:
kubernetes/kubernetes#51014
https://github.com/kubernetes/kubernetes/issues/51014

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-388032011 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsUzQCgIeTenQIHIERxOfHKCzn1O6Aks5txCpogaJpZM4Jf2WK
.

• 1

Halo kawan-kawan,
jika Anda ingin dukungan Docker Swarm di Cilium (terutama untuk ingress dan
sekitar masalah khusus ini), silakan beri komentar/suka pada bug ini -
https://github.com/cilium/cilium/issues/4159

Pada Jumat, 11 Mei 2018 pukul 12:59, McBacker [email protected] menulis:

>

• 1

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-388159466 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU_18F_cNttRUaAwaRF3gVpMZ-3qSks5txJUfgaJpZM4Jf2WK
.

bagi saya dengan versi saat ini berfungsi seperti ini:
saya kemudian dapat mengakses node lain di swarm karena juga ada di jaringan 'default'

  web-server:
    image: blabla:7000/something/nginx:latest
    #ports:
    #  - "80:80"
    #  - "443:443"
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
      - target: 443
        published: 443
        protocol: tcp
        mode: host        
    deploy:
      mode: global
      restart_policy:
        condition: any
      update_config:
        parallelism: 1
        delay: 30s

Saya dapat mengonfirmasi bahwa kuncinya adalah menggunakan ports.mode: host . Dari dokumentasi ( https://docs.docker.com/compose/compose-file/#long-syntax-1 ):

mode: host untuk memublikasikan port host pada setiap node, atau ingress untuk port mode swarm agar beban seimbang.

Kemudian, menggunakan mode: host berhenti loadbalance oleh ingress dan IP asli muncul. Sebagai contoh, berikut adalah log nginx saya:

• dengan mode: host
metrics-agents_nginx.1.pip12ztq3y1h<strong i="14">@xxxxxxxx</strong> | 62.4.X.X - - [12/Jun/2018:08:46:04 +0000] "GET /metrics HTTP/1.1" 200 173979 "-" "Prometheus/2.2.1" "-" [CUSTOM] "request_time: 0.227" remote_addr: 62.4.X.X proxy_add_x_forwarded_for: 62.4.X.X

• tanpa mode: host
metrics-agents_nginx.1.q1eosiklkgac<strong i="20">@xxxxxxxx</strong> | 10.255.0.2 - - [12/Jun/2018:08:50:04 +0000] "GET /metrics HTTP/1.1" 403 162 "-" "Prometheus/2.2.1" "-" [CUSTOM] "request_time: 0.000" remote_addr: 10.255.0.2 proxy_add_x_forwarded_for: 10.255.0.2

Dan Jika Anda bertanya-tanya mengapa log terakhir adalah respons 403 Forbidden, ini karena menggunakan daftar putih di nginx ( allow 62.4.X.X dan deny all ).

Konteks:
Description: Debian GNU/Linux 9.4 (stretch)
Docker version 18.03.0-ce, build 0520e24

Saya mengkonfirmasi apa yang dikatakan @nperron .
Menggunakan mode host memungkinkan untuk mendapatkan ip klien.

Versi Docker 18.03.1-ce, build 9ee9f40
Ubuntu 16.04.4 LTS

Saya dapat mengkonfirmasi itu berfungsi.

Versi Docker 18.03.1-ce, build 9ee9f40
Ubuntu 16.04.4 LTS

PERINGATAN: INI TIDAK AKAN BEKERJA JIKA ANDA TELAH SET IPTABLES=FALSE!
Anda mungkin telah melakukan ini (atau setidaknya saya melakukannya) jika Anda menggunakan UFW untuk mengamankan port dan menemukan kawanan buruh pelabuhan untuk mengesampingkan pengaturan UFW tersebut.

Ada beberapa tutorial yang menyarankan pengaturan iptables = false on melalui perintah atau di /etc/docker/daemon.json

Semoga ini menyelamatkan seseorang dari frustrasi yang baru saja saya alami!

orang benar-benar harus berhenti mengatakan "Mode: Host" = berfungsi, karena itu tidak menggunakan Ingress. Itu membuat tidak mungkin hanya memiliki satu wadah dengan layanan yang berjalan di swarm tetapi masih dapat mengaksesnya melalui host mana pun. Anda juga harus membuat layanan "Global" atau Anda hanya dapat mengaksesnya di host yang dijalankannya, yang agak mengalahkan tujuan Swarm.

TLDR: "Mode: Host" adalah solusi, bukan solusi

@ r3pek Sementara saya setuju dengan Anda bahwa Anda kehilangan Ingress jika Anda menggunakan mode Host untuk mengatasi kesulitan ini, saya akan mengatakan bahwa itu hampir tidak mengalahkan seluruh tujuan Swarm, yang melakukan lebih banyak daripada jaringan ingress yang dihadapi publik. Dalam skenario penggunaan kami, kami memiliki kawanan overlay yang sama:
wadah yang direplikasi manajemen yang hanya boleh diakses melalui intranet -> mereka tidak memerlukan ip pemanggil, oleh karena itu mereka dikonfigurasikan "normal" dan mengambil keuntungan dari masuknya.
wadah yang tidak terpapar -> tidak ada yang perlu dikatakan tentang ini (saya yakin Anda meremehkan kekuatan untuk dapat mengaksesnya melalui nama layanan mereka).
layanan yang menghadap publik -> ini adalah proxy nginx yang melakukan perutean berbasis https dan url. Itu didefinisikan global bahkan sebelum kebutuhan untuk x-forward-untuk ip nyata klien, jadi tidak ada masalah nyata di sana.

Memiliki nginx global dan tidak memiliki ingress berarti Anda dapat menjangkaunya melalui ip cluster mana pun, tetapi tidak memuat seimbang atau toleran terhadap kesalahan, jadi kami menambahkan L4 Azure Load Balancer yang sangat sangat murah dan mudah diatur di depan nginx melayani.

Seperti yang Anda katakan, Host adalah solusi, tetapi mengatakan bahwa mengaktifkannya sepenuhnya mengalahkan tujuan Docker Swarm sedikit berlebihan.

Hai Roberto
Saya tidak berpikir itu berlebihan - karena mode host mengekspos satu poin
dari kegagalan. Selain itu, ia mengharapkan lapisan manajemen tambahan untuk memuat
keseimbangan di luar ekosistem kawanan.

Dengan mengatakan bahwa Anda menggunakan Azure lb sendiri, Anda telah memvalidasi itu
argumen.

Ini sama saja dengan mengatakan bahwa "untuk menjalankan swarm dengan propagasi ip klien,
pastikan Anda menggunakan penyeimbang beban eksternal yang Anda atur...Atau gunakan
salah satu layanan cloud".

Kami tidak mengatakan bahwa ini bukan solusi sementara ... Tapi itu akan menjadi
mengabaikan janji Swarm jika kita semua tidak mengenalinya dengan pasti
kekurangan.

Pada Kam, 5 Juli 2018, 14:16 Roberto Fabrizi, [email protected]
menulis:

@r3pek https://github.com/r3pek Sementara saya setuju dengan Anda bahwa Anda kalah
Masuk jika Anda menggunakan mode Host untuk mengatasi kesulitan ini, saya akan mengatakan itu
hampir tidak mengalahkan seluruh tujuan Swarm, yang melakukan lebih dari itu
jaringan masuk yang menghadap publik. Dalam skenario penggunaan kami, kami memiliki hal yang sama
kawanan overlay:
wadah yang direplikasi manajemen yang hanya boleh diakses melalui
intranet -> mereka tidak memerlukan ip pemanggil, oleh karena itu mereka dikonfigurasi
"biasanya" dan mengambil keuntungan dari masuknya.
wadah yang tidak terpapar -> tidak ada yang perlu dikatakan tentang ini (saya yakin Anda
meremehkan kekuatan untuk dapat mengaksesnya melalui layanan mereka
nama sekalipun).
wadah menghadap publik -> ini adalah proxy nginx yang melakukan https dan url
perutean berbasis. Itu didefinisikan secara global bahkan sebelum kebutuhan untuk x-forward-for
ip nyata klien, jadi tidak ada masalah nyata di sana.

Memiliki nginx global dan tidak memiliki ingress berarti Anda dapat menjangkaunya melalui
setiap ip cluster, tetapi tidak memuat seimbang, jadi kami menambahkan sangat sangat
murah dan mudah untuk mengatur L4 Azure Load Balancer di depan nginx
melayani.

Seperti yang Anda katakan, Host adalah solusi, tetapi mengatakan bahwa mengaktifkannya sepenuhnya
mengalahkan tujuan Docker Swarm sedikit berlebihan imo.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-402650066 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU_ogRzwM6X0PMknXxsxmZLLTtfraks5uDdJlgaJpZM4Jf2WK
.

Jelas bahwa penyeimbang beban yang buruk (IPVS) dipilih untuk masuknya Docker Swarm. Jika mendukung setidaknya protokol proxy L4 maka ini tidak akan menjadi masalah. Kecuali bahwa itu akan tetap menjadi penyeimbang beban L4(TCP) tanpa semua fitur tambahan yang dapat diberikan L7 lb.

Di Kubernetes ada penyeimbang beban L4(TCP)-L7(HTTP) seperti nginx ingress , haproxy ingress yang keduanya memungkinkan penggunaan protokol proxy L4 atau header HTTP L7 untuk memastikan X-Forwarded-For dimanfaatkan untuk meneruskan real pengguna IP ke backend.

Saya bertanya-tanya apa yang akan dikatakan pengembang Docker Swarm ingress. Mungkin seseorang harus memindahkan kasing ini ke https://github.com/docker/swarmkit/issues ?

Di Kubernetes ada penyeimbang beban L4(TCP)-L7(HTTP) seperti nginx ingress, haproxy ingress yang keduanya memungkinkan penggunaan protokol proxy L4 atau header HTTP L7 untuk memastikan X-Forwarded-For dimanfaatkan untuk meneruskan IP asli pengguna ke bagian belakang.

AFAICS, layanan LB tersebut tidak disematkan ke K8 tetapi layanan yang perlu diterapkan secara eksplisit. Anda dapat melakukan hal yang sama dengan kawanan Docker juga. Saya tidak melihat perbedaan di sini. (Selain itu pengontrol ingress nginx tampaknya "resmi".)

Sejauh yang saya tahu, perbedaannya adalah bahwa bahkan jika Anda menggunakan layanan loadbalancing seperti itu, itu akan 'dipanggil' dari swarmkit loadbalancer dan Anda kehilangan ip pengguna. Jadi Anda tidak dapat menonaktifkan loadbalancer swarmkit jika tidak menggunakan hostmode.

untuk bersikap adil - di k8s, dimungkinkan untuk memiliki ingress kustom. di gerombolan itu
tidak.

swarm mengambil sikap bahwa semuanya "built-in". Sama halnya dengan
jaringan - di k8s, Anda perlu mengatur menenun, dll ... di swarm bawaannya.

jadi poin yang dibuat andrey (dan saya agak setuju dengan ) adalah -
swarm harus menjadikan fitur ini sebagai bagian dari ingress, karena pengguna memiliki
tidak ada kendali atasnya.

Pada Sabtu, 28 Juli 2018 pukul 17:07 Seti [email protected] menulis:

Sejauh yang saya tahu, perbedaannya adalah jika Anda menggunakan
layanan loadbalancing itu akan 'dipanggil' dari loadbalancer swarmkit
dan jadi Anda kehilangan ip pengguna. Jadi Anda tidak dapat menonaktifkan swarmkit
loadbalancer jika tidak menggunakan hostmode.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-408601274 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU1-Ism_S1Awml8lO8N0Aq6rtrLH4ks5uLEzugaJpZM4Jf2WK
.

Saya pikir kami sudah selesai menyetrika kerutan gerombolan kami, tetapi kemudian kami naik ke panggung dan memperhatikan bahwa semua akses eksternal ke wadah server web muncul sebagai IP jaringan masuk.

Saya menjalankan tumpukan saya pada sekumpulan simpul tunggal dan akan melakukannya setidaknya selama beberapa bulan ke depan. Bisakah Anda merekomendasikan solusi yang paling tidak buruk untuk kasus penggunaan (single-node swarm) kami saat ini? Saya tidak dapat melakukannya tanpa IP klien - terlalu bergantung padanya.

Pendekatan sementara kami adalah menjalankan wadah proxy sederhana dalam mode "global" (yang IIRC bisa mendapatkan IP NIC yang sebenarnya) dan kemudian meneruskan semua koneksi ke layanan internal yang berjalan di jaringan overlay swarm dengan tambahan header proxy.

Jika mendapatkan header x-forwarded-for sudah cukup untuk Anda, pengaturan itu akan berfungsi AFAICT.

Terima kasih @maximelb. Apa yang akhirnya Anda lakukan (misalnya, nginx, haproxy)?

@jamiejackson di situlah segalanya akan sedikit berbeda. Dalam kasus kami, kami menjalankan server yang menghosting koneksi SSL yang berjalan lama dan protokol biner khusus di bawahnya sehingga proxy HTTP tidak dimungkinkan. Jadi kami membuat forwarder TCP sederhana dan menggunakan header "msgpack" yang dapat kami bongkar secara manual di server internal.

Saya tidak terlalu akrab dengan proxy HTTP tetapi saya menduga sebagian besar dari mereka akan melakukan trik untuk Anda. :-/

hai Maxim,
ini sangat menarik bagi kami. Bisakah Anda membagikan komposisi buruh pelabuhan Anda oleh siapa saja?
peluang ?

Saya mencoba memahami cara kerjanya. Hari ini kami memiliki nginx sebagai kebalikannya
proxy (sebagai layanan) dan beberapa layanan buruh pelabuhan di belakangnya.

Dalam kasus Anda - apakah nginx menjadi proxy "mode global"? atau itu
penerus TCP khusus. Jadi saat Anda mengukur jumlah node, proxy forwarder
berjalan pada setiap node. Saya entah bagaimana berpikir dalam situasi ini x-forwarded for
header hilang .. karena jaringan ingress membunuh ip eksternal
(karena tidak ada proxy-protocol).

Kami akan sangat berterima kasih jika Anda dapat membantu kami dengan beberapa detail lebih lanjut.

Salam
sandeep

Pada Rabu, 8 Agustus 2018 pukul 07:18 Maxime Lamothe-Brassard <
[email protected]> menulis:

Pendekatan sementara kami adalah menjalankan wadah proxy sederhana di
mode "global" (yang IIRC bisa mendapatkan IP NIC yang sebenarnya) dan kemudian memilikinya
meneruskan semua koneksi ke layanan internal yang berjalan di swarm
jaringan overlay dengan header proxy tambahan.

Jika mendapatkan header x-forwarded-for sudah cukup untuk Anda, pengaturan itu seharusnya
bekerja AFAICT.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-411257087 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsUx3DOjXb79FNjsuZ-RZVqkkhHAbYks5uOkOHgaJpZM4Jf2WK
.

@sandys yakin, ini adalah kutipan dari komposisi buruh pelabuhan kami dengan wadah yang relevan.

Ini adalah entri penulisan buruh pelabuhan proxy terbalik:

reverseproxy:
    image: yourorg/repo-proxy:latest
    networks:
      - network_with_backend_service
    deploy:
      mode: global
    ports:
      - target: 443
        published: 443
        protocol: tcp
        mode: host

Ini adalah entri layanan backend:

backendservice:
    image: yourorg/repo-backend:latest
    networks:
      - network_with_backend_service
    deploy:
      replicas: 2

Target dari reverseproxy (sisi backend) adalah tasks.backendservice (yang memiliki catatan A untuk setiap replika). Anda dapat melewati bagian networks jika layanan backend berada di jaringan swarm overlay default.

Bit global mengatakan "deploy container ini tepat sekali pada setiap node swarm Docker. Port mode: host adalah port yang mengatakan "bind to native NIC of the node".

Semoga membantu.

Anda menggunakan mode host. Cukup banyak Anda memiliki penyeimbang beban eksternal
di depan semuanya.
Anda tidak dapat bergantung pada Swarm lagi karena Anda berada dalam mode host.

Itu sebenarnya masalah yang sudah lama kita bicarakan :(

Pada Rab, 8 Agustus 2018, 20:47 Maxime Lamothe-Brassard, <
[email protected]> menulis:

@sandys https://github.com/sandys yakin, ini kutipan dari kami
docker-compose dengan wadah yang relevan.

Ini adalah entri penulisan buruh pelabuhan proxy terbalik:

proksi balik:
gambar: yourorg/repo- proxy: terbaru
jaringan:
- network_with_backend_service
menyebarkan:
modus: global
port:
- sasaran: 443
diterbitkan: 443
protokol: tcp
modus: tuan rumah

Ini adalah entri layanan backend:

layanan backend:
gambar: yourorg/repo- backend: terbaru
jaringan:
- network_with_backend_service
menyebarkan:
replika: 2

Target dari reverseproxy (sisi backend) adalah
tugas.backendservice (yang memiliki catatan A untuk setiap replika). Kamu bisa
lewati bagian jaringan jika layanan backend ada di swarm default
jaringan overlay.

Bit global mengatakan "deploy container ini tepat sekali di setiap Docker
simpul kawanan. Mode port: host adalah yang mengatakan "mengikat ke asli
NIC dari simpul".

Semoga membantu.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-411442155 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU8N7KAFTOp_cPO8wpbBQqzDfpBWOks5uOwEkgaJpZM4Jf2WK
.

Tidak 100% yakin dengan apa yang Anda maksud, tetapi secara eksternal kami menggunakan DNS dengan catatan A per node cluster. Ini memberikan "penyeimbangan" murah tanpa memiliki bagian eksternal yang bergerak. Ketika klien membuat permintaan, mereka memilih catatan A acak, dan terhubung ke 443 di salah satu node cluster.

Di sana, proxy terbalik yang berjalan pada node tertentu dan mendengarkan pada 443 mendapatkan koneksi asli, termasuk IP klien yang sebenarnya. Wadah proxy terbalik itu kemudian menambahkan header dan meneruskan koneksi ke wadah internal lain menggunakan jaringan overlay swarm (tasks.backend). Karena menggunakan target task.backend, itu juga akan mendapatkan catatan A acak untuk layanan internal.

Jadi dalam arti sempit, melewati keajaiban jaringan overlay yang mengalihkan koneksi. Alih-alih mereplikasi perilaku ini dengan proxy terbalik dan menambahkan header. Efek akhirnya sama (dalam arti yang longgar) seperti keajaiban jaringan overlay. Itu juga melakukannya secara paralel dengan menjalankan swarm, artinya saya dapat menjalankan semua layanan saya yang lain yang tidak memerlukan IP klien pada cluster yang sama tanpa melakukan hal lain untuk itu.

Tidak berarti solusi yang sempurna tetapi sampai perbaikan dibuat (jika pernah) itu membuat Anda tanpa komponen eksternal atau konfigurasi buruh pelabuhan utama.

@jamiejackson solusi "paling tidak buruk" yang kami temukan adalah menggunakan Traefik sebagai layanan global dalam mode Host. Mereka memiliki contoh umum yang bagus
https://github.com/containous/traefik/issues/1880

Semoga ini membantu. Kami juga tidak dapat menggunakan solusi yang tidak memungkinkan kami untuk memeriksa IP pemohon yang sebenarnya sehingga kami terjebak dengan perbaikan kludge ini hingga sesuatu berubah. Sepertinya kebutuhan yang cukup umum, setidaknya untuk alasan keamanan.

Dipahami (dan versi longgar inilah yang kami gunakan).

Namun - agenda bug khusus ini adalah untuk meminta devs
untuk membangunnya ke dalam jaringan overlay ajaib (mungkin dengan menggunakan proxy
protokol atau mekanisme lain)

Pada Rab, 8 Agustus 2018, 21:22 Maxime Lamothe-Brassard, <
[email protected]> menulis:

Tidak 100% yakin dengan apa yang Anda maksud, tetapi secara eksternal kami menggunakan DNS dengan A
merekam per node cluster. Ini memberikan "penyeimbangan" murah tanpa harus
bagian luar yang bergerak. Saat klien mengajukan permintaan, mereka memilih A random secara acak
merekam, dan terhubung ke 443 di salah satu node cluster.

Di sana, proxy terbalik yang berjalan pada node tertentu dan
mendengarkan pada 443 mendapatkan koneksi asli, termasuk IP klien yang sebenarnya.
Wadah proxy terbalik itu kemudian menambahkan header dan meneruskan koneksi
ke wadah internal lain menggunakan jaringan swarm overlay
(task.backend). Karena menggunakan target task.backend, itu juga akan mendapatkan
acak Sebuah catatan untuk layanan internal.

Jadi dalam arti sempit, melewati keajaiban jaringan overlay itu
mengalihkan koneksi. Alih-alih mereplikasi perilaku ini dengan
proxy terbalik dan menambahkan header. Efek akhirnya adalah sama (dalam a
akal sehat) sebagai keajaiban jaringan overlay. Itu juga melakukannya di
sejajar dengan menjalankan swarm, artinya saya dapat menjalankan semua layanan saya yang lain itu
tidak memerlukan IP klien pada cluster yang sama tanpa melakukan apa pun
lain untuk mereka.

Tidak berarti solusi yang sempurna tetapi sampai perbaikan dilakukan (jika pernah), itu akan terjadi
Anda tanpa komponen eksternal atau konfigurasi buruh pelabuhan utama.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-411455384 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU5RKjGc3hEk6bk-doicDa1MbYGAyks5uOwlIgaJpZM4Jf2WK
.

TBH Saya tidak yakin mengapa jaringan masuk tidak ditambal untuk menambahkan ip
data dalam protokol proxy.

Ini tambahan, tidak akan merusak tumpukan yang ada, ini didefinisikan dengan baik
standar, ini didukung secara luas bahkan oleh vendor cloud besar, secara luas
didukung oleh kerangka kerja aplikasi.

Apakah ini upaya Dev yang signifikan?

Pada Rabu, 8 Agustus 2018, 21:30 Matt Glaser, [email protected] menulis:

@jamiejackson https://github.com/jamiejackson "paling tidak buruk"
solusi yang kami temukan adalah menggunakan Traefik sebagai layanan global dalam mode host.
Mereka memiliki contoh umum yang bagus di dokumen mereka
https://docs.traefik.io/user-guide/cluster-docker-consul/#full-docker-compose-file_1 .
Kami telah melihat beberapa bug yang mungkin atau mungkin tidak terkait dengan pengaturan ini, tetapi
Traefik adalah proyek hebat dan tampaknya cukup stabil di Swarm. Ada
seluruh utas di halaman masalah mereka (yang kembali ke sini :)), dengan
solusi serupa:
mengandung/traefik#1880
https://github.com/containous/traefik/issues/1880

Semoga ini membantu. Kami juga tidak dapat menggunakan solusi yang tidak memungkinkan kami untuk
periksa IP pemohon yang sebenarnya jadi kami terjebak dengan perbaikan kludge ini sampai
sesuatu berubah. Sepertinya kebutuhan yang cukup umum, untuk alasan keamanan
paling sedikit.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-411458326 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU7NNbsW44L95VYCvlyL_Bje-h6L9ks5uOwsUgaJpZM4Jf2WK
.

Nah, Docker saat ini tidak menyentuh lalu lintas masuk, jadi pasti setidaknya tidak signifikan untuk ditambahkan.
Perlu diingat juga ini adalah proyek open source, jika Anda benar-benar menginginkan sesuatu maka biasanya terserah Anda untuk mengimplementasikannya.

+1, ini benar-benar showstopper.
Saya akan percaya sebagian besar aplikasi membutuhkan ip klien nyata. Pikirkan saja tumpukan server surat - Anda tidak dapat menerima surat dari host yang sewenang-wenang.

Kami beralih ke mode host instance aliran global proxy_protocol nginx, yang diteruskan ke aplikasi yang direplikasi proxy_nginx. Ini bekerja cukup baik untuk saat ini.

layanan nginx_stream global

stream {
    resolver_timeout 5s;
    # 127.0.0.11 is docker swarms dns server
    resolver 127.0.0.11 valid=30s;
    # set does not work in stream module, using map here
    map '' $upstream_endpoint {
        default proxy_nginx:443;
    }

    server {
        listen 443;
        proxy_pass $upstream_endpoint;
        proxy_protocol on;
    }
}

layanan direplikasi nginx_proxy

server {
    listen 443 ssl http2 proxy_protocol;
    include /ssl.conf.include;

    ssl_certificate /etc/nginx/certs/main.crt;
    ssl_certificate_key /etc/nginx/certs/main.key;

    server_name example.org;

    auth_basic           "closed site";
    auth_basic_user_file /run/secrets/default.htpasswd;

    # resolver info in nginx.conf
    set $upstream_endpoint app;
    location / {
        # relevant proxy_set_header in nginx.conf
        proxy_pass http://$upstream_endpoint;
    }
}

Apakah mungkin untuk melewati seluruh konfigurasi nginx untuk nginx_stream dan
nginx_proxy dengan konfigurasi Swarm mereka?

Ini luar biasa jika berhasil!

Pada Selasa, 11 September 2018, 17:14 rubot, [email protected] menulis:

Kami beralih ke instance streaming global proxy_protocol nginx, yaitu
meneruskan ke aplikasi yang direplikasi proxy_nginx. Ini bekerja cukup baik
untuk saat ini.

layanan nginx_stream global

sungai kecil {
resolver_timeout 5 detik;
# 127.0.0.11 adalah server dns kawanan buruh pelabuhan
resolver 127.0.0.11 valid=30 detik;
# set tidak berfungsi dalam modul aliran, menggunakan peta di sini
peta '' $upstream_endpoint {
proksi default_ nginx:443;
}

server {
    listen 443;
    proxy_pass $upstream_endpoint;
    proxy_protocol on;
}

}

layanan direplikasi nginx_proxy

server {
dengarkan 443 ssl http2 proxy_protocol;
sertakan /ssl.conf.include;

ssl_certificate /etc/nginx/certs/main.crt;
ssl_certificate_key /etc/nginx/certs/main.key;

server_name example.org;

auth_basic           "closed site";
auth_basic_user_file /run/secrets/default.htpasswd;

# resolver info in nginx.conf
set $upstream_endpoint app;
location / {
    # relevant proxy_set_header in nginx.conf
    proxy_pass http://$upstream_endpoint;
}

}

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-420244262 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU5K-gK09XdI9NxLlT36IrJP7U7_cks5uZ6IrgaJpZM4Jf2WK
.

@sandys Saya punya solusi berbasis haproxy untuk bagian protokol proxy yang dikonfigurasi melalui variabel lingkungan.

Apakah mungkin untuk melewati seluruh konfigurasi nginx untuk nginx_stream dan nginx_proxy dengan konfigurasi Swarm mereka? Ini luar biasa jika berhasil!

@sandys Sesuatu seperti ini:
https://Gist.github.com/rubot/10c79ee0086a8a246eb43ab631f3581f

mengalami masalah yang sama, Apakah ini akan ditangani? sepertinya fungsi dasar yang harus dijadwalkan untuk rilis.

menyebarkan:
modus: global
port:

• target: 443 diterbitkan: 443 protokol: mode tcp: host

Mengikuti saran ini memperbaiki masalah karena penyeimbang kawanan buruh pelabuhan sekarang keluar dari persamaan.
Bagi saya ini adalah solusi yang valid karena masih HA dan saya sudah haproxy (di dalam wadah proxy aliran buruh pelabuhan).
Satu-satunya masalah adalah bahwa statistik haproxy didistribusikan di antara semua replika jadi saya perlu entah bagaimana untuk mengumpulkan info itu ketika memantau lalu lintas untuk seluruh cluster. Di masa lalu saya hanya memiliki satu contoh haproxy yang berada di belakang penyeimbang kawanan buruh pelabuhan.
Bersulang,
Jacq

Saat membaca permintaan OP ( @PanJ ), tampaknya fitur saat ini menyelesaikan masalah ini, seperti yang telah disarankan selama berbulan-bulan. OP tidak meminta perutean masuk + IP klien AFAIK, mereka meminta cara agar layanan swarm di replika/global memperoleh IP klien, yang sekarang bisa dilakukan. Dua bidang utama perbaikan memungkinkan hal ini terjadi:

1. Kami sekarang dapat membuat layanan Swarm yang "memublikasikan" port ke IP host, melewati lapisan perutean masuk
2. Layanan yang sama dapat melampirkan ke jaringan lain seperti overlay pada saat yang sama, sehingga dapat mengakses layanan lain dengan manfaat overlay

Bagi saya dengan mesin 18.09, saya mendapatkan yang terbaik dari kedua dunia dalam pengujian. Satu layanan dapat terhubung ke jaringan overlay backend dan juga memublikasikan port pada NIC host dan melihat IP klien nyata yang masuk pada IP host. Saya menggunakannya dengan traefik reverse proxy untuk mencatat lalu lintas IP klien di traefik yang ditujukan untuk layanan backend . Saya merasa ini bisa menyelesaikan sebagian besar permintaan yang pernah saya lihat untuk "mencatat IP asli".

@PanJ apakah ini menyelesaikannya untuk Anda?

Kuncinya adalah memublikasikan port di mode: host daripada mode: ingress (default).

Pro untuk mode ini adalah Anda mendapatkan IP klien nyata dan kinerja NIC host asli (karena itu di luar enkapulasi IPVS AFAIK). Kekurangannya adalah hanya akan mendengarkan pada simpul yang menjalankan replika.

Bagi saya, permintaan "Saya ingin menggunakan perutean IPVS masuk dan juga melihat IP klien" adalah permintaan fitur yang berbeda dari libnetwork.

Apa yang berubah di sini? Karena kami telah menggunakan mode host untuk melakukan ini
lama sekarang. Sebenarnya itu adalah solusi yang disarankan di utas ini sebagai
dengan baik.

Masalahnya tentu saja Anda harus mengunci layanan ini ke tertentu
host sehingga Swarm tidak dapat menjadwalkannya di tempat lain. Itu masalahnya
sepenuhnya - protokol proxy/IPVS itu, dll menyelesaikan masalah ini.

Pada Jum, 4 Jan, 2019, 09:34 Bret Fisher < [email protected] menulis:

Saat membaca permintaan OP ( @PanJ https://github.com/PanJ ), itu
tampaknya fitur saat ini sekarang menyelesaikan masalah ini, seperti yang disarankan untuk
bulan. OP tidak meminta perutean masuk + IP klien AFAIK, mereka bertanya
untuk cara memiliki layanan swarm di replika/global, dapatkan IP klien,
yang sekarang bisa dilakukan. Dua bidang utama perbaikan memungkinkan hal ini terjadi:

1. Kami sekarang dapat membuat layanan Swarm yang "memublikasikan" port ke
   host IP, melewatkan lapisan perutean masuk
2. Layanan yang sama dapat dilampirkan ke jaringan lain seperti overlay di
   waktu yang sama, sehingga dapat mengakses layanan lain dengan manfaat overlay

Bagi saya dengan mesin 18.09, saya mendapatkan yang terbaik dari kedua dunia dalam pengujian. A
layanan tunggal dapat terhubung ke jaringan overlay backend dan juga mempublikasikan
port pada NIC host dan lihat IP klien nyata yang masuk pada IP host. saya
menggunakannya dengan traefik reverse proxy untuk mencatat lalu lintas IP klien di traefik
yang ditujukan untuk layanan backend
https://github.com/BretFisher/dogvscat/blob/7e9fe5b998f2cf86951df3f443714beb413d63fb/stack-proxy-global.yml#L75-L83 .
Saya merasa ini dapat menyelesaikan sebagian besar permintaan yang pernah saya lihat untuk "mencatat yang asli
AKU P".

@PanJ https://github.com/PanJ apakah ini menyelesaikannya untuk Anda?

Kuncinya adalah mempublikasikan port dalam mode: host daripada mode: ingress (the
bawaan).

Pro untuk mode ini adalah Anda mendapatkan IP klien asli dan NIC host asli
kinerja (karena itu di luar enkapsulasi IPVS AFAIK). Kontra itu
hanya akan mendengarkan pada simpul yang menjalankan replika.

Bagi saya, permintaan "Saya ingin menggunakan perutean IPVS ingress dan juga melihat
client IP" adalah permintaan fitur yang berbeda dari libnetwork.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451348906 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsUzs15UVWOVl54FLwBJSZJKX-9D0jks5u_tLPgaJpZM4Jf2WK
.

@BretFisher mode: host hanya solusi tetapi bukan solusi. Seperti yang dikatakan @sandys bahwa solusinya memiliki beberapa peringatan, kami tidak boleh menganggap masalah ini telah diperbaiki.

Saya tidak yakin apakah ada peningkatan sejak solusi telah ditemukan. Saya telah pindah ke Kubernetes untuk waktu yang cukup lama dan masih terkejut bahwa masalah ini masih terbuka selama lebih dari dua tahun.

Saya masih agak terkejut, mengapa orang berpikir ini adalah bug. Dari saya
perspektif bahkan pernyataan pindah ke kubernetes tidak memadai
menjawab. Seperti yang saya lihat kubernetes memiliki masalah/perilaku yang sama persis. Kamu juga
memiliki LB eksternal, atau menggunakan sesuatu seperti nginx ingress proxy yang harus
dijalankan sebagai daemonset. Tolong koreksi saya jika saya salah, tetapi kami memiliki hal yang sama
situasi yang tepat di sini, tetapi tidak ada solusi otomatis yang disiapkan di sini. Seseorang bisa
periksa dan kemas solusi aliran tcp yang saya usulkan yang dijelaskan di atas untuk mendapatkan
sesuatu seperti perilaku proxy nginx. Terima saja, kawanan itu perlu
disesuaikan sendiri

Notifikasi [email protected] schrieb am Fr., 4. Jan. 2019, 09:28:

@BretFisher https://github.com/BretFisher mode: Host hanya
solusi tapi bukan solusi. Sebagai @sandys https://github.com/sandys
mengatakan bahwa solusinya memiliki beberapa peringatan, kita tidak boleh mempertimbangkan masalah ini
sebagai tetap.

Saya tidak yakin apakah ada peningkatan karena solusinya telah
telah menemukan. Saya telah pindah ke Kubernetes untuk waktu yang cukup lama dan masih
terkejut bahwa masalah ini masih terbuka selama lebih dari dua tahun.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
.

Anda bahkan dapat memperluas proyek dockerflow dan menambahkan varian nginx untuk memulai
kubernetes-ingressproxy untuk swarn. Pasti ini semua dikemas dengan segerombolan
akan meningkatkan wadah sistem tambahan seperti yang Anda tahu ada banyak
mereka dengan kubernet. Bukankah itu kekuatan swarm untuk sumber daya yang ramping?
proyek menjadi ramping?

Ruben Nicolaides [email protected] schrieb am Fr., 4 Januari 2019, 09:48:

Saya masih agak terkejut, mengapa orang berpikir ini adalah bug. Dari saya
perspektif bahkan pernyataan pindah ke kubernetes tidak memadai
menjawab. Seperti yang saya lihat kubernetes memiliki masalah/perilaku yang sama persis. Kamu juga
memiliki LB eksternal, atau menggunakan sesuatu seperti nginx ingress proxy yang harus
dijalankan sebagai daemonset. Tolong koreksi saya jika saya salah, tetapi kami memiliki hal yang sama
situasi yang tepat di sini, tetapi tidak ada solusi otomatis yang disiapkan di sini. Seseorang bisa
periksa dan kemas solusi aliran tcp yang saya usulkan yang dijelaskan di atas untuk mendapatkan
sesuatu seperti perilaku proxy nginx. Terima saja, kawanan itu perlu
disesuaikan sendiri

Notifikasi [email protected] schrieb am Fr., 4. Jan. 2019, 09:28:

@BretFisher https://github.com/BretFisher mode: Host hanya
solusi tapi bukan solusi. Sebagai @sandys https://github.com/sandys
mengatakan bahwa solusinya memiliki beberapa peringatan, kita tidak boleh mempertimbangkan masalah ini
sebagai tetap.

Saya tidak yakin apakah ada peningkatan karena solusinya telah
telah menemukan. Saya telah pindah ke Kubernetes untuk waktu yang cukup lama dan masih
terkejut bahwa masalah ini masih terbuka selama lebih dari dua tahun.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
.

Itu adalah solusi kompleks - protokol proxy hanya menambahkan header tambahan
informasi dan merupakan standar yang sangat terkenal - haproxy, nginx, AWS elb,
dll semua mengikutinya. https://www.haproxy.com/blog/haproxy/proxy-protocol/

Area permukaan perubahan akan terbatas pada Swarm yang ada di dalamnya
ingress (di mana dukungan ini akan ditambahkan). Dan semua layanan akan memilikinya
tersedia.

Pada Jumat, 4 Januari 2019, 14:36 ​​rubot < [email protected] menulis:

Anda bahkan dapat memperluas proyek dockerflow dan menambahkan varian nginx untuk memulai
kubernetes-ingressproxy untuk swarn. Pasti ini semua dikemas dengan segerombolan
akan meningkatkan wadah sistem tambahan seperti yang Anda tahu ada banyak
mereka dengan kubernet. Bukankah itu kekuatan swarm untuk sumber daya yang ramping?
proyek menjadi ramping?

Ruben Nicolaides [email protected] schrieb am Fr., 4 Januari 2019, 09:48:

Saya masih agak terkejut, mengapa orang berpikir ini adalah bug. Dari saya
perspektif bahkan pernyataan pindah ke kubernetes tidak memadai
menjawab. Seperti yang saya lihat kubernetes memiliki masalah/perilaku yang sama persis. Anda
salah satu
memiliki LB eksternal, atau menggunakan sesuatu seperti nginx ingress proxy yang harus
dijalankan sebagai daemonset. Tolong koreksi saya jika saya salah, tetapi kami memiliki hal yang sama
situasi yang tepat di sini, tetapi tidak ada solusi otomatis yang disiapkan di sini. Seseorang bisa
periksa dan kemas solusi aliran tcp yang saya usulkan yang dijelaskan di atas untuk mendapatkan
sesuatu seperti perilaku proxy nginx. Terima saja, kawanan itu perlu
disesuaikan sendiri

Notifikasi [email protected] schrieb am Fr., 4. Jan. 2019, 09:28:

@BretFisher https://github.com/BretFisher mode: Host hanya
solusi tapi bukan solusi. Sebagai @sandys https://github.com/sandys
mengatakan bahwa solusinya memiliki beberapa peringatan, kita tidak boleh mempertimbangkan ini
isu
sebagai tetap.

Saya tidak yakin apakah ada peningkatan karena solusinya telah
telah menemukan. Saya telah pindah ke Kubernetes untuk waktu yang cukup lama dan masih
menjadi
terkejut bahwa masalah ini masih terbuka selama lebih dari dua tahun.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 , atau
bisu
benang
<
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK
.

Seperti yang saya katakan, periksa solusi aliran tcp di atas, yang sudah menggunakan proxy
protokol.
Menambahkan protokol proxy akan memerlukan juga konfigurasi di dalam wadah jika
ditambahkan ke swarm hulu. Saya tidak melihat nilai, selain lebih bersih dan mungkin lebih baik
tujuan terdokumentasi dalam permintaan Anda

Sandeep Srinivasa [email protected] schrieb am Fr., 4. Jan. 2019,
11:37:

Itu adalah solusi kompleks - protokol proxy hanya menambahkan header tambahan
informasi dan merupakan standar yang sangat terkenal - haproxy, nginx, AWS elb,
dll semua mengikutinya. https://www.haproxy.com/blog/haproxy/proxy-protocol/

Area permukaan perubahan akan terbatas pada Swarm yang ada di dalamnya
ingress (di mana dukungan ini akan ditambahkan). Dan semua layanan akan memilikinya
tersedia.

Pada Jumat, 4 Januari 2019, 14:36 ​​rubot < [email protected] menulis:

Anda bahkan dapat memperluas proyek dockerflow dan menambahkan varian nginx ke
Mulailah
kubernetes-ingressproxy untuk swarn. Pasti ini semua dikemas dengan segerombolan
akan meningkatkan wadah sistem tambahan seperti yang Anda tahu ada banyak
mereka dengan kubernet. Bukankah itu kekuatan swarm untuk sumber daya yang ramping?
proyek menjadi ramping?

Ruben Nicolaides [email protected] schrieb am Fr., 4 Januari 2019, 09:48:

Saya masih agak terkejut, mengapa orang berpikir ini adalah bug. Dari saya
perspektif bahkan pernyataan pindah ke kubernetes tidak memadai
menjawab. Seperti yang saya lihat kubernetes memiliki masalah/perilaku yang sama persis. Anda
salah satu
memiliki LB eksternal, atau menggunakan sesuatu seperti nginx ingress proxy yang
harus
dijalankan sebagai daemonset. Tolong koreksi saya jika saya salah, tetapi kami memiliki hal yang sama
situasi yang tepat di sini, tetapi tidak ada solusi otomatis yang disiapkan di sini. Seseorang bisa
periksa dan kemas solusi aliran tcp yang saya usulkan yang dijelaskan di atas untuk mendapatkan
sesuatu seperti perilaku proxy nginx. Terima saja, kawanan itu perlu
menjadi
disesuaikan sendiri

Notifikasi [email protected] schrieb am Fr., 4. Jan. 2019, 09:28:

@BretFisher https://github.com/BretFisher mode: Host hanya
solusi tapi bukan solusi. Sebagai @sandys <
https://github.com/sandys>
mengatakan bahwa solusinya memiliki beberapa peringatan, kita tidak boleh mempertimbangkan ini
isu
sebagai tetap.

Saya tidak yakin apakah ada peningkatan karena solusinya telah
telah menemukan. Saya telah pindah ke Kubernetes untuk waktu yang cukup lama dan masih
menjadi
terkejut bahwa masalah ini masih terbuka selama lebih dari dua tahun.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 ,
atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
>

.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 , atau
bisu
benang
<
https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK

.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK
.

Solusi di atas memerlukan pengikatan mode host . Itu adalah masalah besar. Dia
menghilangkan kemungkinan menggunakan penjadwal buruh pelabuhan untuk mengalokasikan wadah
ke host yang berbeda - Saya tidak lagi menjadi bagian dari jaringan mesh.

Pada Jum, 4 Jan, 2019, 17:28 rubot < [email protected] menulis:

Seperti yang saya katakan, periksa solusi aliran tcp di atas, yang sudah menggunakan proxy
protokol.
Menambahkan protokol proxy akan memerlukan juga konfigurasi di dalam wadah jika
ditambahkan ke swarm hulu. Saya tidak melihat nilai, selain lebih bersih dan mungkin lebih baik
tujuan terdokumentasi dalam permintaan Anda

Sandeep Srinivasa [email protected] schrieb am Fr., 4. Jan. 2019,
11:37:

Itu adalah solusi kompleks - protokol proxy hanya menambahkan header tambahan
informasi dan merupakan standar yang sangat terkenal - haproxy, nginx, AWS elb,
dll semua mengikutinya. https://www.haproxy.com/blog/haproxy/proxy-protocol/

Area permukaan perubahan akan terbatas pada Swarm yang ada di dalamnya
ingress (di mana dukungan ini akan ditambahkan). Dan semua layanan akan memiliki
dia
tersedia.

Pada Jumat, 4 Januari 2019, 14:36 ​​rubot < [email protected] menulis:

Anda bahkan dapat memperluas proyek dockerflow dan menambahkan varian nginx ke
Mulailah
kubernetes-ingressproxy untuk swarn. Pasti ini semua dikemas dengan
kawanan
akan meningkatkan wadah sistem tambahan seperti yang Anda tahu ada banyak
dari
mereka dengan kubernet. Bukankah itu kekuatan swarm untuk sumber daya yang ramping?
proyek menjadi ramping?

Ruben Nicolaides [email protected] schrieb am Fr., 4 Januari 2019, 09:48:

Saya masih agak terkejut, mengapa orang berpikir ini adalah bug. Dari saya
perspektif bahkan pernyataan pindah ke kubernetes bukanlah
memadai
menjawab. Seperti yang saya lihat kubernetes memiliki masalah/perilaku yang sama persis. Anda
salah satu
memiliki LB eksternal, atau menggunakan sesuatu seperti nginx ingress proxy yang
harus
dijalankan sebagai daemonset. Harap perbaiki saya jika saya salah, tetapi kami memiliki
sama
situasi yang tepat di sini, tetapi tidak ada solusi otomatis yang disiapkan di sini. Seseorang
bisa
periksa dan kemas solusi aliran tcp yang saya usulkan yang dijelaskan di atas untuk mendapatkan
sesuatu seperti perilaku proxy nginx. Terima saja, kawanan itu perlu
menjadi
disesuaikan sendiri

Notifikasi [email protected] schrieb am Fr., 4. Jan. 2019, 09:28:

@BretFisher https://github.com/BretFisher mode: hanya tuan rumah
A
solusi tapi bukan solusi. Sebagai @sandys <
https://github.com/sandys>
mengatakan bahwa solusinya memiliki beberapa peringatan, kita tidak boleh mempertimbangkan
ini
isu
sebagai tetap.

Saya tidak yakin apakah ada peningkatan karena solusinya telah
pernah
telah menemukan. Saya telah pindah ke Kubernetes untuk waktu yang cukup lama dan
tetap
menjadi
terkejut bahwa masalah ini masih terbuka selama lebih dari dua tahun.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 ,
atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 , atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK
>

.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 , atau
bisu
benang
<
https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK

.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451424992 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU-q-I3fXVAP9JcGgTdJJOzI7b575ks5u_0HIgaJpZM4Jf2WK
.

Seperti yang saya katakan, ingress kubernetes nginx membutuhkan pengikatan mode Host juga, yang disebut
daemonset. LB eksternal terhubung ke nodeports, yang juga memerlukan mode host
dalam layanan, atau secara manual mengkonfigurasi protokol proxy dalam layanan. Kubernetes
berurusan dengan masalah yang sama, masih.
Salah satu permintaan fitur yang mungkin dari sudut pandang saya untuk swarm adalah
membuat penyedia jaringan pluggable. Ini akan memungkinkan untuk digunakan
teknik lain selain lvs/iptables

Sandeep Srinivasa [email protected] schrieb am Fr., 4. Jan. 2019,
13:05:

Solusi di atas memerlukan pengikatan mode host . Itu adalah masalah besar. Dia
menghilangkan kemungkinan menggunakan penjadwal buruh pelabuhan untuk mengalokasikan wadah
ke host yang berbeda - Saya tidak lagi menjadi bagian dari jaringan mesh.

Pada Jum, 4 Jan, 2019, 17:28 rubot < [email protected] menulis:

Seperti yang saya katakan, periksa solusi aliran tcp di atas, yang sudah menggunakan proxy
protokol.
Menambahkan protokol proxy juga memerlukan konfigurasi di dalam wadah
jika
ditambahkan ke swarm hulu. Saya tidak melihat nilai, selain pembersih dan mungkin
lebih baik
tujuan terdokumentasi dalam permintaan Anda

Sandeep Srinivasa [email protected] schrieb am Fr., 4. Jan.
2019,
11:37:

Itu adalah solusi kompleks - protokol proxy hanya menambahkan tambahan
header
informasi dan merupakan standar yang sangat terkenal - haproxy, nginx, AWS
elb,
dll semua mengikutinya.
https://www.haproxy.com/blog/haproxy/proxy-protocol/

Area permukaan perubahan akan terbatas pada Swarm yang ada di dalamnya
ingress (di mana dukungan ini akan ditambahkan). Dan semua layanan akan memiliki
dia
tersedia.

Pada Jumat, 4 Januari 2019, 14:36 ​​rubot < [email protected] menulis:

Anda bahkan dapat memperluas proyek dockerflow dan menambahkan varian nginx ke
Mulailah
kubernetes-ingressproxy untuk swarn. Pasti ini semua dikemas dengan
kawanan
akan meningkatkan wadah sistem tambahan seperti yang Anda tahu ada banyak
dari
mereka dengan kubernet. Bukankah itu kekuatan swarm untuk slim
sumber
proyek menjadi ramping?

Ruben Nicolaides [email protected] schrieb am Fr., 4 Januari 2019,
09:48:

Saya masih agak terkejut, mengapa orang berpikir ini adalah bug. Dari
Ku
perspektif bahkan pernyataan pindah ke kubernetes bukanlah
memadai
menjawab. Seperti yang saya lihat kubernetes memiliki masalah/perilaku yang sama persis.
Anda
salah satu
memiliki LB eksternal, atau menggunakan sesuatu seperti nginx ingress proxy
yang
harus
dijalankan sebagai daemonset. Harap perbaiki saya jika saya salah, tetapi kami memiliki
sama
situasi yang tepat di sini, tetapi tidak ada solusi otomatis yang disiapkan di sini. Seseorang
bisa
periksa dan kemas solusi aliran tcp yang saya usulkan yang dijelaskan di atas untuk
Dapatkan
sesuatu seperti perilaku proxy nginx. Terima saja, kebutuhan segerombolan itu
ke
menjadi
disesuaikan sendiri

Notifikasi [email protected] schrieb am Fr., 4. Jan. 2019,
09:28:

@BretFisher https://github.com/BretFisher mode: Host adalah
hanya
A
solusi tapi bukan solusi. Sebagai @sandys <
https://github.com/sandys>
mengatakan bahwa solusinya memiliki beberapa peringatan, kita tidak boleh mempertimbangkan
ini
isu
sebagai tetap.

Saya tidak yakin apakah ada peningkatan karena solusinya telah
pernah
telah menemukan. Saya telah pindah ke Kubernetes untuk waktu yang cukup lama dan
tetap
menjadi
terkejut bahwa masalah ini masih terbuka selama lebih dari dua tahun.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
< https://github.com/moby/moby/issues/25526#issuecomment -451382365
,
atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 ,
atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK

>

.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 , atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK
>

.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451424992 , atau
bisu
benang
<
https://github.com/notifications/unsubscribe-auth/AAEsU-q-I3fXVAP9JcGgTdJJOzI7b575ks5u_0HIgaJpZM4Jf2WK

.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451426276 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAPguw88UN68sw_TNTunZpuAGqgvexxMks5u_0NxgaJpZM4Jf2WK
.

Dan hanya untuk memperjelas, solusi di atas memiliki aliran tcp di depan layanan
proxy. Jadi, permintaan Anda jelas bukan bug, tetapi permintaan fitur. Dan
fitur ini hanya dapat diimplementasikan dalam swarm, jika mode jaringan mau
ubah, karena masalah utama tetap kehilangan ip pada level Nat/host

Ruben Nicolaides [email protected] schrieb am Fr., 4 Januari 2019, 13:11:

Seperti yang saya katakan, ingress kubernetes nginx membutuhkan pengikatan mode Host juga, yang disebut
daemonset. LB eksternal terhubung ke nodeports, yang juga memerlukan mode host
dalam layanan, atau secara manual mengkonfigurasi protokol proxy dalam layanan. Kubernetes
berurusan dengan masalah yang sama, masih.
Salah satu permintaan fitur yang mungkin dari sudut pandang saya untuk swarm adalah
membuat penyedia jaringan pluggable. Ini akan memungkinkan untuk digunakan
teknik lain selain lvs/iptables

Sandeep Srinivasa [email protected] schrieb am Fr., 4. Jan.
2019, 13:05:

Solusi di atas memerlukan pengikatan mode host . Itu adalah masalah besar. Dia
menghilangkan kemungkinan menggunakan penjadwal buruh pelabuhan untuk mengalokasikan
wadah
ke host yang berbeda - Saya tidak lagi menjadi bagian dari jaringan mesh.

Pada Jum, 4 Jan, 2019, 17:28 rubot < [email protected] menulis:

Seperti yang saya katakan, periksa solusi aliran tcp di atas, yang sudah menggunakan proxy
protokol.
Menambahkan protokol proxy juga memerlukan konfigurasi di dalam wadah
jika
ditambahkan ke swarm hulu. Saya tidak melihat nilai, selain pembersih dan mungkin
lebih baik
tujuan terdokumentasi dalam permintaan Anda

Sandeep Srinivasa [email protected] schrieb am Fr., 4. Jan.
2019,
11:37:

Itu adalah solusi kompleks - protokol proxy hanya menambahkan tambahan
header
informasi dan merupakan standar yang sangat terkenal - haproxy, nginx, AWS
elb,
dll semua mengikutinya.
https://www.haproxy.com/blog/haproxy/proxy-protocol/

Area permukaan perubahan akan terbatas pada Swarm yang ada di dalamnya
ingress (di mana dukungan ini akan ditambahkan). Dan semua layanan akan
memiliki
dia
tersedia.

Pada Jumat, 4 Januari 2019, 14:36 ​​rubot < [email protected] menulis:

Anda bahkan dapat memperluas proyek dockerflow dan menambahkan varian nginx ke
Mulailah
kubernetes-ingressproxy untuk swarn. Pasti ini semua dikemas dengan
kawanan
akan meningkatkan wadah sistem tambahan seperti yang Anda tahu ada
kelompok
dari
mereka dengan kubernet. Bukankah itu kekuatan swarm untuk slim
sumber
proyek menjadi ramping?

Ruben Nicolaides [email protected] schrieb am Fr., 4 Januari 2019,
09:48:

Saya masih agak terkejut, mengapa orang berpikir ini adalah bug. Dari
Ku
perspektif bahkan pernyataan pindah ke kubernetes bukanlah
memadai
menjawab. Seperti yang saya lihat kubernetes memiliki masalah/perilaku yang sama persis.
Anda
salah satu
memiliki LB eksternal, atau menggunakan sesuatu seperti nginx ingress proxy
yang
harus
dijalankan sebagai daemonset. Harap perbaiki saya jika saya salah, tetapi kami memiliki
sama
situasi yang tepat di sini, tetapi tidak ada solusi otomatis yang disiapkan di sini. Seseorang
bisa
periksa dan kemas solusi aliran tcp yang saya usulkan yang dijelaskan di atas untuk
Dapatkan
sesuatu seperti perilaku proxy nginx. Terima saja, kawanan itu
perlu
menjadi
disesuaikan sendiri

Notifikasi [email protected] schrieb am Fr., 4. Jan. 2019,
09:28:

@BretFisher https://github.com/BretFisher mode: Host adalah
hanya
A
solusi tapi bukan solusi. Sebagai @sandys <
https://github.com/sandys>
mengatakan bahwa solusinya memiliki beberapa peringatan, kita tidak boleh mempertimbangkan
ini
isu
sebagai tetap.

Saya tidak yakin apakah ada peningkatan karena solusinya telah
pernah
telah menemukan. Saya telah pindah ke Kubernetes untuk waktu yang cukup lama dan
tetap
menjadi
terkejut bahwa masalah ini masih terbuka selama lebih dari dua tahun.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
<
https://github.com/moby/moby/issues/25526#issuecomment-451382365>,
atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 ,
atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK

>

.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 ,
atau
bisu
benang
<

https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK
>

.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451424992 , atau
bisu
benang
<
https://github.com/notifications/unsubscribe-auth/AAEsU-q-I3fXVAP9JcGgTdJJOzI7b575ks5u_0HIgaJpZM4Jf2WK

.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451426276 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAPguw88UN68sw_TNTunZpuAGqgvexxMks5u_0NxgaJpZM4Jf2WK
.

1. setelah utas yang begitu panjang, saya mencoba mendokumentasikan kumpulan fitur saat ini dengan contoh lengkap.
2. Saya tidak melihat kebutuhan spesifik Anda dalam permintaan OP. @PanJ meminta untuk melihat IP klien di luar kotak, yang pada pertengahan 2018 dapat Anda lakukan. Saya tidak melihat mereka mengharuskan itu juga menggunakan mesh perutean masuk.

Apakah Anda menyebutnya bug atau permintaan fitur, ingress mesh tanpa source nat (menurut saya) penting. Ada banyak aplikasi yang rusak ketika tidak dapat melihat IP sumber yang sebenarnya. Tentu, dalam kasus server web Anda dapat membalikkan proxy menggunakan node host dan menambahkan header IP klien. Namun, ini menambah overhead dan mungkin bukan pilihan untuk aplikasi non-web. Dengan aplikasi yang benar-benar membutuhkan IP sumber asli pada paket agar benar, satu-satunya pilihan adalah tidak menggunakan ingress mesh. Itu membuang sebagian besar manfaat menggunakan swarm di tempat pertama.

Beri tahu kami kapan masalah ini telah diperbaiki atau belum?!
haruskah kita menggunakan kuberneties saja ?

Saya mengalami masalah yang sama ... saya belum menemukan perbaikan saat ini.

Ketika seseorang menemukan solusi untuk perilaku ini, harap laporkan di sini.

Terima kasih!

Saya memiliki masalah yang sama. Saya memiliki server httpd Apache dan saya ingin mencatat semua akses untuk mengekstrak statistik nanti tentang negara mana kami menerima permintaan.

Saya sendiri menemukan masalah ini ketika mencoba mencari tahu mengapa php: Apache tidak mencatat bidang header Host dengan benar. Saya terkejut dan kecewa ini belum berhasil setelah bertahun-tahun. Bagaimana kita bisa menggunakan Mode Swarm untuk hosting web ketika bidang host terus mencatat IP proxy userland? Saya belum dapat menemukan cara untuk mengatasi ini dengan Swarm Mode. Saya kira saya bisa menggunakan Classic Swarm (berbasis wadah) dan sesuatu seperti Konsul tetapi saya merasa itu mundur.

Saya menemukan solusi yang dapat diterima untuk skenario saya:

services:
  server:
    image: httpd:2
    deploy:
      mode: global
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
      - target: 443
        published: 443
        protocol: tcp
        mode: host
    networks:
      - my_second_service
      - another_great_software

Ini akan menyebabkan Apache mendengarkan di komputer host alih-alih di belakang jaringan overlay (membaca alamat IP jarak jauh yang tepat), sambil tetap mem-proxy permintaan ke layanan lain melalui opsi networks dan mencapai "ketersediaan tinggi" dengan memilikinya berlari kemana-mana

@rafaelsierra - inilah masalah yang saya miliki dengan ini (dan perbaiki saya jika saya salah), tetapi konfigurasi ini hanya memungkinkan satu wadah Apache/PHP untuk dijalankan dan mengikat ke port 80 pada node Host. Saya perlu menjalankan banyak dan banyak kontainer Apache dengan kontainer Nginx yang terikat ke port 80/443, dan kemudian vhost mereka.

@SysEngDan ya, memang benar bahwa Anda hanya dapat memiliki satu wadah yang mengikat ke port 80/443, tetapi dalam kasus saya itu tidak masalah karena wadah yang mengikat ke port ini hanya bertanggung jawab untuk mem-proxy semua permintaan ke wadah lain yang berjalan di belakang jaringan overlay.

Anda mungkin dapat menggunakan solusi yang sama dengan memiliki satu wadah nginx/Apache yang menerima semua permintaan dan melakukan proxy ke wadah yang tepat berdasarkan vhost, dan wadah tersebut tidak harus mengikat ke Host

@rafaelsierra - Dengan hormat, saya tidak yakin apakah Anda memahami masalah yang didokumentasikan dalam tiket ini. Jika saya mengonfigurasi layanan seperti yang Anda sebutkan di paragraf terakhir Anda, masalahnya adalah bahwa IP Klien tidak diteruskan ke wadah hanya mendengarkan di jaringan overlay. Jika saya mengikat langsung ke Host, tidak masalah. Jika kita mengandalkan proxy jaringan buruh pelabuhan dari eksternal (host) ke internal (hamparan), wadah Apache tujuan tidak akan menerima alamat IP Klien asli melainkan IP proxy (dari jaringan buruh pelabuhan).

@SysEngDan saya mengerti masalahnya, dan karena tidak ada solusi selama 2 tahun terakhir (dan sejujurnya saya tidak yakin apakah ini "dapat diperbaiki"), saya harus menemukan solusi alternatif yang sesuai dengan kebutuhan saya (membatasi akses berdasarkan alamat IP jarak jauh).

Memiliki satu wadah yang mendengarkan pada port 80/443 di Host dan kemudian melakukan proksi ke wadah lain (dengan tajuk HTTP yang sesuai yang tidak saya sebutkan karena berada di luar cakupan masalah ini) menyelesaikan masalah saya, dan saya ingin membagikan solusi ini untuk orang-orang yang menghadapi masalah serupa karena jaringan overlay tidak dapat melewati alamat IP jarak jauh

Oh saya melihat apa yang Anda lakukan di sana ..... maaf, saya melewatkan itu. Anda memotong jaringan overlay dan sebagai gantinya memasang wadah menghadap eksternal Anda langsung ke jaringan layanan (yang dibuat secara otomatis saat Anda memulai layanan baru tanpa menentukan jaringan). Oke, saya pikir itu berhasil. Overhead yang ditambahkan adalah tugas menambahkan jaringan layanan ke file docker-compose. Saya ingin tahu apa yang terjadi ketika penampung host dimulai dan salah satu layanan tersebut tidak tersedia?

Dalam hal ini Anda akan mendapatkan 502.

Saya tidak memiliki satu docker-compose.yml, saya memiliki banyak tumpukan dengan beberapa layanan yang berbicara satu sama lain melalui jaringan overlay, dan kemudian saya memiliki layanan yang menghadap publik yang mengikat ke server Host tetapi masih memiliki akses ke semua jaringan overlay lainnya sehingga dapat mem-proxy semua permintaan.

Solusi mode host telah dibahas beberapa kali tentang masalah ini. Meskipun mungkin OK untuk beberapa skenario terbatas (seperti pengaturan lalu lintas web proxy terbalik tertentu), ini bukan solusi umum untuk masalah ini. Silakan baca posting sebelumnya daripada mengulangi "solusi" yang sama lagi.

@darrellenns ada lebih dari 200 komentar di sini, saya pikir akan lebih baik untuk mengunci dan membersihkan masalah ini dengan memberikan solusi dasar "gunakan host bind jika itu berlaku untuk Anda" sementara tidak ada solusi resmi jika disediakan, jika tidak, lebih banyak orang seperti saya akan ketinggalan itu dan terus saja mengomentari hal yang sama berulang-ulang

Jadi, saya percaya bahwa bug ini mempengaruhi kemampuan traefiks untuk memasukkan ips ke daftar putih. Apakah itu benar?

Bagaimanapun, bagi siapa saja yang ingin menjalankan mode swarm, ini adalah contoh dengan menggunakan mode host untuk menerbitkan port.

docker service create \
--name traefik \
--constraint=node.role==manager \
--publish mode=host,target=80,published=80 \
--publish mode=host,target=443,published=443 \
--mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
--mount type=bind,source=/home/$USER/dev-ops/logs,target=/dev-ops/logs \
--mount type=bind,source=/opt/data/traefik/traefik.toml,target=/traefik.toml \
--mount type=bind,source=/opt/data/traefik/acme.json,target=/acme.json \
--network traefik \
--label traefik.frontend.rule=Host:traefik.example.com \
--label traefik.port=8080 \
traefik \
--docker \
--docker.swarmMode \
--docker.watch \
--docker.exposedByDefault

@coltenkrauter Saya tidak tahu persis apa pengaruhnya, tetapi dalam mode Host saya hanya dapat menjalankan satu replika layanan traefik, dan saya tidak berpikir itu hanya saya. Dengan cara ini saya harus sepenuhnya mempercayai stabilitas traefik tanpa menyampaikan fitur mode swarm untuk layanan.

Juga, seperti yang dilaporkan pertama kali, itu tidak terlalu berkaitan dengan kebutuhan khusus traefik, itu diuji dengan layanan http generik yang tidak menerima ip asli, itu berarti mode kawanan buruh pelabuhan rusak (fitur penting ini hilang), dan sepertinya tidak ada yang peduli.

Dan saya ingin terus mengomentari hal ini, karena saya harap kebisingan itu mengganggu seseorang yang lebih suka memperbaikinya :) (maaf, itu berlaku untuk saya dari pengguna saya)

dalam mode host saya hanya dapat menjalankan satu replika layanan traefik, dan saya tidak berpikir itu hanya saya. Dengan cara ini saya harus sepenuhnya mempercayai stabilitas traefik tanpa menyampaikan fitur mode swarm untuk layanan.

Anda dapat menjalankan satu instance per host

dalam mode host saya hanya dapat menjalankan satu replika layanan traefik, dan saya tidak berpikir itu hanya saya. Dengan cara ini saya harus sepenuhnya mempercayai stabilitas traefik tanpa menyampaikan fitur mode swarm untuk layanan.

Anda dapat menjalankan satu instance per host

ya, tapi traefik terpaksa bekerja pada node manager, karena perlu ini agar berfungsi dengan baik. Jadi, satu node manajer, satu host, satu instance

traefik dapat bekerja dari node manajer dalam berbagai cara, termasuk menggunakan a
proxy soket buruh pelabuhan, soket jarak jauh, atau perusahaan traefik. ini dia
contoh file tumpukan untuk cara melakukannya:
https://github.com/BretFisher/dogvscat/blob/master/stack-proxy-global.yml

Pada Sabtu, 16 Maret 2019 pukul 17:25 Daniele Cruciani [email protected]
menulis:

dalam mode host saya hanya dapat menjalankan satu replika layanan traefik, dan saya tidak
pikir itu hanya aku. Dengan cara ini saya harus sepenuhnya mempercayai stabilitas traefik
tanpa menyampaikan fitur mode swarm untuk layanan.

Anda dapat menjalankan satu instance per host

ya, tetapi traefik terpaksa bekerja pada simpul manajer, karena membutuhkan ini
untuk bekerja dengan benar. Jadi, satu node manajer, satu host, satu instance

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-473593956 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAwW31DHIwEJE1EqN3-8qj44WopocuQTks5vXWE_gaJpZM4Jf2WK
.

Sangat menarik untuk mengetahuinya, tetapi lihat, fitur ini tersedia di kubernetes tetapi tidak dalam mode kawanan buruh pelabuhan, dan Anda bersikeras ada opsi untuk menjalankan beberapa instance traefik, tetapi di beberapa node, jika saya ingin menjalankan beberapa instance di node tunggal, itu tidak mungkin, karena ini tidak didukung.
Selain itu, layanan lain apa pun, yang tidak hanya meminta proxy, tidak diizinkan untuk memetakan port apa pun, karena memerlukan jenis konfigurasi khusus yang perlu memetakan setiap host ke dalamnya, dan lagi pula ia membutuhkan banyak node, setidaknya satu per instance .

Dan seterusnya, dan seterusnya. Anda dapat menggulir diskusi ini ke atas dan menemukan yang lain tentang hal itu. Saya tidak berpikir itu bisa direduksi menjadi demonstrasi seberapa baik Anda menghasilkan solusi, karena solusi itu tetap sulit dipertahankan dan sulit diikuti. Dan semua waktu yang dihabiskan untuk mempertahankan solusi kasus khusus lebih baik dihabiskan untuk memperbaiki masalah.

Di sisi lain, jika fitur semacam ini merupakan masalah keamanan untuk model kawanan buruh pelabuhan, tandai saja sebagai wontfix dan saya berencana untuk beralih ke kubernetes, jika demikian, saya rasa tidak ada konflik antar proyek, itu hanya mengatakan secara eksplisit itu tidak akan pernah terjadi, dan semua orang dapat mengambil tindakan, jika mungkin sebelum pilihan mode gerombolan buruh pelabuhan untuk segala jenis gerombolan simpul

Ada banyak fitur di kubernetes yang tidak ada di swarm, begitu juga sebaliknya. Kita semua membuat keputusan tentang orkestra mana yang akan digunakan untuk solusi spesifik berdasarkan banyak faktor, termasuk fitur. Tidak ada satu alat yang menyelesaikan semua masalah/kebutuhan.

Saya hanya anggota komunitas yang mencoba membantu. Jika Anda tidak menyukai solusi saat ini untuk masalah ini, maka sepertinya Anda harus mencari cara lain untuk menyelesaikannya, mungkin dengan sesuatu seperti kubernetes. Itu adalah alasan yang masuk akal untuk memilih satu orkestra daripada yang lain jika menurut Anda cara kubernetes untuk menyelesaikannya lebih sesuai dengan keinginan Anda.

Secara historis, pengelola moby dan swarm tidak menutup masalah seperti ini sebagai tidak akan diperbaiki karena besok seseorang dari komunitas dapat menjatuhkan PR dengan solusi untuk masalah ini. Juga, saya pikir membahas cara untuk mengatasinya sampai saat itu, adalah penggunaan yang valid dari utas masalah ini. :)

Meskipun bukan pengelola swarm, saya dapat mengatakan bahwa secara historis tim tidak mengungkapkan rencana fitur masa depan di luar apa PR yang saat ini Anda lihat mendapatkan komit dalam repo.

Saya lupa mengatakan bahwa tentu saja komentar Anda diterima (atau saya mengatakannya dengan tidak jelas, maaf). Tapi saya ingin memperkuat laporan @PanJ asli:

Sementara itu, saya pikir saya harus melakukan solusi yang menjalankan wadah proxy di luar mode swarm dan membiarkannya meneruskan ke port yang diterbitkan dalam mode swarm (penghentian SSL harus dilakukan pada wadah ini juga), yang merusak tujuan swarm mode untuk penyembuhan diri dan orkestrasi.

Maksud saya ini "menghancurkan tujuan mode swarm", tentu saja hanya pada topik khusus ini, sudah cukup untuk mendapatkan lebih banyak perhatian.

Saya mencoba membuat tim saya membuat PR yang menambahkan protokol proxy ke
jaringan masuk. Kami bukan programmer Golang, jadi kami merasa sedikit
sulit.

Tapi saya sangat berharap tim Docker setuju bahwa yang terbaik dan terbaik
solusi yang kompatibel (di seluruh ekosistem) adalah dengan melapisi protokol proxy
mendukung jaringan ingress.

Kompleksitasnya muncul dalam kenyataan bahwa jaringan masuk tidak hanya harus
menyuntikkan tajuknya sendiri, tetapi harus mendukung fakta bahwa mungkin ada
header protokol proxy upstream sudah dimasukkan (misalnya Google LB atau
AWS ELB).

Pada Minggu, 17 Mar, 2019, 12:17 Daniele Cruciani, [email protected]
menulis:

Saya lupa mengatakan bahwa tentu saja komentar Anda diterima (atau saya mengatakannya dalam
cara yang tidak jelas, maaf). Tapi saya suka memperkuat @PanJ yang asli
https://github.com/PanJ laporan:

Sementara itu, saya pikir saya harus melakukan solusi yang sedang berjalan
wadah proxy di luar mode swarm dan biarkan meneruskan ke port yang diterbitkan
dalam mode swarm (penghentian SSL harus dilakukan pada wadah ini juga), yang
mematahkan tujuan mode swarm untuk penyembuhan diri dan orkestrasi.

Maksud saya ini "menghancurkan tujuan mode swarm", tentu saja hanya untuk ini
topik tertentu, sudah cukup untuk mendapatkan perhatian lebih.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-473621667 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsUwNWJsGKlLejcNzS2pR0awBB4OVlks5vXeTugaJpZM4Jf2WK
.

https://stackoverflow.com/questions/50585616/kubernetes-metallb-traefik-how-to-get-real-client-ip
Seperti yang diminta untuk k8 di mana ia berlapis, sepenuhnya dan dapat dikonfigurasi

Bagi siapa saja yang menjalankan nginx di digitalocean dengan kawanan buruh pelabuhan dan mencoba untuk mendapatkan $remote_addr bukan hanya 10.255.0.2 dalam log nginx Anda; anda dapat menggunakan solusi dari @coltenkrauter. Tangkapannya adalah Anda hanya dapat menjalankan satu wadah nginx di Host dengan solusi ini, yang seharusnya tidak masalah bagi kebanyakan orang.

Cukup ubah file docker-compose.yml :

SALAH

services:
  nginx:
    ports:
      - "80:80"
      - "443:443"

BENAR

services:
  nginx:
    ports:
      - target: 80
        published: 80
        mode: host
      - target: 443
        published: 443
        mode: host

_edit: sekarang kita semua dijamin mendapatkan jawaban yang benar_

Tidak menggunakan ingress ( mode: host ) bukanlah solusi, ketika masalah menyatakan bahwa masalah terjadi dengan jaringan ingress.
Tidak ada yang akan menggunakan hanya satu host sebagai proxy terbalik. Anda ingin banyak host dengan ip mengambang, dan swarm-mesh wajib untuk mencapai pengaturan ini.

Mungkin itu tidak mungkin, tetapi saya pikir, memodifikasi aturan iptables untuk melakukan MASQUERADE pada tahap tertentu dalam rantai INGRESS akan menjadi solusi sehingga mempertahankan ip sumber asli. Bukankah beberapa ahli iptables/netfilter ada?

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-INGRESS  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         

Chain DOCKER-INGRESS (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

Sebagai alternatif, tidak bisakah swarm mengambil ip sumber asli dan membuat X-Forwarded-For Header?

Tidak ada yang akan menggunakan hanya satu host sebagai proxy terbalik. Anda ingin banyak host dengan ip mengambang, dan swarm-mesh wajib untuk mencapai pengaturan ini.

Setiap node dalam swarm dapat menjalankan instance reverse-proxy, dan merutekan lalu lintas ke layanan yang mendasarinya melalui jaringan overlay (tetapi hanya proxy yang tahu tentang alamat IP asli).

Pastikan untuk membaca seluruh utas (saya melihat GitHub menyembunyikan beberapa komentar yang cukup berguna, jadi Anda harus memperluasnya :kecewa :);

Sebagai alternatif, tidak bisakah swarm mengambil ip sumber asli dan membuat X-Forwarded-For Header?

Lihat https://github.com/moby/moby/issues/25526#issuecomment -367642600; X-Forwarded-For adalah protokol L7; Swarm ingress adalah L4, menggunakan IPVS dengan DNAT

@port22 umumnya kami setuju bahwa solusi bukanlah solusi, solusinya adalah membuatnya dapat berlapis , lihat komentar #25526

Sebagai alternatif, tidak bisa swarm ambil saja ip sumber aslinya dan buat

sebuah X-Forwarded-For Header?
Lihat #25526 (komentar)
https://github.com/moby/moby/issues/25526#issuecomment-367642600 ;
X-Forwarded-For adalah protokol L7; Swarm ingress adalah L4, menggunakan IPVS dengan DNAT

solusi yang tepat di sini adalah protokol proxy yang disuntikkan di L4. ada beberapa
diskusi pro dan kontra yang relevan di Envoy untuk kasus penggunaan yang sama
https://github.com/envoyproxy/envoy/issues/4128 dan
https://github.com/envoyproxy/envoy/issues/1031

Pada Rabu, 10 Apr 2019 pukul 01:40 Sebastiaan van Stijn <
[email protected]> menulis:

Tidak ada yang akan menggunakan hanya satu host sebagai proxy terbalik. Anda ingin banyak
host dengan ip mengambang, dan swarm-mesh wajib untuk mencapai ini
mempersiapkan.

Setiap node dalam swarm dapat menjalankan instance dari reverse-proxy, dan route
lalu lintas ke layanan yang mendasari melalui jaringan overlay (tetapi hanya
proxy akan tahu tentang alamat IP asli).

Pastikan untuk membaca seluruh utasnya (saya melihat GitHub menyembunyikan beberapa hal yang berguna
komentar, jadi Anda harus memperluasnya );

Sebagai alternatif, tidak bisa swarm ambil saja ip sumber aslinya dan buat
sebuah X-Forwarded-For Header?

Lihat #25526 (komentar)
https://github.com/moby/moby/issues/25526#issuecomment-367642600 ;
X-Forwarded-For adalah protokol L7; Swarm ingress adalah L4, menggunakan IPVS dengan DNAT

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-481415217 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsU5KdnWQ21hJx_xzc-QROJiWbAlulks5vfPOigaJpZM4Jf2WK
.

Setiap node dalam swarm dapat menjalankan instance dari reverse-proxy

Ini menghilangkan fitur swarm load balancer, yang merupakan masalah sebenarnya.
Dan masalah saya lebih spesifik adalah, traefik itu tidak gesit cluster. Itu harus dijalankan mandiri kecuali Anda menggunakan konsul sebagai backend konfigurasi, yang kemudian membatasi sertifikat maksimum hingga ~ 100 yang tidak berlaku untuk saya. Tentu, Anda dapat menyatakan bahwa ini bukan masalah swarm tetapi masalah traefik. fakta menyenangkan: traefik menyatakan ini adalah masalah konsul. konsul menyatakan: traefik melakukan kesalahan.

@port22 umumnya kami setuju bahwa solusi bukanlah solusi

Maksud saya adalah, bahwa TIDAK menggunakan ingress bukanlah solusi saat Anda MEMBUTUHKAN ingress. Solusinya adalah sesuatu yang memungkinkan untuk tetap menggunakan swarm loadbalancer sambil mempertahankan ip sumber, bahkan jika itu memerlukan beberapa peretasan.

menggunakan IPVS dengan DNAT

jadi saya berpikir bahwa itu bisa dilakukan dengan MASQUERADE dalam aturan/rantai DNAT. ?

@ port22 Saya mengerti maksud Anda, tetapi buruh pelabuhan mengelola jaringannya sendiri, saya mencoba membuatnya bekerja dengan shorewall, tetapi satu-satunya cara adalah membuat pengecualian untuk aturan/rantai buruh pelabuhan, dan saya tidak berhasil dengan mode gerombolan buruh pelabuhan (tapi itu tidak apa-apa untuk buruh pelabuhan dalam mode swarm, sejauh ini saya menonaktifkan semua layanan tetapi yang menjalankan swarm)
Mungkin harus ada opsi seperti ada untuk jaringan jembatan https://docs.docker.com/network/overlay/#customize -the-docker_gwbridge-interface
jadi untuk membuatnya sederhana untuk setup ini, tapi tetap saja masalah utama adalah dukungan yang hilang di jaringan overlay. Jadi opsi tidak ada, karena itu akan diabaikan, dan dockerd akan menulis ulang aturan jika dimodifikasi dari luar.

Saya telah mengajukan permintaan fitur untuk dukungan protokol proxy untuk menyelesaikan
masalah dalam bug ini.

Kalau-kalau ada yang ingin menambahkan komentar mereka.

https://github.com/moby/moby/issues/39465

Pada Rabu, 10 April 2019, 21:37 Daniele Cruciani, [email protected]
menulis:

@ port22 https://github.com/port22 Saya mengerti maksud Anda, tetapi buruh pelabuhan mengelola
jaringannya sendiri, saya mencoba membuatnya bekerja dengan shorewall, tetapi
satu-satunya cara adalah membuat pengecualian untuk aturan/rantai buruh pelabuhan, dan saya tidak punya
sukses dengan mode swarm buruh pelabuhan (tapi tidak apa-apa untuk buruh pelabuhan dalam mode swarm, as
jauh saya menonaktifkan semua layanan tetapi yang berjalan ke swarm)
Mungkin harus ada opsi seperti ada untuk jaringan jembatan
https://docs.docker.com/network/overlay/#customize -the-docker_gwbridge-interface
jadi untuk membuatnya mudah untuk mengatur ini, tetapi tetap saja masalah utamanya adalah
dukungan yang hilang di jaringan overlay. Jadi pilihan tidak ada, karena
itu akan diabaikan, dan dockerd akan menulis ulang aturan jika dimodifikasi dari
di luar.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526#issuecomment-481754635 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEsUxsVQ7m9uiYbHhNKMMtkhTZV6iTNks5vfgwygaJpZM4Jf2WK
.

Setelah 3 tahun, tidak ada perbaikan?

Saya juga mengalami masalah yang sama tetapi dengan haproxy. Meskipun tidak apa-apa untuk memiliki server proxy dalam mode host dan HA menggunakan keepalive, satu-satunya bagian yang hilang adalah penyeimbangan beban yang menurut saya tidak terlalu menjadi masalah untuk proxy web sederhana. Kecuali jika skrip rumit disertakan atau proxy dan backend tidak berada pada mesin fisik yang sama dan lalu lintas jaringan terlalu tinggi untuk satu NIC dan...

Jadi apakah benar-benar tidak mungkin untuk melihat alamat IP sumber permintaan dari luar Docker Swarm daripada alamat pribadi jaringan overlay internal? Tetap?

@thaJeztah Dapatkah seseorang di tim Docker Inc memperbarui kami tentang status masalah ini. Apakah masih dipertimbangkan dan/atau dikerjakan? Ada ETA? Atau apakah ini sepenuhnya diabaikan sejak integrasi Docker dengan Kubernetes ? Telah dilaporkan hampir 3 tahun yang lalu :/

@thaJeztah https://github.com/thaJeztah Dapatkah seseorang di Docker Inc
tim memperbarui kami tentang status masalah ini. Apakah masih dipertimbangkan?
dan/atau dikerjakan? Ada ETA? Atau apakah ini benar-benar diabaikan sejak Docker
integrasi dengan Kubernetes ? Telah dilaporkan hampir 3 tahun yang lalu :/

Akan sangat bagus untuk mendapatkan pernyataan ini ("tidak akan diperbaiki") sehingga saya dapat sepenuhnya
membenarkan migrasi ke kubernetes. Memalukan.

Terima kasih.

>

Mungkin mereka akan membalas di twitter?

https://twitter.com/suretec/status/1160496779386904576?s=19

ada permintaan peningkatan yang diusulkan yang harus memperbaikinya - https://github.com/moby/moby/issues/39465

silakan tambahkan pemikiran dan komentar Anda di sana

Saya sudah mengomentari masalah itu :-)

Yang ini telah menjadi pemblokir bagi saya selama beberapa waktu. Saya harus melewati alamat IP dan setelah banyak pencarian (wow hampir 3 tahun mencari bersama dengan orang lain di utas ini ...) belum menemukan solusi yang bisa diterapkan dengan swarm.

Saya tidak dapat menggunakan swarm dalam produksi karena masalah ini dan saya menunggu jawaban resmi jika ini dapat ditambahkan atau tidak. Jika ini tidak ditambahkan, alternatif solusi yang diusulkan disambut.

Kami mengalami masalah yang sama menggunakan traefik di belakang haproxy. Saya terkejut melihat ini memiliki 254 komentar sejak 2016.

@Betriebsrat Mengapa tidak mengizinkan traefik menangani permintaan segera? Apakah haproxy benar-benar diperlukan, atau hanya kebiasaan? Jika Anda mengekspos traefik dalam mode host, Anda akan melihat alamat IP klien, dan kemudian semuanya baik-baik saja :)

Saya percaya "solusi" ini disebutkan beberapa kali, tetapi orang-orang terus melewatkannya.

Saya juga tahu itu kadang-kadang bukan pilihan, tetapi saya percaya sebagian besar waktu ini seharusnya mungkin.

@ajardan solusi yang telah saya coba dan tidak layak bagi saya karena saya lebih dari satu Host untuk merespons di frontend. Idealnya saya ingin seluruh kawanan dapat merutekan permintaan. Saya setuju bahwa untuk operasi skala kecil cukup membalik satu layanan ke mode host dan menggunakannya sebagai server penyerapan dapat berfungsi dengan baik.

Menempatkan sesuatu seperti traefik dalam mode Host meniadakan manfaat yang kami coba manfaatkan dari menggunakan swarm meskipun dalam banyak kasus :(

@pattonwebz Mode host dapat diaktifkan untuk layanan yang menjalankan beberapa kontainer di beberapa host, Anda bahkan dapat melakukannya dengan mode=global. Kemudian traefik akan berjalan di semua node swarm Anda dan menerima koneksi ke port tertentu, lalu merutekan permintaan secara internal ke layanan yang perlu melihat koneksi ini.

Saya menggunakan pengaturan ini dengan layanan dalam mode global tetapi terbatas pada node manajer, dan itu berfungsi dengan baik untuk puluhan ribu permintaan/dtk

Saya akan dengan senang hati menjelaskannya jika diperlukan lebih banyak detail.

@pattonwebz @ajardan Saya menggunakan layanan haproxy yang dapat dikonfigurasi untuk semua kasus ini. haproxy hanya menggunakan 2 MB RAM dalam kasus saya. Saya pikir itu diabaikan.

@pattonwebz Selain solusi @ajardan di atas, Anda dapat menjalankan https://hub.docker.com/r/decentralize/swarm-tcp-proxy dalam mode global dengan jaringan host untuk menambahkan dukungan protokol PROXY ke lalu lintas masuk, dan kemudian meneruskannya ke Traefik yang dikonfigurasi untuk memecahkan kode header protokol proxy.

Seharusnya hanya menjadi bendera sebagai bagian dari Docker Swarm, tidak semua ini
solusi berbelit-belit IMHO.

Kami hanya menggunakan haproxy untuk mengelola sertifikat dan membongkar ssl.
Orang-orang terus melewatkan bahwa solusi "berjalan adalah mode host" bukanlah solusi.
Mereka ingin itu bekerja dengan jaringan masuk untuk memanfaatkan penyeimbangan beban buruh pelabuhan.
Seluruh utas pada dasarnya adalah lingkaran 'gunakan hostmode' -> 'tidak mungkin karena "alasan"' yang berlangsung selama 3 tahun sekarang.

Saya akan melihat swarm-tcp-proxy sebagai alternatif yang layak di sini lagi namun melihat hal-hal serupa di masa lalu sesuatu selalu berakhir menjadi kesepakatan bagi saya dengan ide-ide seperti itu.

Di dunia yang sempurna, kawanan saya yang ada (dan bekerja dengan baik dengan pengecualian tidak ada kemampuan untuk mengambil IP klien nyata) hanya akan bekerja dan melewati data IP tanpa memerlukan lapisan layanan tambahan atau lebih banyak proxy melalui proxy.

Orang-orang terus melewatkan bahwa solusi "berjalan adalah mode host" bukanlah solusi.

Ini bukan solusi dengan sendirinya , tetapi dapat digunakan (dan sedang digunakan) dengan sangat sukses sebagai solusi. Anda masih dapat menggunakan penyeimbang beban asli Docker - yang Anda lakukan hanyalah menambahkan lapisan ke tumpukan jaringan host sebelum Anda menekan mesh layanan Docker.

@Betriebsrat traefik dapat melakukan sertifikat dan SSL dengan sangat baik, jadi saya masih tidak yakin mengapa itu diperlukan.

Juga seperti yang disebutkan oleh @matthanley sebelumnya, penyeimbangan beban buruh pelabuhan tidak hilang. Jika Anda tidak menyukai bagaimana traefik menyeimbangkan permintaan Anda di backend, Anda dapat menginstruksikannya untuk menggunakan LB swarm, dan itu hanya akan mengirim permintaan ke layanan VIP, di mana swarm akan menanganinya nanti.

Ini bahkan dapat dikonfigurasi per layanan, jadi Anda cukup fleksibel.

Anda dapat mencoba mengatur server Nginx lain di luar cluster swarm buruh pelabuhan, dan meneruskan permintaan ke layanan swarm. di conf Niginx ini cukup tambahkan header forward. misalnya.
lokasi / {
proxy_pass http://phpestate;

    #Proxy Settings
    proxy_redirect     off;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;

Tampaknya tidak ada solusi untuk mendapatkan ip klien nyata dalam mode kawanan buruh pelabuhan.

Kami melihat masalah yang sama dan mengatasinya dengan menerapkan:
https://github.com/moby/moby/issues/25526#issuecomment -475083415

Ini adalah solusi yang tidak ideal karena kami tidak dapat menjalankan beberapa wadah masuk pada satu simpul (kira mereka sudah global sekarang)

Kesulitannya adalah kesepakatan Docker di TCP/UDP, sementara ini adalah masalah protokol HTTP. Setidaknya saya berharap buruh pelabuhan akan "memalsukan" IP sumber sebagai Host jarak jauh vs memberikan IP internalnya sendiri dari Swarm Mesh ...

Cara termudah adalah dengan menambahkan header untuk IP asli untuk setiap permintaan http.

Benar. Untuk lebih spesifik - sebagai tajuk protokol proxy yang berfungsi pada l4
dan l7 dan diterima oleh perangkat lunak aplikasi yang paling terkenal (serta
penyedia cloud besar).

Saya telah mengajukan bug terpisah untuk itu, yang menautkan beberapa komentar
di atas. Tambahkan ke bug itu jika Anda tertarik

Pada Kamis, 5 September 2019, 18:56 Vladimir, [email protected] menulis:

Cara termudah adalah dengan menambahkan header untuk IP asli untuk setiap
permintaan http.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/25526?email_source=notifications&email_token=AAASYU7APUNJPLZ6AJ6XXMDQIECIJA5CNFSM4CL7MWFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WWW2issued
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAASYU4VZGKUFLL5STZ44GDQIECIJANCNFSM4CL7MWFA
.

Ini 2019 dan ini masih menjadi masalah ?? Itu membuat daftar putih ip di traefik menyebalkan. Saya seharusnya tidak membutuhkan port Host di setiap node.

@kaysond posisi kami adalah menyerah pada Swarm. Kami telah pindah ke AWS dan ECS. Maaf saya tidak dapat memposting sesuatu yang lebih konstruktif tetapi pada akhirnya kami membutuhkan sesuatu yang berhasil; ini bukan satu-satunya bug Swarm utama (atau kurangnya fitur) yang memengaruhi kami dan lainnya yang tidak menerima perbaikan/umpan balik yang jelas selama beberapa tahun terakhir. Paling mengecewakan, tapi ada.

@jmkgreen kami berada di posisi yang sama dan telah menghabiskan 6+ bulan terakhir berpindah dari kawanan buruh pelabuhan ke hal-hal lain karena masalah ini masih berlangsung. Saya telah menghabiskan puluhan jam sendiri dan ratusan jam waktu anggota tim ke dalam ini tanpa pernah menemukan solusi yang dapat diterima. Mengikat ke semua port host benar-benar mengalahkan tujuan LB mengambang kami :(

Apa masalah Anda dengan solusinya? Anda mendeklarasikan layanan Anda pada mode Host + global dan mengatur LB Anda untuk mencapai semua node, itu berfungsi. Karena proxy itu ringan (saya menggunakan nginx karena saya melakukan pembongkaran https dan hal-hal lain), fakta bahwa itu digunakan di setiap server bukanlah masalah, ia menggunakan kurang dari 1% dari sumber daya server. Saya dapat membantu Anda jika Anda menemukan kesalahan selama proses ([email protected]).

Apa masalah Anda dengan solusinya? Anda mendeklarasikan layanan Anda pada mode Host + global dan mengatur LB Anda untuk mencapai semua node, itu berfungsi.

@RemiBou Ketika proxy itu sendiri perlu diperbarui/dimulai ulang, penyeimbang beban eksternal tidak segera mendeteksi pemadaman dan terus mengirim permintaan ke node tempat proxy masih memulai ulang. Jadi ada pemadaman ~ 30 detik tergantung pada konfigurasi LB eksternal.

Juga tidak ada cara di Swarm untuk mengaitkan proses pembaruan layanan untuk memanggil penyeimbang beban eksternal dan mengeluarkan node dari layanan selama pembaruan. Anda juga tidak dapat memicu skrip untuk berjalan di dalam penampung sebelum diperbarui (misalnya, untuk menghapus tanda " i_am_healthy " dan membiarkan LB eksternal mengetahui bahwa skrip tidak berfungsi melalui polling).

Apa masalah Anda dengan solusinya?

Masalah saya adalah bahwa dengan solusi itu tidak mungkin bagi saya untuk menjalankan beberapa layanan yang sama (atau beberapa layanan yang menginginkan port yang sama) pada Host. Itu kebutuhan untuk proyek yang saya kerjakan.

Memang, tetapi tidak bisakah Anda menggunakan layanan proxy yang hanya akan melakukan ini dan kemudian ketika ip ada di dalam swarm. Anda dapat meneruskannya sebagai header http ke layanan Anda yang lain?

Memang, tetapi tidak bisakah Anda menggunakan layanan proxy yang hanya akan melakukan ini dan kemudian ketika ip ada di dalam swarm. Anda dapat meneruskannya sebagai header http ke layanan Anda yang lain?

Ya... dan selama layanan proxy tipis itu tidak perlu dikonfigurasi ulang atau diperbarui, dimungkinkan untuk memperbarui komponen di belakangnya menggunakan Swarm LB untuk menghindari waktu henti.

Seseorang menunjuk https://hub.docker.com/r/decentralize/swarm-tcp-proxy yang menggunakan haproxy untuk menyelesaikannya.

Jenis rasa sakit meskipun. Dan jika Anda harus memperbarui proxy, Anda masih memiliki waktu henti.

@ms1111 Nginx docker image startup dalam beberapa detik, dan jika layanan ini hanya mengelola bagian ini maka Anda tidak perlu sering memperbaruinya. IMHO sisi negatifnya tidak terlalu penting tetapi mungkin berbeda pada kasus Anda

Apa masalah Anda dengan solusinya?

Dalam kasus kami, ini adalah kombinasi dari solusi ini dengan ketidakmampuan untuk mengikat port yang terpapar host ke alamat IP tertentu. Sebagai gantinya, semua layanan internal yang membutuhkan IP pengunjung asli dan mendukung protokol PROXY, port mereka terekspos pada 0.0.0.0 pada host yang kurang optimal.

Satu lagi adalah hit kinerja yang tidak dapat diabaikan ketika Anda memiliki ratusan koneksi baru per detik - semua port yang terbuka sebenarnya adalah aturan DNAT di iptables yang membutuhkan conntrack dan memiliki masalah lain (mencapai k8s juga, tetapi Swarm memiliki ini tingkat NAT tambahan yang membuatnya lebih buruk).

Untuk buruh pelabuhan,

Bangun! Ada masalah yang jelas mengingat berapa banyak orang yang terlibat dalam masalah ini (ada orang lain dengan penyebab yang sama). Yang kami dapatkan hanyalah orang-orang yang berulang-ulang mengatakan bahwa ada solusi, meskipun sudah dijelaskan beberapa kali mengapa solusi itu bukan solusi. Kata "solusi" itu sendiri menunjukkan bahwa itu adalah hal sementara yang akan diselesaikan nanti. Sudah lebih dari 3 tahun sejak masalah dibuat dan selama itu tanggapannya adalah "ada solusi".

Untuk semua pengguna Swarm,

Mari bersikap realistis. Kebenaran yang menyedihkan adalah bahwa tidak ada seorang pun, termasuk Docker, yang benar-benar peduli dengan Swarm. Semua orang pindah ke k8s dan tidak ada investasi "nyata" di Swarm. Proyek ini sedang menunggu kematian, jadi jangan berharap masalah ini akan diperbaiki. Jadilah cerdas dan pindah ke k8s.

Masalah ini tampaknya terlalu lama diabaikan. Tampaknya tidak akan pernah diterapkan. Potong saja ke pengejaran dan gunakan k8s.

@leojonathanoh dapatkah Anda menjelaskan bagaimana tepatnya k8s memecahkan masalah khusus ini :)?

Sederhana: protokol proxy

@ajatkj Seperti yang dikatakan. Atau, jika tidak memungkinkan, maka penyeimbang beban eksternal dan externalTrafficPolicy: Local pada sumber daya Service . Itu saja yang akan saya katakan di sini. Dan saya berhenti berlangganan dari utas.

Mengapa orang berharap bahwa orang lain akan melakukan pekerjaan untuk mereka?

Saya ingin menjadi pahlawan dan mengurus ini, tetapi kenyataannya adalah saya sedang mengerjakan banyak hal lain dan ini tidak berpengaruh pada hari ke hari saya. Apakah ini mempengaruhi hari ke hari Anda? Kami membutuhkan bantuan untuk menyelesaikan masalah ini!

Saya juga telah melihat ini beberapa kali dan sepertinya tidak ada cara untuk membuatnya bekerja dengan IPVS NAT, yang digunakan oleh perutean swarm ajaib.

Saya setuju bahwa k8s jauh lebih fleksibel di sini. Jika itu sesuai dengan kebutuhan Anda, lebih baik gunakan.
Mengeluh bahwa itu tidak diperbaiki dan kemudian mengancam untuk beralih ke k8s benar-benar tidak memiliki tempat di pelacak masalah kami dan umumnya tidak membantu.

Orang-orang membantu dengan pengetahuan yang mereka miliki. Tidak semua memiliki keahlian untuk mengubah kode itu sendiri, jadi mereka membuat masalah seperti ini untuk membantu mencapai konsensus tentang perubahan yang diperlukan.

Tidak ada seorang pun di sini yang berpendapat bahwa Anda secara khusus harus membuat perubahan, tetapi bahkan pada masalah yang dibuka oleh @sandys tentang protokol proxy, tim inti menyetujui perubahan tersebut. Jadi bagaimana seseorang bisa mengerjakan ini jika mereka tidak tahu apakah perubahan itu akan diterima?

Cara terbaik adalah membuat proposal, mis. seperti apa arsitektur yang Anda harapkan setelah pekerjaan selesai. Apa yang dibawanya? Apa yang kita kehilangan?

coba host-mode-networking

Cara terbaik adalah membuat proposal, mis. seperti apa arsitektur yang Anda harapkan setelah pekerjaan selesai. Apa yang dibawanya? Apa yang kita kehilangan?

Sudah selesai di sini: #39465

coba host-mode-networking

Harap baca seluruh utas sebelum berkomentar

"Gunakan protokol proxy", sementara memang menarik tidak menjelaskan apa
perubahan perlu dilakukan pada basis kode.

Mungkin ini pertanyaan yang naif, tetapi mengapa perlu menulis ulang ip sumber untuk memulai? Bukankah lalu lintas akan dikembalikan melalui gateway default antarmuka? Bahkan jika itu datang melalui penyeimbang beban swarm, gateway hanya dapat mengembalikannya melalui penyeimbang beban yang sudah tahu dari mana lalu lintas berasal ...

Mungkin ini pertanyaan yang naif, tetapi mengapa perlu menulis ulang ip sumber untuk memulai? Bukankah lalu lintas akan dikembalikan melalui gateway default antarmuka? Bahkan jika itu datang melalui penyeimbang beban swarm, gateway hanya dapat mengembalikannya melalui penyeimbang beban yang sudah tahu dari mana lalu lintas berasal ...

Penting untuk mengetahui dari IP mana permintaan tersebut berasal. Mungkin pengguna tertentu ingin membatasi ip, dan Anda tidak dapat melakukannya di luar layanan yang sedang berjalan, yaitu traefik tidak tahu isi permintaan yang dapat menentukan pengguna mana yang membuatnya, sehingga tidak dapat mengecualikan beberapa pengguna dan menerima lainnya hanya berdasarkan ip (karena kebijakan dalam contoh ini adalah ip + request-content => allow/disallow).

Atau, lebih sering, hanya untuk koneksi logging. Saya perlu menagih pelanggan untuk penggunaan layanan saya, dan saya perlu memberikan dalam bentuk tabel: waktu permintaan, jumlah sumber daya, IP sumber permintaan. Hampir setiap layanan yang ditagih memberikan laporan semacam ini.

Saya pikir Anda salah memahami pertanyaan saya. Saya mengerti mengapa layanan ingin melihat ip sumber yang sebenarnya. Saya ingin tahu mengapa Docker mengubahnya sebelum sampai ke wadah

Pada 1 November 2019, 01:47, 01:47, Daniele Cruciani [email protected] menulis:

Mungkin ini pertanyaan yang naif, tapi kenapa perlu ditulis ulang
sumber ip untuk memulai? Bukankah lalu lintas akan dikembalikan melalui
gateway default antarmuka lagian? Bahkan jika itu datang melalui swarm load
penyeimbang, gateway hanya dapat mengembalikannya melalui penyeimbang beban yang
sudah tahu dari mana lalu lintas berasal ...

Penting untuk mengetahui dari IP mana permintaan tersebut berasal. Mungkin
pengguna tertentu ingin membatasi ip, dan Anda tidak dapat melakukannya di luar
layanan berjalan, yaitu traefik tidak tahu isi permintaan
yang dapat menentukan pengguna mana yang membuatnya, sehingga tidak dapat mengecualikan beberapa
pengguna dan menerima lainnya hanya berdasarkan ip (karena kebijakan dalam hal ini
contohnya adalah ip + request-content => allow/disallow).

Atau, lebih sering, hanya untuk koneksi logging. Saya perlu menagih pelanggan
untuk penggunaan layanan saya, dan saya perlu menyediakan dalam bentuk tabel: waktu
permintaan, jumlah sumber daya, IP sumber permintaan. Hampir setiap layanan
ditagih memberikan laporan semacam ini.

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/moby/moby/issues/25526#issuecomment -548711563

@kaysond Bukan tempat yang baik untuk bertanya.

Anda pada dasarnya mengajukan dua pertanyaan,

1. Bagaimana IPVS bekerja secara teknis, dan
2. Mengapa libnetwork memilih IPVS untuk memulai

Keduanya sulit dijawab dengan cara yang berbeda.

Saya bertanya-tanya di mana tempat terbaik untuk mengajukan pertanyaan-pertanyaan ini karena saya sekarang sangat tertarik untuk membaca sejarah pilihan-pilihan itu dan bagaimana semuanya bekerja sehingga saya bisa mendapatkan lebih banyak konteks di sini.

@kaysond Bukan tempat yang baik untuk bertanya.

Anda pada dasarnya mengajukan dua pertanyaan,

1. Bagaimana IPVS bekerja secara teknis, dan
2. Mengapa libnetwork memilih IPVS untuk memulai

Keduanya sulit dijawab dengan cara yang berbeda.

perubahan apapun?

Saya telah mengikuti utas ini untuk sementara waktu sekarang karena saya menemukan masalah yang sama, tetapi setelah memutar beberapa wadah whoami di segerombolan di belakang traefik saya melihatnya berfungsi. Masalahnya adalah kami berada di belakang cloudflare dan harus mendapatkan header yang diteruskan CF. (ya kami menggunakan ipvs dan layanan kami direplikasi dalam swarm).

Baru saja mencoba ini lagi dengan:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea838
 Built:             Wed Nov 13 07:29:52 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea838
  Built:            Wed Nov 13 07:28:22 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

dan penulisan buruh pelabuhan berikut:

version: "3.3"

services:

  traefik:
    image: "traefik:v2.0.0-rc3"
    container_name: "traefik"
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.swarmMode=true"
      - "--providers.docker.endpoint=unix:///var/run/docker.sock"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    container_name: "simple-service"
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.whoami.rule=HostRegexp(`{any:.*}`)"
        - "traefik.http.routers.whoami.entrypoints=web"
        - "traefik.http.services.whoami.loadbalancer.server.port=80"

keluaran whoami adalah:

Hostname: 085c373eb06d
IP: 127.0.0.1
IP: 10.0.1.10
IP: 172.19.0.4
RemoteAddr: 10.0.1.11:51888
GET / HTTP/1.1
Host: testserver.nub.local
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 10.0.0.2
X-Forwarded-Host: testserver.nub.local
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ad14e372f6e9
X-Real-Ip: 10.0.0.2

Jadi tidak. itu masih tidak berhasil

Karena penasaran.... dapatkah beberapa pengembang mengarahkan saya ke kode yang mengelola jaringan swarm?

https://github.com/docker/libnetwork

Baru saja mencoba ini lagi dengan:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea838
 Built:             Wed Nov 13 07:29:52 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea838
  Built:            Wed Nov 13 07:28:22 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

dan penulisan buruh pelabuhan berikut:

version: "3.3"

services:

  traefik:
    image: "traefik:v2.0.0-rc3"
    container_name: "traefik"
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.swarmMode=true"
      - "--providers.docker.endpoint=unix:///var/run/docker.sock"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    container_name: "simple-service"
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.whoami.rule=HostRegexp(`{any:.*}`)"
        - "traefik.http.routers.whoami.entrypoints=web"
        - "traefik.http.services.whoami.loadbalancer.server.port=80"

keluaran whoami adalah:

Hostname: 085c373eb06d
IP: 127.0.0.1
IP: 10.0.1.10
IP: 172.19.0.4
RemoteAddr: 10.0.1.11:51888
GET / HTTP/1.1
Host: testserver.nub.local
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 10.0.0.2
X-Forwarded-Host: testserver.nub.local
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ad14e372f6e9
X-Real-Ip: 10.0.0.2

Jadi tidak. itu masih tidak berhasil

Anda dapat menggunakan traefik dengan mode host untuk mendapatkan ip asli

ports:
      - target: 80
        published: 80
        mode: host
      - target: 443
        published: 443
        mode: host

masih dibuka?
2020-05-08

masih dibuka?
2020-05-08

Iya, masih dibuka. Ada masalah arsitektur yang dicatat di utas yang menyoroti mengapa ini tidak dapat diselesaikan semudah yang terlihat di permukaan. Pada titik ini kemungkinan masalah tersebut mungkin tidak dapat diatasi.

Jika Anda perlu mendapatkan IP pengguna nyata maka beberapa alternatif diposting di utas di sini yang mungkin cocok. Mode HOST untuk layanan tampaknya merupakan pendekatan yang paling sederhana tetapi itu tidak cocok untuk beberapa yang membutuhkan skalabilitas pada masing-masing node.

Kami telah berhasil menggunakan protokol PROXY dengan DigitalOcean LB -> Traefik -> Apache container. Kontainer Apache dapat mencatat IP sebenarnya dari pengguna yang mengakses layanan. Secara teoritis harus bekerja selama semua lapisan proxy mendukung protokol PROXY.

https://docs.traefik.io/v1.7/configuration/entrypoints/#proxyprotocol

Layanan Traefik berada di satu jaringan Docker bernama 'ingress', layanan Apache memiliki jaringan stack sendiri tetapi juga merupakan bagian dari jaringan 'ingress' sebagai eksternal.

https://autoize.com/logging-client-ip-addresses-behind-a-proxy-with-docker/

2020 dan masih belum diperbaiki, sungguh merepotkan. sepertinya fitur yang sangat penting

Ini sangat dibutuhkan. Masukan beberapa mode host hanya patch, kadang-kadang perlu untuk menjalankan NGINX di belakang jaringan (tergantung pada penggunaan dan setup). Tolong perbaiki ini.

saya pikir solusi untuk ini dan menjalankan kawanan buruh pelabuhan tanpa mengatur Host adalah dengan mendapatkan IP di sisi klien. mantan. menggunakan js untuk klien web dan seluler dan hanya menerima dari sumber tepercaya. mantan. js -> get ip, backend hanya menerima ips yang menyertakan token pengguna atau lainnya. ip dapat diatur di header dan dienkripsi melalui https. Namun, saya tidak tahu tentang kinerja

@Damidara16 itulah yang tidak ingin kami lakukan. Benar-benar tidak aman untuk melakukan itu. Anda dapat melewatinya sesuka Anda.

Sayangnya ini masih merupakan masalah terbuka, sayangnya ... sepertinya tidak akan segera diperbaiki

Sayangnya ini masih merupakan masalah terbuka, sayangnya ... sepertinya tidak akan segera diperbaiki

Saya pikir itu akan segera ditutup oleh bot. Sejak github meluncurkan fitur ini, banyak bug dapat diabaikan.

Sayangnya ini masih merupakan masalah terbuka, sayangnya ... sepertinya tidak akan segera diperbaiki

Saya pikir itu akan segera ditutup oleh bot. Sejak github meluncurkan fitur ini, banyak bug dapat diabaikan.

Ini adalah fitur terbaik untuk tim perusahaan yang membengkak untuk mendapatkan kendali atas komunitas.

Sangat kecil kemungkinan ini akan diperbaiki. AFAIK semua orang menganggap k8 memenangkan "perlombaan" dan kawanan tidak diperlukan, tetapi saya akan mengatakan keduanya dapat hidup berdampingan dan digunakan dengan benar tergantung pada kebutuhan dan keterampilan tim yang menggunakan ini. RIP kawan :)

Saya menggunakan HAIP yang dikelola, tetapi Anda bisa menggunakan sesuatu yang lain di depan swarm, penyeimbang beban nginx mandiri yang menunjuk ke IP swarm Anda.
https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/

Di swarm Anda, proxy terbalik membutuhkan ini:

server {
        listen 443 ssl proxy_protocol;
        location / {
        proxy_set_header   X-Real-IP $proxy_protocol_addr;  # this is the real IP address 

Jika Anda menjalankan swarm, Anda akan memerlukan load balancer untuk melakukan round-robin permintaan ke swarm Anda (atau sticky, dll).

Sejauh ini, keputusan arsitektural ini mungkin tampak seperti "bagian yang hilang", namun, ini menambah fleksibilitas dengan menyediakan opsi dan menghilangkan kebutuhan untuk menonaktifkan fungsionalitas bawaan untuk menggantinya dengan sesuatu yang lebih sesuai dengan kebutuhan aplikasi.

Saya yakin saya mungkin telah menemukan solusi untuk masalah ini, dengan batasan _current_ bahwa semua replika wadah layanan harus disebarkan ke satu node, misalnya dengan --constraint-add='node.hostname==mynode', atau dengan kumpulan swarm yang masing-masing terdiri dari satu node.

Masalah

Masalah mendasar disebabkan oleh aturan SNAT di tabel iptables nat di namespace ingress_sbox, yang menyebabkan semua permintaan masuk dilihat oleh container memiliki alamat IP node di jaringan ingress (mis. 10.0.0.2, 10.0.0.3, . .., dalam konfigurasi jaringan ingress default), misalnya:

iptables -t nat -A POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j SNAT --to-source 10.0.0.2

Namun, menghapus aturan SNAT ini berarti bahwa sementara wadah masih menerima paket masuk - sekarang berasal dari IP sumber asli - paket keluar yang dikirim kembali ke IP sumber asli dikirim melalui gateway default wadah, yang tidak berada di jaringan masuk yang sama tetapi pada jaringan docker_gwbridge (misalnya 172.31.0.1), dan paket-paket tersebut kemudian hilang.

Solusinya

Jadi solusinya terdiri dari: 1. menghapus (sebenarnya, menghambat) aturan SNAT ini di namespace ingress_sbox; dan 2. membuat aturan perutean kebijakan untuk wadah layanan swarm, yang memaksa paket-paket keluar tersebut kembali ke alamat IP jaringan masuk node yang akan dituju (misalnya 10.0.0.2); 3. mengotomatiskan penambahan aturan perutean kebijakan, sehingga setiap wadah layanan baru segera menginstalnya saat dibuat.

1. Untuk menghambat aturan SNAT, kami membuat aturan sebelumnya di tabel yang mencegah SNAT biasa tercapai:

nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

(Kami melakukannya dengan cara ini, daripada hanya menghapus aturan SNAT yang ada, karena buruh pelabuhan tampaknya membuat ulang aturan SNAT beberapa kali selama proses pembuatan layanan. Pendekatan ini hanya menggantikan aturan itu, yang membuatnya lebih tangguh).

1. Untuk membuat aturan perutean kebijakan container:

docker inspect -f '{{.State.Pid}}' <container-id>
nsenter -n -t $NID bash -c "ip route add table 1 default via 10.0.0.2 && ip rule add from 10.0.0.0/24 lookup 1 priority 32761"

1. Terakhir, dengan menggabungkan yang di atas dengan docker event kita mengotomatiskan proses modifikasi aturan SNAT, dan mengawasi container yang baru dimulai, dan menambahkan aturan perutean kebijakan, melalui skrip ingress-routing-daemon :

#!/bin/bash

# Ingress Routing Daemon
# Copyright © 2020 Struan Bartlett
# --------------------------------------------------------------------
# Permission is hereby granted, free of charge, to any person 
# obtaining a copy of this software and associated documentation files 
# (the "Software"), to deal in the Software without restriction, 
# including without limitation the rights to use, copy, modify, merge, 
# publish, distribute, sublicense, and/or sell copies of the Software, 
# and to permit persons to whom the Software is furnished to do so, 
# subject to the following conditions:
#
# The above copyright notice and this permission notice shall be 
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS 
# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
# SOFTWARE.
# --------------------------------------------------------------------
# Workaround for https://github.com/moby/moby/issues/25526

echo "Ingress Routing Daemon starting ..."

read INGRESS_SUBNET INGRESS_DEFAULT_GATEWAY \
  < <(docker inspect ingress --format '{{(index .IPAM.Config 0).Subnet}} {{index (split (index .Containers "ingress-sbox").IPv4Address "/") 0}}')

echo INGRESS_SUBNET=$INGRESS_SUBNET
echo INGRESS_DEFAULT_GATEWAY=$INGRESS_DEFAULT_GATEWAY

# Add a rule ahead of the ingress network SNAT rule, that will cause the SNAT rule to be skipped.
echo "Adding ingress_sbox iptables nat rule: iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -D POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j ACCEPT; do true; done 2>/dev/null
nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

# Watch for container start events, and configure policy routing rules on each container
# to ensure return path traffic from incoming connections is routed back via the correct interface.
docker events \
  --format '{{.ID}} {{index .Actor.Attributes "com.docker.swarm.service.name"}}' \
  --filter 'event=start' \
  --filter 'type=container' | \
  while read ID SERVICE
  do
    if [ -n "$SERVICE" ]; then

      NID=$(docker inspect -f '{{.State.Pid}}' $ID)
      echo "Container ID=$ID, NID=$NID, SERVICE=$SERVICE started: applying policy route."
      nsenter -n -t $NID bash -c "ip route add table 1 default via $INGRESS_DEFAULT_GATEWAY && ip rule add from $INGRESS_SUBNET lookup 1 priority 32761"
    fi
  done

Sekarang, ketika permintaan tiba di port yang diterbitkan untuk node tunggal, wadahnya akan melihat alamat IP asli dari mesin yang membuat permintaan.

Penggunaan

Jalankan ingress-routing-daemon sebagai root pada _each dan setiap satu_ node swarm Anda _sebelum_ membuat layanan Anda. (Jika layanan Anda sudah dibuat, pastikan Anda menskalakannya ke 0 sebelum menskalakannya kembali ke jumlah replika yang positif.) Daemon akan menginisialisasi iptables, mendeteksi saat buruh pelabuhan membuat wadah baru, dan menerapkan aturan perutean baru ke setiap wadah baru.

Pengujian, kasus penggunaan, dan batasan

Hal di atas telah diuji menggunakan beberapa replika yang dibatasi ke satu node pada layanan yang berjalan pada swarm multi-node.

Itu juga telah diuji menggunakan beberapa node, masing-masing dengan layanan per-node terpisah yang dibatasi untuk node itu, tetapi ini datang dengan batasan bahwa port yang diterbitkan berbeda harus digunakan untuk setiap layanan per-node. Tetap saja itu mungkin berhasil untuk beberapa kasus penggunaan.

Metode ini juga harus bekerja menggunakan banyak node, jika masing-masing dikonfigurasi sebagai satu node dalam kumpulannya sendiri. Ini membawa batasan bahwa kawanan buruh pelabuhan tidak dapat lagi digunakan untuk mendistribusikan kontainer di seluruh node, namun masih ada manfaat administrasi lain dari penggunaan layanan buruh pelabuhan, seperti replika kontainer dan manajemen siklus hidup.

Meningkatkan solusi untuk mengatasi kasus penggunaan lebih lanjut

Dengan pengembangan lebih lanjut, metode ini harus mampu menskalakan ke beberapa node tanpa memerlukan layanan per-node yang terpisah atau memisahkan swarm. Saya dapat memikirkan dua pendekatan yang mungkin: 1. Mengatur Docker, atau daemon yang dipesan lebih dahulu, untuk menghapus semua IP non-lokal dari tabel ipvsadm setiap node. 2. Memperluas aturan routing kebijakan untuk mengakomodasi paket output routing kembali ke node yang benar.

Untuk 1, kita dapat melakukan polling ipvsadm -S -n untuk mencari IP baru yang ditambahkan ke layanan apa pun, memeriksa apakah masing-masing lokal, dan menghapus yang tidak. Ini akan memungkinkan setiap node berfungsi sebagai penyeimbang beban untuk wadahnya sendiri dalam layanan keseluruhan, tetapi tanpa permintaan yang mencapai satu node dapat diteruskan ke yang lain. Ini tentu akan memuaskan kasus penggunaan saya sendiri, di mana kami memiliki penyeimbang beban IPVS kami sendiri yang duduk di depan satu set server, masing-masing menjalankan aplikasi web, yang ingin kami ganti dengan beberapa instance kemas dengan beban seimbang dari aplikasi yang sama , untuk memungkinkan kami meluncurkan pembaruan tanpa kehilangan seluruh server.

Untuk 2, kita dapat menggunakan iptables untuk menetapkan TOS per-node di iptable ingress_sbox setiap node (misalnya ke byte terakhir dari IP jaringan ingress node); kemudian di wadah, atur untuk memetakan nilai TOS ke tanda koneksi, dan kemudian dari tanda koneksi ke tanda firewall untuk paket keluar, dan untuk setiap tanda firewall pilih tabel perutean berbeda yang merutekan paket kembali ke node asal. Aturan untuk ini akan sedikit kikuk, tetapi saya membayangkan harus menskalakan dengan baik hingga 2-16 node.

Saya harap hal di atas berguna. Saya juga akan mencoba (2), dan jika saya membuat kemajuan akan memposting pembaruan lebih lanjut.

Di bawah ini adalah versi perbaikan dari daemon perutean masuk, ingress-routing-daemon-v2 , yang memperluas model aturan perutean kebijakan untuk memungkinkan setiap wadah merutekan kembali paket keluarannya ke simpul yang benar, tanpa memerlukan SNAT.

Model yang ditingkatkan

Selain menghambat aturan SNAT sesuai model sebelumnya, model baru memerlukan aturan iptables di namespace ingress_sbox pada setiap node yang ingin Anda gunakan sebagai titik akhir penyeimbang beban IPVS (jadi biasanya node manajer Anda, atau subset dari itu manager node), yang memberikan nilai TOS per-node ke semua paket yang ditujukan untuk setiap node di jaringan ingress. (Kami menggunakan byte terakhir dari IP jaringan masuknya node.)

Karena nilai TOS disimpan di dalam paket, nilai tersebut dapat dibaca oleh node tujuan tempat permintaan masuk telah diarahkan, dan paket telah dikirim.

Kemudian dalam container pada node tujuan, kami mengatur untuk memetakan nilai TOS pada setiap paket yang masuk ke tanda koneksi, menggunakan nilai yang sama.

Sekarang, karena paket keluar pada koneksi yang sama akan memiliki tanda koneksi yang sama, kami memetakan tanda koneksi pada setiap paket keluar ke tanda firewall, sekali lagi menggunakan nilai yang sama.

Akhirnya, seperangkat aturan perutean kebijakan memilih tabel perutean yang berbeda, yang dirancang untuk merutekan paket keluar kembali ke simpul titik akhir penyeimbang beban yang diperlukan, sesuai dengan nilai tanda firewall.

Sekarang, ketika permintaan klien tiba di port yang diterbitkan untuk setiap node dalam swarm, wadah (baik pada node yang sama dan/atau lainnya) yang menjadi tujuan permintaan tersebut akan melihat alamat IP asli dari klien yang membuat permintaan, dan dapat mengarahkan respons kembali ke node penyeimbang beban asal; yang akan, pada gilirannya, dapat mengarahkan respons kembali ke klien.

Penggunaan

Pengaturan

Hasilkan nilai untuk INGRESS_NODE_GATEWAY_IPS khusus untuk swarm Anda, dengan menjalankan ingress-routing-daemon-v2 sebagai root pada setiap node swarm Anda _yang ingin Anda gunakan sebagai titik akhir load-balancer_ (biasanya hanya manajer Anda node, atau subset dari node manajer Anda), dengan mencatat nilai yang ditampilkan untuk INGRESS_DEFAULT_GATEWAY . Anda hanya perlu melakukan ini sekali, atau setiap kali Anda menambah atau menghapus node. INGRESS_NODE_GATEWAY_IPS akan terlihat seperti 10.0.0.2 10.0.0.3 10.0.0.4 10.0.0.5 (sesuai dengan subnet yang ditentukan untuk jaringan ingress, dan jumlah node).

Menjalankan daemon

Jalankan INGRESS_NODE_GATEWAY_IPS="<Node Ingress IP List>" ingress-routing-daemon-v2 --install sebagai root pada _each dan setiap satu_ node swarm Anda (manajer dan pekerja) _before_ membuat layanan Anda. (Jika layanan Anda sudah dibuat, pastikan Anda menskalakannya ke 0 sebelum menskalakannya kembali ke jumlah replika yang positif.) Daemon akan menginisialisasi iptables, mendeteksi saat buruh pelabuhan membuat wadah baru, dan menerapkan aturan perutean baru ke setiap wadah baru.

Jika Anda perlu membatasi aktivitas daemon ke layanan tertentu, maka ubah [ -n "$SERVICE" ] menjadi [ "$SERVICE" = "myservice" ] .

Menghapus instalan aturan iptables

Jalankan ingress-routing-daemon-v2 --uninstall pada setiap node.

Pengujian

Skrip ingress-routing-daemon-v2 telah diuji dengan 8 replika layanan web yang disebarkan ke swarm empat simpul.

Permintaan Curl untuk layanan, diarahkan ke salah satu IP node titik akhir seimbang beban yang ditentukan, mengembalikan respons yang berhasil, dan pemeriksaan log kontainer menunjukkan bahwa aplikasi melihat permintaan yang masuk berasal dari IP klien Curl.

Keterbatasan

Karena nilai TOS dapat menyimpan angka 8-bit, model ini pada prinsipnya dapat mendukung hingga 256 node titik akhir penyeimbang beban.

Namun karena model mengharuskan setiap wadah diinstal dengan satu aturan mangle iptables + satu aturan perutean kebijakan + satu tabel perutean kebijakan per node titik akhir manajer, mungkin ada beberapa penurunan kinerja karena jumlah node titik akhir tersebut meningkat (walaupun pengalaman menyarankan ini adalah tidak mungkin terlihat dengan <= 16 node titik akhir load-balancer pada perangkat keras modern).

Jika Anda menambahkan node titik akhir load-balancer ke swarm Anda - atau ingin mulai menggunakan node manajer yang ada sebagai titik akhir load-balancer - Anda harus melangkah dengan hati-hati karena kontainer yang ada tidak akan dapat mengarahkan lalu lintas kembali ke node titik akhir yang baru. Coba mulai ulang INGRESS_NODE_GATEWAY_IPS="<Node Ingress IP List>" ingress-routing-daemon-v2 dengan nilai yang diperbarui untuk INGRESS_NODE_GATEWAY_IPS , lalu lakukan pembaruan bergulir dari semua wadah, sebelum menggunakan titik akhir penyeimbang beban yang baru.

Cakupan untuk integrasi Docker asli

Saya tidak terbiasa dengan basis kode Docker, tetapi saya tidak dapat melihat apa pun yang dilakukan ingress-routing-daemon-v2 yang pada prinsipnya tidak dapat diimplementasikan oleh Docker secara asli, tetapi saya akan menyerahkannya kepada tim Docker pertimbangkan, atau sebagai latihan untuk seseorang yang akrab dengan kode Docker.

Skrip daemon v2 perutean masuk

Ini skrip ingress-routing-daemon-v2 .

#!/bin/bash

# Ingress Routing Daemon v2
# Copyright © 2020 Struan Bartlett
# ----------------------------------------------------------------------
# Permission is hereby granted, free of charge, to any person 
# obtaining a copy of this software and associated documentation files 
# (the "Software"), to deal in the Software without restriction, 
# including without limitation the rights to use, copy, modify, merge, 
# publish, distribute, sublicense, and/or sell copies of the Software, 
# and to permit persons to whom the Software is furnished to do so, 
# subject to the following conditions:
#
# The above copyright notice and this permission notice shall be 
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS 
# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
# SOFTWARE.
# ----------------------------------------------------------------------
# Workaround for https://github.com/moby/moby/issues/25526

if [ "$1" = "--install" ]; then
  INSTALL=1
elif [ "$1" = "--uninstall" ]; then
  INSTALL=0
else
  echo "Usage: $0 [--install|--uninstall]"
fi

echo
echo "  Dumping key variables..."

if [ "$INSTALL" = "1" ] && [ -z "$INGRESS_NODE_GATEWAY_IPS" ]; then
  echo "!!! ----------------------------------------------------------------------"
  echo "!!! WARNING: Using default INGRESS_NODE_GATEWAY_IPS"
  echo "!!! Please generate a list by noting the values shown"
  echo "!!! for INGRESS_DEFAULT_GATEWAY on each of your swarm nodes."
  echo "!!!"
  echo "!!! You only have to do this once, or whenever you add or remove nodes."
  echo "!!!"
  echo "!!! Then relaunch using:"
  echo "!!! INGRESS_NODE_GATEWAY_IPS=\"<Node Ingress IP List>\" $0 -x"
  echo "!!! ----------------------------------------------------------------------"
fi

read INGRESS_SUBNET INGRESS_DEFAULT_GATEWAY \
  < <(docker inspect ingress --format '{{(index .IPAM.Config 0).Subnet}} {{index (split (index .Containers "ingress-sbox").IPv4Address "/") 0}}')

echo "  - INGRESS_SUBNET=$INGRESS_SUBNET"
echo "  - INGRESS_DEFAULT_GATEWAY=$INGRESS_DEFAULT_GATEWAY"

# We need the final bytes of the IP addresses on the ingress network of every node
# i.e. We need the final byte of $INGRESS_DEFAULT_GATEWAY for every node in the swarm
# This shouldn't change except when nodes are added or removed from the swarm, so should be reasonably stable.
# You should configure this yourself, but for now let's assume we have 8 nodes with IPs in the INGRESS_SUBNET numbered x.x.x.2 ... x.x.x.9
if [ -z "$INGRESS_NODE_GATEWAY_IPS" ]; then
  INGRESS_NET=$(echo $INGRESS_DEFAULT_GATEWAY | cut -d'.' -f1,2,3)
  INGRESS_NODE_GATEWAY_IPS="$INGRESS_NET.2 $INGRESS_NET.3 $INGRESS_NET.4 $INGRESS_NET.5 $INGRESS_NET.6 $INGRESS_NET.7 $INGRESS_NET.8 $INGRESS_NET.9"
fi

echo "  - INGRESS_NODE_GATEWAY_IPS=\"$INGRESS_NODE_GATEWAY_IPS\""

# Create node ID from INGRESS_DEFAULT_GATEWAY final byte
NODE_ID=$(echo $INGRESS_DEFAULT_GATEWAY | cut -d'.' -f4)
echo "  - NODE_ID=$NODE_ID"

if [ -z "$INSTALL" ]; then
  echo
  echo "Ingress Routing Daemon v2 exiting."
  exit 0
fi

# Add a rule ahead of the ingress network SNAT rule, that will cause the SNAT rule to be skipped.
[ "$INSTALL" = "1" ] && echo "Adding ingress_sbox iptables nat rule: iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -D POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j ACCEPT; do true; done 2>/dev/null
[ "$INSTALL" = "1" ] && nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

# 1. Set TOS to NODE_ID in all outgoing packets to INGRESS_SUBNET
[ "$INSTALL" = "1" ] && echo "Adding ingress_sbox iptables mangle rule: iptables -t mangle -A POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t mangle -D POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff; do true; done 2>/dev/null
[ "$INSTALL" = "1" ] && nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t mangle -A POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff

if [ "$INSTALL" = "0" ]; then
  echo
  echo "Ingress Routing Daemon v2 iptables rules uninstalled, exiting."
  exit 0
fi

echo "Ingress Routing Daemon v2 starting ..."

# Watch for container start events, and configure policy routing rules on each container
# to ensure return path traffic for incoming connections is routed back via the correct interface
# and to the correct node from which the incoming connection was received.
docker events \
  --format '{{.ID}} {{index .Actor.Attributes "com.docker.swarm.service.name"}}' \
  --filter 'event=start' \
  --filter 'type=container' | \
  while read ID SERVICE
  do
    if [ -n "$SERVICE" ]; then

      NID=$(docker inspect -f '{{.State.Pid}}' $ID)
      echo "Container ID=$ID, NID=$NID, SERVICE=$SERVICE started: applying policy routes."

      # 3. Map any connection mark on outgoing traffic to a firewall mark on the individual packets.
      nsenter -n -t $NID iptables -t mangle -A OUTPUT -p tcp -j CONNMARK --restore-mark

      for NODE_IP in $INGRESS_NODE_GATEWAY_IPS
      do
        NODE_ID=$(echo $NODE_IP | cut -d'.' -f4)

    # 2. Map the TOS value on any incoming packets to a connection mark, using the same value.
        nsenter -n -t $NID iptables -t mangle -A PREROUTING -m tos --tos $NODE_ID/0xff -j CONNMARK --set-xmark $NODE_ID/0xffffffff

    # 4. Select the correct routing table to use, according to the firewall mark on the outgoing packet.
        nsenter -n -t $NID ip rule add from $INGRESS_SUBNET fwmark $NODE_ID lookup $NODE_ID prio 32700

    # 5. Route outgoing traffic to the correct node's ingress network IP, according to its firewall mark
    #    (which in turn came from its connection mark, its TOS value, and ultimately its IP).
        nsenter -n -t $NID ip route add table $NODE_ID default via $NODE_IP dev eth0

      done

    fi
  done

Halo @struanb , saya tidak mengerti cara kerja bagian uninstall di skrip v2 Anda, apakah ada yang kurang?

Halo @jrbcart. Saya harap tidak. Sebelum aturan iptables diinstal, Anda akan melihat ada dua while loop yang menghapus aturan yang sudah ada sebelumnya, menggunakan iptables -D . Ini adalah tindakan pengamanan, jika skrip dijalankan dengan --install beberapa kali berturut-turut, tanpa ada panggilan intervensi dengan --uninstall .

Dengan demikian, ketika skrip dipanggil dengan --uninstall, pada saat skrip keluar, aturan tersebut akan dihapus, dan aturan baru belum ditambahkan.

Semoga ini menjawab pertanyaan Anda.

Hai semuanya, saya ingin memberi tahu Anda bahwa saya menemukan perbaikan untuk masalah ini, tanpa menginstal dan mengonfigurasi apa pun selain mendefinisikan konfigurasi NGINX dengan baik. Saya tahu bahwa kita semua telah mencoba pendekatan yang berbeda. Yang ini ditemukan secara tidak sengaja. Sejujurnya, aku sudah menyerah dengan ini sejak lama. Nah, sampai hari ini. Saat saya menerapkan sistem pemantauan, saya bisa mendapatkan IP sumber, IP sumber asli, menggunakan log NGINX, jadi saya mulai men-debug bagaimana mungkin.

Berikut adalah contoh dari jenis log

10.0.0.2 - - [19/Nov/2020:04:56:31 +0000] "GET / HTTP/1.1" 200 58 "-" req_t=0.003 upstream_t=0.004 "<browser-info>" "<source-ip-1,source-ip2,....>"

Catatan: Ada beberapa IP sumber jika Anda menggunakan proxy (yaitu Cloudfare dan lainnya).

Infonya ada di sana, IP asli saya ada di sana. Kemudian, saya meninjau format NGINX logging untuk mengetahui bagaimana keajaiban itu mungkin terjadi, dan saya menemukan ini:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      'req_t=$request_time upstream_t=$upstream_response_time '
                      '"$http_user_agent" "$http_x_forwarded_for"';

Artinya, keajaiban ada di sini -> $http_x_forwarded_for

Setelah ini, saya mengubah header proxy seperti proxy_set_header X-Real-IP $http_x_forwarded_for; .

Dan akhirnya, tes terakhir, menggunakan informasi itu pada proyek NodeJS, di dalam sistem seperti produksi, menggunakan Docker Swarm dengan jaringan overlay, dengan sekitar 4 VM, dan coba tebak, itu berhasil! Saya akhirnya bisa mendapatkan alamat IP yang sebenarnya.

Saya sangat senang karena masalah ini sudah lama dibuka tetapi saya pikir ini adalah jawabannya. Versi yang saya gunakan adalah:

Docker version: 19.03.8
NGINX version: nginx/1.14.2

Saya akan menunggu tanggapan Anda. Saya harap Anda dapat memiliki hasil yang sama seperti saya.

Bersulang!
Sebastian.

PS: Coba ini menggunakan antarmuka jaringan lain, artinya, di luar localhost, karena Anda akan menemukan "-" di log, bukan alamat IP asli Anda. Cobalah untuk mengujinya di sepanjang internet, sepenuhnya di luar jaringan rumah Anda.

Bonus: Saya juga bisa memetakan alamat IP ke geolokasi, menggunakan tabel pencarian, menghitungnya dan meletakkannya di peta, jadi jawabannya ya, ini yang kami cari guys :)

@sebastianfelipe itu klaim besar setelah bertahun-tahun. Anda yakin tidak menggunakan mode host atau solusi lain di utas ini?

@sebastianfelipe itu klaim besar setelah bertahun-tahun. Anda yakin tidak menggunakan mode host atau solusi lain di utas ini?

Saya yakin. Saya tidak menggunakan host jaringan pada semua layanan yang terhubung itu. Saya baru saja menerapkan tumpukan, dengan jaringan overlay di lingkungan seperti produksi, termasuk penyeimbang beban Digital Ocean dan berhasil. Maksudku, aku tidak bisa mengujinya lebih baik dari ini. Apakah 100% nyata.

@sebastianfelipe Saya menduga penyeimbang beban Digital Ocean menambahkan alamat IP pengguna ke header X-Forwarded-For. Ini adalah solusi yang diketahui yang tidak menyelesaikan masalah mengambil IP pengguna dalam mode Docker Swarm mandiri.

@beornf Saya mencoba untuk tidur dan kemudian saya membaca pemberitahuan Anda jadi saya harus bangun dan mencoba pendekatan tanpa penyeimbang beban Digital Ocean dan gagal. Anda benar, Digital Ocean menambahkan keajaiban di sana saat penyeimbang beban ditambahkan. Ini terjadi pada variabel $http_x_forwarded_for . Penyeimbang beban Digital Ocean menambahkan info ke variabel NGINX lain, info yang tidak ditambahkan oleh Docker Swarm secara langsung. Mungkin ini bisa mengarah pada pendekatan "seperti boneka" untuk memiliki solusi nyata untuk setiap kasus. Setidaknya pelanggan Digital Ocean bisa senang mengetahui bagaimana menangani hal ini saat ini.

@beornf @sebastianfelipe Menambahkan konteks, CloudFlare juga menambahkan X-Forwarded-For dan sebagian besar gratis.

@beornf @sebastianfelipe Menambahkan konteks, CloudFlare juga menambahkan X-Forwarded-For dan sebagian besar gratis.

Saya pikir ini bisa bekerja untuk banyak dari kita yang membutuhkan jalan keluar untuk mendapatkan IP asli. Cloudfare dapat disesuaikan sebagai proxy atau hanya DNS saja. Sangat cocok untuk tidak ada pelanggan Digital Ocean. Ini adalah solusi bersih sampai sekarang. Tapi saya setuju dengan @beornf , kami membutuhkan solusi nyata, tanpa bergantung pada Digital Ocean atau Cloudfare untuk menyelesaikannya.

Terima kasih!