Për të krijuar aplikacionin tuaj web në ditët e sotme, nuk mjafton vetëm të dini si ta zhvilloni atë. Një aspekt i rëndësishëm është konfigurimi i mjeteve për deploymin e aplikacionit, monitorimin, si dhe menaxhimin dhe administrimin e mjedisit në të cilin ai funksionon. Epoka e deploymet manual po shkon në harresë, madje edhe për projekte të vogla, mjetet e automatizimit mund të sjellin përfitime të ndjeshme. Kur deploymojmë me duar, shpesh harrojmë të transferojmë diçka, të marrim parasysh ndonjë detaj, të aktivizojmë një test të harruar; ky listë mund të vazhdojë për një kohë të gjatë.
Ky artikull mund të ndihmojë ata që sapo po mësojnë bazat e krijimit të aplikacioneve web dhe dëshirojnë të kuptojnë pak më shumë mbi terminologjitë dhe konventat kryesore.
Pra, ndërtimi i aplikacioneve mund të ndahet në dy pjesë: gjithçka që ka të bëjë me kodin e aplikacionit dhe gjithçka që ka të bëjë me mjedisin në të cilin ky kod ekzekutohet. Kodi i aplikacionit, nga ana e tij, gjithashtu ndahen në server-side (ai që ekzekutohet në server, shpesh: logjika e biznesit, autorizimi, ruajtja e të dhënave, etj.) dhe në client-side (ai që ekzekutohet në makinën e përdoruesit: shpesh ndërfaqja dhe logjika e lidhur me të).
Le të fillojmë, besoj, me mjedisin.
Baza për funksionimin e çdo kodi, sistemi, software është Sistemi Operativ, prandaj më poshtë do të shqyrtojmë sistemet më të njohura që janë të pranishme në tregun e hostimeve dhe do t'i japim një përshkrim të shkurtër atyre:
Windows Server â ajo qĂ« Ă«shtĂ« Windows, por nĂ« versionin server. Disa funksionalitete qĂ« janĂ« tĂ« disponueshme nĂ« versionin klient (tĂ« zakonshĂ«m) tĂ« Windows nuk janĂ« kĂ«tu, pĂ«r shembull, disa shĂ«rbime pĂ«r mbledhjen e statistikave dhe softuer tĂ« ngjashĂ«m; megjithatĂ«, ekziston njĂ« set mjetesh pĂ«r administrimin e rrjetit dhe software-i bazik pĂ«r deploymin. serverĂ«sh (web, ftp, ...). NĂ« pĂ«rgjithĂ«si, Windows Server duket si Windows e zakonshme, zĂ«shĂ«m si Windows e zakonshme, megjithatĂ«, çmimi i tij Ă«shtĂ« dy herĂ« mĂ« i lartĂ« se ai i shokut tĂ« tij normal. MegjithatĂ«, duke marrĂ« parasysh se deploymi i aplikacionit do tĂ« bĂ«het ndoshta nĂ« njĂ« server tĂ« dedikuar/virtual, kostot pĂ«r ju mund tĂ« rriten, por jo kritikisht. Duke marrĂ« parasysh se platforma Windows zĂ« njĂ« pozicion tĂ« rĂ«ndĂ«sishĂ«m nĂ« tregun e sistemeve operative pĂ«r pĂ«rdorues, edicioni i saj server do tĂ« jetĂ« mĂ« i njohur pĂ«r shumicĂ«n e pĂ«rdoruesve.
Unix-sistemi i ngjashĂ«m. Puna tradicionale nĂ« kĂ«to sisteme nuk parashikon prani tĂ« njĂ« ndĂ«rfaqe grafike tĂ« njohur, duke ofruar pĂ«r pĂ«rdoruesin si element kontrolli vetĂ«m njĂ« konsolĂ«. PĂ«r njĂ« pĂ«rdorues tĂ« papĂ«rvojshĂ«m, puna nĂ« njĂ« format tĂ« tillĂ« mund tĂ« pĂ«rbĂ«jĂ« vĂ«shtirĂ«si, sa vetĂ«m dalja nga njĂ« redaktor tĂ« tillĂ« tekstual tĂ« njohur. Vim, pyetja e lidhur me kĂ«tĂ« ka grumbulluar tashmĂ« mĂ« shumĂ« se 1.8 milion shikime nĂ« 6 vjet. Distribuuesit kryesorĂ« (edicionet) e kĂ«tij familjeje janĂ«: Debian - njĂ« distribucion i njohur, versionet e pakove nĂ« tĂ« orientohen kryesisht nĂ« LTS (Long Term Support â mbĂ«shtetje pĂ«r njĂ« kohĂ« tĂ« gjatĂ«), e cila shprehet nĂ« besueshmĂ«rinĂ« dhe stabilitetin e sistemit dhe pakove; Ubuntu â pĂ«rmban distribucionet e tĂ« gjitha pakove nĂ« versionet e tyre tĂ« fundit, gjĂ« qĂ« mund tĂ« ndikojĂ« nĂ« stabilitetin, megjithatĂ« lejon pĂ«rdorimin e funksionalitetit qĂ« ofrohet me versionet e reja; Red Hat Enterprise Linux - OS, e pozicionuar pĂ«r pĂ«rdorim tregtar, Ă«shtĂ« me pagesĂ«, megjithatĂ« pĂ«rfshin mbĂ«shtetje nga ofruesit e softuerit, disa paketa proprietar dhe paketa drajverash; CentOS - opensource variacion i Red Hat Enterprise Linux, dallohet nga mungesa e paketeve proprietar dhe mbĂ«shtetjes.
Për ata që sapo po e mësojnë këtë fushë, rekomandimi im do të ishin sistemet Windows Server, ose Ubuntu. Nëse shqyrtojmë Windows, kjo në radhë të parë është njohja e sistemit, Ubuntu - më shumë tolerancë ndaj përditësimeve, dhe nga ana tjetër, për shembull, më pak probleme kur nisni projekte në teknologji që kërkojnë versionet e reja.
Pra, pasi të kemi përcaktuar OS-në, le të kalojmë në grupin e mjeteve që lejojnë vendosjen (instalimin), përditësimin dhe monitorimin e gjendjes së aplikacionit ose pjesëve të tij në server.
Vendimi tjetĂ«r i rĂ«ndĂ«sishĂ«m do tĂ« jetĂ« â vendosja e aplikacionit tuaj dhe serverit pĂ«r kĂ«tĂ«. Aktualisht, tre rrugĂ« mĂ« tĂ« zakonshme janĂ«:
- Të hostohet (mbahen) serverin vetë, - opsioni më ekonomik, por do të duhet të porositni nga ofruesi një IP statike, në mënyrë që burimi juaj të mos ndryshojë adresën me kalimin e kohës.
- TĂ« marrĂ«sh me qira njĂ« Server tĂ« Dedikuar (VDS) â dhe tĂ« merresh vetĂ« me administrimin dhe skalimin e ngarkesave.
- Paguani një abonim në ndonjë shërbim të cloud hosting, ku modeli i pagesës për burime të përdorura është mjaft i zakonshëm. Disa nga përfaqësuesit më të njohur të këtij sektori janë: Amazon AWS (ofron një vit falas me kufizim mujor), Google Cloud (ofron 300$ në llogari, të cilat mund të shpenzohen brenda një viti për shërbimet e cloud-it e hostimit), Yandex.Cloud (ofron 4000 rubla për 2 muaj), Microsoft Azure (ofron akses falas në shërbimet më të njohura për një vit, + 12,500 rubla për çdo shërbim për një muaj). Kështu, mund të provoni çdo nga këta ofrues, pa shpenzuar asnjë qindarkë, por duke marrë një ide të përgjithshme mbi cilësinë dhe nivelin e shërbimeve të ofruara.
NĂ« varĂ«si tĂ« rrugĂ«s sĂ« zgjedhur, faktori qĂ« pĂ«rcakton pĂ«rgjegjĂ«sitĂ« pĂ«r fushat e ndryshme tĂ« administratĂ«s do tĂ« ndryshojĂ«. NĂ«se e hostoni vetĂ«, duhet tĂ« kuptoni se çdo ndĂ«rprerje me energjinĂ« elektrike, internetin, serverin vetĂ«, ose softuerin e instaluar mbi tĂ« â janĂ« plotĂ«sisht nĂ« duar tuaja. MegjithatĂ«, pĂ«r qĂ«llime mĂ«simore dhe testimi, kjo Ă«shtĂ« mĂ« se e mjaftueshme.
Nëse nuk keni një makinë shtesë që mund të shërbejë si server, atëherë do të dëshironit të shfrytëzoni rrugën e dytë ose të tretë. Rasti i dytë është i ngjashëm me të parin, me përjashtimin se e transferoni përgjegjësinë për disponueshmërinë e serverit dhe kapacitetit tek hostuesi. Administrimi i serverit dhe softuerit është ende nën kontrollin tuaj.
Dhe përfundimisht, opsioni për të marrë me qira kapacitetet e ofruesve të cloud. Këtu mund të konfiguroni menaxhimin automatizuar të praktikisht gjithçkaje, pa u thelluar shumë në nuancat teknike. Për më tepër, në vend të një mausin, mund të keni disa instanca të funksionuara paralelisht (shembuj), të cilat mund, p.sh., të përgjigjen për pjesë të ndryshme të aplikacionit, ndërsa nuk do të ndryshojnë shumë në kosto nga posedimi i një serveri të dedikuar. Gjithashtu, këtu janë në dispozicion vegëza për orkestrimin, kontenerizimin, automatizimin e deploy-it, integrimin e vazhdueshëm dhe shumë të tjera! Disa nga këto do t'i shqyrtojmë më poshtë.
Në përgjithësi, infrastruktura e serverit duket si më poshtë: ne kemi atë që quhet "orchestrator" ("orchestrimi" - procesi i menaxhimit të disa instancave të serverëve), që menaxhon ndryshimet në ambientin e instancës së serverit, një kontenier virtualizimi (opcional, por shumë shpesh i përdorur), që lejon ndarjen e aplikacionit në shtresa logjike të izoluara, dhe softuer për Integrim të Vazhdueshëm - që lejon përditësimin e kodit të vendosur përmes "skenarëve".
Pra, orchestrimi ju lejon të shihni statuset e serverëve, të kryeni "në gjithë" ose "rënien" e përditësimeve të ambientit të serverit, dhe kështu me radhë. Në fillim, ky aspekt do të ndodhetyrshë nuk do t'ju preki, sepse për të orkestruar diçka, nevojiten disa serverë (mund të ketë edhe një, por përse nevojitet?), dhe për të pasur disa serverë, nevojitet një nevojë për ta. Nga mjetet në këtë drejtim, më të njohurit janë Kubernetes, i zhvilluar Google.
Hapi tjetĂ«r Ă«shtĂ« virtualizimi nĂ« nivelin e OS. Tani Ă«shtĂ« bĂ«rĂ« e zakonshme koncepti i "dockerizimit", i cili erdhi nga mjeti Docker, i ofron funksionalitetin e kontejnerĂ«ve tĂ« izoluar nga njĂ«ri-tjetri, por qĂ« funksionojnĂ« nĂ« kontekstin e njĂ« sistemi operativ. ĂfarĂ« do tĂ« thotĂ« kjo: nĂ« secilin prej kĂ«tyre kontejnerĂ«ve mund tĂ« aktivizohet njĂ« aplikacion, ose madje njĂ« grup aplikacionesh, tĂ« cilat do tĂ« besojnĂ« se janĂ« tĂ« vetmet nĂ« tĂ« gjithĂ« OS-nĂ«, pa dyshuar fare pĂ«r ekzistencĂ«n e dikujt tjetĂ«r nĂ« kĂ«tĂ« makinĂ«. Kjo funksion Ă«shtĂ« shumĂ« e dobishme si pĂ«r ekzekutimin e aplikacioneve tĂ« njĂ«jta nĂ« versione tĂ« ndryshme, ose pĂ«r aplikacione qĂ« kanĂ« konflikte, si dhe pĂ«r ndarjen e pjesĂ«ve tĂ« aplikacioneve nĂ« nivele. Ky shpĂ«rndarje i niveleve, mĂ« vonĂ« mund tĂ« ruhet nĂ« njĂ« imazh, i cili mund tĂ« pĂ«rdoret, pĂ«r shembull, pĂ«r ndarjen e aplikacionit. Pra, duke instaluar kĂ«tĂ« imazh dhe duke aktivizuar kontejnerĂ«t qĂ« ai pĂ«rmban, ju merrni njĂ« mjedis tĂ« gatshĂ«m pĂ«r tĂ« funksionuar aplikacionin tuaj! NĂ« hapat e parĂ« ju mund tĂ« pĂ«rdorni kĂ«tĂ« mjet si pĂ«r qĂ«llime njohĂ«se, ashtu edhe pĂ«r tĂ« marrĂ« pĂ«rfitime reale, duke shpĂ«rndarĂ« logjikĂ«n e aplikacionit nĂ« katĂ«r nivele tĂ« ndryshme. Por, Ă«shtĂ« e nevojshme tĂ« thuhet se dockerizimi nuk Ă«shtĂ« i nevojshĂ«m pĂ«r tĂ« gjithĂ«, dhe jo gjithmonĂ«. Dockerizimi Ă«shtĂ« i justifikuar kur aplikacioni Ă«shtĂ« âi fragmentuarâ, i ndarĂ« nĂ« pjesĂ« tĂ« vogla, çdo njĂ«ra e cila pĂ«rgjigjet pĂ«r njĂ« detyrĂ« tĂ« saj, njĂ« arkitekturĂ« tĂ« ashtuquajtur âmikroshĂ«rbimâ.
PĂ«r mĂ« tepĂ«r, pĂ«rveç sigurimit tĂ« mjedisit, ne duhet tĂ« sigurojmĂ« gjithashtu njĂ« implementim tĂ« duhur tĂ« aplikacionit, qĂ« pĂ«rfshin tĂ« gjitha transformimet e kodit, instalimin e bibliotekave dhe paketeve tĂ« lidhura me aplikacionin, ekzekutimin e testeve, njoftimet pĂ«r kĂ«to operacione etj. KĂ«tu ne duhet tĂ« drejtojmĂ« vĂ«mendjen tonĂ« drejt njĂ« koncepti si âIntegrimi i VazhdueshĂ«mâ (CI â Integrimi i VazhdueshĂ«m). Instrumentet kryesore nĂ« kĂ«tĂ« fushĂ« aktualisht janĂ« Jenkins (njĂ« PO pĂ«r CI, e shkruar nĂ« Java, mund tĂ« duket disi e komplikuar nĂ« fillim), Travis CI (e shkruar nĂ« Ruby, subjektivisht, disi mĂ« e lehtĂ« se Jenkinsâi, megjithatĂ«, akoma kĂ«rkon disa njohuri nĂ« fushĂ«n e konfigurimit tĂ« implementimit), Gitlab CI (e shkruar nĂ« Ruby dhe Go).
Tani, pasi folëm për mjedisin në të cilin do të punojë aplikacioni juaj, është koha të shohim se cilat mjete na ofron bota moderne për krijimin e këtyre aplikacioneve.
Le tĂ« fillojmĂ« me tĂ« parĂ«n: Backend (backend) â pjesa serverore. Zgjedhja e gjuhĂ«s, grupit tĂ« funksioneve thelbĂ«sore dhe strukturĂ«s sĂ« paracaktuar (framework) kĂ«tu pĂ«rcaktohet kryesisht nga preferencat personale, megjithatĂ«, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rmendet pĂ«r shqyrtim (opinioni i autorit pĂ«r gjuhĂ«t Ă«shtĂ« mjaft subjektiv, megjithatĂ« pretendon pĂ«r njĂ« pĂ«rshkrim tĂ« paanshĂ«m):
- Python â njĂ« gjuhĂ« e miqshme pĂ«r pĂ«rdoruesit e rinj, fal shumĂ« gabime, por gjithashtu mund tĂ« jetĂ« mjaft e rreptĂ« me zhvilluesin, pĂ«r tĂ« mos lejuar tĂ« bĂ«j ndonjĂ« gabim tĂ« rĂ«ndĂ«. NjĂ« gjuhĂ« programimi e rritur dhe e menduar, qĂ« u shfaq nĂ« vitin 1991.
- Go â njĂ« gjuhĂ« nga kompania Google, gjithashtu mjaft e miqshme dhe e pĂ«rshtatshme, Ă«shtĂ« gjithashtu e lehtĂ« tĂ« kompilohet dhe tĂ« marrĂ«sh njĂ« skedar ekzekutiv nĂ« çfarĂ«do platforme. Mund tĂ« jetĂ« e thjeshtĂ« dhe e kĂ«ndshme, por gjithashtu mund tĂ« jetĂ« e komplikuar dhe serioze. E freskĂ«t dhe e re, duket relativisht kohĂ«t e fundit, nĂ« vitin 2009.
- Rust â pak mĂ« e vjetĂ«r se kolegu i mĂ«parshĂ«m, u lansua nĂ« vitin 2006, Ă«shtĂ« ende mjaft e re krahasuar me vĂ«llezĂ«rit e saj. E orientuar ndaj zhvilluesve mĂ« me pĂ«rvojĂ«, megjithatĂ«, ende pĂ«rpiqet tĂ« zgjidhĂ« shumĂ« probleme me nivele tĂ« ulĂ«ta pĂ«r programuesin.
- Java â njĂ« veteran i zhvillimit komercial, u shfaq nĂ« vitin 1995, njĂ« nga gjuhĂ«t mĂ« tĂ« pĂ«rdorura aktualisht pĂ«r zhvillimin e aplikacioneve korporative. Me konceptet e saj themelore dhe konfigurimin e rĂ«ndĂ« tĂ« mjedisit tĂ« ekzekutimit, mund tĂ« bĂ«het mjaft e komplikuar pĂ«r fillestarĂ«t.
- ASP.net â njĂ« platformĂ« pĂ«r zhvillimin e aplikacioneve, e lĂ«shuar nga kompania Microsoft. PĂ«r tĂ« shkruar funksionalitetin kryesisht pĂ«rdoret gjuha C# (shkruhet C si Sharp), qĂ« u shfaq nĂ« vitin 2000. NĂ« kompleksitet, Ă«shtĂ« nĂ« nivelin midis Java dhe Rust.
- PHP â fillimisht e pĂ«rdorur pĂ«r paraproçesimin e HTML, aktualisht, ndonĂ«se mban liderĂ«n absolute nĂ« tregun e gjuhĂ«ve, ka njĂ« tendencĂ« nĂ« rĂ«nie tĂ« pĂ«rdorimit. Dallohet pĂ«r pragun e ulĂ«t tĂ« hyrjes, thjeshtĂ«sinĂ« e shkruarjes sĂ« kodit, por nĂ« tĂ« njĂ«jtĂ«n kohĂ«, gjatĂ« zhvillimit tĂ« aplikacioneve mjaft tĂ« mĂ«dha, funksionaliteti i gjuhĂ«s mund tĂ« jetĂ« i pamjaftueshĂ«m.
Dhe pjesa finale e aplikacionit tonĂ« â mĂ« e prekshme pĂ«r pĂ«rdoruesin â Frontend (frontend) â Ă«shtĂ« fytyra e aplikacionit tuaj, pikĂ«risht me kĂ«tĂ« pjesĂ« pĂ«rdoruesi interagjon drejtpĂ«rdrejt.
Pa paqët modernë sot bazohen në tre shtylla, ku fletarët (dhe ndonjëherë më pak) përdoren për të krijuar ndërfaqe përdoruesi. Prandaj, tre më të njohurat janë:
- ReactJS â nuk Ă«shtĂ« njĂ« fletar, por njĂ« bibliotekĂ«. NĂ« thelb, ndan titullin e fletarit vetĂ«m pĂ«r shkak tĂ« mungesĂ«s sĂ« disa funksioneve "nga kutia", si dhe nevojĂ«s pĂ«r t'i instaluar ato manualisht. Prandaj, ka disa variante tĂ« "preparimit" tĂ« kĂ«saj biblioteke, qĂ« formojnĂ« fletarĂ« tĂ« veçantĂ«. Mund tĂ« jetĂ« pak e ndĂ«rlikuar pĂ«r fillestarĂ«t pĂ«r shkak tĂ« disa parimeve bazĂ«, si dhe konfigurimit mjaft agresiv tĂ« ambientit tĂ« ndĂ«rtimit. MegjithatĂ«, pĂ«r njĂ« fillim tĂ« shpejtĂ«, mund tĂ« pĂ«rdorni paketĂ«n "create-react-app".
- VueJS â Ă«shtĂ« fletar pĂ«r ndĂ«rtimin e ndĂ«rfaqeve tĂ« pĂ«rdoruesit. Nga kjo trio, me meritĂ« fiton titullin e fletarit mĂ« miqĂ«sor pĂ«r pĂ«rdoruesin, sepse pĂ«r zhvillimin nĂ« Vue, pragu i hyrjes Ă«shtĂ« mĂ« i ulĂ«t se ai i kolegĂ«ve tĂ« tjerĂ«. PĂ«r mĂ« tepĂ«r, ai Ă«shtĂ« mĂ« i riu mes tyre.
- Angular â konsiderohet si mĂ« i komplikuari nga fletarĂ«t e pĂ«rmendur, i vetmi qĂ« kĂ«rkon TypeScript (njĂ« shtresĂ« mbi gjuhĂ«n Javascript). Shpesh pĂ«rdoret pĂ«r tĂ« ndĂ«rtuar aplikacione tĂ« mĂ«dha korporative.
Duke pĂ«rmbledhur atĂ« qĂ« u tha mĂ« lart, mund tĂ« arrijmĂ« nĂ« pĂ«rfundimin se tani ndĂ«rtimi i njĂ« aplikacioni Ă«shtĂ« radikalisht ndryshe nga mĂ«nyra se si ky proces ka ndodhur mĂ« parĂ«. MegjithatĂ«, askush nuk ndalon qĂ« tĂ« bĂ«het "deploi" nĂ« mĂ«nyrĂ«n e vjetĂ«r. Por a ia vlen njĂ« pjesĂ« e kohĂ«s sĂ« kursyer nĂ« fillim â njĂ« sasi tĂ« madhe pengesash me tĂ« cilat do tĂ« pĂ«rballet zhvilluesi qĂ« ka zgjedhur kĂ«tĂ« rrugĂ«? UnĂ« mendoj se pĂ«rgjigjja Ă«shtĂ« "jo". Duke shpenzuar pak mĂ« shumĂ« kohĂ« pĂ«r t'u njohur me kĂ«to mjete (dhe mĂ« shumĂ« nuk Ă«shtĂ« e nevojshme, pasi ju duhet tĂ« kuptoni nĂ«se ju nevojiten nĂ« projektin aktual apo jo), do tĂ« mund t'i rikuperoni ato, duke reduktuar ndjeshĂ«m, pĂ«r shembull, rastet e gabimeve fantazmĂ« qĂ« varen nga ambienti dhe shfaqen vetĂ«m nĂ« serverat e prodhimit, analizat e natĂ«s, se çfarĂ« e solli rĂ«nien e serverit, dhe pse ai nuk fillon, dhe shumĂ« tĂ« tjera.
Burimi: habr.com
