Portál AbcLinuxu, 4. května 2025 23:15
https_proxy='http://server:port' firefox --profile ~/dev_profile https://www.application.com apod.
Zapomněl jsem zmínit, že aplikace vně používá https, ale tls je ukončeno na vstupní bráně a jednotlivé kontejnery používají jen http. To bych pro vývoj řešil vygenerováním vlastní CA a její registraci v příslušném profilu browseru.
Postupně jsem zkoumal různá řešení:
haproxy: používáme ji jako reverzní proxy a umí dělat forward proxy... ale pouze pro http
nginx: v základu to neumí, pouze při přikompilování modulu třetí strany čínské provenience... kompilaci bych se raději vyhnul
squid: má funkcionalitu sql-bump, která vypadá že odpovídá mému požadavku, ale strávil jsem s tím mnoho času a nepřišel jsem na to, jak proxy přimět, aby moduly kontaktovala via http na mnou zadaném portu
Mám pocit, že vynalézám kolo - tohle přece už někdo musel vyřešit a já jen špatně hledám odpověď.
Má někdo z ctěných čtenářů zkušenost s řešením uvedené situace? Děkuji za každou odpověď.
Zapomněl jsem zmínit, že aplikace vně používá https, ale tls je ukončeno na vstupní bráně a jednotlivé kontejnery používají jen http. To bych pro vývoj řešil vygenerováním vlastní CA a její registraci v příslušném profilu browseru.Tím jsem myslel, že jednotlivé moduly aplikce SSL neřeší, pouze při různých přesměrováních apod. generují adresy s protokolem "https", takže browser musí používat https protokol, ale do kontajnerů už musí jít http - čili brána, po jejímž řešení se pídím musí dokázat odbavit https požadavek a převést ho na http a odpověď v http zas převést na https. Čili neřeším problém reverzní proxy se SSL backendem, ale forward proxy se SSL frontendem (i když tím termínem si nejsem jistý) a http backendem. Ještě jednou zjednodušeně:
{user}_{aplikace}_{version}_backoffice někde v mé lokální síti.
Čili neřeším problém reverzní proxy se SSL backendem, ale forward proxy se SSL frontendem (i když tím termínem si nejsem jistý) a http backendem.Heh, ta terminologie se bere z pohledu klienta, nejses klient => 'reverzni proxy'. To je uplne standardni situace. HTTPS klient je terminovany na proxy, ktera predava pozadavky po HTTP na servery a obracene odpovedi zase bali pro klienty do HTTPS.
SERVER1 <-- (http) -- \ SERVER2 <-- (http) -- PROXY <-- (https) -- CLIENT SERVER3 <-- (http) -- /
Komplikace: Nechci provádět kejkle s DNS Nechci z kontejneru vystavit privilegovaný port. Nechci mít v url číslo portu.Jak teda rozlisis jednotlive servery??
https_proxy. Tím docílíš, že když v browseru zadáš https://backoffice.application.com, tak browser místo kontaktování backoffice.application.com metodou GET zavolá ten proxy server metodou CONNECT, čímž si vyžádá vystavění spojení na ten cílový stroj (jeho url je parametrem metody CONNECT. U https se předpokládá, že to bude spojení transparentní, ale pokud serveru squid dáš odpovídající SSL certifikát a klíč, tak ten to spojení dešifruje a umí ho cachovat a přeposlat dál. Žel, dokumentace je v tom směru poněkud nejasná a já neovládám správnou terminologii. Základní popis je https://wiki.squid-cache.org/Features/SslBump, ale hned v úvodu je poznámka This feature was replaced in Squid-3.3 by server-first a následně This feature was replaced in Squid-3.5 by peek-n-splice a protože dostupné návody zpravidla neuvádějí, pro jakou verzi squidu jsou, dost se v tom motám.
Aktuálně mne napadá řešení (které jsem ale ještě neměl čas vyzkoušet):
CLIENT -- http CONNECT --> squid
CLIENT -- https --> squid -- https --> haproxy -- http --> server[1,2,3]
squid je rozliší pomocí parametru metody CONNECT
haproxy je rozliší pomocí hlavičky Host (od verze http 1.1, starší http 1.0 nepodporuju)
squid sám, ale na to já nestačím, tak asi budu muset využít na forward proxy squid a na reverzní proxy haproxy (vím že nginx také umí reverzní proxy, ale já ho prostě nemám rád 
)
nginx by mluvilo jenom to, když by uměl jako cíl reverzní proxy vzít obsah hlavičky Host - to by mi ušetřilo potřeby udržovat mapování té hlavičky na backend - což by v haproxy bylo nutné. Vzhledem k tomu, že v docker síti mohu kontejneru nastavit hostname jaké chci, mohu tam mít klidně backoffice.application.com, api.application.com, www.application.com...
V haproxy je to něco ve smyslu:
frontend application
mode http
bind *:443 ssl crt /etc/haproxy/certs alpn h2,http/1.1
use_backend backoffice if { hdr(host) -i backoffice.application.com }
...
backend backoffice
mode http
server backoffice.application.com:8080
http {
server {
listen 443
location / {
proxy_pass http://$host:8080
}
}
Forward proxy - v browseru nastavíš použitou proxy, nebo mu ji dáš v proměnné prostředí https_proxy.Jako klient se na tohle kazdy vykasle. Nikdo 20 let nenastavuje proxy v prohlizeci a nebude. Neni k tomu zadny duvod a ten MITM je pokus, ktery hadam moderni prohlizec detekuje a zase to bude generovat varovani na strane klienta. Ne. Zadam do prohlizece https://backoffice.application.com a zbytek je tvuj problem, jak to dorucis do cile.
$ mkdir -p ~/browser-profiles/develop
$ firefox --profile ~/browser-profiles/develop
~/browser-profiles/develop a tvé obvyklé instance se nedotknou. Čili pro běžný provoz nikdo proxy používat nemusí, podvržená certifikační autorita mu tam nestraší.
Když to nazvu dev.backoffice.application.com, jak to nasměruju na dockerizovanou instanci? Vývojářská instance poběží na vývojářově počítači, nebo, v případě že nebude vyhovovat hw, na firemním serveru. Musím počítat s během několika instancí zároveň - i kdyby u sebe měl vývojář maximálně jednu, na firemním serveru jich musí být paralelně několik.
Vývojářská instance poběží na vývojářově počítači.A ta proxy taky poběží na vývojářově počítači nebo tu aplikaci bude otevírat do sítě? Přijde mi, že ten přístup problémy spíš přidělává, než řeší. Možná bych to dokázal pochopit, pokud je potřeba HTTPS. Takhle mám pocit, že to je složité řešení toho, že aplikace neumí správně vytvářet odkazy s protokolem a portem, když se změní. Jako vývojář nebudu mít radost z toho, že si aplikaci nedokážu vyzkoušet v jiném prohlížeči nebo z terminálu. Když už, tak bych chtěl mít stejné řešení jako na produkci, kde je předpokládám reverzní proxy. DNS si případně dopíšu do
hosts.
Pokud by ti to pomohlo, ve firefoxu jde nastavit proxy přes Multi-account Containers pro jednotlivé taby. Používám to s SSH tunelem, když se potřebuju připojit z jiné IP adresy.
9.7.2024 20:22
Max | skóre: 72
| blog: Max_Devaine
byl bych rád, kdybych se to dozvěděl od svých kolegů a nadřízených, až je seznámím s prototypemJak jsem jiz psal, konzultujte reseni s Vasimi kolegy a pokud se ukaze, o cem osobne pochybuji, ze je to finalni reseni, muzeme se bavit o konfiguraci. Nicmene podle gitu si hadam poradite sam. Pokdu narazite na nejaky konkretni techciky problem, klidne napiste.
backoffice.application.com interní adresaci backoffice.in.application.com.
CI/CD probíhá odesláním docker images do AWS ECR, kde se spustí příslušné kontejnery v ECS.
Přínos má být v přiblížení vývojářského prostředí produkčnímu. Ideální přiblížení by bylo duplikací produkčního prostředí v AWS pro každého vývojáře, ale pro 25 vývojářů, z nichž by každý potřeboval v průměru 2 instance to leze do peněz. Nehledě na nepružnost vývoje, když je třeba po každé změně nasazovat upravený image.
Dosavadní vývoj probíhal na společném vývojářském serveru uzpůsobeném pro všechny moduly (php/c++/typescript), ale tenhle dvacet let starý přístup už je dnes neudržitelný.
9.7.2024 20:20
Max | skóre: 72
| blog: Max_Devaine
{user}.interni.domena.com/{aplikace}/{instance}/{modul}/, na produkci pak {modul}.produkcni-domena.com.
Frontend pro vývoj naslouchá na interni.domena.com:{fe-port}, produkce na {zakaznik}.produkcni-domena.com.
C++ modul pro vývoj naslouchá na interni.domena.com:{c-port}, ale nikdo k němu napřímo nepřistupuje - pouze přes php interface.
Po dockerizaci vývoje to vypadá tak, že se ke každému modulu bude přistupovat přes interni.domena.com:{module-port}, což pro frontend není žádná změna, ale pro ostatní to znamená údržbu seznamu víc jak deseti čísel portů. Tohle je obecně používaný postup?
https_proxy=http://${HOSTNAME}:3128 curl https://api.in.application.com/api/auth/get_token
nginx: v základu to neumíJestli jsem to tedy pochopil správně, tak to má být - zvenku na nginx https, z nginxu na kontejner http. To nginx zvádá.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.