Om jou eie webtoepassing in ons tyd te skep, is dit nie genoeg om dit te kan ontwikkel nie. 'n Belangrike aspek is die opstel van gereedskap vir toepassings-ontplooiing, monitering, sowel as die bestuur en administrasie van die omgewing waarin dit funksioneer. Soos die era van handmatige ontplooiing in die vergetelheid vervaag, selfs vir klein projekte, kan outomatiseringsinstrumente tasbare voordele inhou. Wanneer ons "met die hand" ontplooi, kan ons dikwels vergeet om iets te skuif, hierdie of daardie nuanse in ag te neem, 'n vergete toets uit te voer, hierdie lys kan nogal lank voortgesit word.
Hierdie artikel kan diegene help wat net die basiese beginsels van die skep van webtoepassings leer en 'n bietjie wil verstaan oor die basiese terme en konvensies.
So, boutoepassings kan steeds in 2 dele verdeel word: alles wat verband hou met die toepassingskode, en alles wat verband hou met die omgewing waarin hierdie kode uitgevoer word. Die toepassingskode word op sy beurt ook verdeel in bedienerkode (die een wat op die bediener loop, dikwels: besigheidslogika, magtiging, databerging, ens.), en kliëntkode (die een wat op die gebruiker se masjien loop: dikwels die koppelvlak, en verwante logika daarmee).
Kom ons begin met Woensdag.
Die basis vir die werking van enige kode, stelsel of sagteware is die bedryfstelsel, so hieronder sal ons kyk na die gewildste stelsels op die gasheermark en hulle 'n kort beskrywing gee:
Windows Server - dieselfde Windows, maar in 'n bedienervariasie. Sommige funksies wat beskikbaar is in die kliënt (gewone) weergawe van Windows is nie hier teenwoordig nie, byvoorbeeld sommige dienste vir die insameling van statistieke en soortgelyke sagteware, maar daar is 'n stel nutsprogramme vir netwerkadministrasie, basiese sagteware vir die implementering van bedieners (web, ftp, ...). Oor die algemeen lyk Windows Server soos gewone Windows, kwaksalwers soos gewone Windows, maar dit kos 2 keer meer as sy gewone eweknie. As u egter in ag neem dat u die toepassing heel waarskynlik op 'n toegewyde/virtuele bediener sal ontplooi, is die finale koste vir u, hoewel dit kan styg, nie krities nie. Aangesien die Windows-platform 'n oorweldigende plek in die verbruikersbedryfstelselmark beklee, sal sy bedieneruitgawe die bekendste vir die meeste gebruikers wees.
Unix- soortgelyke stelsel. Tradisionele werk in hierdie stelsels vereis nie die teenwoordigheid van 'n bekende grafiese koppelvlak nie, wat die gebruiker slegs 'n konsole as 'n beheerelement bied. Vir 'n onervare gebruiker kan dit moeilik wees om in hierdie formaat te werk, net wat is die koste om 'n teksredigeerder te verlaat wat baie gewild is in data Vim, 'n vraag wat hiermee verband hou, het reeds meer as 6 miljoen kyke in 1.8 jaar ontvang. Die hoofverspreidings (uitgawes) van hierdie familie is: Debian - 'n gewilde verspreiding, pakketweergawes daarin is hoofsaaklik gefokus op LTS (Langtermynondersteuning - ondersteuning vir 'n lang tyd), wat uitgedruk word in 'n redelike hoë betroubaarheid en stabiliteit van die stelsel en pakkette; Ubuntu – bevat verspreidings van alle pakkette in hul nuutste weergawes, wat stabiliteit kan beïnvloed, maar laat jou toe om die funksionaliteit te gebruik wat met nuwe weergawes kom; Red Hat Enterprise Linux – OS, geposisioneer vir kommersiële gebruik, word betaal, maar sluit ondersteuning van sagtewareverkopers, sommige eie pakkette en bestuurderpakkette in; CentOS - oopbron 'n variasie van Red Hat Enterprise Linux, gekenmerk deur die afwesigheid van eie pakkette en ondersteuning.
Vir diegene wat net begin om hierdie area te bemeester, sal my aanbeveling stelsels wees Windows ServerOf Ubuntu. As ons Windows oorweeg, dan is dit hoofsaaklik die bekendheid van die stelsel, Ubuntu – meer verdraagsaamheid teenoor opdaterings, en op sy beurt, byvoorbeeld, minder probleme wanneer projekte op tegnologieë geloods word wat nuwe weergawes vereis.
Dus, nadat ons op die bedryfstelsel besluit het, kom ons gaan voort na 'n stel nutsmiddels waarmee u die toestand van die toepassing of sy dele op die bediener kan ontplooi (installeer), opdateer en monitor.
Die volgende belangrike besluit is die plasing van jou toepassing en die bediener daarvoor. Op die oomblik is die mees algemene 3 maniere:
- Om 'n bediener op jou eie te huisves (hou) is die mees begrotingsvriendelike opsie, maar jy sal 'n statiese IP van jou verskaffer moet bestel sodat jou hulpbron nie mettertyd sy adres verander nie.
- Huur 'n toegewyde bediener (VDS) – en administreer dit onafhanklik en skaal vragte
- Betaal (dikwels gee hulle jou 'n kans om die platform se funksionaliteit gratis te probeer) vir 'n intekening op een of ander wolkgasheer, waar die betaalmodel vir die hulpbronne wat gebruik word, redelik algemeen is. Die mees prominente verteenwoordigers van hierdie rigting: Amazon AWS (hulle gee 'n gratis jaar om die dienste te gebruik, maar met 'n maandelikse limiet), Google Cloud (hulle gee $ 300 aan die rekening, wat gedurende die jaar aan wolkgasheerdienste bestee kan word) , Yandex.Cloud (hulle gee 4000 roebels . vir 2 maande), Microsoft Azure (gee gratis toegang tot gewilde dienste vir 'n jaar, + 12 500 roebels vir enige dienste vir een maand). U kan dus enige van hierdie verskaffers probeer sonder om 'n sent te spandeer, maar om 'n benaderde mening te kry oor die kwaliteit en vlak van diens wat gelewer word.
Afhangende van die gekose pad, is die enigste ding wat in die toekoms sal verander, wie grootliks verantwoordelik is vir hierdie of daardie area van administrasie. As jy jouself gasheer, dan moet jy verstaan dat enige onderbrekings in elektrisiteit, die internet, die bediener self, die sagteware wat daarop ontplooi is - dit alles lê geheel en al op jou skouers. Vir opleiding en toetsing is dit egter meer as genoeg.
As jy nie 'n ekstra masjien het wat die rol van 'n bediener kan speel nie, sal jy die tweede of derde manier wil gebruik. Die tweede geval is identies aan die eerste, met die uitsondering dat jy die verantwoordelikheid vir die beskikbaarheid van die bediener en sy krag na die skouers van die gasheer oorplaas. Administrasie van die bediener en sagteware is steeds onder jou beheer.
En laastens, die opsie om die kapasiteit van wolkverskaffers te huur. Hier kan jy outomatiese beheer van byna enigiets opstel sonder om te veel tegniese besonderhede in te gaan. Daarbenewens, in plaas van een masjien, kan jy verskeie parallelle lopende gevalle hê, wat byvoorbeeld verantwoordelik kan wees vir verskillende dele van die toepassing, terwyl dit nie veel verskil in koste van die besit van 'n toegewyde bediener nie. En ook, daar is gereedskap vir orkestrasie, houerisering, outomatiese ontplooiing, deurlopende integrasie en nog baie meer! Ons sal hieronder na sommige van hierdie dinge kyk.
Oor die algemeen lyk die bedienerinfrastruktuur soos volg: ons het 'n sogenaamde "orkestreerder" ("orkestrasie" is die proses om verskeie bedienergevalle te bestuur), wat omgewingsveranderinge op 'n bedienerinstansie, 'n virtualisasiehouer (opsioneel, maar redelik) bestuur wat dikwels gebruik word), wat jou toelaat om die toepassing in geïsoleerde logiese lae te verdeel, en Deurlopende Integrasie-sagteware - wat opdaterings van gehoste kode deur middel van "skrifte" moontlik maak.
So, orkestrasie laat jou toe om die status van bedieners te sien, opdaterings na die bedieneromgewing uit te voer of terug te rol, ensovoorts. Aanvanklik is dit onwaarskynlik dat hierdie aspek jou sal beïnvloed, want om enigiets te orkestreer, het jy verskeie bedieners nodig (jy kan een hê, maar hoekom is dit nodig?), en om verskeie bedieners te hê, het jy hulle nodig. Onder die instrumente in hierdie rigting is die gewildste Kubernetes, ontwikkel deur Google.
Die volgende stap is virtualisering op die OS-vlak. Deesdae het die konsep van "dokerisering" wydverspreid geword, wat van die instrument kom Docker, wat die funksionaliteit bied van houers wat van mekaar geïsoleer is, maar in die konteks van een bedryfstelsel bekendgestel is. Wat beteken dit: in elkeen van hierdie houers kan jy 'n toepassing, of selfs 'n stel toepassings, laat loop wat sal glo dat dit die enigstes in die hele bedryfstelsel is, sonder om eers die bestaan van iemand anders op hierdie masjien te vermoed. Hierdie funksie is baie nuttig vir die bekendstelling van identiese toepassings van verskillende weergawes, of bloot botsende toepassings, sowel as om stukke van 'n toepassing in lae te verdeel. Hierdie laagverspreiding kan later in 'n beeld geskryf word, wat byvoorbeeld gebruik kan word om 'n toepassing te ontplooi. Dit wil sê, deur hierdie prent te installeer en die houers wat dit bevat te ontplooi, kry jy 'n gereedgemaakte omgewing om jou toepassing te laat loop! In die eerste stappe kan u hierdie instrument beide vir inligtingsdoeleindes gebruik en om baie werklike voordele te kry deur die toepassingslogika in verskillende lae te verdeel. Maar dit is die moeite werd om hier te sê dat nie almal dokwerk nodig het nie, en nie altyd nie. Dockerisering is geregverdig in gevalle waar die toepassing "gefragmenteerd" is, verdeel in klein dele, elkeen verantwoordelik vir sy eie taak, die sogenaamde "mikrodiensargitektuur".
Benewens die verskaffing van die omgewing, moet ons 'n bekwame ontplooiing van die toepassing verseker, wat alle soorte kodetransformasies, installering van toepassingverwante biblioteke en pakkette, lopende toetse, kennisgewings oor hierdie bedrywighede, ensovoorts, insluit. Hier moet ons aandag gee aan so 'n konsep soos "Deurlopende integrasie" (CI – Deurlopende integrasie). Die belangrikste gereedskap op hierdie gebied op die oomblik is Jenkins (CI-sagteware wat in Java geskryf is, kan aan die begin 'n bietjie ingewikkeld lyk), Travis C.I. (geskryf in Ruby, subjektief, ietwat eenvoudiger Jenkins'n mate van kennis in die veld van ontplooiingskonfigurasie word egter steeds vereis), Gitlab CI (geskryf op Ruby en Gaan).
Dus, nadat ons gepraat het oor die omgewing waarin u toepassing sal werk, is dit tyd om uiteindelik te kyk na watter hulpmiddels die moderne wêreld ons bied om hierdie einste toepassings te skep.
Kom ons begin met die basiese beginsels: Backend (agterkant) – bediener deel. Die keuse van taal, stel basiese funksies en vooraf gedefinieerde struktuur (raamwerk) word hier hoofsaaklik deur persoonlike voorkeure bepaal, maar dit is nietemin die moeite werd om te noem vir oorweging (die skrywer se mening oor tale is redelik subjektief, hoewel met 'n aanspraak na 'n onbevooroordeelde beskrywing):
- Python is 'n redelik vriendelike taal vir 'n onervare gebruiker, dit vergewe 'n paar foute, maar dit kan ook redelik streng met die ontwikkelaar wees sodat hy niks sleg doen nie. Reeds 'n redelik volwasse en betekenisvolle taal, wat in 1991 verskyn het.
- Gaan - 'n taal van Google, is ook redelik vriendelik en gerieflik, dit is redelik maklik om saam te stel en 'n uitvoerbare lêer op enige platform te kry. Dit kan eenvoudig en aangenaam wees, of dit kan kompleks en ernstig wees. Fris en jonk, het relatief onlangs verskyn, in 2009.
- Rust is 'n bietjie ouer as sy vorige kollega, wat in 2006 vrygestel is, maar is nog redelik jonk in vergelyking met sy eweknieë. Gemik op meer ervare ontwikkelaars, hoewel dit steeds probeer om baie lae-vlak take vir die programmeerder op te los.
- Java is 'n veteraan van kommersiële ontwikkeling, bekendgestel in 1995, en is vandag een van die mees gebruikte tale in ondernemingstoepassingsontwikkeling. Met sy basiese konsepte en swaar opstelling kan die looptyd nogal uitdagend word vir 'n beginner.
- ASP.net is 'n toepassingsontwikkelingsplatform wat deur Microsoft vrygestel is. Om funksionaliteit te skryf, word hoofsaaklik die C#-taal (uitgespreek C Sharp), wat in 2000 verskyn het, gebruik. Die kompleksiteit daarvan is vergelykbaar met die vlak tussen Java en Rust.
- PHP, wat oorspronklik vir HTML-voorverwerking gebruik is, is tans, hoewel dit absolute leierskap in die taalmark beklee, 'n neiging tot 'n afname in gebruik. Dit het 'n lae toegangsdrempel en maklik om kode te skryf, maar terselfdertyd, wanneer redelik groot toepassings ontwikkel word, is die funksionaliteit van die taal dalk nie genoeg nie.
Wel, die laaste deel van ons aansoek - die mees tasbare vir die gebruiker - Voorkant (frontend) – is die gesig van jou toepassing; dit is met hierdie deel dat die gebruiker direk interaksie het.
Sonder om in besonderhede in te gaan, staan die moderne frontend op drie pilare, raamwerke (en nie soseer nie), om gebruikerskoppelvlakke te skep. Gevolglik is die drie gewildste:
- ReactJS is nie 'n raamwerk nie, maar 'n biblioteek. Eintlik verskil die raamwerk slegs van sy trotse titel in die afwesigheid van sommige funksies "uit die boks" en die behoefte om dit met die hand te installeer. Daar is dus verskeie variasies van die "voorbereiding" van hierdie biblioteek, wat unieke raamwerke vorm. Dit kan 'n bietjie moeilik wees vir 'n beginner, as gevolg van 'n paar basiese beginsels, en nogal aggressiewe opstelling van die bou-omgewing. Vir 'n vinnige begin kan jy egter die "create-react-app"-pakket gebruik.
- VueJS is 'n raamwerk vir die bou van gebruikerskoppelvlakke. Van hierdie drie-eenheid neem dit met reg die titel van die mees gebruikersvriendelike raamwerk; vir ontwikkeling in Vue is die toegangsgrens laer as dié van die ander genoemde broers. Boonop is hy die jongste onder hulle.
- Hoekig word beskou as die mees komplekse van hierdie raamwerke, die enigste een wat vereis tikwerk (byvoeging vir Javascript-taal). Dikwels gebruik om groot ondernemingstoepassings te bou.
Opsomming van wat hierbo geskryf is, kan ons tot die gevolgtrekking kom dat die implementering van 'n toepassing radikaal verskil van hoe hierdie proses voorheen verloop het. Niemand keer jou egter om die "ontplooiing" op die outydse manier te doen nie. Maar is die bietjie tyd wat aan die begin gespaar is, die groot aantal foute werd wat 'n ontwikkelaar wat hierdie pad kies, sal moet trap? Ek glo die antwoord is nee. Deur 'n bietjie meer tyd te spandeer om jouself met hierdie gereedskap vertroud te maak (en jy het nie meer as dit nodig nie, want jy moet verstaan of jy dit nodig het in jou huidige projek of nie), kan jy dit uitspeel, en aansienlik verminder, bv. , gevalle van spookfoute afhangende van die omgewing en wat slegs op die produksiebediener verskyn, nagtelike ontleding van wat gelei het tot die bedienerongeluk en hoekom dit nie sal begin nie, en nog baie meer.
Bron: will.com