Veebirakenduste loomise ja avaldamise kontrolnimekiri

Tänapäeval ei piisa veebirakenduse loomiseks selle arendamise oskusest. Oluline on ka seadistada tööriistad rakenduse juurutamiseks, jälgimiseks ning keskkonna haldamiseks ja administreerimiseks, kus see töötab. Kämanualkatermine jääb minevikku, isegi väikeste projektide puhul võivad automatiseerimistööriistad tuua märkimisväärset kasu. Manuaalse juurutamise puhul unustame sageli midagi üle kanda, arvesse võtta teatud nüanssi või käivitada ununenud test, ja see nimekiri võib olla üsna pikk.

See artikkel võib olla abiks neile, kes alles õpivad veebirakenduste loomise aluseid ja soovivad pisut paremini mõista põhitermineid ja konventsioone.

Seega jaguneb rakenduste loomine kaheks osaks: kõik, mis on seotud rakenduse koodiga, ja kõik, mis on seotud keskkonnaga, kus see kood töötab. Rakenduse kood jaguneb omakorda serveripoolseks (see, mis töötab serveris, sageli: äriloogika, autoriseerimine, andmete salvestamine jne) ja kliendipoolseks (see, mis töötab kasutaja masinas: sageli liides ja sellega seotud loogika).

Alustame võib-olla keskkonnast.

Iga koodi, süsteemi või tarkvara töö aluseks on operatsioonisüsteem, seetõttu vaatame allpool kõige populaarsemaid süsteeme, mis on turul olemas, ja anname neile lühikese iseloomustuse:

Windows Server – see sama Windows, aga serveriversioonis. Mõned funktsioonid, mis on saadaval kliendi (tavalises) versioonis, ei ole siin kohal, näiteks mõned statistikakogumise teenused ja sarnased rakendused, kuid selle asemel on olemas komplekt võrgu haldamise utiliite, põhitäitmine tarkvara jaoks. serverite (web, ftp, …). Üldiselt tundub Windows Server nagu tavaline Windows, see käivitub nagu tavaline Windows, kuid maksab kaks korda rohkem kui tema tavaline vend. Arvestades, et rakenduse käitamine toimub tõenäoliselt pühendatud/virtuaalsel serveril, võib lõplik hind teie jaoks tõusta, kuid mitte kriitiliselt. Kuna Windowsi platvorm hõivab suure osa kasutajate operatsioonisüsteemide turust, on selle serveriversioon enamiku kasutajate jaoks kõige harjumuslikum.

Unix-sarnane süsteem. Traditsiooniline töö nendes süsteemides ei eelda tuttava graafilise kasutajaliidese olemasolu, pakkudes kasutajale juhtelemendiks vaid konsooli. Kogenematule kasutajale võib selline formaat olla raske, mida tõestab ka küsimus, mis on seotud ühe populaarse tekstiredaktoriga Vim, mis on 6 aastaga kogunud üle 1.8 miljoni vaatamise. Selle perekonna peamised distributsioonid (väljaanded) on järgmised: Debian — populaarne distributsioon, mille paketiversioonid on suunatud peamiselt LTS (Long Term Support – pika toetust), mis väljendub süsteemi ja paketide piisavas usaldusväärsuses ja stabiilsuses; Ubuntu – sisaldab kõiki pakettide jaotusi nende uusimates versioonides, mis võib mõjutada stabiilsust, kuid võimaldab kasutada uusimate versioonidega kaasnevaid funktsioone; Red Hat Enterprise Linux – operatsioonisüsteem, mis on suunatud äriliseks kasutamiseks, on tasuline, kuid sisaldab toetust tarkvaratootjatelt, mõningaid proprietaalseid pakette ja draiverite pakette; CentOS – avatud lähtekoodiga variant Red Hat Enterprise Linux, millel puuduvad proprietaarsed paketid ja tugi.

Algajatele soovitan süsteeme Windows Server, või Ubuntu. Kui proovida Windowsit, siis eelkõige selle süsteemi tuttavlikkus, Ubuntu – suurem taluvus värskenduste suhtes, mille tulemuseks on vähem probleeme projektide käivitamisel uuemaid versioone vajavatel tehnoloogiatel.

Nii et pärast operatsioonisüsteemi valimist liigume edasi tööriistade komplekti suunas, mis võimaldavad rakenduse või selle osade paigaldamist, värskendamist ja oleku jälgimist serveris.

Järgmine oluline otsus on teie rakenduse ja selle serveri paigutamine. Praegu on kolm kõige levinumat teed:

• Hostida serverit endal — see on kõige soodsam valik, kuid tuleb tellida teenuselt staatiline IP, et teie ressursi aadress ei muutuks ajas.
• Rendi Dedikeeritud Server (VDS) ja hallake seda ise, sealhulgas koormuse suurendamine.
• Maksta (tihti pakuvad tasuta prooviperioodi platvormi funktsioonide testimiseks) tellimuse eest mõnes pilvehostingus, kus on laialt levinud tasu maksmine kasutatud ressursside eest. Seda suunda esindavad kõige paremini: Amazon AWS (pakuvad tasuta aastase kasutuse, kuid piiranguga kuus), Google Cloud (pakuvad 300 dollarit kontole, mida saab aasta jooksul pilveteenuste eest kasutada). hostingu), Yandex.Cloud (annavad 4000 rubla 2 kuu jooksul), Microsoft Azure (annavad tasuta juurdepääsu populaarsetele teenustele aastaks, + 12 500 rubla kõigile teenustele ühe kuu jooksul). Niisiis, saate proovida ükskõik millist neist teenusepakkujatest, kulutamata sentigi, kuid saamata umbkaudset arusaamist kvaliteedist ja teenuse tasemest.

Valitud teest sõltuvalt muutub edaspidi ainult see, kellel on enamasti vastutus konkreetse haldamisala eest. Kui hostite ise, peate mõistma, et kõik elektri-, Interneti-, serveri- ja sellele installitud tarkvara katkestused langevad täielikult teie õlule. Siiski on see õppimiseks ja katsetamiseks rohkem kui piisav.

Kui aga teil ei ole vaba masinat, mis võiks serverina toimida, siis soovite kasutada teist või kolmandat teed. Teine juhtum on identne esimesele, välja arvatud see, et te kandate serveri kättesaadavuse ja selle jõudluse vastutuse hosti õlule. Serveri ja tarkvara haldamine jääb siiski teie kontrolli alla.

Ja lõpuks, variatsioon pilveteenuste pakkujate ressursside rentimiseks. Siin saate seadistada automatiseeritud juhtimise peaaegu igasuguste toimingute jaoks, ilma et peaksite sügavale tehnilistesse detailidesse minema. Lisaks, ühe masina asemel võite omada mitut paralleelselt töötavat instantsi, mis võivad näiteks vastutada rakenduse erinevate osade eest, samas ei erine hinnakujundus oluliselt pühendatud serveri omamisest. Ja veel, siin on saadaval orkestreerimise, konteineriseerimise, automaatse juurutamise, pideva integreerimise ja palju muu tööriistad! Mõned neist asjadest vaatleme allpool.

Üldiselt näeb serveri infrastruktuur välja järgmine: meil on nii nimetatud „orkestrator” („orkestreerimine“ – protsess, millega haldatakse mitme serveri instantsi), mis haldab keskkonna muudatusi serveri instantsis, virtualiseerimise konteiner (valikuline, kuid sageli kasutatav), mis võimaldab rakendust jagada isoleeritud loogiliste kihtideks, ja pideva integreerimise tarkvara – mis võimaldab juurutada paigaldatud koodi „skeemide” kaudu.

Nii et orkestreerimine võimaldab Teil näha serverite staatuseid, teostada keskkonna uuendusi, nagu „rakendamine” või „tagasivõtmine”, ja nii edasi. Alguses ei puutu see teema Teisse tõenäoliselt, kuna orkestreerimiseks on vajalik mitu serverit (võib olla ka üks, aga milleks see on vajalik?), ja et oleks mitu serverit, peab olema vajadus nende järele. Sellest valdkonnast tuntud tööriist on peamiselt Kubernetes, mille on välja töötanud. Google.

Järgmine samm on virtuaalsus operatsioonisüsteemi tasandil. Praegu on laialdaselt levinud mõisted „dookerlus”, mis tuleneb tööriistast. Docker, mis pakub isoleeritud konteinerite funktsionaalsust, mis töötavad ühe operatsioonisüsteemi kontekstis. Mis see tähendab: igas sellises konteineris saab käivitada rakenduse või isegi rakenduste komplekti, mis arvavad, et nad on ainsad kogu operatsioonisüsteemis, teadmata, et teised samal masinal eksisteerivad. See funktsioon on väga kasulik nii erinevate versioonide sama rakenduse käivitamiseks kui ka lihtsalt konflikti põhjustavate rakenduste eraldamiseks ning rakenduse osade kihtideks jagamiseks. See kihistumise jäljend, mida hiljem saab salvestada kujutisse, mida saab kasutada, näiteks rakenduse juurutamiseks. Seega, kui installite selle kujutise ja käivitate selle sisaldavad konteinerid, saate valmis keskkonna oma rakenduse käivitamiseks! Alguses võite seda tööriista kasutada nii tutvumiseks kui ka reaalse kasu saamiseks, jagades rakenduse loogikat erinevateks kihtideks. Kuid siin on oluline märkida, et konteineriseerimine ei ole kõigile vajalik ja mitte alati. Konteineriseerimine on õigustatud olukordades, kus rakendus on 'fragmenteeritud', jagunenud väikesteks osadeks, millest igaühe ülesanne on oma, nn 'mikroteenuste arhitektuur'.

Lisaks keskkonna tagamisele on meil vajalik ka rakenduse nõuetekohane juurutamine, mis hõlmab kõiki koodi transformatsioonide teostamist, rakendusega seotud raamatukogude ja paketide installimist, testide läbiviimist, teavitamist nende toimingute kohta ja nii edasi. Siinkohal tuleb meil tähelepanu pöörata sellisele mõistele nagu „Pidev Integreerimine“ (CI – Pidev Integreerimine). Praegu on peamised tööriistad selles valdkonnas Jenkins (CI tarkvara, mis on kirjutatud Java keeles, võib alguses tunduda veidi keeruline), Travis CI (kirjutatud Ruby keeles, subjektiivselt, veidi lihtsam Jenkins’ist, kuid siiski on vajalik mõningane teadmine juurutamise seadistamisest), Gitlab CI (kirjutatud Ruby ja Go).

Nii et pärast arutelu keskkonna üle, kus teie rakendus töötab, on aeg lõpuks vaadata, milliseid tööriistu pakub meile tänapäeva maailm nende rakenduste loomiseks.

Alustame põhitõdedest: Backend (backend) – serveripool. Keel, põhifunktsioonide komplekt ja eelnevalt määratud struktuur (raamistik) sõltuvad siin peamiselt isiklikest eelistustest, kuid tasub siiski mainida kaalumist (autore arvamus keelte kohta on piisavalt subjektiivne, kuigi väidetavalt on see objektiivne kirjeldus):

• Python – piisavalt viisakas ja sõbralik keel algaja kasutajale, andes andeks mõned vead, kuid samas võib olla arendajaga ka piisavalt ranget, et ta ei teeks halbu asju. Juba piisavalt küps ja mõtestatud programmeerimiskeel, mis ilmus 1991. aastal.
• Go – Google'i keelek, samuti piisavalt sõbralik ja mugav, seda on lihtne kompileerida ja saada täidetav fail igas platvormis. Võib olla lihtne ja meeldiv, aga ka keeruline ja tõsine. Nooruslik ja värske, ilmus suhteliselt hiljuti, 2009. aastal.
• Rust – veidi vanem oma eelmisest kolleegist, ilmus 2006. aastal, on siiski oma kaaslastest veel piisavalt noor. Suunatud rohkem kogenud arendajatele, kuigi püüab endiselt lahendada paljusid madala taseme ülesandeid arendaja eest.
• Java – 1995. aastal turule tulnud ärirakenduste arendamiseks üks tuntumaid programmeerimiskeeli, mille keerukad põhimõtted ja arenduskeskkonna seadistus võivad olla algajatele korralikuks väljakutseks.
• ASP.net – rakenduste arenduse platvorm, mille on välja töötanud Microsoft. Funktsionaalsuse kirjutamiseks kasutatakse peamiselt C# keelt (hääldatakse C-si Sharp), mis ilmus 2000. aastal. Oma keerukuselt jääb see Java ja Rusti vahele.
• PHP – algselt HTML-i eelprotsessimiseks mõeldud keel, mis hoiab endiselt tugevat turupositsiooni, kuid kasutuses on näha langustrendi. Iseloomustab madal pääsukoht, lihtne koodikirjutamine, kuid sihikindlate rakenduste arendamisel võib keele funktsionaalsus olla ebapiisav.

Ja meie rakenduse viimane osa – kõige käegakatsutavam kasutajale – Frontend (front-end) – on teie rakenduse nägu, just sellega kasutaja vahetult suhtleb.

Tänapäeva front-end areng põhineb kolmel sambal, raamistikul (ja mitte ainult), mis võimaldavad luua kasutajaliideseid. Seega on kolm kõige populaarsemat järgmised:

• ReactJS – ei ole raamistik, vaid teek. Tegelikult eristab seda uhkest raamistikust ainult mõningate funktsioonide puudumine "karbis", mis tuleb paigaldada käsitsi. Seega on olemas mitmeid variatsioone selle teegi "valmistamiseks", mis vormivad omamoodi raamistikke. Algajale võib see olla keeruline, arvestades mõningaid põhialuseid ja piisavalt keerukat kogu keskkonna seadistust. Siiski, kiireks alustamiseks võib kasutada "create-react-app" paketti.
• VueJS – raamistik kasutajaliideste loomiseks. Antud kolmest raamist on see õigusega kõige kasutajasõbralikum, kuna Vue'ga programmeerimise sisenemislävi on madalam kui teistel mainitud raamistikudel. Lisaks on see nende seas ka noorim.
• Angular – peetakse olevat kõige keerulisem tõlgitud raamistikke, ainus, mis nõuab olemasolu TypeScript (JavaScript'i pealse). Sageli kasutatakse suurte ettevõtte rakenduste loomisel.

Kokkuvõttes võib öelda, et rakenduse käitamine erineb radikaalselt sellest, kuidas see protsess varem kulges. Kuid keegi ei keela teha „deplooži” vanamoodsete meetoditega. Kuid kas natuke säästetud aega alguses tasub tohutut hulka takistusi, millele arendaja valinud see tee, peale astub? Arvan, et vastus on „ei”. Veidi rohkem aega nende tööriistadega tutvumiseks (ja rohkem ei olegi vaja, sest peate lihtsalt aru saama, kas need on teie praeguses projektis vajalikud või mitte) aitab oluliselt vähendada näiteks keskkonnast sõltuvate kummitusvigade esinemist, mis ilmnevad ainult tootmisserveris, öiste arutelude põhjuste osas, mis viis serveri kokkuvarisemiseni, ja palju muud.

Allikas: habr.com