Kontrollnimekiri veebirakenduste loomiseks ja avaldamiseks

Oma veebirakenduse loomiseks meie ajal ei piisa selle arendamise oskusest. Oluline aspekt on tööriistade seadistamine rakenduste juurutamiseks, jälgimiseks, samuti keskkonna, milles see töötab, haldamiseks ja administreerimiseks. Kuna käsitsi juurutamise ajastu hääbub isegi väikeste projektide puhul, võivad automatiseerimisvahendid tuua käegakatsutavat kasu. “Käsitsi” juurutades võime sageli unustada midagi liigutama, seda või teist nüanssi arvesse võtta, unustatud testi teha, seda nimekirja võib päris pikalt jätkata.

See artikkel võib aidata neid, kes alles õpivad veebirakenduste loomise põhitõdesid ja soovivad põhimõisteid ja tavasid veidi mõista.

Seega saab rakenduste loomise ikkagi jagada kaheks osaks: kõik, mis on seotud rakenduse koodiga, ja kõik, mis on seotud keskkonnaga, milles seda koodi käivitatakse. Rakenduse kood jaguneb omakorda ka serverikoodiks (see, mis töötab serveris, sageli: äriloogika, autoriseerimine, andmete salvestamine jne) ja kliendikoodiks (see, mis töötab kasutaja masinas: sageli liides ja sellega seotud loogika).

Alustame kolmapäevast.

Mis tahes koodi, süsteemi või tarkvara toimimise aluseks on operatsioonisüsteem, nii et allpool vaatleme hostimisturu kõige populaarsemaid süsteeme ja anname neile lühikirjelduse:

Windows Server - sama Windows, kuid serveri variatsioonis. Mõned Windowsi kliendi (tavalises) versioonis saadaolevad funktsioonid siin puuduvad, näiteks mõned statistika kogumise teenused jms tarkvara, kuid võrgu haldamiseks on olemas utiliitide komplekt, põhitarkvara serverite juurutamiseks (veeb, ftp, ...). Üldiselt näeb Windows Server välja nagu tavaline Windows, on nagu tavaline Windows, kuid see maksab 2 korda rohkem kui tavaline Windows. Arvestades aga, et juurutate rakenduse suure tõenäosusega spetsiaalses/virtuaalses serveris, ei ole teie jaoks lõplik hind, kuigi see võib suureneda, kriitiline. Kuna Windowsi platvormil on tarbijatele mõeldud OS-i turul ülekaalukas koht, on selle serveriväljaanne enamikule kasutajatele kõige tuttavam.

Unix- sarnane süsteem. Traditsiooniline töö nendes süsteemides ei nõua tuttava graafilise liidese olemasolu, pakkudes kasutajale juhtimiselemendina ainult konsooli. Kogenematu kasutaja jaoks võib selles vormingus töötamine olla keeruline, kui palju maksab aga andmetes üsna populaarsest tekstiredaktorist väljumine tarm, sellega seotud küsimust on 6 aastaga vaadatud juba üle 1.8 miljoni. Selle perekonna peamised distributsioonid (väljaanded) on: Debian - populaarne distributsioon, selles sisalduvad paketiversioonid on keskendunud peamiselt LTS-ile (Pikaajaline tugi - pikaajaline tugi), mis väljendub süsteemi ja pakettide üsna kõrges töökindluses ja stabiilsuses; Ubuntu – sisaldab kõigi pakettide distributsioone nende uusimates versioonides, mis võib mõjutada stabiilsust, kuid võimaldab kasutada uute versioonidega kaasnevaid funktsioone; Red Hat Enterprise Linux – OS, mis on positsioneeritud äriliseks kasutamiseks, on tasuline, kuid sisaldab tarkvaramüüjate tuge, mõningaid patenteeritud pakette ja draiveripakette; CentOS - avatud lähtekoodiga Red Hat Enterprise Linuxi variatsioon, mida iseloomustab patenteeritud pakettide ja toe puudumine.

Neile, kes alles hakkavad seda valdkonda valdama, oleks minu soovitus süsteemid Windows ServerVõi Ubuntu. Kui arvestada Windowsiga, siis on see eelkõige süsteemi tundmine, Ubuntu – suurem tolerantsus uuenduste suhtes ja omakorda näiteks vähem probleeme uusi versioone vajavate tehnoloogiate projektide käivitamisel.

Niisiis, pärast OS-i kasuks otsustamist liigume edasi tööriistakomplekti juurde, mis võimaldab teil juurutada (installida), värskendada ja jälgida rakenduse või selle osade olekut serveris.

Järgmine oluline otsus on teie rakenduse ja selle serveri paigutus. Praegu on kõige levinumad kolm võimalust:

  • Serveri omaette majutamine (hoidmine) on kõige eelarvesõbralikum variant, kuid selleks, et teie ressurss aja jooksul oma aadressi ei muudaks, peate oma teenusepakkujalt tellima staatilise IP.
  • Rentige spetsiaalne server (VDS) – ja hallake seda iseseisvalt ja skaleerige koormusi
  • Maksa (sageli annavad nad võimaluse platvormi funktsioone tasuta proovida) mõne pilvemajutuse tellimise eest, kus kasutatud ressursside maksemudel on üsna tavaline. Selle suuna silmapaistvamad esindajad: Amazon AWS (nad annavad tasuta aasta teenuste kasutamist, kuid kuulimiidiga), Google Cloud (nad annavad kontole 300 dollarit, mida saab aasta jooksul pilvemajutusteenustele kulutada) , Yandex.Cloud (nad annavad 4000 rubla . 2 kuu eest), Microsoft Azure (annavad tasuta juurdepääsu populaarsetele teenustele aastaks, + 12 500 rubla mis tahes teenuste eest ühe kuu jooksul). Seega võite proovida mõnda neist teenusepakkujatest ilma senti kulutamata, kuid saada ligikaudne arvamus pakutava teenuse kvaliteedi ja taseme kohta.

Olenevalt valitud teest muutub tulevikus ainult see, kes selle või teise haldusvaldkonna eest suuresti vastutab. Kui hostite ennast, peate mõistma, et kõik elektrikatkestused, Interneti, serveri enda ja sellele juurutatud tarkvara - kõik see lasub täielikult teie õlul. Koolituse ja testimise jaoks on see aga enam kui piisav.

Kui teil pole lisamasinat, mis võiks serveri rolli täita, siis soovite kasutada teist või kolmandat viisi. Teine juhtum on identne esimesega, välja arvatud see, et nihutate vastutuse serveri kättesaadavuse ja selle võimsuse eest hosti õlgadele. Serveri ja tarkvara administreerimine on endiselt teie kontrolli all.

Ja lõpuks võimalus rentida pilvepakkujate võimsust. Siin saate seadistada peaaegu kõike automaatset juhtimist, laskumata liigsetesse tehnilistesse üksikasjadesse. Lisaks võib ühe masina asemel olla mitu paralleelselt töötavat eksemplari, mis võivad näiteks vastutada rakenduse erinevate osade eest, samas ei erine kulud palju spetsiaalse serveri omamisest. Lisaks on olemas tööriistad orkestreerimiseks, konteineriseerimiseks, automaatseks juurutamiseks, pidevaks integreerimiseks ja paljuks muuks! Vaatleme allpool mõnda neist asjadest.

Üldiselt näeb serveri infrastruktuur välja selline: meil on nn "orkestraator" ("orkestreerimine" on mitme serveri eksemplari haldamise protsess), mis haldab serveri eksemplari keskkonnamuutusi, virtualiseerimiskonteiner (valikuline, kuid üsna sageli kasutatav), mis võimaldab jagada rakenduse eraldatud loogilisteks kihtideks ja pideva integratsiooni tarkvara, mis võimaldab hostitud koodi värskendada skriptide kaudu.

Seega võimaldab orkestreerimine näha serverite olekut, juurutada või tagasi võtta serverikeskkonna värskendusi ja nii edasi. Alguses see aspekt teid tõenäoliselt ei mõjuta, kuna millegi orkestreerimiseks on teil vaja mitut serverit (teil võib olla üks, aga miks see vajalik on?) ja mitme serveri jaoks on neid vaja. Selle suuna tööriistade hulgas on kõige populaarsem Kubernetes, mille on välja töötanud Google.

Järgmine samm on virtualiseerimine OS-i tasemel. Tänapäeval on laialt levinud mõiste "dokkeriseerimine", mis tuleneb tööriistast laevalaadija, mis pakub üksteisest eraldatud, kuid ühe operatsioonisüsteemi kontekstis käivitatud konteinerite funktsioone. Mida see tähendab: kõigis nendes konteinerites saate käivitada rakenduse või isegi rakenduste komplekti, mis usuvad, et need on kogu OS-is ainsad, kahtlustamata isegi kellegi teise olemasolu selles masinas. See funktsioon on väga kasulik erinevate versioonide identsete rakenduste või lihtsalt vastuoluliste rakenduste käivitamiseks, samuti rakenduse osade kihtideks jagamiseks. Selle kihivormingu saab hiljem kirjutada pildiks, mida saab kasutada näiteks rakenduse juurutamiseks. See tähendab, et selle pildi installimisel ja selles sisalduvate konteinerite juurutamisel saate oma rakenduse käitamiseks valmis keskkonna! Esimestel sammudel saate seda tööriista kasutada nii informatiivsel eesmärgil kui ka väga reaalse kasu saamiseks, jagades rakendusloogika erinevatesse kihtidesse. Kuid siin tasub öelda, et mitte kõik ei vaja dokkimist ja mitte alati. Dokkimine on õigustatud juhtudel, kui rakendus on killustatud, jagatud väikesteks osadeks, millest igaüks vastutab oma ülesande, nn mikroteenuse arhitektuuri eest.

Lisaks peame lisaks keskkonna pakkumisele tagama ka rakenduse kompetentse juurutamise, mis hõlmab kõikvõimalikke kooditeisendusi, rakendustega seotud teekide ja pakettide installimist, testide käitamist, nende toimingute teavitusi jne. Siin peame pöörama tähelepanu sellisele kontseptsioonile nagu "pidev integratsioon" (CI – pidev integreerimine). Peamised tööriistad selles valdkonnas on hetkel Jenkins (Javas kirjutatud CI-tarkvara võib alguses tunduda veidi keeruline), Travis C.I. (kirjutatud rubiiniga, subjektiivne, mõnevõrra lihtsam Jenkinssiiski on vaja mõningaid teadmisi juurutamise konfigureerimise alal), Gitlab CI (kirjutatud Ruby ja mine).

Seega, olles rääkinud keskkonnast, milles teie rakendus töötab, on aeg lõpuks vaadata, milliseid tööriistu kaasaegne maailm meile just nende rakenduste loomiseks pakub.

Alustame põhitõdedest: Taustaprogramm (tagaprogramm) – serveri osa. Keelevaliku, põhifunktsioonide komplekti ja etteantud struktuuri (raamistiku) määravad siinkohal peamiselt isiklikud eelistused, kuid sellegipoolest väärib see kaalumist (autori arvamus keelte kohta on üsna subjektiivne, kuigi väidetavalt erapooletu kirjelduse juurde):

  • Python on kogenematu kasutaja jaoks üsna sõbralik keel, andestab mõned vead, kuid võib olla ka üsna range arendaja suhtes, et ta midagi halba ei teeks. Juba üsna küps ja sisukas keel, mis ilmus 1991. aastal.
  • Go - Google'i keel, on ka üsna sõbralik ja mugav, käivitatava faili koostamine ja hankimine on üsna lihtne igal platvormil. See võib olla lihtne ja meeldiv või keeruline ja tõsine. Värske ja noor, ilmus suhteliselt hiljuti, 2009. aastal.
  • Rust on küll veidi vanem oma eelmisest, 2006. aastal välja antud kolleegist, kuid on eakaaslastega võrreldes veel üsna noor. Suunatud kogenumatele arendajatele, kuigi see püüab siiski lahendada programmeerija jaoks palju madala tasemega ülesandeid.
  • Java on kommertsarenduse veteran, mis võeti kasutusele 1995. aastal ja on tänapäeval üks enamkasutatavaid keeli ettevõtte rakenduste arendamisel. Oma põhikontseptsioonide ja raske seadistuse tõttu võib käitusaeg muutuda algajale üsna keeruliseks.
  • ASP.net on Microsofti välja antud rakenduste arendusplatvorm. Funktsionaalsuse kirjutamiseks kasutatakse peamiselt 2000. aastal ilmunud C# keelt (hääldatakse C Sharp). Selle keerukus on võrreldav Java ja Rusti vahelise tasemega.
  • PHP, mida algselt kasutati HTML-i eeltöötluseks, on praegu, kuigi sellel on keeleturul absoluutne liider, selle kasutamine väheneb. Sellel on madal sisenemislävi ja koodi kirjutamise lihtsus, kuid samas ei pruugi üsna suurte rakenduste arendamisel keele funktsionaalsusest piisata.

Noh, meie rakenduse viimane osa - kasutaja jaoks kõige käegakatsutavam - Frontend (frontend) – on teie rakenduse nägu; selle osaga suhtleb kasutaja otse.

Detailidesse laskumata seisab kaasaegne frontend kasutajaliideste loomisel kolmel sambal, raamistikul (ja mitte nii väga). Seetõttu on kolm kõige populaarsemat:

  • ReactJS ei ole raamistik, vaid raamatukogu. Tegelikult erineb raamistik oma uhkest pealkirjast vaid mõne funktsiooni puudumisega "karbist välja" ja vajadusega need käsitsi installida. Seega on selle raamatukogu "ettevalmistamisel" mitu variatsiooni, mis moodustavad ainulaadsed raamistikud. Algajale võib see mõne põhiprintsiibi ja ehituskeskkonna üsna agressiivse häälestuse tõttu olla pisut keeruline. Kiireks alustamiseks võite aga kasutada paketti "loo-reageeri-rakendus".
  • VueJS on kasutajaliideste loomise raamistik. Sellest kolmsusest võtab see õigustatult kõige kasutajasõbralikuma raamistiku tiitli; Vue arendamiseks on sisenemisbarjäär madalam kui teistel mainitud vendadel. Pealegi on ta nende seas noorim.
  • Angular peetakse nendest raamistikest kõige keerukamaks, ainsaks, mis nõuab TypeScript (Javascripti keele lisandmoodul). Sageli kasutatakse suurte ettevõtete rakenduste loomiseks.

Eespool kirjutatut kokku võttes võime järeldada, et praegune rakenduse juurutamine erineb radikaalselt sellest, kuidas see protsess varem kulges. Kuid keegi ei takista teil "juurutamist" vanamoodsal viisil tegemast. Kuid kas alguses säästetud vähe aega on väärt seda tohutut vigade hulka, millele selle tee valinud arendaja astuma peab? Usun, et vastus on eitav. Kulutades veidi rohkem aega nende tööriistadega tutvumisele (ja rohkem polegi vaja, sest pead aru saama, kas sul on neid praeguses projektis vaja või mitte), saad selle läbi mängida, vähendades oluliselt näiteks , kummitusvigade juhtumid, mis olenevad keskkonnast ja mis ilmuvad ainult tootmisserveris, igaõhtune analüüs selle kohta, mis viis serveri krahhini ja miks see ei käivitu, ja palju muud.

Allikas: www.habr.com

Lisa kommentaar