Puncte:0

Cum să obțineți o adresă IP statică pentru cererile de ieșire în AWS?

drapel fr

Suntem într-un proces de integrare și compania solicită adrese IP statice incluse în lista albă. Soluția sugerată de AWS este de a crea noi ECS care utilizează noi subrețele. Este posibil să schimbați subrețele într-un cluster existent? Trebuie să redistribuim totul într-un cluster nou? Deoarece redistribuirea este un proces riscant pentru noi, avem nevoie de o soluție mai ușoară pentru asta.

MLu avatar
drapel id
MLu
Redistribuirea ar trebui să fie automată, nu riscantă. Doar spuneam.
Buse B. avatar
drapel fr
Poti explica mai mult te rog? De fapt, nu lucrăm cu aceeași echipă tehnologică care s-a desfășurat în primul rând, iar echipa actuală ezită să se redistribuie.
drapel ml
După cum spune @MLu, ar trebui să puteți redistribui. Dacă nu, ar trebui să faceți din asta o prioritate pentru a putea. Înțeleg că ar putea exista dependențe externe, dar ar trebui să puteți implementa într-un cont diferit/nou și să verificați dacă totul este bine înainte de redistribuire.
Puncte:0
drapel nl

Probabil că trebuie să fiți mai explicit cu privire la 1) configurația curentă pe care o aveți și 2) care este scopul principal. Pe #1, depinde de ce mod de rețea utilizați (bridge vs VPC). Cu acesta din urmă, un cluster nu este legat de o subrețea/VPC și puteți alege orice doriți (în interiorul aceluiași cluster). Poate fi necesar să redistribuiți sarcinile/serviciile, totuși pentru a le muta. Totuși, nu sunt sigur cum se referă acest lucru la „obținerea unui IP static pentru cererile de ieșire”.Dacă aveți nevoie de un IP de ieșire cunoscut pentru toate sarcinile dvs., ar trebui să configurați un Gateway NAT în subrețeaua privată în care se află sarcinile dvs.

Presupun că problema dvs. este că sarcinile existente sunt pe o subrețea publică cu propriul IP public și trebuie să le mutați într-o subrețea privată cu un GW NAT asociat?

Buse B. avatar
drapel fr
Subrețelele noastre sunt publice, dar problema este că subrețelele nu folosesc NAT Gateway. Soluția sugerată este crearea unei noi subrețele cu un Gateway NAT.Se susține că nu putem schimba subrețele dintr-un cluster existent, așa că trebuie să creăm un nou cluster care să folosească subrețele noi. În acest scenariu, trebuie să redistribuim totul într-un cluster nou. Dar nu sunt sigur că acesta este singurul mod de a face asta.
mreferre avatar
drapel nl
Da, NAT GW nu poate fi atașat la subrețele publice. Pot exista motive pentru care nu puteți adăuga subrețele suplimentare la un VPC existent (ați consumat/configurat deja tot spațiul IP al VPC-ului dvs. etc.). Câteva întrebări: 1) aplicația dvs. este implementată ca serviciu ECS? 2) Are un Load Balancer configurat? 3) Este implementat pe EC2 sau Fargate? Dacă este implementat pe EC2, care este modul de rețea configurat (Bridge sau VPC)?
Buse B. avatar
drapel fr
1) ECS și rețea realizate prin VPC, 2) Load balancer configurat, 3) ECS fargate.
mreferre avatar
drapel nl
Dacă acesta este scenariul, este *posibil* ca prin [crearea unui nou set de sarcini](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-task-set.html) indică un nou VPC și LB și apoi [actualizarea serviciului ECS](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) ar trebui să vă puteți muta sarcinile către subrețele private. În teorie, ați putea face acest lucru fără a recrea clusterul sau chiar serviciul ECS, dar toate sarcinile ar trebui să fie mutate la un nou VPC/LB).

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.