Puncte:1

Cum să direcționați traficul către serviciul Compute sau Cloud Run pe baza adresei URL

drapel jp

În prezent, avem o aplicație web care rulează pe o VM Compute și lucrăm la migrarea treptată a acesteia la Cloud Run. (O facem treptat, deoarece backend-ul actual este în PHP și îl rescriem în Go, câte un punct final)

Site-ul nostru este accesat în prezent la, de exemplu:
https://www.myapp.com
și API la:
https://www.myapp.com/books

Planul nostru este ca noua API Cloud Run/Go să fie accesibilă fie pe calea „v2”:
https://www.myapp.com/v2/books
sau pe un subdomeniu
https://v2.myapp.com/books
și apoi decideți ce API să utilizați în client în funcție de ceea ce s-a terminat de migrat.

Mă întrebam ce modalitate bună de a face asta ar fi.

Lucruri pe care le-am luat în considerare (ca începător GCP)

  • Avem deja nginx care rulează pe VM Compute, așa că configurați un proxy invers pentru https://www.myapp.com/v2 Mi s-a părut o idee bună la început, dar se pare că în prezent nu există nicio modalitate de a accesa Cloud Run de la Compute prin IP privată, așa că cererea ar trebui să treacă pe internet, încetinind lucrurile (de asemenea, nu sunt sigur dacă reverse proxy la un extern URL-ul ar cauza probleme cu autentificarea etc.?)

  • Cu https://v2.myapp.com/books opțiunea, se pare că maparea domeniilor personalizate pentru Cloud Run este încă în versiune de previzualizare așa că ezit să-l folosesc într-un sistem de producție, de asemenea, în mod ideal, am dori să folosim propriul nostru certificat SSL care nu pare să fie acceptat.

  • Opțiunea de găzduire Firebase pare că ar fi puțin complicată și are, de asemenea, un timeout de solicitare de 60 de secunde, care este prea scurt pentru unele dintre încărcările video etc. pe care le primim.

  • Echilibratorul de încărcare la un NEG ar adăuga un pic mai multă complexitate/cost, dar aceasta pare să fie cealaltă opțiune. Se pare că NEG-urile fără server nu se pot conecta la Compute și NEG-urile VM gestionate nu se pot conecta la Cloud Run, așa că aș avea nevoie de unul din fiecare în acest caz?

Goli Nikitha avatar
drapel ng
Consultați această [documentație](https://cloud.google.com/run/docs/configuring/connecting-vpc) pentru utilizarea cloud run și a unui IP privat GCE (motor de calcul) prin VPC partajat.
Puncte:0
drapel br

Comentează mai jos toate cele 4 opțiuni pe care le-ai menționat

  • Avem deja nginx care rulează pe VM Compute, așa că configurați un proxy invers pentru https://www.myapp.com/v2 părea o idee bună la în primul rând, dar se pare că în prezent nu există nicio modalitate de a accesa Cloud Rulați de pe Compute prin IP privată, astfel încât solicitarea să fie eliminată pe internet încetinind lucrurile (de asemenea, nu sunt sigur dacă invers proxy către o adresă URL externă ar cauza probleme cu autentificarea etc?)

Acest lucru este corect din punct de vedere tehnic, puteți configura un serviciu Cloud Run pentru a accepta numai trafic de la VPC (acesta se numește Opțiuni de intrare, puteți citi despre el în documentul aici [1]). Și atunci când o faci, serviciul tău Cloud Run va continua să fie difuzat pe ceea ce pare a fi o adresă URL publică (cea generată atunci când implementezi serviciul).Dar acea adresă URL este accesibilă doar din VPC și chiar dacă se pare că clientul va efectua un apel către un serviciu de internet, acel trafic rămâne în rețeaua noastră și nu părăsește niciodată coloana vertebrală, așa că din punct de vedere tehnic, acest lucru nu ar trebui să adauge latență.

  • Cu https://v2.myapp.com/books opțiunea, se pare că cartografierea domeniile personalizate pentru Cloud Run sunt încă în versiunea de previzualizare, așa că sunt ezită să-l folosim într-un sistem de producție, de asemenea, în mod ideal, am face-o ne place să folosim propriul nostru certificat SSL, care nu pare să fie sprijinit.

Nu aș recomanda utilizarea unei funcții de previzualizare în producție, există riscul ca funcția să se schimbe într-un mod incompatibil cu înapoi. Pe tema folosirii propriilor certificate SSL, puteți implementa un LoadBalancer HTTP în fața serviciului dvs. Cloud Run (care este setat să fie privat) și puteți personaliza LoadBalancer-ul pentru a se potrivi nevoilor dvs.

  • Opțiunea de găzduire Firebase pare că ar fi puțin complicată și are, de asemenea, un timeout de solicitare de 60 de secunde, care este prea scurt pentru unele dintre ele încărcările video etc. pe care le primim.

Nu sunt foarte familiarizat cu Firebase.

  • Echilibratorul de încărcare la un NEG ar adăuga puțin mai multă complexitate/cost, dar asta pare a fi cealaltă variantă. Se pare că NEG-urile fără server nu pot conectați-vă la Compute și NEG-urile VM gestionate nu se pot conecta la Cloud Run, așa că as avea nevoie de cate unul din fiecare in acest caz?

Opțiunea LoadBalancer pare complicată, dar chiar nu este, poți folosi ceva de genul Terraform pentru a furniza LoadBalancer, trebuie să o faci o singură dată

Sper că acest lucru vă ajută să umbriți opțiunile dvs [1] https://cloud.google.com/run/docs/securing/ingress

jezjez avatar
drapel jp
Vă mulțumesc pentru răspuns, este bine de știut ideea dvs. despre efectuarea de apeluri pe internet, am presupus că acest lucru ar încetini foarte mult lucrurile, dar dacă nu, cred că am putea alege această opțiune. Voi arunca o privire mai mult în Load balancer și Terraform, de asemenea

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.