In proxybestinging moat de direkte ferbining mislearje litte

Skied it testnetwurk fan de applikaasje fan ’e útgong fan ’e proxy, sadat in net opmurken direkte ferbining in proxybestinging net slagge lykje lit.

In lokale proxy dy’t njonken in applikaasje harket, meitsje gjin netwurk opnij dat tagong fia proxy freget. De applikaasje kin de konfigurearre proxy negearje, direkt ferbine en dochs sukses melde.

Skied it netwurk fan de applikaasje fan ’e útgeande wei fan ’e proxy. Ien op konteners basearre opstelling set de applikaasje allinnich op in yntern netwurk en jout de proxy in twadde útgongnetwurk. Yn in besteande Compose-definysje kinne de netwurkferbinings der sa útsjen:

services:
  app:
    networks: [clients]
  proxy:
    networks: [clients, egress]
networks:
  clients:
    internal: true
  egress: {}

Dit is in netwurkfragmint foar al definiearre tsjinsten. Konfigurearje de goedkarde trochstjoerproxy en de werklike klant fan ’e applikaasje apart. Docker dokumintearret ynterne netwurken as fan bûten isolearre; allinnich de proxy hat yn dizze opstelling it ekstra bûtendoar-netwurk.

Nim in negatyf gefal op sûnder proxygebrûk: it eksterne fersyk fan ’e applikaasje moat mislearje. By in autentisearre HTTP-proxy moat in wegere akkount syn autentikaasjeflater jaan, wylst it akseptearre akkount it doel berikt mei in oerienkommende proxy-observaasje.

Test de tastiene en wegere gefallen fan ’e proxy apart. Hâld de applikaasje fuort fan oare eksterne netwurken en foegje gjin hostnetwurkmode ta dy’t de proxy omslacht. In slagge fersyk is pas nuttich bewiis as de test krekt de bedoelde rûte beskikber stelt.

Relatearre artikelen