Veebirakenduste loomise ja avaldamise kontrollnimekiri

Tänapäeva veebirakenduse loomine ei piisa enam vaid arendamisest. Oluline aspekt on rakenduse juurutamise, jälgimise ning keskkonna haldamise ja administratsiooni seadistamine. Käsitsi juurutamise ajastu on unustusse minekul, isegi väikeste projektide puhul võivad automatiseerimise tööriistad tuua märgatavat kasu. Käsitsi juurutamisel unustame sageli midagi edastada, arvestada mõne nüansi või käivitada unustatud testi; see nimekiri võib olla üsna pikk.

See artikkel võib aidata neid, kes alles õpivad veebirakenduste loomise aluseid ja soovivad paremini mõista põhitingimusi ja konventsioone.

Seega saab rakenduste loomise jagada siiski kaheks osaks: see, mis on seotud rakenduskoodiga, ja see, mis on seotud keskkonnaga, kus see kood töötab. Rakenduskood jaguneb omakorda serveripoolseks (see, mis töötab serveris, sageli: ärilogika, autoriseerimine, andmete salvestamine jne) ja kliendipoolseks (see, mis töötab kasutaja arvutis: sageli liides ja sellega seotud loogika).

Alustame siiski keskkonnast.

Iga koodi, süsteemi või tarkvara aluseks on operatsioonisüsteem, seega vaatame allpool kõige populaarsemaid süsteeme, mis on saadaval hostimisteenuste turul, ja anname neile lühikese kirjelduse:

Windows Server – sama Windows, kuid serveriversioonis. Mõned funktsioonid, mis on saadaval tava (tavalisel) Windowsi versioonil, ei ole siin saadaval, näiteks mõned statistika kogumise teenused ja sellised rakendused, kuid asemele on olemas hulk võrguhalduse utiliite, põhivahendid juurutamiseks (web, ftp jne). Üldiselt näeb Windows Server välja nagu tavaline Windows, näitab sama käitusviisi, kuid maksab kaks korda rohkem kui selle tavaline vend. Kuid arvestades, et rakenduse juurutamine toimub tõenäoliselt pühendatud/virtuaalses serveris, võib teie lõplik kulu küll tõusta, kuid mitte kriitiliselt. Kuna Windowsi platvorm hõivab suure osa kasutajakontrollide turust, on selle serveriversioon enamikule kasutajatele kõige tuttavam. serverid (web, ftp, …). Üldiselt näeb Windows Server välja nagu tavaline Windows, toimib nagu tavaline Windows, kuid maksab kaks korda rohkem kui tema tavapärane versioon. Arvestades, et rakenduse käitamine toimub tõenäoliselt pühendatud/virtuaalses serveris, võib lõpphind küll tõusta, kuid mitte kriitiliselt. Kuna Windowsi platvorm omab turul domineerivat positsiooni kasutajate operatsioonisüsteemide seas, on selle serveriversioon enamikule kasutajatest kõige tuttavam.

Unix-sarnane süsteem. Traditsiooniline töö nende süsteemide juures ei eelda tuttava graafilise liidese olemasolu, pakkudes kasutajale juhtimise elemendina vaid konsooli. Kogenematule kasutajale võib selline vormis töötamine olla keeruline, nagu on ainult välja minek piisavalt populaarsest tekstiredaktoris. Vim, küsimus, mis sellega seotud, on 6 aastaga kogunud juba üle 1,8 miljoni vaatamise. Peamised distributsioonid (redaktsioonid) sellest perekonnast on: Debian - populaarne distributsioon, mille versioonid on suunatud peamiselt LTS (Long Term Support – pikaajaline tugi), mis väljendub piisavalt suure usaldusväärsuse ja stabiilsuse süsteemi ja pakettide puhul; Ubuntu – sisaldab kõiki pakette nende viimastes versioonides, mis võib mõjutada stabiilsust, kuid võimaldab kasutada funktsioone, mis on varustatud uute versioonidega; Red Hat Enterprise Linux - operatsioonisüsteem, mis on positsioneeritud kommertskasutuseks, on tasuline, kuid sisaldab tarkvaratootjate toetust, mõned omandiõigused ja draiveripaketid; CentOS - avatud lähtekoodiga variatsioon Red Hat Enterprise Linuxist, erineb omandiõiguste ja toe puudumise poolest.

Nende jaoks, kes alles hakkavad seda valdkonda valdama, on minu soovitus süsteemid Windows Server, või Ubuntu. Kui vaadata Windowsi, siis on see eelkõige süsteemi tuttavus, Ubuntu – suurem tolerantsus värskenduste suhtes, ja seetõttu vähem probleeme, näiteks projektide käivitamisel tehnoloogiate osas, mis nõuavad uusi versioone.

Nii et, olles määratlenud operatsioonisüsteemi, liigume tööriistade komplekti poole, mis võimaldavad rakenduse või selle osade paigaldamist, uuendamist ja jälgimist serveris.

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

• Hõlbustada (hoida) serverit endal, iseseisvalt - kõige odavam variant, kuid peate tellima pakkuja juures staatilise IP, et teie ressurss ei muudaks oma aadressi aja jooksul.
• Rentida Dedicated Server (VDS) – ja tegeleda iseseisvalt selle haldamise ja koormuse skaleerimisega.
• Maksa (tihti antakse tasuta proovi platvormi funktsionaalsusele) tellimus mõnel pilve hostimisteenusel, kus on üsna laialt levinud makse mudel kasutatud ressursside eest. Kõige silmapaistvamad esindajad sellel alal: Amazon AWS (pakuvad tasuta aastat teenuste kasutamist, kuid kuumahu limiidiga), Google Cloud (annavad 300 dollarit arvele, mida saab aastas kasutada pilveteenuste jaoks, hostimist), Yandex. Облако (annavad 4000 rubla kaheks kuuks), Microsoft Azure (pakuvad tasuta juurdepääsu populaarsetele teenustele aastaks, pluss 12 500 rubla mistahes teenuste jaoks ühe kuu jooksul). Seega saate proovida mõnda neist pakkujatest, kulutamata sentigi, kuid saades umbkaudse arvamuse teenuste kvaliteedi ja taseme kohta.

Sõltuvalt valitud teest muutub edaspidi vaid see fakt, kellel peamiselt lasub vastutus ühe või teise haldusvaldkonna eest. Kui hostite ise, siis peate mõistma, et kõik elektri, interneti, serveri, sellel käivitatud tarkvara katkestused – kõik see langeb täielikult teie õlgadele. Kuid õppimiseks ja testimiseks on seda enam kui piisavalt.

Kui teil aga ei ole üleliigset masinat, mis saaks mängida serveri rolli, siis soovite kasutada teist või kolmandat teed. Teine juhtum on esimesega identne, erandiga, et te ülekandate vastutuse serveri kättesaadavuse ja selle võimsuse eest hostimisele. Serveri ja tarkvara haldamine jääb endiselt teie kontrolli all.

Ja lõpuks, variant pilve pakkujate võimsuste rentimisel. Siin saate seadistada peaaegu iga asi automatiseeritud juhtimise, sügavatesse tehnilistesse nüanssidesse laskumata. Lisaks sellele, ühe masina asemel võite omada mitu paralleelselt töötavat instantsi (eksemplari), mis võivad näiteks vastutada rakenduse erinevate osade eest, samas ei erine nende hind eraldiseisva serveri omamisest palju. Ja seal on ka orkestreerimise, konteineriseerimise, automaatse juurutamise, pideva integreerimise ja paljude teiste tööriistade võimalused! Mõned neist asjadest käsitleme allpool.

Üldiselt on serveri infrastruktuur järgmine: meil on nii kutsutud "orkestrator" ("orkestreerimine" – protsess, mis haldab mitmeid serveri instantsse), mis juhib keskkonna muudatusi serveri instantsis, ning virtualiseerimise konteiner (valikuline, kuid tihti kasutatav), mis võimaldab rakendust jagada isoleeritud loogilisteks kihtideks, ja pideva integreerimise tarkvara – mis võimaldab paigaldatud koodi uuendamist "skriptide" kaudu.

Seega võimaldab orkestreerimine teil näha serverite staatust, teostada keskkonna uuenduste "rakendamist" või "tagasipöördumist" ning nii edasi. Alguses ei pruugi see aspekt teid puudutada, kuna midagi orkestreerimiseks on vajalik mitu serverit (üks võib ka olla, kuid milleks see vajalik on?), ja et oleks mitu serverit, on vajalik nende vajadus. Selle valdkonna tööriistadest on kõige tuntum Kubernetes, mis on välja töötatud. Google.

Järgmine samm on virtualiseerimine operatsioonisüsteemi tasandil. Praegu on laialt levinud mõisted "dokkerimine" – mis on tulnud tööriistast. Docker, mis pakub eraldiseisvaid konteinerite funktsioone, mis töötavad ühe operatsioonisüsteemi kontekstis. Mis see tähendab: igas sellises konteineris saab käivitada rakenduse või isegi rakenduste kogumi, mis arvavad, et nad on ainsad kogu OP-s, isegi teadmata, et teised on sellel masinal olemas. See funktsioon on väga kasulik, et käivitada erinevate versioonidega samu rakendusi või lihtsalt konfliktis olevaid rakendusi, samuti rakenduse osade kihtideks jaotamiseks. See kihtide koopia saab hiljem salvestada pildiks, mida saab kasutada näiteks rakenduse juurutamiseks. Seega, kui installite selle pildi ja avate seejärel konteinerid, mille ta sisaldab, saate valmis keskkonna oma rakenduse käivitamiseks! Esimestel etappidel saate seda tööriista kasutada nii tutvumiseks kui ka reaalsete eeliste saavutamiseks, jagades rakenduse loogikat erinevatesse kihtidesse. Kuid siin tuleb öelda, et konteineriseerimine pole kaugeltki kõigile vajalik ja mitte alati. Konteineriseerimine on põhjendatud juhtudel, kui rakendus on „fragmenteeritud”, jagatud väikesteks osadeks, millest igaühel on oma ülesanne, nn „mikroteenuste arhitektuur”.

Lisaks keskkonna tagamisele peame tagama ka rakenduse õige juurutamise, mis hõlmab erinevaid koodimoodustusi, rakendusega seotud teekide ja pakettide installimist, testide läbiviimist, teavitusi nende toimingute kohta jne. Siin peame tähelepanu pöörama mõistele „Jätkuv Integreerimine“ (CI – Jätkuv Integreerimine). Praegu on peamised tööriistad selle vallas Jenkins (CI jaoks mõeldud Java-s kirjutatud tarkvara, mis võib alguses tunduda keeruline), Travis CI (kirjutatud Ruby's, subjektiivselt, veidi lihtsam Jenkins'ist, kuid siiski vajab see endiselt teatud teadmisi juurutamise seadistamise alal), Gitlab CI (kirjutatud Rubys ja Go's).

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

Alustame põhialustest: Backend (backend) – serveripool. Keelte, põhifunktsioonide komplekti ja ettenähtud struktuuri (raamistik) valik sõltub peamiselt isiklikest eelistustest, kuid siiski tasub mainida arutlemiseks (autori arvamus keelte kohta on piisavalt subjektiivne, kuigi pretendeerib erapooletule kirjeldusele):

• Python – piisavalt sõbralik keelekasutajatele, kes on algajad, andestab mõned vead, kuid võib ka olla piisavalt range, et arendaja ei teeks halbu asju. Juba piisavalt küps ja läbimõeldud programmeerimiskeel, mis ilmus 1991. aastal.
• Go – Google'i keel, samuti piisavalt sõbralik ja mugav, on lihtne kompileerida ja saada täidetav fail igal platvormil. Võib olla lihtne ja meeldiv, kuid ka keeruline ja tõsine. Uus ja noor, ilmus suhteliselt hiljuti, 2009. aastal.
• Rust – veidi vanem kui eelmine kolleeg, ilmus 2006. aastal ja on endiselt noor oma kaaslaste seas. Suunatud kogenumatele arendajatele, kuigi püüab siiski lahendada paljusid madalama taseme ülesandeid programmeerija eest.
• Java – kommertsarenduse veteran, mis ilmus 1995. aastal, on hetkel üks kõige sagedamini kasutatavaid keeli ettevõtte rakenduste arendamisel. Selle põhikontseptsioonide ja raskesti seadistatud töökeskkonna tõttu võib see algajale olla piisavalt keeruline.
• ASP.net – rakenduste arendamise platvorm, mille on välja töötanud Microsoft. Funktsionaalsuse kirjutamiseks kasutatakse peamiselt C# keelt (hääldatakse C si Sharp), mis ilmus 2000. aastal. Oma keerukuse poolest on see võrreldav Java ja Rusti vahel.
• PHP – algselt kasutatud HTML-i eelprotsessimiseks, on hetkel kuigi palju kasutatud, kuid on nähtav kalduvus langusele. Erineb madalast sisenemise künnist, koodi lihtsast kirjutamisest, kuid samas, suurte rakenduste arendamisel võib selle keele funktsionaalsus osutuda ebapiisavaks.

Ja meie rakenduse lõpposa – kasutajale kõige käegakatsutavam – Frontend (frontend) – on Teie rakenduse nägu, just selle osaga kasutaja otse suhtleb.

Kaevamata detailidesse, tänapäeva front-end põhineb kolmel sambal ja raamistikul (ning vähemal määral), et luua kasutajaliideseid. Seega on kolm kõige populaarsemat:

• ReactJS – ei ole raamistik, vaid teek. Tegelikult eristab seda uhkest raamistikust ainult teatud funktsioonide "karbist" puudumine ja vajadus neid käsitsi installida. Seega on olemas mitu varianti, kuidas seda teeki "valmistada", luues omalaadseid raamistikke. Algajale võib see olla keeruline mõnede põhimõtete ja suhteliselt agressiivse koostamisvõime seadistuste tõttu. Siiski, kiireks alustamiseks võib kasutada paketti "create-react-app".
• VueJS – raamistik kasutajaliideste loomiseks. Sellest kolmikust võtab ta õigusega tiitli kõige kasutajasõbralikumate raamistike seas, arendades Vue'ga, on sisenemisbarjäär madalam kui teistel mainitud kolleegidel. Lisaks on ta nendest kõige noorem.
• Angular – peetakse kõige keerulisemaks antud raamistike seas, ainus, mis nõuab olemasolu TypeScript (JavaScripti keele ülesehitus). Sageli kasutatakse suuri ettevõtte rakenduste arendamiseks.

Kokkuvõttes võib järeldada, et rakenduse käivitamine erineb kardinaalselt sellest, kuidas see protsess varem toimus. Siiski ei takista miski vanaviisi "deploomise" tegemist. Kuid kas see säästetud aeg tasub ära arendajale nähtavaid hulgaliselt komistuskive, kui ta valib selle tee? Ma arvan, et vastus on "ei". Kulutades natuke rohkem aega nende tööriistadega tutvumisele (ja rohkem ei olegi vaja, kuna peate lihtsalt aru saama, kas need on teie praeguses projektis vajalikud või mitte), suudate seda aega kompenseerida, vähendades näiteks näkyvaid vigu, mis sõltuvad keskkonnast ja ilmneda vaid produktsiooniserveris, öiseid arutelusid selle üle, mis põhjustas serveri krahhi ja miks see ei käivitu, jne.

Allikas: habr.com