5 mënyra për të përmirësuar konfigurimin e serverit të aplikacionit në ueb të prodhimit

Prezantimi

Pasi aplikacioni juaj të jetë gati dhe të funksionojë në një mjedis të serverit cloud, mund të pyesni veten se si mund ta përmirësoni mjedisin e serverit tuaj për të bërë një hap nga \funksionon në një mjedis prodhimi të plotë. Ky artikull do t'ju ndihmojë të filloni me planifikimi dhe zbatimi i një mjedisi prodhimi duke krijuar një përkufizim të lirë të prodhimit, në kontekstin e një aplikacioni ueb në një mjedis serveri cloud dhe duke ju treguar disa komponentë që mund t'i shtoni në arkitekturën tuaj ekzistuese për të bërë tranzicionin.

Për qëllimet e këtij demonstrimi, le të supozojmë se po fillojmë me një konfigurim të ngjashëm me atë të përshkruar në 5 konfigurime të zakonshme të serverit, si ky mjedis me dy serverë që thjesht i shërben një aplikacioni ueb:

Konfigurimi juaj aktual mund të jetë më i thjeshtë ose më kompleks, por idetë dhe komponentët e përgjithshëm të diskutuar këtu duhet të zbatohen në një farë mase në çdo mjedis serveri.

Le të fillojmë me përcaktimin e asaj që nënkuptojmë kur themi mjedis prodhimi.

Çfarë është një mjedis prodhimi?

Një mjedis serveri për një aplikacion ueb, në një kuptim të përgjithshëm, përbëhet nga hardueri, softueri, të dhënat, planet operacionale dhe personeli që janë të nevojshëm për të mbajtur aplikacionin të funksionojë. Një mjedis prodhimi zakonisht i referohet një mjedisi serveri që është projektuar dhe zbatuar me konsideratë maksimale për nivelet e pranueshme të këtyre faktorëve:

Disponueshmëria: Mundësia që aplikacioni të jetë i përdorshëm nga përdoruesit e tij të synuar gjatë orëve të reklamuara. Disponueshmëria mund të ndërpritet nga çdo dështim që prek mjaft rëndë një komponent kritik (p.sh. aplikacioni rrëzohet për shkak të një gabimi, pajisja e ruajtjes së bazës së të dhënave dështon ose administratori i sistemit fik aksidentalisht serverin e aplikacionit).

Një mënyrë për të promovuar disponueshmërinë është zvogëlimi i numrit të pikave të vetme të dështimit në një mjedis. Për shembull, përdorimi i një IP statike dhe një shërbimi i dështimit të monitorimit siguron që përdoruesit të kenë akses vetëm në artikullin e ngarkesës së shëndetshme në balancimin e ngarkesës.

Rikuperueshmëria: Aftësia për të rikuperuar një mjedis aplikacioni në rast të dështimit të sistemit ose humbjes së të dhënave. Nëse një komponent kritik dështon dhe nuk është i rikuperueshëm, disponueshmëria do të bëhet inekzistente. Përmirësimi i mirëmbajtjes, një koncept i lidhur, zvogëlon kohën e nevojshme për të kryer një proces të caktuar rikuperimi në rast dështimi, dhe për këtë arsye mund të përmirësojë disponueshmërinë në rast dështimi
Performanca: Aplikacioni funksionon siç pritej nën ngarkesën mesatare ose maksimale (p.sh. është në mënyrë të arsyeshme reaguese). Edhe pse shumë e rëndësishme për përdoruesit tuaj, performanca ka rëndësi vetëm nëse aplikacioni është i disponueshëm

Merrni pak kohë për të përcaktuar nivelet e pranueshme për secilin nga artikujt e sapopërmendur, në kontekstin e aplikimit tuaj. Kjo do të ndryshojë në varësi të rëndësisë dhe natyrës së aplikacionit në fjalë. Për shembull, ndoshta është e pranueshme që një blog personal që u shërben pak vizitorëve të vuajë nga ndërprerja e rastësishme ose performanca e dobët, për sa kohë që blogu mund të rikuperohet, por dyqani online i një kompanie duhet të arrijë nota shumë të larta në të gjithë bordin. Sigurisht, do të ishte mirë të arrihej 100% në çdo kategori, për çdo aplikim, por kjo shpesh nuk është e realizueshme për shkak të kufizimeve në kohë dhe para.

Vini re se nuk kemi përmendur (a) besueshmërinë e harduerit, probabilitetin që një komponent i caktuar i harduerit të funksionojë siç duhet për një kohë të caktuar përpara dështimit, ose (b) sigurinë si faktorë. Kjo është për shkak se ne po supozojmë (a) serverët cloud që po përdorni janë përgjithësisht të besueshëm, por kanë potencial për dështim (pasi funksionojnë në serverë fizikë) dhe (b) ju po ndiqni praktikat më të mira të sigurisë sipas aftësive tuaja - thënë thjesht, ato janë jashtë objektit të këtij neni. Sidoqoftë, duhet të jeni të vetëdijshëm se besueshmëria dhe siguria janë faktorë që mund të ndikojnë drejtpërdrejt në disponueshmërinë dhe të dyja mund të kontribuojnë në nevojën për rikuperim.

Në vend që t'ju tregojmë një procedurë hap pas hapi për krijimin e një mjedisi prodhimi, gjë që është e pamundur për shkak të nevojave dhe natyrës së ndryshme të çdo aplikacioni, ne do të paraqesim disa komponentë të prekshëm që mund të përdoren për të transformuar konfigurimin tuaj ekzistues në një mjedis prodhimi.

Le të hedhim një vështrim në përbërësit!

1. Sistemi rezervë

Një sistem rezervë do t'ju japë mundësinë për të krijuar kopje rezervë periodike të të dhënave tuaja dhe për të rivendosur të dhënat nga kopjet rezervë. Rezervimet lejojnë gjithashtu rikthimin e të dhënave tuaja, në një gjendje të mëparshme, në rast të fshirjes aksidentale ose modifikimit të padëshiruar, që mund të ndodhë për një sërë arsyesh, duke përfshirë gabimin njerëzor. I gjithë hardueri i kompjuterit ka një shans të dështimit në një moment në kohë, gjë që mund të shkaktojë humbje të të dhënave. Duke pasur parasysh këtë, duhet të mbani kopje rezervë të fundit të të gjitha të dhënave tuaja të rëndësishme.

Kërkohet për prodhim? Po. Një sistem rezervë mund të zbusë efektet e humbjes së të dhënave, e cila është e nevojshme për të arritur rikuperimin dhe, për rrjedhojë, ndihmon disponueshmërinë në rast të humbjes së të dhënave—por ai duhet të përdoret së bashku me planet e ngurta rikuperimi, të cilat diskutohen në seksionin vijues. Vini re se kopjet rezervë të bazuara në fotografi të DigitalOcean mund të mos jenë të mjaftueshme për të gjitha nevojat tuaja rezervë, pasi nuk është i përshtatshëm për të bërë kopje rezervë të bazave të të dhënave aktive dhe aplikacioneve të tjera me I/O me shkrim të lartë në disk — nëse përdorni këto lloj aplikacionesh, ose dëshironi më shumë fleksibilitet të planifikimit rezervë, sigurohuni që të përdorni një sistem tjetër rezervë si Bacula.

Diagrami i mësipërm është një shembull i një sistemi bazë rezervë. Serveri rezervë ndodhet në të njëjtën qendër të dhënash si serverët e aplikacionit, ku krijohen kopjet rezervë fillestare. Më vonë, kopjet jashtë sajtit të kopjeve rezervë bëhen në një server në një qendër të ndryshme të dhënash për të siguruar që të dhënat të ruhen, të themi, në rast të një fatkeqësie natyrore.

Konsideratat

Zgjedhja e kopjeve rezervë: Të dhënat që do të rezervoni. Minimalisht, rezervoni çdo të dhënë që nuk mund t'i riprodhoni në mënyrë të besueshme nga një burim alternativ
Orari i rezervimit: Kur dhe sa shpesh do të kryeni kopje rezervë të plotë ose në rritje. Duhet të merren konsiderata të veçanta për kopjet rezervë të llojeve të caktuara të të dhënave, të tilla si bazat e të dhënave aktive, të cilat mund të ndikojnë në orarin tuaj të rezervimit
Periudha e ruajtjes së të dhënave: Sa kohë do t'i ruani kopjet rezervë përpara se t'i fshini ato
Hapësira e diskut për kopje rezervë: Kombinimi i tre artikujve të mëparshëm ndikon në sasinë e hapësirës në disk që do të kërkojë sistemi juaj rezervë. Përfitoni nga kompresimi dhe kopjet rezervë në rritje për të zvogëluar hapësirën në disk të kërkuar nga rezervimet tuaja
Rezervimet jashtë sajtit: Për të mbrojtur kopjet rezervë nga fatkeqësitë lokale, brenda një qendre të caktuar të dhënash, këshillohet që të ruani një kopje të kopjeve rezervë në një vendndodhje gjeografikisht të veçantë. Në diagramin e mësipërm, kopjet rezervë të NYC3 janë kopjuar në SFO1 për këtë qëllim
Testet e restaurimit të kopjeve rezervë: Testoni periodikisht procesin tuaj të restaurimit të kopjeve rezervë për t'u siguruar që kopjet rezervë funksionojnë siç duhet

Mësime të ngjashme

Si të zgjidhni një strategji efektive rezervë për VPS-në tuaj
Si të instaloni serverin Bacula në Ubuntu 14.04
Si të përdorni Rsync për të sinkronizuar drejtoritë lokale dhe të largëta në një VPS
Të kuptuarit e kopjeve rezervë të pikave të DigitalOcean

2. Planet e rimëkëmbjes

Planet e rikuperimit janë një grup procedurash të dokumentuara për të rikuperuar nga dështimet e mundshme ose gabimet e administrimit brenda mjedisit tuaj të prodhimit. Së paku, do të dëshironi një plan rikuperimi për çdo skenar gjymtues që mendoni se do të ndodhë në mënyrë të pashmangshme, të tilla si dështimi i harduerit të serverit ose fshirja aksidentale e të dhënave. Për shembull, një plan shumë themelor rikuperimi për një dështim të serverit mund të përbëhet nga një listë e hapave që keni marrë për të kryer vendosjen fillestare të serverit, me procedura shtesë për rivendosjen e të dhënave të aplikacionit nga kopjet rezervë. Një plan më i mirë rikuperimi, përveç dokumentacionit të mirë, mund të përdorë skriptet e vendosjes dhe mjetet e menaxhimit të konfigurimit, si Ansible, Chef ose Puppet, për të ndihmuar në automatizimin dhe përshpejtimin e procesit të rikuperimit.

Kërkohet për prodhim? Po. Megjithëse planet e rikuperimit nuk ekzistojnë si softuer në mjedisin e serverit tuaj, ato janë një komponent i domosdoshëm për një konfigurim prodhimi. Ato ju mundësojnë të përdorni kopjet rezervë në mënyrë efektive dhe ofrojnë një plan për rindërtimin e mjedisit tuaj ose rikthimin në gjendjen e dëshiruar kur lind nevoja.

Diagrami i mësipërm është një përmbledhje e një plani rikuperimi për një server të dështuar të bazës së të dhënave. Në këtë rast, serveri i bazës së të dhënave do të zëvendësohet nga një i ri me të njëjtin softuer të instaluar dhe rezervimi i fundit i mirë do të përdoret për të rivendosur konfigurimin dhe të dhënat e serverit. Së fundi, serveri i aplikacionit do të konfigurohet për të përdorur serverin e ri të bazës së të dhënave.

Konsideratat

Dokumentacioni i procedurës: Grupi i dokumenteve që duhen ndjekur në rast dështimi. Një pikënisje e mirë është ndërtimi i një dokumenti hap pas hapi që mund të ndiqni për të rindërtuar një server të dështuar, më pas duke shtuar hapa për rivendosjen e të dhënave të ndryshme të aplikacionit dhe konfigurimin nga kopjet rezervë
Mjetet e automatizimit: Skriptet dhe softueri i menaxhimit të konfigurimit ofrojnë automatizim, i cili mund të përmirësojë proceset e vendosjes dhe rikuperimit. Ndërsa udhëzuesit hap pas hapi shpesh janë adekuat për të rikuperuar thjesht nga një dështim, ato duhet të ekzekutohen nga një person dhe për këtë arsye nuk janë aq të shpejta apo të qëndrueshme sa një proces i automatizuar
Përbërësit kritik: Komponentët që janë të nevojshëm që aplikacioni juaj të funksionojë siç duhet. Në shembullin e mësipërm, si serveri i aplikacionit ashtu edhe ai i bazës së të dhënave janë komponentë kritikë, sepse nëse njëri dështon, aplikacioni do të bëhet i padisponueshëm
Pikat e vetme të dështimit: Komponentët kritikë që nuk kanë një mekanizëm automatik të dështimit konsiderohen të jenë një pikë e vetme dështimi. Ju duhet të përpiqeni të eliminoni pikat e vetme të dështimit, sa më mirë që keni mundësi, për të përmirësuar disponueshmërinë
Rishikimet: Përditësoni dokumentacionin tuaj ndërsa procesi juaj i vendosjes dhe rikuperimit përmirësohet

3. Balancimi i ngarkesës

Balancimi i ngarkesës mund të shtohet në një mjedis serveri për të përmirësuar performancën dhe disponueshmërinë duke shpërndarë ngarkesën e punës nëpër serverë të shumtë. Nëse një nga serverët që është i balancuar në ngarkesë dështon, serverët e tjerë do të trajtojnë trafikun në hyrje derisa serveri i dështuar të bëhet përsëri i shëndetshëm. Në një mjedis të serverit cloud, balancimi i ngarkesës zakonisht mund të zbatohet duke shtuar një server të balancuesit të ngarkesës, që ekzekuton softuerin e balancuesit të ngarkesës (proxy i kundërt), përpara serverëve të shumtë që ekzekutojnë një komponent të veçantë të një aplikacioni.

Kërkohet për prodhim? Jo domosdoshmërisht. Balancimi i ngarkesës nuk kërkohet gjithmonë për një mjedis prodhimi, por mund të jetë një mënyrë efektive për të reduktuar numrin e pikave të vetme të dështimit në një sistem, nëse zbatohet në mënyrë korrekte. Mund të përmirësojë gjithashtu performancën duke shtuar më shumë kapacitet përmes shkallëzimit horizontal.

Diagrami i mësipërm shton një server shtesë aplikacioni për të ndarë ngarkesën dhe një balancues ngarkese për të shpërndarë kërkesat e përdoruesve në të dy serverët e aplikacioneve. Ky konfigurim mund të ndihmojë me performancën, nëse serveri i vetëm i aplikacionit po luftonte për të vazhduar me trafikun, dhe gjithashtu mund të ndihmojë në mbajtjen e aplikacionit të disponueshëm nëse një nga serverët e aplikacionit dështon. Megjithatë, ai ka ende dy pika të vetme të dështimit në serverin e bazës së të dhënave dhe vetë serverin e balancuesit të ngarkesës.

Shënim: Balancuesit e ngarkesës DigitalOcean janë një shërbim balancimi i ngarkesës i menaxhuar plotësisht dhe shumë i disponueshëm. Nëse po ekzekutoni aplikacionin tuaj në DigitalOcean, shërbimi Load Balancer mund të jetë i përshtatshëm për mjedisin tuaj.

Konsideratat

Përbërësit e balancueshëm të ngarkesës: Jo të gjithë komponentët në një mjedis mund të ngarkohen lehtësisht. Vëmendje e veçantë duhet t'i kushtohet llojeve të caktuara të softuerit si bazat e të dhënave ose aplikacionet shtetërore
Replikimi i të dhënave të aplikacionit: Nëse një server aplikacioni i balancuar me ngarkesë ruan të dhënat e aplikacionit në nivel lokal, siç janë skedarët e ngarkuar, këto të dhëna duhet t'u vihen në dispozicion serverëve të tjerë të aplikacionit nëpërmjet metodave të tilla si riprodhimi ose sistemet e skedarëve të përbashkët . Kjo është e nevojshme për të siguruar që të dhënat e aplikacionit do të jenë të disponueshme pavarësisht se cili server aplikacioni është zgjedhur për të shërbyer një kërkesë të përdoruesit
Gykat e ngushta të performancës: Nëse një balancues i ngarkesës nuk ka burime të mjaftueshme ose nuk është i konfiguruar siç duhet, ai në fakt mund të ulë performancën e aplikacionit tuaj
Pikat e vetme të dështimit: Ndërsa balancimi i ngarkesës mund të përdoret për të eliminuar pikat e vetme të dështimit, balancimi i ngarkesës i planifikuar keq në fakt mund të shtojë më shumë pika të vetme dështimi. Balancimi i ngarkesës përmirësohet me përfshirjen e një balancuesi të dytë të ngarkesës me një IP statike përpara çiftit që dërgon trafikun tek njëri ose tjetri në varësi të disponueshmërisë.

Mësime të ngjashme

Një hyrje në HAProxy dhe konceptet e balancimit të ngarkesës
Si të zbatohet përfundimi SSL me HAProxy në Ubuntu 14.04
Si të përdorni HAProxy si një balancues i ngarkesës së shtresës 7 për WordPress dhe Nginx në Ubuntu 14.04
Të kuptuarit e proxying Nginx HTTP, Load Balancing, Buffering dhe Caching
Si të krijoni balancuesin tuaj të parë të ngarkesës DigitalOcean
Si të përdorni IP-të e rezervuara

4. Monitorimi

Monitorimi mund të mbështesë një mjedis serveri duke ndjekur statusin e shërbimeve dhe tendencat e përdorimit të burimeve të serverit tuaj, duke siguruar kështu shikueshmëri të madhe në mjedisin tuaj. Një nga përfitimet më të mëdha të sistemeve të monitorimit është se ato mund të konfigurohen për të shkaktuar një veprim, të tillë si ekzekutimi i një skripti ose dërgimi i një njoftimi, kur një shërbim ose server nuk funksionon, ose nëse një burim i caktuar, si CPU, memorie ose magazinimi, bëhet i mbi-shfrytëzuar. Këto njoftime ju mundësojnë të reagoni ndaj çdo problemi sapo ato të ndodhin, gjë që mund të ndihmojë në minimizimin ose parandalimin e kohës së ndërprerjes së aplikacionit tuaj.

Kërkohet për prodhim? Jo domosdoshmërisht, por nevoja për monitorim rritet ndërsa mjedisi i prodhimit rritet në madhësi dhe kompleksitet. Ai ofron një mënyrë të thjeshtë për të mbajtur gjurmët e shërbimeve tuaja kritike dhe burimeve të serverit. Nga ana tjetër, monitorimi mund të përmirësojë rikuperimin dhe të informojë planifikimin dhe mirëmbajtjen e konfigurimit tuaj.

Diagrami i mësipërm është një shembull i një sistemi monitorimi. Në mënyrë tipike, serveri i monitorimit do të kërkojë të dhëna statusi nga softueri i agjentit që funksionon në serverët e aplikacionit dhe bazës së të dhënave, dhe secili agjent do të përgjigjet me informacionin e statusit të softuerit dhe harduerit. Administratori(ët) e sistemit më pas mund të përdorin tastierën e monitorimit për të parë gjendjen e përgjithshme të aplikacionit dhe për të gjetur informacione më të detajuara, sipas nevojës.

Konsideratat

Shërbimet për të monitoruar: Shërbimet dhe programet kompjuterike që do të monitoroni. Minimalisht, duhet të monitoroni gjendjen e të gjitha shërbimeve që duhet të jenë në një gjendje të shëndetshme funksionimi që aplikacioni juaj të funksionojë siç duhet
Burimet për të monitoruar: Burimet që do të monitoroni. Shembuj burimesh përfshijnë CPU-në, memorien, ruajtjen dhe përdorimin e rrjetit, si dhe gjendjen e serverit në tërësi
Ruajtja e të dhënave: Periudha kohore që ruani të dhënat e monitorimit përpara se t'i hidhni ato. Kjo, së bashku me zgjedhjen tuaj të artikujve për të monitoruar, do të ndikojë në sasinë e hapësirës në disk që do të kërkojë sistemi juaj i monitorimit
Rregullat e zbulimit të problemeve: Pragjet dhe rregullat që përcaktojnë nëse një shërbim ose burim është në gjendje të mirë. Për shembull, një shërbim ose server mund të konsiderohet të jetë i shëndetshëm nëse funksionon dhe shërben kërkesa, ndërsa një burim, si ruajtja, mund të shkaktojë një paralajmërim nëse përdorimi i tij arrin një prag të caktuar për një kohë të caktuar
Rregullat e njoftimit: Pragjet dhe rregullat që përcaktojnë nëse duhet të dërgohet një njoftim. Ndërsa njoftimet janë të rëndësishme, është po aq e rëndësishme që të rregulloni rregullat tuaja të njoftimit në mënyrë që të mos merrni shumë; një kuti hyrëse plot me paralajmërime dhe sinjalizime shpesh do të shpërfillet, duke i bërë ato pothuajse po aq të padobishme sa nuk ka njoftime fare

Mësime të ngjashme

Si të instaloni Nagios 4 dhe të monitoroni serverët tuaj në Ubuntu 14.04
Si të përdorni Icinga për të monitoruar serverët dhe shërbimet tuaja në Ubuntu 14.04
Si të instaloni Zabbix në Ubuntu dhe ta konfiguroni atë për të monitoruar shumë serverë VPS
Monitorimi dhe menaxhimi i rrjetit tuaj me SNMP
Si të konfiguroni Sensu Monitoring, RabbitMQ dhe Redis në Ubuntu 14.04

5. Prerjet e centralizuara

Regjistrimi i centralizuar mund të mbështesë një mjedis serveri duke ofruar një mënyrë të thjeshtë për të parë dhe kërkuar regjistrat tuaj, të cilët zakonisht ruhen lokalisht në serverë individualë në të gjithë mjedisin tuaj, në një vend të vetëm. Përveç lehtësisë për të mos pasur nevojë të identifikoheni në serverë individualë për të lexuar regjistrat, regjistrimi i centralizuar gjithashtu ju lejon të identifikoni lehtësisht çështjet që përfshijnë shumë serverë duke ndërlidhur regjistrat dhe metrikat e tyre gjatë një periudhe kohe specifike. Gjithashtu jep më shumë fleksibilitet për sa i përket mbajtjes së regjistrave, sepse regjistrat lokalë mund të shkarkohen nga serverët e aplikacionit në një server të centralizuar të regjistrave që ka ruajtjen e tij të pavarur.

Kërkohet për prodhim? Jo, por si monitorimi, regjistrimi i centralizuar mund të ofrojë njohuri të paçmueshme në mjedisin e serverit tuaj ndërsa rritet në madhësi dhe kompleksitet. Përveçse është më i përshtatshëm se regjistrimi tradicional, ai ju mundëson të auditoni me shpejtësi regjistrat e serverit tuaj me shikueshmëri më të madhe.

Diagrami i mësipërm është një shembull i thjeshtuar i një sistemi të centralizuar të prerjeve. Një agjent i dërgesës së regjistrave është instaluar në çdo server dhe është konfiguruar për të dërguar regjistrat e rëndësishëm të aplikacioneve dhe bazës së të dhënave te serveri i centralizuar i regjistrimit. Administratori(ët) e sistemit më pas mund të shikojnë, filtrojnë dhe kërkojnë të gjitha regjistrat e rëndësishëm nga një tastierë e vetme.

Konsideratat

Regjistrimet për të mbledhur: Regjistrat e veçantë që do të dërgoni nga serverët tuaj në serverin e centralizuar të regjistrimit. Ju duhet të mbledhni regjistrat e rëndësishëm nga të gjithë serverët tuaj
Ruajtja e të dhënave: Periudha kohore që ruani regjistrat përpara se t'i hidhni ato. Kjo, së bashku me zgjedhjen tuaj të regjistrave për të mbledhur, do të ndikojë në sasinë e hapësirës në disk që do të kërkojë sistemi juaj i centralizuar i regjistrimit
Filtat e regjistrit: Filtrat që analizojnë regjistrat e thjeshtë në të dhënat e regjistrit të strukturuar. Filtrimi i regjistrave do të përmirësojë aftësinë tuaj për të kërkuar, analizuar dhe grafikuar të dhënat në mënyra kuptimplote
Orat e serverit: Sigurohuni që orët e serverëve tuaj të jenë të sinkronizuara dhe duke përdorur të vendosura në të njëjtën zonë kohore, në mënyrë që afati kohor i regjistrit tuaj të jetë i saktë në të gjithë mjedisin tuaj

Mësime të ngjashme

Si të instaloni Elasticsearch, Logstash dhe Kibana 4 në Ubuntu 14.04
Si të përdorni aplikacionin DigitalOcean ELK Stack me një klikim
Hyrje në statistikat e gjurmimit në serverë
Si të instaloni Graylog2 dhe të centralizoni regjistrat në Ubuntu 14.04

konkluzioni

Kur bashkoni të gjithë komponentët, mjedisi juaj i prodhimit mund të duket diçka si kjo:

Tani që jeni njohur me komponentët që mund të përdoren për të mbështetur dhe përmirësuar konfigurimin e serverit të prodhimit, duhet të mendoni se si mund t'i integroni ato në mjediset e serverit tuaj. Sigurisht, ne nuk mbuluam çdo mundësi, por kjo duhet t'ju japë një ide se ku të filloni. Mos harroni të hartoni dhe zbatoni mjedisin e serverit tuaj bazuar në një ekuilibër të burimeve tuaja të disponueshme dhe qëllimeve tuaja të prodhimit.

Nëse jeni të interesuar të konfiguroni një mjedis si ai i mësipërm, shikoni këtë tutorial: Ndërtimi për Prodhim: Aplikacione Ueb.