PĂ«r tĂ« krijuar aplikacionin tuaj web sot, nuk mjafton tĂ« dini si ta zhvilloni atĂ«. NjĂ« aspekt i rĂ«ndĂ«sishĂ«m Ă«shtĂ« konfigurimi i mjeteve pĂ«r implementimin e aplikacionit, monitorimin, si dhe menaxhimin dhe administrimin e mjedisit nĂ« tĂ« cilin ai punon. Epoka e implementimeve manuale po shuhet, madje edhe pĂ«r projekte tĂ« vogla, mjetet e automatizimit mund tĂ« sjellin pĂ«rfitime tĂ« konsiderueshme. Kur implementojmĂ« 'me dorĂ«', shpesh mund tĂ« harrojmĂ« tĂ« transferojmĂ« diçka, tĂ« marrim parasysh ndonjĂ« nuancĂ«, ose tĂ« ekzekutojmĂ« njĂ« test tĂ« haruar â ky listĂ« mund tĂ« vazhdojĂ« mjaft gjatĂ«.
Ky artikull mund të ndihmojë ata që sapo po mësojnë bazat e krijimit të aplikacioneve web dhe duan të kuptojnë pak më shumë rreth terminologjisë dhe konventave themelore.
Pra ndërtimin e aplikacioneve mund të ndajmë në 2 pjesë, ajo që lidhet me kodin e aplikacionit dhe ajo që lidhet me ambientin ku ekzekutohet ky kod. Kodi i aplikacionit gjithashtu ndahet në kodin e serverit (ai që ekzekutohet në server, shpesh: logjika e biznesit, autorizimi, ruajtja e të dhënave, etj.), dhe në kodin e klientit (ai që ekzekutohet në makinën e përdoruesit: shpesh interfejsi dhe logjika e lidhur me të).
Le të fillojmë me ambientin.
Baza për funksionimin e çdo kodi, sistemi, programi është Sistemi Operativ, prandaj më poshtë do të shqyrtojmë sistemet më të njohura që ofrohen në tregun e hostimit dhe do t'i japim një përshkrim të shkurtër:
Windows Server â ajo vetĂ« Windows, por nĂ« versionin server. Disa funksione qĂ« janĂ« tĂ« pranishme nĂ« versionin e zakonshĂ«m tĂ« Windows nuk janĂ« kĂ«tu, pĂ«r shembull, disa shĂ«rbime pĂ«r mbledhjen e statistikave dhe lloje tĂ« ngjashme tĂ« softuerit, por Ă«shtĂ« i pranishĂ«m njĂ« grup mjetesh pĂ«r administrimin e rrjetit, softuer bazik pĂ«r implementim. servera (web, ftp, âŠ). NĂ« thelb, Windows Server duket si njĂ« Windows standard, tingĂ«llon si njĂ« Windows standard, por Ă«shtĂ« dy herĂ« mĂ« i shtrenjtĂ« se ai. MegjithatĂ«, duke marrĂ« parasysh se implementimin e aplikacionit do ta bĂ«ni ndoshta nĂ« njĂ« server tĂ« dedikuar / virtual, kostoja pĂ«r ju mund tĂ« rritet, por jo nĂ« mĂ«nyrĂ« kritike. Duke marrĂ« parasysh se platforma Windows zĂ« njĂ« vend dominuese 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-sistem tĂ« ngjashĂ«m. Punimi tradicional nĂ« kĂ«to sisteme nuk parashikon njĂ« ndĂ«rfaqe grafike tĂ« njohur, duke ofruar pĂ«rdoruesit vetĂ«m njĂ« konsol si element kontrolli. PĂ«r njĂ« pĂ«rdorues tĂ« pakĂ«ndshĂ«m, puna nĂ« njĂ« format tĂ« tillĂ« mund tĂ« paraqesĂ« vĂ«shtirĂ«si, çka bĂ«n qĂ« dalja nga njĂ« redaktues teksti mjaft popullor nĂ« kĂ«tĂ« kontekst, Vim, çështja e lidhur me kĂ«tĂ« ka grumbulluar gjatĂ« 6 viteve mĂ« shumĂ« se 1.8 milion shikime. Distribuuesit kryesorĂ« (redaktimet) tĂ« kĂ«saj familjeje janĂ«: Debian â njĂ« distribucion popullor, versionet e paketimeve nĂ« tĂ« janĂ« tĂ« orientuara kryesisht ndaj LTS (Long Term Support â mbĂ«shtetje pĂ«r njĂ« kohĂ« tĂ« gjatĂ«), qĂ« shpreh njĂ« besueshmĂ«ri dhe stabilitet tĂ« mjaftueshĂ«m tĂ« sistemit dhe pakove; Ubuntu â pĂ«rmban distribuime tĂ« tĂ« gjitha pakove nĂ« versionet e tyre mĂ« tĂ« fundit, gjĂ« qĂ« ndikon nĂ« stabilitet, megjithatĂ« lejon pĂ«rdorimin e funksionaliteteve qĂ« ofrohen me versionet e reja; Red Hat Enterprise Linux â OS, e pozicionuar pĂ«r pĂ«rdorim komercial, Ă«shtĂ« me pagesĂ«, megjithatĂ« pĂ«rfshin mbĂ«shtetje nga ofruesit e softuerit, disa paketa pronĂ«sore dhe paketa drejtuese; CentOS â opensource variacioni i Red Hat Enterprise Linux, e dalluar nga mungesa e pakove pronĂ«sore dhe mbĂ«shtetjes.
PĂ«r ata qĂ« vetĂ«m po fillojnĂ« tĂ« mĂ«sojnĂ« kĂ«tĂ« fushĂ«, rekomandimi im do tĂ« jenĂ« sistemet Windows Server, ose Ubuntu. NĂ«se shqyrtojmĂ« Windows, kjo Ă«shtĂ« nĂ« radhĂ« tĂ« parĂ« njohja me sistemin, Ubuntu â mĂ« shumĂ« tolerant ndaj pĂ«rditĂ«simeve, dhe pĂ«r kĂ«tĂ« arsye, pĂ«r shembull, mĂ« pak probleme gjatĂ« lansimit tĂ« projekteve qĂ« kĂ«rkojnĂ« versione tĂ« reja.
Pra, pasi të jemi përcaktuar me OS-në, kalojmë në një grup mjetesh që lejojnë të vendosim (instalojmë), përditësojmë dhe monitorojmë gjendjen e aplikacionit ose pjesëve të tij në server.
Zgjidhja tjetër e rëndësishme do të jetë vendosja e aplikacionit tuaj dhe serverit për të. Aktualisht, ka tri mënyra më të zakonshme:
- TĂ« hostoni (mbani) serverin vetĂ« â opsioni mĂ« ekonomik, por do t'ju duhet tĂ« porosisni njĂ« IP tĂ« palĂ«vizshme nga ofruesi, nĂ« mĂ«nyrĂ« qĂ« burimi juaj tĂ« mos ndryshojĂ« adresĂ«n me kalimin e kohĂ«s.
- TĂ« merrni me qira njĂ« Server tĂ« Dedikuar (VDS) â dhe tĂ« merret vetĂ« me administrimin dhe shkallĂ«zimin e ngarkesave.
- TĂ« paguani njĂ« abonim nĂ« ndonjĂ« hosting cloud, ku modeli i pagesĂ«s pĂ«r burimet e pĂ«rdorura Ă«shtĂ« shumĂ« i zakonshĂ«m. Disa nga ofruesit mĂ« tĂ« njohur janĂ«: Amazon AWS (ofrojnĂ« njĂ« vit falas pĂ«rdorimi, por me njĂ« kufi nĂ« muaj), Google Cloud (ofrojnĂ« 300 dollarĂ« nĂ« llogari, tĂ« cilat mund tĂ« shpenzohen brenda njĂ« viti pĂ«r shĂ«rbimet e cloud-it). hosting), Yandex.ĐблаĐșĐŸ (ofron me 4000 rubla pĂ«r 2 muaj), Microsoft Azure (ofron qasje falas nĂ« shĂ«rbime tĂ« njohura pĂ«r njĂ« vit, + 12,500 rubla pĂ«r çdo shĂ«rbim gjatĂ« njĂ« muaji). NĂ« kĂ«tĂ« mĂ«nyrĂ«, ju mund tĂ« provoni çdonjĂ«rin nga kĂ«ta ofrues pa shpenzuar asnjĂ« qindarkĂ«, por duke marrĂ« njĂ« ide pĂ«r cilĂ«sinĂ« dhe nivelin e shĂ«rbimeve qĂ« ofrojnĂ«.
NĂ« pĂ«rputhje me rrugĂ«n e zgjedhur, ndryshon vetĂ«m fakti se kush, kryesisht, ka pĂ«rgjegjĂ«sinĂ« pĂ«r atĂ« ose kĂ«tĂ« fushĂ« tĂ« administratĂ«s. NĂ«se e hostoni vetĂ«, duhet tĂ« kuptoni se çdo ndĂ«rprerje me energjinĂ« elektrike, internetin, serverin vetĂ«, ose programin qĂ« Ă«shtĂ« instaluar mbi tĂ« â kĂ«to janĂ« plotĂ«sisht nĂ« duar tĂ« tuat. MegjithatĂ«, pĂ«r mĂ«sim dhe testim, kjo Ă«shtĂ« mĂ« se e mjaftueshme.
Nëse nuk keni një makinë të tepërt që mund të luajë rolin e një serveri, atëherë do të dëshironit të shfrytëzoni rrugën e dytë ose të tretë. Rastin e dytë është identik me të parin, përveç se ju e trasferoni përgjegjësinë për disponueshmërinë e serverit dhe fuqinë e tij mbi shpatullat e hosit. Administrimi i serverit dhe i programit mbetet ende në kontrollin tuaj.
Dhe në fund, ka opsioni për qiranë e kapaciteteve nga ofruesit e cloud. Këtu mund të konfiguroni menaxhimin automatizues të praktikisht çfarëdo, pa u përfshirë shumë në nuancat teknike. Gjithashtu, në vend të një makine, mund të keni disa instanca të lansuara paralelisht (ekzemplarë), të cilat mund, për shembull, të marrin përsipër pjesë të ndryshme të aplikacionit, ndërsa nuk gjithashtu nuk dallojnë shumë në çmim nga zotërimi i një serveri të dedikuar. Po ashtu, këtu ka mjete orkestrimi, kontenierizimi, deploy automatik, integrim të vazhdueshëm dhe shumë më tepër! Disa nga këto gjëra do t'i shqyrtojmë më poshtë.
NĂ« pĂ«rgjithĂ«si, infrastruktura e serverit duket si mĂ« poshtĂ«: kemi njĂ« "orkestrues" ("orkestrimi" â procesi i menaxhimit tĂ« disa instancave tĂ« serverĂ«ve), i cili drejton ndryshimet nĂ« mjedis nĂ« instancĂ«n e serverit, njĂ« konteiner virtualizimi (opsional, por mjaft shpesh i pĂ«rdorur), duke lejuar ndarjen e aplikacionit nĂ« shtresa logjike tĂ« izoluara, dhe njĂ« softuer pĂ«r Integrimin e PandĂ«rprerĂ« â i cili lejon pĂ«rditĂ«simin e kodit tĂ« vendosur nĂ«pĂ«rmjet "skenarĂ«ve".
Tani, orkestrimi ju lejon të shihni statuset e serverëve, të bëni "përditësime", ose "rënien" e përditësimeve të mjedisit të serverit, dhe kështu me radhë. Në fillim, ky aspekt do të ndikohet ndoshta shumë pak, pasi për të orkestruar diçka nevojiten disa serverë (mund të ketë edhe një, por për çfarë do të ishte kjo?), dhe për të pasur disa serverë, duhet të ketë një nevojë për ta. Nga mjetet e këtij drejtimi, në mendje shpesh vjen Kubernetes, i zhvilluar. Google.
Hapi tjetĂ«r Ă«shtĂ« virtualizimi nĂ« nivelin e OS. Aktualisht, koncepti i "dockers" Ă«shtĂ« pĂ«rhapur gjerĂ«sisht, i cili ka ardhur nga mjeti Docker, qĂ« ofron funksionalitet tĂ« kontejnerĂ«ve tĂ« izoluar nga njĂ«ri-tjetri, por qĂ« funksionojnĂ« nĂ« kontekstin e njĂ« sistemi tĂ« vetĂ«. ĂfarĂ« do tĂ« thotĂ« kjo: nĂ« secilin prej kĂ«tyre kontejnerĂ«ve mund tĂ« nisni njĂ« aplikacion, ose madje njĂ« grup aplikacionesh, tĂ« cilat do tĂ« mendonin se janĂ« tĂ« vetmet nĂ« tĂ« gjithĂ« sistemin operativ, pa u dyshuar pĂ«r ekzistencĂ«n e ndonjĂ« 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 thjesht pĂ«r aplikacione qĂ« kanĂ« konflikte, ashtu edhe pĂ«r ndarjen e pjesĂ«ve tĂ« aplikacionit nĂ« shtresa. Ky mold i shtresave mund tĂ« regjistrohet mĂ« vonĂ« nĂ« njĂ« imazh, qĂ« pĂ«rdoret, pĂ«r shembull, pĂ«r implementimin e aplikacionit. KĂ«shtu, duke instaluar kĂ«tĂ« imazh dhe duke aktivizuar kontejnerĂ«t qĂ« ai pĂ«rmban, merrni njĂ« mjedis tĂ« gatshĂ«m pĂ«r ekzekutimin e aplikacionit tuaj! NĂ« hapat e parĂ« mund tĂ« pĂ«rdorni kĂ«tĂ« mjet si pĂ«r qĂ«llime informuese, ashtu edhe pĂ«r tĂ« marrĂ« pĂ«rfitime reale, duke ndarĂ« logjikĂ«n e aplikacionit nĂ« shtresa tĂ« ndryshme. Por, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se dockerizimi nuk Ă«shtĂ« i nevojshĂ«m pĂ«r tĂ« gjithĂ« dhe jo gjithmonĂ«. Dockerizimi Ă«shtĂ« i justifikuar nĂ« rastet kur aplikacioni Ă«shtĂ« 'fragmenduar', i ndarĂ« nĂ« pjesĂ« tĂ« vogla, secila pĂ«rgjegjĂ«se pĂ«r detyrĂ«n e saj, e ashtuquajtura 'arkitekturĂ« mikroshĂ«rbimesh'.
PĂ«rveç sigurimit tĂ« mjedisit, na nevojitet gjithashtu njĂ« implementim i duhur i 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 dhe kĂ«shtu me radhĂ«. KĂ«tu duhet tĂ« kushtojmĂ« vĂ«mendje njĂ« koncepti si «Integrimi i VazhdueshĂ«m» (CI â Integrimi i VazhdueshĂ«m). Instrumentet kryesore nĂ« kĂ«tĂ« fushĂ« aktualisht janĂ« Jenkins (njĂ« P.O. pĂ«r CI, e shkruar nĂ« Java, qĂ« mund tĂ« duket pak e komplikuar nĂ« fillim), Travis CI (e shkruar nĂ« Ruby, subektivisht, pak 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).
Pra, pasi folëm për mjedisin ku do të punojë aplikacioni juaj, është koha për të parë se çfarë instrumentesh na ofron bota moderne për krijimin e këtyre aplikacioneve.
TĂ« nisim me tĂ« parin: Backend (back-end) â pjesa serverike. Zgjedhja e gjuhĂ«s, setit tĂ« funksioneve kryesore dhe strukturĂ«s sĂ« paracaktuar (framework) pĂ«rcaktohet kryesisht nga preferencat personale, por megjithatĂ«, ia vlen tĂ« pĂ«rmendet pĂ«r shqyrtim (opinionin e autorit mbi gjuhĂ«t Ă«shtĂ« mjaft subjektiv, edhe pse pretendohet tĂ« jetĂ« njĂ« pĂ«rshkrim i paanshĂ«m):
- Python â njĂ« gjuhĂ« mjaft miqĂ«sore pĂ«r pĂ«rdoruesit e paekspert, fal shumĂ« gabime, por gjithashtu mund tĂ« jetĂ« mjaft e ashpĂ«r me programuesin, qĂ« ai tĂ« mos bĂ«jĂ« ndonjĂ« gjĂ« tĂ« keqe. NjĂ« gjuhĂ« programimi tashmĂ« mjaft e zhvilluar dhe e kuptueshme, qĂ« ka dalĂ« nĂ« vitin 1991.
- Go â njĂ« gjuhĂ« nga kompania Google, gjithashtu mjaft miqĂ«sore dhe e lehtĂ« pĂ«r tu pĂ«rdorur, e thjeshtĂ« pĂ«r tu kompiluara dhe pĂ«r tĂ« marrĂ« njĂ« skedĂ« ekzekutimi nĂ« çdo platformĂ«. Mund tĂ« jetĂ« e thjeshtĂ« dhe e kĂ«ndshme, por gjithashtu e ndĂ«rlikuar dhe serioze. E freskĂ«t dhe e re, u shfaq relativisht kohĂ«t e fundit, nĂ« vitin 2009.
- Rust â pak mĂ« i vjetĂ«r se kolegu i tij i mĂ«parshĂ«m, i lĂ«shuar nĂ« vitin 2006, ende mjaft i ri krahasuar me vĂ«llezĂ«rit e tij. Orientuar drejt programuesve mĂ« tĂ« pĂ«rvojshĂ«m, megjithatĂ«, pĂ«rpiqet tĂ« zgjidhĂ« shumĂ« nga detyrat e nivelit tĂ« ulĂ«t pĂ«r programuesin.
- Java â njĂ« veteran i zhvillimit komercial, qĂ« doli nĂ« vitin 1995, njĂ« nga gjuhĂ«t mĂ« tĂ« pĂ«rdorura pĂ«r zhvillimin e aplikacioneve korporative sot. Me konceptet e tij themelore dhe konfigurimin e komplikuar tĂ« mjedisit tĂ« ekzekutimit, mund tĂ« bĂ«het mjaft e ndĂ«rlikuar pĂ«r fillestarĂ«t.
- ASP.net â njĂ« platformĂ« pĂ«r zhvillimin e aplikacioneve, e lĂ«shuar nga kompania Microsoft. PĂ«r shk writing finansit, pĂ«rdoret kryesisht gjuha C# (shkruhet C si Sharp), e cila doli nĂ« vitin 2000. NĂ« nivelin e saj tĂ« vĂ«shtirĂ«sisĂ«, ajo Ă«shtĂ« e ngjashme me njĂ« nivel ndĂ«rmjet Java dhe Rust.
- PHP â fillimisht e pĂ«rdorur pĂ«r parapĂ«rpunimin e HTML, ndonĂ«se tani mbetet nĂ« krye tĂ« tregut tĂ« gjuhĂ«ve, ka njĂ« tendencĂ« nĂ« rĂ«nie tĂ« pĂ«rdorimit. Karakterizohet nga njĂ« kufi tĂ« ulĂ«t hyrjeje, lehtĂ«sinĂ« e shkruarjes sĂ« kodit, por nĂ« tĂ« njĂ«jtĂ«n kohĂ«, nĂ« zhvillimin e aplikacioneve tĂ« mĂ«dha, funksionaliteti i gjuhĂ«s mund tĂ« jetĂ« jo mjaftueshĂ«m.
Dhe pjesa finale e aplikacionit tonĂ« â mĂ« e prekshme pĂ«r pĂ«rdoruesin â Frontend (frontend) â Ă«shtĂ« fytyra e aplikacionit tuaj, kjo Ă«shtĂ« ajo pjesĂ« me tĂ« cilĂ«n pĂ«rdoruesi ndĂ«rvepron drejtpĂ«rdrejt.
Pa mos u theksuar në detaje, frontend-i modern bazohet në tre shtylla, framework-e (dhe jo vetëm), për krijimin e ndërfaqeve përdoruesi. Prandaj, tre më të njohurat janë:
- ReactJS â nuk Ă«shtĂ« njĂ« framework, por njĂ« bibliotekĂ«. NĂ« fakt, ndan nga titulli i krenar i njĂ« framework-u vetĂ«m pĂ«r shkak tĂ« mungesĂ«s sĂ« disa funksioneve "nga kutia", dhe nevojĂ«s pĂ«r t'i instaluar ato manualisht. KĂ«shtu, ka disa variante tĂ« "pĂ«rgatitjes" sĂ« kĂ«saj biblioteke, qĂ« formojnĂ« framework-e tĂ« veçantĂ«. PĂ«r njĂ« fillestar mund tĂ« jetĂ« pak e vĂ«shtirĂ«, pĂ«r shkak tĂ« disa principeve bazĂ« 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Ă« njĂ« framework pĂ«r ndĂ«rtimin e ndĂ«rfaqeve pĂ«rdoruesi. Nga kjo trio, me tĂ« drejtĂ« merr titullin e framework-ut mĂ« miqĂ«sor pĂ«r pĂ«rdoruesin, sepse pĂ«r zhvillimin nĂ« Vue, pragun e hyrjes Ă«shtĂ« mĂ« tĂ« ulĂ«t se ai i tĂ« tjerĂ«ve. PĂ«r mĂ« tepĂ«r, ai Ă«shtĂ« mĂ« i riu mes tyre.
- Angular â konsiderohet mĂ« i komplikuari nga tĂ« dhĂ«nĂ« framework-e, i vetmi qĂ« kĂ«rkon TypeScript (shtesĂ« mbi gjuhĂ«n Javascript). Shpesh pĂ«rdoret pĂ«r ndĂ«rtimin e aplikacioneve tĂ« mĂ«dha pĂ«rfaqĂ«suese.
Duke përmbledhur, mund të konkludojmë se tani deployimi i aplikacioneve ndryshe nga si ka qenë më parë. Megjithatë, askush nuk e ndalon implementimin e 'deploy' sipas mënyrës tradicionale. Por a ia vlen pakko e kursyer në fillim për një numër të madh problemesh që do të hasë zhvilluesi që e ka zgjedhur këtë rrugë? Mendoj se përgjigjja është 'jo'. Duke kaluar pak më shumë kohë për të mësuar këto mjete (dhe nuk kërkohet më shumë, sepse duhet të kuptoni nëse ju nevojiten në projektin aktual ose jo), ju do të pastroni kohën tuaj, duke reduktuar ndjeshëm, për shembull, rastet e gabimeve fantazmë që varen nga mjedisi dhe shfaqen vetëm në serverin e prodhimit, analizave të natës për të kuptuar se çfarë e arriti rënien e serverit, dhe pse ai nuk po aktivizohet, dhe shumë gjëra të tjera.
Burimi: habr.com
