Rodzina apliakcji web typu "Embedded jetty"

0
  1. Rodzina aplikacji webowych, historycznie kiedyś WAR, zgodnie z nową tendencją FatJAR na embedded Jetty

Jednak "stare" miało te zaletę, że było serwowane z jednego adresu, jednego portu. Rodzaj intranetu. Jakieś NAT na roterze, jakieś firewalle, te klimaty.
Czy da się i jak, aby było znów jak dawniej, z jednego adresu i portu ?

  1. Apliakcje choć niezależne technicznie, tworzą biznesowo pewnego rodzaju komplet. Apki serverside. Tu nie jest pytanie czy się da, tylko czy macie jakieś tricki, żeby gdy wyświetla się apka A, miała wiedzę co wyświetlić w menu głównym z apki B (tylko menu głowne, zestaw par Caption String, URL). Ma się samo aktualizować po aktualizacji C, albo wgraniu nieistniejącego wcześniej D. Jakiś fajny wzorzec koordynarora, czegoś podobnego?
0

HAProxy do tego nie służy? Chociaż ono dynamicznie nie doda chyba przekierowań, trzeba wbić je na sztywno?

0 
Hystrix, Netflix Eureka, JHipster, load balancer, Service Mesh, Kubernetes

Jakiś buzzword z powyższych może by pomógł?

0
AnyKtokolwiek napisał(a):
  1. Rodzina aplikacji webowych, historycznie kiedyś WAR, zgodnie z nową tendencją FatJAR na embedded Jetty

Jednak "stare" miało te zaletę, że było serwowane z jednego adresu, jednego portu. Rodzaj intranetu. Jakieś NAT na roterze, jakieś firewalle, te klimaty.
Czy da się i jak, aby było znów jak dawniej, z jednego adresu i portu ?

Jedyna różnica była taka, że aplikacja nie wystawiała portu (tak jak cały zdrowy świat) tylko używała platformy (serwera aplikacyjnego) do którego pisało się kod w formie pluginów (servletów). Czyli takie odwrócenie zależności. Cała reszta, którą napisałeś to jakieś majaki z których ciężko wyłuskać coś co ma sens

  1. Apliakcje choć niezależne technicznie, tworzą biznesowo pewnego rodzaju komplet. Apki serverside. Tu nie jest pytanie czy się da, tylko czy macie jakieś tricki, żeby gdy wyświetla się apka A, miała wiedzę co wyświetlić w menu głównym z apki B (tylko menu głowne, zestaw par Caption String, URL). Ma się samo aktualizować po aktualizacji C, albo wgraniu nieistniejącego wcześniej D. Jakiś fajny wzorzec koordynarora, czegoś podobnego?

Dalej, czym są apki serverside?

0

Pierwszego akapitu o majakach nie skomentuję

@AnyKtokolwiek: po prostu nie wiem co ma sposób odpalania aplikacji standalone w porównaniu do takiego JavaEE *.war. Tak czy owak na koniec jest wystawiony jeden port

Te które nie są ClientSide czyli frameworki javascriptowe

@AnyKtokolwiek: to co przychodzi do głowy to jakaś modularyzacja. Masz wspólny moduł na wspólne rzeczy i potem ich używasz w apkach A i B

0
KamilAdam napisał(a):

HAProxy do tego nie służy? Chociaż ono dynamicznie nie doda chyba przekierowań, trzeba wbić je na sztywno?

Właśnie, coś pomiedzy Proxy a Load balancer TYLKO. Już czytam w drugim oknie.

To drobne "tylko" to dostarczenie informacji że
http:///somewhere/invoices proszę do mnie (aplikacja A)
gdy
http:///somewhere/dayplan do mnie (aplikacja B)

Czyli coś, co kontener WAR-ów robi z mocy ustawy

W rynku .NET jak przeszłi z IIS który był samodzielnym kontenerem apliakcji (po naszemu, chyba nikt tego slowa nie użył) na Kestrel "jakoś" zalecane są "reverse proxy", ale nigdy nie byłem pazurami w tych okolicach.

1
AnyKtokolwiek napisał(a):
slsy napisał(a):

Pierwszego akapitu o majakach nie skomentuję

@AnyKtokolwiek: po prostu nie wiem co ma sposób odpalania aplikacji standalone w porównaniu do takiego JavaEE *.war. Tak czy owak na koniec jest wystawiony jeden port

W kontenerze WAR-ów mogło być tych WARów więcej (aka modułów, funkcjonalności, aplikacji), nadal na jednym porcie, różniących się elementami URL-a.
Gdy każda aplikacja (moduł) jest zbundlowana z własnym egzemplarzem np Embedded Jetty, każda musi miec inny

1

Rozumiem, że twoja sytuacja jest taka:

  1. Miałeś kiedyś jeden serwer aplikacji, na którym leżało wiele WARów.
  2. W końcu ktoś podjął decyzję o przerzuceniu tych aplikacji na standalone, w tym konkretnym przypadku - każdy WAR będzie oddzielną aplikacją.

W największym skrócie: nie da się tego łatwo ogarnąć bo wcześniej wszystkie WARy leżały na jednym JVMie - co pozwalało JVMowi zarządzać ruchem sieciowym. Teraz masz podejście jeden JVM - jeden WAR, co oznacza, że będą one się gryźć jeśli spróbujesz odpalić nasłuchiwanie na danym porcie.

  1. Tak jak zasugerował @KamilAdam postawić jakiegoś load balancera (niekoniecznie HAproxy, tak naprawdę każdy się nada), który będzie odpowiednio kierował ruch. Idealnie też by było, żebyś zablokował ruch zewnętrzny przez wszystko co nie jest load balancerem, tj. jeśli twoja konfiguracja wygląda tak:

To ruch powinien tylko przechodzić przez http://myhost:8080. Cała reszta powinna być blokowana.

  1. Ewentualnie przepisać te WARy tak, żeby istniał jeden WAR. Nie polecam, ale może rozwiąże to twoje problemy.
1

ad 1.
generalnie jak to działa na jakimś kubernetes to -> ingres
jak bawisz się reczie to jak napisali proxy/load balancer (ja to wrzucam pod reverse proxy apache)
ad 2.
nie wiem, ale podobne rzeczy trzyma się w Zookeeper - taki rejestr

0
AnyKtokolwiek napisał(a):

W kontenerze WAR-ów mogło być tych WARów więcej (aka modułów, funkcjonalności, aplikacji), nadal na jednym porcie, różniących się elementami URL-a.
Gdy każda aplikacja (moduł) jest zbundlowana z własnym egzemplarzem np Embedded Jetty, każda musi miec inny

To napisz aplikację w taki sposób, że nie jest to problem tj. część odpowiedzialna za definicję serwera HTTP jest odzielna od funkcji main.
Ewentualnie, jeśli to absolutny wymóg (co jest często prawdą w przypadku odzielnnych serwisów) to trzeba użyć jakiegoś reverse proxy. NGINX, envoy, jakieś load balancery w cloudzie

0
slsy napisał(a):

To napisz aplikację w taki sposób, że nie jest to problem tj. część odpowiedzialna za definicję serwera HTTP jest odzielna od funkcji main.

A dokładnie, myślimy nad relacją kernel-plugin, ale to etap kartek i kaw, do "proda" daleko

Ewentualnie, jeśli to absolutny wymóg (co jest często prawdą w przypadku odzielnnych serwisów) to trzeba użyć jakiegoś reverse proxy. NGINX, envoy, jakieś load balancery w cloudzie

Tak, wziąłem się za zgłębianie zwł. koncepcji reverse proxy, byc może w implementacji Apache za @jarekr000000
W pierwszym impulsie się brzydziłem "eeee natywne", ale w sumie w "gospodarstwo" będzie można wpuścić zupełnie inne języki niż JVM

1

Gotowe rozwiązania to tak jak nginx, apache itp.

A tak od ręki to masz tak, jakiś adres URL, ten adres jest tłumaczony na adres IP.

Robisz serwer mówi się na to proxy*, tam pod tym ip i http usłudze, odczytujesz request, patrzysz GET/UPDATE/POST URL HTTP/1.1 i masz przykładowo GET 4program.net to parsujesz i jak widzisz, że jest taki i taki url, to albo odpalasz jakąś aplikację i wynik odsyłasz też jako http request, albo robisz kolejny request, ale do innego serwisu i jak ten serwis ci odpisze, to odsyłasz do tego adresu co do ciebie pisał.

I tyle pod jednym adresem IP masz mnóstwo serwisów, mogą mieć dns adresy, które istnieją już, ale po prostu twój serwer proxy po swojemu je zakwalifikuje.

Ręcznie takie proxy napisać to jest kwestia 15minut.
Najprostsze proxy to nic nie parsujesz nagłówków tylko przesyłasz do serwera jakie dostałeś i jakie otrzymasz odsyłasz z powrotem do clienta.

Ale oczywiście tobie chodzi, żeby przy requestach pod dany url odsyłać do innego kontenera dockera lub pod inny serwer w sieci lokalnej lub odpalić inną aplikację lokalnie/inny algorytm i jego wynik odesłać.

1
nightm4re napisał(a):

Ręcznie takie proxy napisać to jest kwestia 15minut.

Zapraszam :-)
Ale serio - to jest idealne miejsce, gdzie widać jak proste wymagania funkcjonalne zderzają się z morzem pozafunkcjonalnych:
protokoły HTTP 1.x./2.x HTTPS,Sockety, obsługa błędów, timeouty, odporność na DoS, wysokie obciążenie, obsługa długich połączeń, obsługa dużych requestów/response, respektowanie Cache, i tony porypanych nagłówków HTTP ->
ogólnie piękna miazga.

1 użytkowników online, w tym zalogowanych: 0, gości: 1