Përshëndetje të gjithëve! Unë quhem Kirill, jam CTO në Adapty. Pjesa më e madhe e arkitekturës sonë ndodhet në AWS, dhe sot do të flas për se si e kemi zvogëluar shpenzimin për servera me 3 herë duke përdorur instancat spot në mjedisin e prodhimit, si dhe për mënyrën se si t'i konfiguroni ato për automatikisht të shkallëzohen. Në fillim do të ketë një përmbledhje se si funksionon kjo, pastaj një udhëzues i detajuar për fillimin.
ĂfarĂ« janĂ« instancat spot?
spot janë servera të përdoruesve të tjerë të AWS që aktualisht janë të papërdorur, dhe ata i shesin ato me një zbritje të madhe (Amazon shkruan deri në 90%, sipas përvojës sonë ~3x, variabla në varësi të rajonit, AZ dhe tipit të instancës). Ndryshimi i tyre kryesor nga të zakonshmit është se ato mund të fikën në çdo moment. Prandaj, për një kohë të gjatë e kemi konsideruar se ishte mirë t'i përdornim ato për mjedise zhvillimi, ose për detyra për llogaritje diçkaje, duke ruajtur rezultatet ndërmjet në S3 ose në një bazë të dhënash, por jo për prodhim. Ekzistojnë zgjidhje të tjera që lejojnë përdorimin e instancave spot në prodhim, por për rastin tonë atje kishte shumë pengesa, prandaj nuk i implementuam ato. Qasja e përshkruar në artikull funksionon plotësisht brenda funksionalitetit standard të AWS, pa skripte shtesë, cron-e etj.
Më poshtë do të sjell disa screenshot që tregojnë historinë e çmimeve për instancat spot.
m5.large nĂ« rajonin eu-west-1 (IrlandĂ«). Ămimi ka qenĂ« kryesisht i stabilizuar pĂ«r 3 muaj, aktualisht kursimi Ă«shtĂ« 2.9x.
m5.large nĂ« rajonin us-east-1 (Virginia e Veriut). Ămimi ndryshon vazhdimisht pĂ«r 3 muaj, aktualisht kursimi Ă«shtĂ« nga 2.3x deri nĂ« 2.8x nĂ« varĂ«si tĂ« zonĂ«s sĂ« disponueshmĂ«risĂ«.
t3.small nĂ« rajonin us-east-1 (Virginia e Veriut). Ămimi Ă«shtĂ« stabil nĂ« pĂ«rpjekje pĂ«r 3 muaj, aktualisht kursimi Ă«shtĂ« 3.4x.
Arkitektura e shërbimit
Arkitektura bazë e shërbimit, për të cilin do të flasim në kuadër të këtij artikulli, shfaqet në diagramin më poshtë.
Application Load Balancer â EC2 Target Group â Elastic Container Service
Si balancues përdoret Application Load Balancer (ALB), i cili dërgon kërkesat në grupin e objektivave EC2 (TG). TG është përgjegjës për hapjen e porteve në instancat për ALB dhe lidhjen e tyre me portet e kontejnerëve të Elastic Container Service (ECS). ECS është ekuivalenti i Kubernetes në AWS, që merret me menaxhimin e kontejnerëve Docker.
Në një instancë mund të ketë disa kontejnerë funksionalë me portet e njëjta, prandaj nuk mund t'i caktojmë ato në mënyrë fikse. ECS i raporton TG-së se po nis një detyrë të re (në terminologjinë e Kubernetes quhet pod), ajo bën një kontroll të porteve të lira në instancë dhe caktuar një nga ato për detyrën e nisur. Gjithashtu, TG kontrollon rregullisht nëse instanca dhe API-ja e saj funksionojnë përmes kontrollit të shëndetit, dhe nëse sheh ndonjë problem, ndalon dërgimin e kërkesave atje.
Grupet e Shkallëzimit Auto EC2 + Furnizuesit e Kapacitetit ECS
Në diagramin e mësipërm nuk tregohet shërbimi i Grupit të Shkallëzimit Auto EC2 (ASG). Nga emri mund të kuptojmë se ai merret me shkallëzimin e instancave. Megjithatë, deri para pak kohësh, në AWS nuk kishte mundësi të integruar për të menaxhuar numrin e makinave të nisura nga ECS. ECS lejonte të shkallëzohej numri i detyrave, për shembull, në varësi të përdorimit të CPU, RAM ose numrit të kërkesave. Por nëse detyrat zaptonin të gjitha instancat e lira, makinat e reja nuk ngriheshin automatikisht.
Kjo ndryshoi me shfaqjen e Furnizuesve të Kapacitetit ECS (ECS CP). Tani çdo shërbim në ECS mund të lidhet me ASG, dhe nëse detyrat nuk përputhen me instancat funksionale, do të ngrihen të reja (por brenda kufijve të vendosur nga ASG). Kjo funksionon edhe në anën e kundërt, nëse ECS CP sheh instancat e papërdorura pa detyra, ajo do t'i japë urdhër ASG që t'i ndalë ato. ECS CP ka mundësi të përcaktojë përqindjen e synuar të ngarkesës së instancave, në mënyrë që disa makinat të jenë gjithmonë të lira për shkallëzim të shpejtë të detyrave, do të flas për këtë pak më vonë.
Shabllonet e Nisjes EC2
Shërbimi i fundit për të cilin do të flas para se të kaloj në përshkrimin e detajuar të krijimit të kësaj infrastrukture është Shabllonët e Nisjes EC2. Ai lejon krijimin e një shablloni në bazë të të cilit do të nisen të gjitha makinat, për të mos e përsëritur këtë çdo herë nga e para. Këtu mund të zgjidhni llojin e makinës që do të nisni, grupin e sigurisë, imazhin e diskut dhe shumë parametra të tjerë. Gjithashtu, mund të shtoni të dhëna të përdoruesve, të cilat do të ngarkohen në të gjitha instancat e nisin. .
Një nga parametrat më të rëndësishëm në kuadër të këtij artikulli është =true. Nëse ky parametër është aktiv, sapo ECS merr sinjalin se instanca e spots po merr fund, ai e kthen të gjitha detyrat që po punojnë mbi të në statusin Draining. Asnjë detyrë e re nuk do të caktohet në këtë instancë; nëse ka detyra që aktualisht dëshirojnë të kalojnë në të, ato anullohen. Kërkesat nga balancuesi gjithashtu nuk do të vijojnë. Njoftimi për fshirjen e instancës vjen 2 minuta para ngjarjes reale. Prandaj, nëse shërbimi juaj nuk kryen detyra më gjatë se 2 minuta dhe nuk ruan asgjë në disk, atëherë mund të përdorni instanca të spots pa humbje të dhënash.
PĂ«rsa i pĂ«rket diskut â AWS sĂ« fundmi tĂ« mundur pĂ«rdorimin e Elastic File System (EFS) sĂ« bashku me ECS; me kĂ«tĂ« skemĂ« as disku nuk Ă«shtĂ« njĂ« pengesĂ«, por ne nuk e kemi provuar, pasi nĂ« parim nuk na nevojitet disku pĂ«r ruajtjen e gjendjes. Nga default, pas marrjes sĂ« SIGINT (e cila dĂ«rgohet nĂ« momentin e kalimit tĂ« detyrĂ«s nĂ« statusin Draining), tĂ« gjitha detyrat aktive do tĂ« ndalohen brenda 30 sekondave, edhe nĂ«se ata nuk kanĂ« arritur ta pĂ«rfundojnĂ«; ky kohĂ« mund tĂ« ndryshohet me anĂ« tĂ« parametrit . E rĂ«ndĂ«sishme Ă«shtĂ« qĂ« tĂ« mos e vendosni mĂ« shumĂ« se 2 minuta pĂ«r makinat e spots.
Krijimi i shërbimit
Tani kalojmĂ« nĂ« krijimin e shĂ«rbimit tĂ« pĂ«rshkruar. GjatĂ« procesit do tĂ« pĂ«rshkruaj disa momente tĂ« dobishme qĂ« nuk u pĂ«rmendĂ«n mĂ« lart. NĂ« pĂ«rgjithĂ«si, kjo Ă«shtĂ« njĂ« udhĂ«zim hap pas hapi, por disa raste shumĂ« bazike ose pĂ«rkundrazi shumĂ« specifike nuk do tâi shqyrtoj. TĂ« gjitha veprimet realizohen nĂ« konsolĂ«n vizuale tĂ« AWS, por ato gjithashtu mund tĂ« riprodhohen programatikisht me anĂ« tĂ« CloudFormation ose Terraform. Ne nĂ« Adapty pĂ«rdorim Terraform.
EC2 Launch Template
Në këtë shërbim krijohet një konfigurim i makinave që do të përdoren. Menaxhimi i shablloneve ndodh në seksionin EC2 -> Instances -> Launch templates.
Imazhi i makinĂ«s Amazon (AMI) â tregojmĂ« imazhin e diskut me tĂ« cilin do tĂ« lancohen tĂ« gjitha instancat. PĂ«r ECS, nĂ« shumicĂ«n e rasteve, Ă«shtĂ« e rekomandueshme tĂ« pĂ«rdorim imazhin e optimizuar nga Amazon. Ai pĂ«rditĂ«sohet rregullisht dhe pĂ«rmban gjithçka tĂ« nevojshme pĂ«r funksionimin e ECS. PĂ«r tĂ« mĂ«suar ID-nĂ« e imazhit aktual, hyni nĂ« faqen , zgjidhni rajonin e pĂ«rdorur dhe kopjoni ID-nĂ« AMI pĂ«r tĂ«. PĂ«r shembull, pĂ«r rajonin us-east-1, ID aktual nĂ« momentin e shkruarjes sĂ« artikullit Ă«shtĂ« ami-00c7c1cf5bdc913ed. Ky ID duhet tĂ« shtohet nĂ« pikĂ«n Specify a custom value.
Lloji i instancĂ«s â specifikoni llojin e instancĂ«s. Zgjidhni atĂ« qĂ« i pĂ«rshtatet mĂ« mirĂ« nevojave tuaja.
Ăift çelĂ«sash (login) â specifikoni certifikatĂ«n qĂ« do tĂ« pĂ«rdoret pĂ«r t'u lidhur me instancĂ«n pĂ«rmes SSH, nĂ«se Ă«shtĂ« e nevojshme.
CilĂ«simet e rrjetit â specifikoni parametrat e rrjetit. Platforma e rrjetit nĂ« shumicĂ«n e rasteve duhet tĂ« jetĂ« Virtual Private Cloud (VPC). Grupet e sigurisĂ« â grupe sigurie pĂ«r instancat tuaja. Duke qenĂ« se do tĂ« pĂ«rdorim njĂ« balancer para instancave, rekomandoj tĂ« specifikoni kĂ«tu njĂ« grup qĂ« lejon lidhjet hyrĂ«se vetĂ«m nga balanceri. KĂ«shtu do tĂ« keni 2 grupe sigurie, njĂ« pĂ«r balancerin qĂ« lejon lidhjet hyrĂ«se (inbound) nga kudo pĂ«r portet 80 (http) dhe 443 (https), dhe e dyta pĂ«r makinat, qĂ« lejon lidhjet hyrĂ«se pĂ«r çdo port nga grupi i balancerit. Lidhjet dalĂ«se (outbound) nĂ« tĂ« dy grupet duhet tĂ« hapen pĂ«r protokollin TCP pĂ«r tĂ« gjitha portet e tĂ« gjitha adresave. Mund tĂ« kufizoni portet dhe adresat pĂ«r lidhjet dalĂ«se, por atĂ«herĂ« duhet vazhdimisht tĂ« monitoroni qĂ« tĂ« mos pĂ«rpiqeni tĂ« lidheni diku pĂ«rmes njĂ« porti tĂ« mbyllur.
Ruajtja (vĂ«llimet) â specifikoni parametrat e disqeve pĂ«r makinat. Kapaciteti i diskut nuk mund tĂ« jetĂ« mĂ« i vogĂ«l se ai qĂ« Ă«shtĂ« pĂ«rcaktuar nĂ« AMI, pĂ«r ECS Optimized â 30 GiB.
Detajet e avancuara â specifikoni parametra shtesĂ«.
Opsioni i blerjes â a duam tĂ« blejmĂ« instanca spote. Ne duam, por kĂ«tu nuk do ta shĂ«nojmĂ« kĂ«tĂ«, do ta konfirmojmĂ« nĂ« Grupin e ShkallĂ«zimit Automatik, aty ka mĂ« shumĂ« mundĂ«si.
Profili i instancĂ«s IAM â specifikoni rolin me tĂ« cilin do tĂ« ndizni instancat. PĂ«r tĂ« siguruar qĂ« instancat tĂ« funksionojnĂ« nĂ« ECS, ata kanĂ« nevojĂ« pĂ«r tĂ« drejta qĂ« zakonisht janĂ« nĂ« rolin ecsInstanceRole. NĂ« disa raste ajo mund tĂ« krijohet, nĂ«se jo, atĂ«herĂ« kĂ«tu pĂ«r atĂ« se si mund ta bĂ«ni kĂ«tĂ«. Pasi tĂ« krijohet, e specifikoni atĂ« nĂ« shabllon.
Më pas ka shumë parametra, në shumicën e rasteve mund të lini vlerat e paracaktuara, por çdo njëri prej tyre ka një përshkrim të qartë. Unë gjithmonë përfshij parametrat e instancës EBS-optimized dhe T2/T3 Unlimited, nëse përdoren Të dhënat e përdoruesit
â specifikoni tĂ« dhĂ«nat e pĂ«rdoruesit. Ne do tĂ« redaktojmĂ« skedarin , nĂ« tĂ« cilin ndodhet konfigurimi i agjentit ECS. /etc/ecs/ecs.configShembulli i asaj se si mund tĂ« duket tĂ« dhĂ«nat e pĂ«rdoruesit:
ECS_CLUSTER=DemoApiClusterProd
#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.configECS_CLUSTER=DemoApiClusterProd â parametri tregon se instanca i pĂ«rket njĂ« klasteri me emrin e caktuar, do thotĂ« se ky klaster mund tĂ« vendosĂ« detyrat e tij nĂ« kĂ«tĂ« server. Ne ende nuk e kemi krijuar klasterin, por kur ta krijojmĂ«, do ta pĂ«rdorim kĂ«tĂ« emĂ«r.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true â parametri tregon se kur tĂ« merrni njĂ« sinjal pĂ«r tĂ« fikur instancĂ«n e spots, tĂ« gjitha detyrat nĂ« tĂ« duhet tĂ« kalojnĂ« nĂ« statusin Draining.
ECS_CONTAINER_STOP_TIMEOUT=1m â parametri tregon se pas marrjes sĂ« sinjalit SIGINT, tĂ« gjitha detyrat kanĂ« 1 minuta pĂ«rpara se tĂ« vriten.
ECS_ENGINE_AUTH_TYPE=docker â parametri tregon se si mekanizĂ«m autorizimi pĂ«rdoret skema docker.
ECS_ENGINE_AUTH_DATA=... â parametrat e lidhjes me regjistrin privat tĂ« kontejnerĂ«ve, ku ruajnĂ« imazhet tuaja Docker. NĂ«se Ă«shtĂ« publik, nuk duhet tĂ« tregoni asgjĂ«.
Në këtë artikull do të përdor një imazh publik nga Docker Hub, prandaj nuk do të tregoj parametra. ECS_ENGINE_AUTH_TYPE dhe ECS_ENGINE_AUTH_DATA nuk është e nevojshme.
Eshte e dobishme tĂ« dihet: rekomandohet tĂ« pĂ«rditĂ«soni rregullisht AMI-nĂ«, sepse nĂ« versionet e reja pĂ«rditĂ«sohen versionet e Docker, Linux, ECS agentit dhe tĂ« tjera. PĂ«r tĂ« mos e harruar kĂ«tĂ«, mund tĂ« pĂ«r daljen e versioneve tĂ« reja. Mund tĂ« merrni njoftime nĂ« email dhe tâi pĂ«rditĂ«soni manualisht, ose mund tĂ« shkruani njĂ« funksion Lambda qĂ« do tĂ« krijojĂ« automatikisht njĂ« version tĂ« ri tĂ« Template tĂ« LĂ«shimit me AMI-nĂ« e pĂ«rditĂ«suar.
EC2 Auto Scaling Group
Grupi i Auto Scaling është përgjegjës për nisjen dhe shkallëzimin e instancave. Menaxhimi i grupeve ndodh në seksionin EC2 -> Auto Scaling -> Auto Scaling Groups.
Template i nisjes â zgjidhni modelin e krijuar nĂ« hapin e mĂ«parshĂ«m. Lini versionin nĂ« tĂ« parin.
MundĂ«sitĂ« e blerjes dhe llojet e instancĂ«s â pĂ«rcaktoni llojet e instancave pĂ«r klasterin. Adhere to launch template pĂ«rdor llojin e instancĂ«s nga Template i LĂ«shimit. Combine purchase options and instance types lejon tĂ« konfigurojmĂ« fleksibĂ«l llojet e instancave. Do ta pĂ«rdorim atĂ«.
BazĂ« opsionale On-Demand â numri i instancave normale, jo-spots, qĂ« do tĂ« punojnĂ« gjithmonĂ«.
PĂ«rqindja On-Demand mbi bazĂ«n â raporti nĂ« mes instancave normale dhe tĂ« spots, 50-50 do tĂ« shpĂ«rndajĂ« barabar, 20-80 pĂ«r çdo instancĂ« normale do tĂ« ngrihen 4 spots. NĂ« kĂ«tĂ« shembull do tĂ« tregoj 50-50, por nĂ« tĂ« vĂ«rtetĂ« shpesh bĂ«jmĂ« 20-80, nĂ« disa raste 0-100.
Llojet e instancave â kĂ«tu mund tĂ« specifikoni lloje tĂ« tjera instancash, tĂ« cilat do tĂ« pĂ«rdoren nĂ« kluster. KurrĂ« nuk i kemi pĂ«rdorur, sepse nuk e kuptoj shumĂ« kuptimin e kĂ«saj historie. Ndoshta Ă«shtĂ« çështje e limitimeve pĂ«r lloje specifike instancash, por ato rriten lehtĂ«sisht pĂ«rmes mbĂ«shtetjes. NĂ«se e dini njĂ« pĂ«rdorim, do tĂ« isha i lumtur tĂ« lexoj nĂ« komentet)
Network global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check â cilĂ«simet e rrjetit, zgjidhni VPC dhe nĂ«nrrjetat pĂ«r makinat, nĂ« shumicĂ«n e rasteve Ă«shtĂ« mĂ« mirĂ« tĂ« zgjidhni tĂ« gjitha nĂ«nrrjetat e disponueshme.
Balancimi i ngarkesĂ«s â cilĂ«simet e balancuesit, por ne do ta bĂ«jmĂ« kĂ«tĂ« veçmas, kĂ«tu nuk prekim asgjĂ«. Kontrolli i shĂ«ndetit do tĂ« konfigurohet mĂ« vonĂ«.
MadhĂ«sia e grupit â specifikoni kufijtĂ« pĂ«r numrin e makinave nĂ« kluster dhe numrin e dĂ«shiruar tĂ« makinave nĂ« fillim. Numri i makinave nĂ« kluster nuk do tĂ« bĂ«het kurrĂ« mĂ« i vogĂ«l se sa ai i specifikuar minimalisht dhe as mĂ« i madh se maksimalja, madje edhe nĂ«se sipas metrave duhet tĂ« ndodhi njĂ« skalim.
Politikat e skalimit â parametrat e skalimit, por ne do tĂ« bĂ«jmĂ« skalimin duke u nisur nga detyrat e ECS tĂ« ekzekutuara, prandaj do ta konfigurojmĂ« skalimin mĂ« vonĂ«.
Mbrojtja e shkallĂ«s sĂ« instancave â mbrojtja e instancave nga fshirja gjatĂ« skalimit poshtĂ«. E aktivizojmĂ«, nĂ« mĂ«nyrĂ« qĂ« ASG tĂ« mos fshijĂ« makinĂ«n ku ka detyra tĂ« ekzekutuara. NdĂ«rsa do tĂ« çaktivizojmĂ« mbrojtjen pĂ«r instancat qĂ« nuk kanĂ« detyra, do tĂ« jetĂ« ECS Capacity Provider.
Shto etiketa â mund tĂ« specifikoni etiketa pĂ«r instancat (pĂ«r kĂ«tĂ« duhet tĂ« jetĂ« e kontrolluar kutia Tag new instances). Rekomandoj tĂ« specifikoni etiketĂ«n Emri, kĂ«shtu qĂ« tĂ« gjitha instancat qĂ« inizohen brenda grupit do tĂ« kenĂ« tĂ« njĂ«jtin emĂ«r, Ă«shtĂ« e lehtĂ« pĂ«r tĂ« parĂ« nĂ« konsolĂ«.
Pas krijimit të grupit, hapeni atë dhe shkoni në seksionin Konfigurime të avancuara, pse në fazën e krijimit në konsolë nuk janë të dukshme të gjitha opsionet.
Politikat e pĂ«rfundimit â rregullat qĂ« merret parasysh gjatĂ« fshirjes sĂ« instancave. Ato aplikohen nĂ« rend. Ne zakonisht pĂ«rdorim ato, siç Ă«shtĂ« nĂ« figurĂ«n mĂ« poshtĂ«. SĂ« pari fshihen instancat me Modelin mĂ« tĂ« vjetĂ«r tĂ« Kryerjes (pĂ«r shembull, nĂ«se kemi pĂ«rmirĂ«suar AMI-nĂ«, na Ă«shtĂ« krijuar njĂ« version i ri, por tĂ« gjitha instancat kanĂ« arritur ta kalojnĂ« atĂ«). Pastaj zgjidhen instancat qĂ« janĂ« mĂ« afĂ«r orĂ«s sĂ« ardhshme matĂ«se pĂ«r faturimin. Dhe mĂ« pas zgjidhen ato mĂ« tĂ« vjetrat sipas datĂ«s sĂ« fillimit.
Eshte e dobishme të dihet: për të përditësuar të gjitha makinat në kluster, është e lehtë të përdorim . Nëse e kombinoni këtë me funksionin Lambda nga hapi i mëparshëm, atëherë do të keni një sistem përditësimi të instancave të automatizuar plotësisht. Para përditësimit të të gjitha makinave, është e nevojshme të çaktivizoni mbrojtjen nga shkallëzimi për të gjitha instancat në grup. Jo konfigurimin në grup, por pikërisht mbrojtjen e vet instancave, kjo bëhet në seksionin Menaxhimi i Instancave.
Application Load Balancer dhe EC2 Target Group
Balancuesi krijohet nĂ« seksionin EC2 â Balancimi i NgarkesĂ«s â Balancuesit. Ne do tĂ« pĂ«rdorim Application Load Balancer, krahasimi i llojeve tĂ« ndryshme tĂ« balancuesve mund tĂ« lexoni nĂ« .
Listeners â ka kuptim tĂ« krijoni portat 80 dhe 443 dhe tĂ« bĂ«ni redirekt nga 80 nĂ« 443 me ndihmĂ«n e rregullave tĂ« balancuesit.
Zones of Availability â nĂ« shumicĂ«n e rasteve zgjedhim tĂ« gjitha zonat e disponueshmĂ«risĂ«.
Konfiguro Settings e SigurisĂ« â kĂ«tu shĂ«nohet certifikata SSL pĂ«r balancuesin, opsioni mĂ« i pĂ«rshtatshĂ«m Ă«shtĂ« nĂ« ACM. Rreth diferencave Politika e SigurisĂ« mund tĂ« lexoni nĂ« , mund tĂ« lini atĂ« tĂ« zgjedhur siç Ă«shtĂ« nga fillimi ELBSecurityPolicy-2016-08. Pas krijimit tĂ« balancuesit, do tĂ« shihni emrin DNS, tĂ« cilin duhet ta konfiguroni si CNAME pĂ«r domainin tuaj. Ja si duket nĂ« Cloudflare.
Grupi i SigurisĂ« â krijojmĂ« ose zgjedhim njĂ« grup sigurie pĂ«r balancuesin, mĂ« shumĂ« mbi kĂ«tĂ« kam shkruar mĂ« sipĂ«r nĂ« seksionin EC2 Launch Template â CilĂ«simet e Rrjetit.
Grupi i targetĂ«ve â krijojmĂ« njĂ« grup, i cili Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r ruterimin e kĂ«rkesave nga balancuesi nĂ« makina dhe kontrollon disponueshmĂ«rinĂ« e tyre, pĂ«r tâi zĂ«vendĂ«suar nĂ« rast probleme. Lloji i targetit duhet tĂ« jetĂ« Instance, Protokolli dhe Port çdo lloj, nĂ«se pĂ«rdorni HTTPS pĂ«r komunikimin midis balancuesit dhe instancave, atĂ«herĂ« ata duhet tĂ« ngarkojnĂ« certifikatĂ«n. NĂ« kĂ«tĂ« shembull ne nuk do ta bĂ«jmĂ« kĂ«tĂ«, thjesht do tĂ« lĂ«mĂ« portin 80.
Kontrolli i shĂ«ndetit â parametrat e verifikimit tĂ« funksionalitetit tĂ« shĂ«rbimit. NĂ« shĂ«rbimin aktual, kjo duhet tĂ« jetĂ« njĂ« kĂ«rkesĂ« e veçantĂ«, e cila realizon pjesĂ« tĂ« rĂ«ndĂ«sishme tĂ« logjikĂ«s biznesore, nĂ« kĂ«tĂ« shembull do ta lĂ« cilĂ«simin sipas parazgjedhjeve. MĂ« pas mund tĂ« zgjidhni intervalin e kĂ«rkesave, kohĂ«n e skadimit, kodet e pĂ«rgjigjeve tĂ« suksesshme etj. NĂ« shembullin tonĂ« do tĂ« shĂ«nojmĂ« kodet e suksesit 200-399, sepse imazhi Docker, i cili do tĂ« pĂ«rdoret, ktheu kodin 304.
Regjistro TargetĂ«t â kĂ«tu zgjidhen makinat pĂ«r grupin, por nĂ« rastin tonĂ«, kjo do tĂ« merret me ECS, prandaj thjesht e kalojmĂ« kĂ«tĂ« hap.
Eshte e dobishme të dihet: në nivelin e balancuesit mund të aktivizoni regjistrimet, të cilat do të ruhen në S3 në një vend të caktuar . Atyre mund të eksportohen në shërbime të jashtme për analizë, ose mund të bëni kërkesa SQL drejtpërdrejt mbi të dhënat në S3 me . Kjo është e përshtatshme dhe funksionon pa ndonjë kod shtesë. Gjithashtu, rekomandoj të konfigurohet fshirja e të dhënave nga bucket S3 pas një periudhe të caktuar kohe.
Përkufizimi i Detyrës ECS
NĂ« hapat e mĂ«parshĂ«m krijuam gjithçka qĂ« lidhet me infrastrukturĂ«n e shĂ«rbimit, tani kalojmĂ« nĂ« pĂ«rshkrimin e konteinerĂ«ve qĂ« do tĂ« startojmĂ«. Kjo bĂ«het nĂ« seksionin ECS â Task Definitions.
Kompatibiliteti i llojit tĂ« lançimit â zgjidhni EC2.
Roli IAM pĂ«r ekzekutimin e DetyrĂ«s â zgjidhni ecsTaskExecutionRole. Me ndihmĂ«n e kĂ«tij roli shkruhen log-et, jepet qasje nĂ« variablat sekrete etj.
NĂ« seksionin Container Definitions klikoni Shto Konteiner.
ProHoster rÉylÉri â lidhja me imazhin me kodin e projektit, pĂ«r shembullin e kĂ«tij projekti do tĂ« pĂ«rdor njĂ« imazh publik nga Docker Hub .
KufijtĂ« e MemorisĂ« â kufijtĂ« pĂ«r memorinĂ« e konteinerit. Kufiri i FortĂ« â kufiri i fortĂ«, nĂ«se konteineri kalon vlerĂ«n e caktuar, do tĂ« ekzekutohet komanda docker kill, konteineri do tĂ« vdesĂ« menjĂ«herĂ«. Kufiri i ButĂ« â kufiri i butĂ«, konteineri mund tĂ« kalojĂ« vlerĂ«n e caktuar, por nĂ« kĂ«tĂ« rast, gjatĂ« vendosjes sĂ« detyrave nĂ« makinat do tĂ« merret parasysh ky parametr. PĂ«r shembull, nĂ«se nĂ« makinĂ«n ka 4 GiB RAM dhe kufiri i butĂ« i konteinerit Ă«shtĂ« 2048 MiB, atĂ«herĂ« nĂ« kĂ«tĂ« makinĂ« mund tĂ« ketĂ« maksimumi 2 detyra tĂ« aktivizuara me kĂ«tĂ« konteiner. NĂ« realitet, 4 GiB RAM Ă«shtĂ« pak mĂ« pak se 4096 MiB, mund ta shikoni nĂ« skedĂ«n ECS Instances nĂ« klaster. Kufiri i butĂ« nuk mund tĂ« jetĂ« mĂ« i madh se kufiri i fortĂ«. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se nĂ«se nĂ« njĂ« detyrĂ« ka disa konteinerĂ«, atĂ«herĂ« kufijtĂ« e tyre do tĂ« shuma.
Hartimet e Porteve â nĂ« PĂ«rsi e pritjes vendosim 0, do tĂ« thotĂ« qĂ« porta do tĂ« caktohet nĂ« mĂ«nyrĂ« dinamike, do tĂ« monitorohet nga Grupi i Objektivave. Porti i Konteinerit â porta nĂ« tĂ« cilĂ«n punon aplikacioni juaj, shpesh caktuar nĂ« komandĂ«n pĂ«r ekzekutimin ose emĂ«rohet nĂ« kodin e aplikacionit tuaj, Dockerfile etj. PĂ«r shembullin tonĂ« pĂ«rdorim 3000, sepse Ă«shtĂ« caktuar nĂ« imazhin e pĂ«rdorur.
Kontrolli i ShĂ«ndetit â parametrat e kontrollit tĂ« funksionimit tĂ« konteinerit, nuk duhet ngatĂ«rruar me atĂ« qĂ« Ă«shtĂ« caktuar nĂ« Grupi i Objektivave.
Mjedisi â konfigurimet e mjedisit. NjĂ«sitĂ« CPU â ngjan si kufijtĂ« e Memorjes, vetĂ«m pĂ«r procesorin. Ădo bĂ«rthamĂ« e procesorit Ă«shtĂ« 1024 njĂ«sive, kĂ«shtu qĂ« nĂ«se serveri ka njĂ« procesor me dy bĂ«rthama dhe vlera e kontejnerit Ă«shtĂ« 512, atĂ«herĂ« nĂ« njĂ« server mund tĂ« ekzekutohen 4 task-e me kĂ«tĂ« kontejner. NjĂ«sitĂ« e CPU gjithmonĂ« pĂ«rputhen me numrin e bĂ«rthamave, nuk mund tĂ« jenĂ« pak mĂ« tĂ« vogla siç ndodh me memorien.
KomandĂ« â komandĂ« pĂ«r tĂ« nisur shĂ«rbimin brenda kontejnerit, tĂ« gjitha parametrat jepen me presje. Mund tĂ« jetĂ« gunicorn, npm etj. NĂ«se nuk caktohet, do tĂ« pĂ«rdoret vlera e drejtorisĂ« CMD nga Dockerfile. Caktoni npm,start.
Variablat e mjedisit â variablat e mjedisit tĂ« kontejnerit. KĂ«to mund tĂ« jenĂ« si tĂ« dhĂ«na tekstuale, ashtu edhe variabla sekrete nga ose .
Ruajtja dhe Regjistrimi â kĂ«tu do tĂ« konfigurojmĂ« regjistrimin nĂ« CloudWatch Logs (shĂ«rbimi pĂ«r regjistrimin nga AWS). PĂ«r kĂ«tĂ«, mjafton tĂ« aktivizoni opsionin Auto-configure CloudWatch Logs. Pas krijimit tĂ« Task Definition, do tĂ« krijohet automatikisht njĂ« grup regjistrimesh nĂ« CloudWatch. Sipas parazgjedhjes, regjistrimet nĂ« tĂ« ruhet pafundĂ«sisht, rekomandoj tĂ« ndryshoni periudhĂ«n e Ruajtjes nga Never Expire nĂ« periudhĂ«n e kĂ«rkuar. Kjo bĂ«het nĂ« CloudWatch Log groups, duhet tĂ« klikoni mbi periudhĂ«n aktuale dhe tĂ« zgjidhni tĂ« re.
Klastri ECS dhe Ofruesi i Kapacitetit ECS
Shkoni te seksioni ECS â Clusters pĂ«r tĂ« krijuar njĂ« klasĂ«r. Si model zgjidhni EC2 Linux + Networking.
Emri i klasrit â shumĂ« e rĂ«ndĂ«sishme, bĂ«ni kĂ«tu tĂ« njĂ«jtin emĂ«r siç Ă«shtĂ« caktuar nĂ« Template-in e Lanshimit nĂ« parametrin ECS_CLUSTER, nĂ« rastin tonĂ« â DemoApiClusterProd. ShĂ«noni kutinĂ« Create an empty cluster. Opcionalisht, mund tĂ« aktivizoni Container Insights pĂ«r tĂ« parĂ« metrikat pĂ«r shĂ«rbimet nĂ« CloudWatch. NĂ«se keni bĂ«rĂ« gjithçka siç duhet, atĂ«herĂ« nĂ« seksionin ECS Instances do tĂ« shihni makinat qĂ« u krijuan nĂ« grupin e Auto Scaling.
Shkoni te tab-i Ofruesit e Kapacitetit dhe krijoni njĂ« tĂ« ri. Me kujdes, ai Ă«shtĂ« i nevojshĂ«m pĂ«r tĂ« menaxhuar krijimin dhe fikjen e makinave nĂ« varĂ«si tĂ« numrit tĂ« task-eve ECS qĂ« punojnĂ«. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se ofruesi mund tĂ« lidhet vetĂ«m me njĂ« grup.
Grupi Auto Scaling â zgjidhni grupin qĂ« u krijua mĂ« parĂ«.
Skalimi i menaxhuar â aktivizoni, nĂ« mĂ«nyrĂ« qĂ« ofruesi tĂ« jetĂ« nĂ« gjendje tĂ« shkallĂ«zojĂ« shĂ«rbimin.
Kapaciteti i Synuar % â cila pĂ«rqindje e ngarkesĂ«s sĂ« makinave me detyra na nevojitet. NĂ«se jepni 100%, tĂ« gjitha makinat gjithnjĂ« do tĂ« jenĂ« tĂ« angazhuara me detyra nĂ« punĂ«. NĂ«se jepni 50%, gjysma e makinave gjithnjĂ« do tĂ« jenĂ« tĂ« lira. NĂ« kĂ«tĂ« rast, nĂ«se ndodh njĂ« rritje e papritur e ngarkesĂ«s, taksitĂ« e reja do tĂ« kalojnĂ« menjĂ«herĂ« nĂ« makinat e lira, pa nevojĂ«n pĂ«r tĂ« pritur implementimin e instancave.
Mbrojtje e menaxhuar e ndĂ«rprerjes â e aktivizojmĂ«, ky parametr lejon ofruesin tĂ« heqĂ« mbrojtjen e instancave nga fshirja. Kjo ndodh kur nĂ« makinĂ« nuk ka detyra aktive dhe lejon Target capacity %.
ECS Shërbimi dhe konfigurimi i shkallëzimit
Hapi i fundit :) Për të krijuar një shërbim, duhet të hyj në klasterin e krijuar më parë në kartelën Shërbimet.
Lloji i lansimit â duhet tĂ« klikoni nĂ« Switch to capacity provider strategy dhe tĂ« zgjidhni ofruesin e krijuar mĂ« parĂ«.
PĂ«rkufizimi i DetyrĂ«s â zgjedhim PĂ«rkufizimin e DetyrĂ«s tĂ« krijuar mĂ« parĂ« dhe avokatin e tij.
Emri i shĂ«rbimit â pĂ«r tĂ« mos u ngatĂ«rruar, gjithmonĂ« e pĂ«rmendim tĂ« njĂ«jtin, si PĂ«rkufizimi i DetyrĂ«s.
Lloji i shĂ«rbimit â gjithmonĂ« Replica.
Numri i detyrave â numri i dĂ«shiruar i detyrave aktive nĂ« shĂ«rbim. Ky parametr menaxhohet nga shkallĂ«zimi, por gjithsesi duhet tĂ« caktohet.
PĂ«rqindja minimale e shĂ«ndetshme dhe PĂ«rqindja maksimale â pĂ«rcaktojnĂ« sjelljen e detyrave gjatĂ« deploy-it. Vlerat e paracaktuara 100 dhe 200 tregojnĂ« se nĂ« momentin e deploy-it numri i detyrave do tĂ« rritet dyfish, dhe mĂ« pas do tĂ« kthehet nĂ« numrin e dĂ«shiruar. NĂ«se keni 1 detyrĂ« duke punuar, min=0 dhe max=100, atĂ«herĂ« gjatĂ« deploy-it ajo do tĂ« fshihet dhe mĂ« pas do tĂ« ngrihet njĂ« e re, qĂ« do tĂ« thotĂ« se do tĂ« ketĂ« pritje. NĂ«se punon 1 detyrĂ«, min=50, max=150, atĂ«herĂ« deploy-i nuk do tĂ« ndodhĂ« fare, sepse 1 detyrĂ« nuk mund tĂ« ndahet nĂ« gjysmĂ« ose tĂ« rritet nĂ« 1.5 herĂ«.
Lloji i deploy-it â e lĂ«mĂ« Rolling update.
Shabllonat e vendosjes â rregullat e vendosjes sĂ« detyrave nĂ« makina. Si paracaktohet Ă«shtĂ« AZ Balanced Spread â kjo do tĂ« thotĂ« se çdo detyrĂ« e re do tĂ« vendoset nĂ« njĂ« instancĂ« tĂ« re deri sa tĂ« ngrihen makinat nĂ« tĂ« gjitha zonat e disponueshmĂ«risĂ«. Ne zakonisht bĂ«jmĂ« BinPack â CPU dhe Spread â AZ, sipas kĂ«saj politike detyrat vendosen sa mĂ« afĂ«r njĂ«ra-tjetrĂ«s nĂ« njĂ« makinĂ« sipas CPU. NĂ« rastin e nevojĂ«s pĂ«r tĂ« krijuar njĂ« makinĂ« tĂ« re, ajo krijohet nĂ« njĂ« zonĂ« tĂ« re tĂ« disponueshmĂ«risĂ«.
Lloji i balancuesit tĂ« ngarkesĂ«s â zgjedhim Application Load Balancer.
Roli IAM i shĂ«rbimit â zgjedhim ecsServiceRole.
Emri i balancuesit tĂ« ngarkesĂ«s â zgjedhim balancuesin e krijuar mĂ« parĂ«.
Periudha e faljes pĂ«r kontrollin e shĂ«ndetit â pauza pĂ«rpara kryerjes sĂ« kontrollove tĂ« funksionimit pas publikimit tĂ« detyrĂ«s sĂ« re, ne zakonisht vendosim 60 sekonda.
Container pĂ«r tĂ« balancuar ngarkesĂ«n â nĂ« pikĂ«n Emri i grupit tĂ« destinacionit zgjedhim grupin e krijuar mĂ« parĂ«, dhe gjithçka do tĂ« plotĂ«sohet automatikisht.
ShĂ«rbimi i Auto Skalimit â parametrat e skalimit tĂ« shĂ«rbimit. Zgjidhni Konfiguro ShĂ«rbimin e Auto Skalimit pĂ«r tĂ« rregulluar numrin e dĂ«shiruar tĂ« shĂ«rbimit tuaj. Caktoni numrin minimal dhe maksimal tĂ« detyrave gjatĂ« skalimit.
Roli IAM pĂ«r ShĂ«rbimin e Auto Skalimit â zgjedhim AWSServiceRoleForApplicationAutoScaling_ECSService.
Politikat automatike tĂ« skalimit tĂ« detyrave â rregullat pĂ«r skalimin. JanĂ« 2 lloje:
- Ndjekja e targetit â ndjekja e metrikĂ«s sĂ« synuar (pĂ«rdorimi i CPU/RAM ose numri i kĂ«rkesave pĂ«r secilĂ«n detyrĂ«). PĂ«r shembull, ne duam qĂ« ngarkesa mesatare e procesorit tĂ« jetĂ« 85%, kur ajo tĂ« rritet mĂ« shumĂ«, detyrat e reja do tĂ« shtohen deri sa tĂ« arrijĂ« vlerĂ«n e synuar. NĂ«se ngarkesa Ă«shtĂ« mĂ« e vogĂ«l, detyrat do tĂ« hiqen, pĂ«rveç nĂ«se mbrojtja nga ulja e skalimit nuk Ă«shtĂ« e aktivizuar (Ăaktivizo uljen e skalimit).
- Skalimi nĂ« hapa â reagimi ndaj ngjarjeve tĂ« rastĂ«sishme. KĂ«tu mund tĂ« konfiguroni reagimin ndaj ndonjĂ« ngjarjeje (Alarm CloudWatch), kur kjo ndodh, mund tĂ« shtoni ose hiqni njĂ« numĂ«r tĂ« caktuar detyrash, ose tĂ« caktoni njĂ« numĂ«r tĂ« saktĂ« detyrash.
Shërbimi mund të ketë disa rregulla skalimi, kjo mund të jetë e dobishme, por është e rëndësishme të siguroheni që ato të mos bien në konflikt me njëra-tjetrën.
PĂ«rfundim
Nëse keni ndjekur udhëzimet dhe keni përdorur të njëjtin imazh Docker, shërbimi juaj duhet të kthejë një faqe të tillë.
- Ne kemi krijuar një shabllon, sipas të cilit fillojnë të gjitha makinat në shërbim. Po ashtu kemi mësuar si të përditësojmë makinat kur shablloni ndryshon.
- Ne kemi konfiguruar trajtimin e sinjalit të ndalimit të instancës së pikave, kështu që brenda një minute pas marrjes, të gjitha detyrat aktive hiqen nga makina, duke siguruar kështu që asgjë të mos humbet apo të ndërpritet.
- Ne kemi ngritur një balancues, për të shpërndarë ngarkesën në mënyrë uniforme mes makinave.
- Ne kemi krijuar një shërbim që funksionon në instanca pikash, duke reduktuar kështu shpenzimet për makinat rreth 3 herë.
- Ne kemi konfiguruar auto skalimin në të dy drejtimet, për të përballuar rritjen e ngarkesave, ndërkohë që nuk paguajmë për papunësi.
- Ne përdorim Ofruesin e Kapacitetit, në mënyrë që aplikacioni të menaxhojë infrastrukturën (makinat), dhe jo e kundërta.
- Ne jemi të shkëlqyer.
Nëse keni shpërthime të parashikueshme të ngarkesës, për shembull, nëse bëni promovime në një email të madh, mund të konfiguroni skalimin sipas .
Një tjetër mundësi është shkallëzimi në bazë të të dhënave nga pjesë të ndryshme të sistemit tuaj. Për shembull, ne kemi funksionalitetin përdoruesve të aplikacionit mobil. Ndonjëherë, fushata dërgohet tek 1M+ njerëz. Pas kësaj, gjithmonë vërehet një rritje e madhe në kërkesat për API, sepse shumë përdorues hyjnë në aplikacion njëkohësisht. Prandaj, nëse ne shohim se numri i njoftimeve për dërgimin e promos është rritur ndjeshëm më shumë se treguesit standardë, mund të aktivizojmë menjëherë disa makina dhe detyra shtesë për t'u përgatitur për ngarkesën.
Do të isha i lumtur nëse në komentet do të ndani raste interesante të përdorimit të instancave spot dhe ECS apo diçka mbi shkallëzimin.
Së shpejti do të publikojmë artikuj mbi mënyrën se si ne përpunojmë mijëra ngjarje analitike në sekondë në një arkitekturë kryesisht pa server (me fonde) dhe si është e organizuar deploy-i i shërbimeve duke përdorur GitLab CI dhe Terraform Cloud.
Na ndiqni, do të jetë interesante!
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
A përdorni instanca spot në prodhim?
22,2%Po6
66,7%Jo18
11,1%MĂ«soj pĂ«r to nga njĂ« artikull, planifikoj tâi pĂ«rdor3
27 përdorues votuan. 5 përdorues abstenuan.
Burimi: habr.com
