Dotaz: Vstupní brána do dockeru pro vývoj

[srbt]

Dobrý den,

mám aplikaci sestávající z několika modulů běžících každý v samostatném kontejneru, které spolu navzájem komunikují a na které se potřebuji připojit browserem. Navíc bych rád, aby takových sad mohlo běžet několik najednou nezávisle na sobě.

Myšlenka je ta, že pro každou vytvořím samostatnou "docker network", ve které každý modul dostane stejné hostname, jako bude mít na produkci a modul v něm poběží vždy na stejném neprivilegovaném portu (aby to nemuselo běžet pod rootem). Browser by se připojoval z vně té sítě k jednomu kontejneru, který by vystavil port, opět neprivilegovaný a pro každou sadu kontejnerů jiný.

Abych v browseru nemusel zadávat číslo portu, použil bych funkcionalitu proxy - prohlížeč by se pak pouštěl:

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ěď.

Odpovědi

[X]

Nebylo by jednodzsi nepouzivat SSL na strane aplikace, ale predsunout SSL az na reverzni proxy vrstvu? Jinak receno, potrebujes komunikaci na backend v SSL? Mimochodem, pokud se nepletu, nginx reverzni proxy s SSL backendem umi, takze asi netusim co resis za problem.

[srbt]

Asi jsem se vyjádřil nepřesně:

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ě:

• Do browseru zadám "https://backoffice.application.com"
• Dostanu stránku, kterou vygeneruje nodejs naslouchající protokolem http na portu 8080 v kontejneru {user}_{aplikace}_{version}_backoffice někde v mé lokální síti.

Komplikace:

• Nechci provádět kejkle s DNS
• Nechci z kontejneru vystavit privilegovaný port.
• Nechci mít v url číslo portu.

[X]

Č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??

[X]

Dodavam, ze infrastruktura za proxy je porad tvoje => bezne ma server v URL port kterym se identifikuje na proxy(8000,8001,8802...) a na klienta to uz jde ciste a obalene do SSL. Takto se provadi napriklad load balance na nejaky cluster.

[srbt]

Kdepak, pořád si nerozumíme.

Forward proxy - v browseru nastavíš použitou proxy, nebo mu ji dáš v proměnné prostředí 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]

Čili abych zodpověděl, jak rozliším jednotlivé servery:

• squid je rozliší pomocí parametru metody CONNECT
• haproxy je rozliší pomocí hlavičky Host (od verze http 1.1, starší http 1.0 nepodporuju)

Původně jsem doufal, že to vše zvládne 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 )

[srbt]

Pro 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

V nginxu by to asi bylo (ovšem nemám ověřené, že tam projde ta proměnná $host a že nebudu muset nastavovat resolvera, prostě nginx není můj denní chleba):

http {
  server {
    listen 443
    location / {
       proxy_pass http://$host:8080
    }
}

[X]

Ja tomu rozumim, ale nerozumim duvodu proc to takto stavis.

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.

[srbt]

Jde o instalaci pro vývoj (ne pro klienty), která má být co nejpodobnější produkci - produkční backoffice poběží na adrese backoffice.application.com (to je pochopitelně jen smyšlená doména pro tuto konverzaci), tak chci, aby i vývojář mohl ke své instalaci přistoupit stejnou adresou. Vývojář si proxy v prohlížeči nastavovat nemusí, stačí když ke spuštění browseru použije script, který mu dodám a který tu proxy nastaví přes proměnné prostředí. Ten MITM pokus se projeví tak, že vývojář bude muset na počátku importovat vygenerovanou certifikační autoritu - proto script pustí prohlížeč v samostatném profilu, aby to vývojáři nezaprasilo jeho běžný prohlížeč. Je tu riziko záměny okna browseru pro vývoj a běžného, ale tomu bych předešel tím, že vývojářský backoffice, frontend atd. mají jinou barvu.

[X]

Co kdyz si vyvojar bude chtit zobrazit produkci? Pritom by stacilo nazvat vyvojove prostredi dev.backoffice.application.com a nemusis delat vubec nic. Zadne barvy, zadne proxy, zadne certifikaty. Podsunes proxy => ostatni web vyvojare pujde cely pres proxy? No offence, ale zkusil jsi se zeptat tech vyvojaru co by jim vyhovovalo? To co vytvaris neni z meho pohledu bezna praxe a proto se tezko hledat reseni.

[srbt]

Když bude chtít vývojář zobrazit produkci, použije svůj obvyklý profil browseru.

Když spustíš browser (např. firefox, ale předpokládám, že ostatní to mají podobně) třeba takhle:

$ mkdir -p ~/browser-profiles/develop
$ firefox --profile ~/browser-profiles/develop

tak se všechna data a nastavení té instance prohlížeče uloží do adresáře ~/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.

[tttttttttttt]

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.

[srbt]

Ta proxy poběží na vývojářově počítači, nebo na vývojářském serveru - bude dělat vstupní bránu do docker sítě, ve které budou moduly aplikace. Řešení ke kterému jsem zatím dospěl je tady: https://github.com/srbt/developers-gateway/tree/readme , jen se mi k němu nedaří napsat správné readme, protože nejsem dobrý v angličtině. Řešení nakonec kombinuje squid a nginx - doufal jsem, že bude stačit jeden z těchto nástrojů a zvládne obě funkce, ale nepodařilo se mi to ohnout a asi by to nebylo dobře.

[X]

Kdys si to budu chtit pustit lokalne budu taky potrebovat squid? Podle ceho poznam jestli jsem na produkci nebo nejsem? Jak u toho probiha CI/CD? Porad ve forward proxy nevidim zadny prinos.

[X]

Jeste bych doplnil, ze tohle je ukazka dnesniho 'DevOps', kdy si z nedostatku lidi hraje programator na spravce a vytvari infrastrukturu o ktere si mysli, ze bude vyhovovat. Dalsi jednorzec, ktereho nechces zdedit. Bez urazky, ale ty nechces zadnou radu, ty si jsem prisel hledat nekoho kdo se do tech "sracek" namoci s tebou..

[srbt]

Bez urážky, ano, nechci radu - chtěl jsem odpověď od někoho, kdo má větší zkušenosti se squidem (nebo haproxy, nebo nginxem) než já, aby mi poradil, jak mohu vyřešit problém, který jsem popsal.

Bez urážky, místo toho jsem dostal řadu doplňujících otázek, na které šlo většinou odpovědět citací z mého úvodního dotazu, ale napsal jsem, že děkuji za každou odpověď, tak poctivě odpovídám a vysvětluji.

Bez urážky, výsledkem je to, že jsem se dozvěděl, že podle vašeho názoru je mé řešení nesmyslné a zbytečné. Nepopírám, že to je možné - ale pokud ano, byl bych rád, kdybych se to dozvěděl od svých kolegů a nadřízených, až je seznámím s prototypem. Zatím jde o můj soukromý výzkum, řekněme sebevzdělání.

Bez urážky, podle dosavadní komunikace to vypadá, že o konfiguraci forward proxy a reverzní proxy moc nevíte, zato oplýváte psychoanaytickými schopnostmi, které vám umožňují diagnostikovat mé úmysly, které jsem se snažil zamaskovat pod rouškou žádosti o radu.

(omlouvám se, že jsem sklouzl do vykání - není to nic osobního, jen je to můj obvyklý způsob komunikace s lidmi, které neznám)

[Max]

Já se taktéž přikláním na stranu pana X. Přijde mi to též nesmyslné. Říkám to jako někdo, kde 30 devíků vyvíjí (interní vývojáři, externí atd.), jedeme z velké části on-prem (k8s nad RKE, CI/CD v on-prem Gitlabu, lokální gitlab runnery apod.).
Zdar Max

[X]

byl bych rád, kdybych se to dozvěděl od svých kolegů a nadřízených, až je seznámím s prototypem

Jak 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.

[srbt]

Když si to budu chtít pustit lokálně, budu mít připravenou konfiguraci dockeru (třeba v docker compose), která mi nahodí požadované moduly aplikace i ty moduly proxy, které jsou tam navíc (aktuálně squid a nginx).

Že jsem na vývojové instalaci poznám podle grafiky aplikace - už teď provozujeme preprod prostředí, které má jiné barevné schéma a v rohu velký červený nápis "TESTING". Navíc jsem v řešení ustoupil od původního předpokladu, že to bude na produkční doméně a použil jsem místo 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ý.

[Max]

Nějak jsem nepochopil, co to znamená "po každé změně nasazovat upravený image". Však globální konfigurace je stejná pro všechny prostředí a záleží jen na tom, do jakého se dělá deploy a podle toho se dynamicky načtou proměnné. Nebo vy máte pro každé prostředí sólo konfiguraci?

Jinak my máme 4 prostředí (dev, test, uat, prod) s tím, že vývojář má možnost si spustit app i lokálně (db už moc ne, bo pak náročnost roste).
Zdar Max

[srbt]

Větou "po každé změně nasazovat upravený image" jsem myslel případ, kdy by každý vývojář měl v AWS stejnou infrastrukturu, jako je produkce a neměl možnost spustit aplikaci lokálně. Pak by musel při každé změně zdrojáků udělat nový deploy - jistě, pouze konkrétního modulu a pouze změněné vrstvy, ale pořád je to pomalejší než jen reload browseru v případě php a typescriptu (v případě c++ je tu ještě kompilace, ale i tak by byla režie dost velká).

Děkuji za informaci o vašich prostředích, můžete více rozvést, jak spouštíte aplikaci lokálně a jak k ní vývojář během vývoje přistupuje?

[srbt]

Škoda že neodpovídáte, takhle se mi dostalo dvou upozornění, že navrhuju špatné řešení, ale žádné informace, jak se to dělá správně.

Předpokládám, že vám připadám umanutý a debata se mnou k ničemu nevede. Zkusím to z jiné strany. Dosud jsme aplikaci vyvíjeli na serveru s httpd pro php, nodejs pro frontend a gcc pro c++.

Php moduly jsou pro vývoj dostupné pod adresou {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?

[srbt]

Můžeš si aplikaci vyzkoušet kdekoliv, třeba z curl v terminálu, jen nastavíš proměnnou `https_proxy`na adresu toho vstupního bodu.

Např.:

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á.

[srbt]

Ne ne, jde o tohle: https://www.alibabacloud.com/blog/how-to-use-nginx-as-an-https-forward-proxy-server_595799