Puncte:1

Cea mai bună practică: migrarea mai multor VM și VHosts la Docker

drapel sg

În prezent, am aproximativ 20 de site-uri și aplicații găzduite în AWS EC2. Unele au propriul lor EC2, în timp ce alții partajează un EC2 cu mai multe gazde virtuale pe acel EC2.

Fiecare site este complet separat și nu are legătură cu celălalt. Cele care partajează un EC2 sunt, în general, mult mai mici, cu puțină cerință de trafic/resurse (de unde serverul partajat).

Am, de asemenea, un server EC2 care este folosit pur și simplu pentru a rula sarcini în lot și programate alături de versiunea live a site-ului, pentru a se asigura că site-ul live rămâne accesibil chiar și atunci când sarcinile programate sunt grele.

Doresc să folosesc Docker în întregul meu mediu de dezvoltare > prod pentru o mai bună utilizare a resurselor serverului și migrații mai ușoare între medii etc.

Sunt dornic să vă aflu părerile despre cele mai bune practici pentru hardware-ul serverului de producție.

Este cel mai bine să folosiți un EC2 mai mare și să aveți fiecare site ca propriul container docker acolo? Acest lucru sună a mai puțin administrator de server, o configurare generală mai ordonată și, din câte am înțeles, fiecare container docker încă se păstrează singur din punct de vedere al securității. Dar, orice problemă de server sau vârfuri de resurse ar avea un impact asupra tuturor site-urilor (atenuate de un echilibrator de încărcare).

Sau, sunt cel mai bine să le păstrez împărțite în mai multe EC2, adică pe EC2 per container docker? Acest lucru pare complet împotriva punctului docker, dar nu sunt sigur dacă îmi scapa ceva.

Folosirea unui singur EC2 pentru toate site-urile facilitează apoi (mai puțin administrator) configurarea echilibratoarelor de încărcare și/sau a căderii serverelor.

Notă; dacă face vreo diferență, folosesc RDS pentru MySQL; nici un MySQL care rulează direct pe orice EC2.

Mulțumesc anticipat

Puncte:1
drapel id
MLu

De obicei folosim ECS (serviciu de containere elastice) cu un număr X de sarcini (= site-urile dvs. web) și numărul Y de gazde (= instanțe EC2 pentru rularea acelor sarcini), unde X >= Y. Apoi lăsăm ECS să distribuie sarcinile pe gazde așa cum consideră de cuviință, conform cerințelor. Puteți specifica cantitatea de RAM și puterea procesorului de care are nevoie fiecare sarcină/site web.

Avem și instanțele EC2 într-un Grup de scalare automată - dacă unul dintre ei moare, acesta este înlocuit automat, iar ECS reinstalează automat containerele pierdute și le înregistrează la Load Balancer, totul fără nicio intervenție umană.

De asemenea, este posibil să doriți să rulați unele sarcini în AWS Fargate, care este un serviciu container fără server - mai ales pentru sarcinile/site-urile web mai mari, poate fi o opțiune bună. Pentru sarcini mici, este adesea mai economic să le consolidați pe o singură instanță EC2.

Concluzia este să decupla sarcinile (containere) de gazde - au un grup de site-uri web și nu-ți pasă unde rulează, și au un grup de gazde și nu-ți pasă ce rulează pe ele.Totuși, are nevoie de un anumit nivel de automatizare - doriți ca sarcinile să fie înregistrate automat în grupurile țintă ALB, gazde adăugate automat când rămân fără capacitate / înlocuite dacă mor, etc. Dar această automatizare de bază ar trebui să fie dată oricum.

Sper că te ajută :)

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.