Por krei vian propran TTT-aplikaĵon en nia tempo, ne sufiĉas povi disvolvi ĝin. Grava aspekto estas starigi ilojn por aplikaĵa deplojo, monitorado, same kiel administri kaj administri la medion en kiu ĝi funkcias. Ĉar la epoko de mana deplojo velkas en forgeson, eĉ por malgrandaj projektoj, aŭtomatigaj iloj povas alporti palpeblajn avantaĝojn. Kiam oni disfaldas "mane", ni ofte povas forgesi movi ion, konsideri ĉi tiun aŭ alian nuancon, fari forgesitan teston, ĉi tiu listo povas esti daŭrigita dum sufiĉe longa tempo.
Ĉi tiu artikolo povas helpi tiujn, kiuj nur lernas la bazojn pri kreado de TTT-aplikoj kaj volas iom kompreni la bazajn terminojn kaj konvenciojn.
Do, konstrui aplikaĵojn ankoraŭ povas esti dividita en 2 partoj: ĉio, kio rilatas al la aplika kodo, kaj ĉio, kio rilatas al la medio, en kiu ĉi tiu kodo estas ekzekutita. La aplika kodo, siavice, estas ankaŭ dividita en servila kodo (tiu, kiu funkcias sur la servilo, ofte: komerca logiko, rajtigo, datumstokado ktp.), kaj klientokodo (tiu, kiu funkcias sur la maŝino de la uzanto: ofte. la interfaco, kaj rilata logiko kun ĝi).
Ni komencu per merkredo.
La bazo por funkciado de iu ajn kodo, sistemo aŭ programaro estas la Operaciumo, do ĉi-sube ni rigardos la plej popularajn sistemojn sur la gastiga merkato kaj donos al ili mallongan priskribon:
Vindoza Servilo - la sama Vindozo, sed en servila variaĵo. Iu funkcieco disponebla en la klienta (regula) versio de Vindozo ne ĉeestas ĉi tie, ekzemple, kelkaj servoj por kolektado de statistikoj kaj simila programaro, sed ekzistas aro da utilecoj por retadministrado, baza programaro por deploji servilojn (retejo, ftp, ...). Ĝenerale, Vindoza Servilo aspektas kiel regula Vindozo, ĉarlatoj kiel regula Vindozo, tamen ĝi kostas 2 fojojn pli ol sia kutima ekvivalento. Tamen, konsiderante ke vi plej verŝajne deplojos la aplikaĵon sur dediĉita/virtuala servilo, la fina kosto por vi, kvankam ĝi povas pliiĝi, ne estas kritika. Ĉar la Vindoza platformo okupas superfortan lokon en la konsumanta OS-merkato, ĝia servila eldono estos la plej konata al plej multaj uzantoj.
Unikso-simila sistemo. Tradicia laboro en ĉi tiuj sistemoj ne postulas la ĉeeston de konata grafika interfaco, ofertante al la uzanto nur konzolon kiel kontrolelementon. Por nesperta uzanto, labori en ĉi tiu formato povas esti malfacila, kiom kostas eliri tekstredaktilon, kiu estas sufiĉe populara en datumoj. mi venis, demando rilata al tio jam ricevis pli ol 6 milionojn da vidoj en 1.8 jaroj. La ĉefaj distribuoj (eldonoj) de ĉi tiu familio estas: Debian - populara distribuo, pakaĵversioj en ĝi estas koncentritaj ĉefe al LTS (Longtempe - subteno por longa tempo), kiu estas esprimita en sufiĉe alta fidindeco kaj stabileco de la sistemo kaj pakoj; ubuntu – enhavas distribuojn de ĉiuj pakaĵoj en siaj plej novaj versioj, kiuj povas influi stabilecon, sed permesas vin uzi la funkciojn, kiuj venas kun novaj versioj; Red Hat Enterprise Linukso - OS, poziciigita por komerca uzo, estas pagita, aliflanke, inkludas subtenon de softvarvendistoj, kelkaj proprietaj pakaĵoj kaj ŝoforpakaĵoj; CentOS - malferma fonto vario de Red Hat Enterprise Linux, karakterizita per la foresto de proprietaj pakaĵoj kaj subteno.
Por tiuj, kiuj ĵus komencas regi ĉi tiun areon, mia rekomendo estus sistemoj Vindoza Serviloaŭ ubuntu. Se ni konsideras Vindozon, tiam ĉi tio estas ĉefe la familiareco de la sistemo, ubuntu – pli da toleremo al ĝisdatigoj, kaj siavice, ekzemple, malpli da problemoj dum lanĉo de projektoj pri teknologioj, kiuj postulas novajn versiojn.
Do, decidinte pri la OS, ni transiru al aro da iloj, kiuj permesas vin disfaldi (instali), ĝisdatigi kaj kontroli la staton de la aplikaĵo aŭ ĝiaj partoj sur la servilo.
La sekva grava decido estos la lokigo de via aplikaĵo kaj la servilo por ĝi. Nuntempe, la plej oftaj estas 3 manieroj:
- Gastigi (konservi) servilon memstare estas la plej buĝeta opcio, sed vi devos mendi statikan IP de via provizanto por ke via rimedo ne ŝanĝu ĝian adreson laŭlonge de la tempo.
- Luu Dediĉitan Servilon (VDS) - kaj sendepende administru ĝin kaj skalu ŝarĝojn
- Pagu (ofte ili donas al vi ŝancon provi la funkciojn de la platformo senpage) por abono al iu nuba gastigado, kie la pagmodelo por la uzataj rimedoj estas sufiĉe ofta. La plej elstaraj reprezentantoj de ĉi tiu direkto: Amazon AWS (ili donas senpagan jaron de uzado de la servoj, sed kun monata limo), Google Cloud (ili donas $ 300 al la konto, kiu povas esti elspezita dum la jaro por nuba gastigado de servoj) , Yandex.Cloud (ili donas 4000 rublojn . dum 2 monatoj), Microsoft Azure (donas senpagan aliron al popularaj servoj dum jaro, + 12 500 rubloj por iuj servoj dum unu monato). Tiel, vi povas provi iun ajn el ĉi tiuj provizantoj sen elspezi eĉ unu pencon, sed ricevi proksimuman opinion pri la kvalito kaj nivelo de servo provizita.
Depende de la elektita vojo, la sola afero, kiu ŝanĝos estonte, estas kiu plejparte respondecas pri tiu aŭ alia areo de administrado. Se vi gastigas vin, tiam vi devas kompreni, ke ajnaj interrompoj en elektro, Interreto, la servilo mem, la programaro deplojita sur ĝi - ĉio ĉi kuŝas tute sur viaj ŝultroj. Tamen, por trejnado kaj testado, ĉi tio estas pli ol sufiĉa.
Se vi ne havas kroman maŝinon, kiu povas ludi la rolon de servilo, tiam vi volos uzi la duan aŭ trian manieron. La dua kazo estas identa al la unua, kun la escepto, ke vi ŝanĝas la respondecon pri la havebleco de la servilo kaj ĝia potenco al la ŝultroj de la gastiganto. Administrado de la servilo kaj programaro estas ankoraŭ sub via kontrolo.
Kaj fine, la eblo de lui la kapablon de nubaj provizantoj. Ĉi tie vi povas agordi aŭtomatan kontrolon de preskaŭ io ajn sen eniri tro da teknikaj detaloj. Krome, anstataŭ unu maŝino, vi povas havi plurajn paralelajn kurantajn petskribojn, kiuj povas, ekzemple, respondeci pri malsamaj partoj de la aplikaĵo, dum ne multe diferencas en kosto de posedado de dediĉita servilo. Kaj ankaŭ, ekzistas iloj por instrumentado, kontenerigo, aŭtomata disfaldo, kontinua integriĝo kaj multe pli! Ni rigardos kelkajn el ĉi tiuj aferoj sube.
Ĝenerale, la servila infrastrukturo aspektas jene: ni havas tiel nomatan "orkestratoro" ("orkestrado" estas la procezo de administrado de pluraj servilaj petskriboj), kiu administras mediajn ŝanĝojn en servila petskribo, virtualiga ujo (laŭvola, sed sufiĉe. ofte uzata), kiu ebligas al vi dividi la aplikaĵon en izolitajn logikajn tavolojn, kaj Daŭran Integrigan programaron—permesante ĝisdatigojn al gastigita kodo per "skriptoj".
Do, orkestrado ebligas al vi vidi la staton de serviloj, ruliĝi aŭ refari ĝisdatigojn al la servila medio, ktp. Komence, ĉi tiu aspekto verŝajne ne influos vin, ĉar por orkestre ion ajn, vi bezonas plurajn servilojn (vi povas havi unu, sed kial tio estas necesa?), kaj por havi plurajn servilojn, vi bezonas ilin. El la iloj en ĉi tiu direkto, la plej populara estas Kubernetes, evoluigita de google.
La sekva paŝo estas virtualigo ĉe la OS-nivelo. Nuntempe, la koncepto de "dokerigo" disvastiĝis, kiu venas de la ilo Docker, kiu disponigas la funkciecon de ujoj izolitaj unu de la alia, sed lanĉitaj en la kunteksto de unu operaciumo. Kion tio signifas: en ĉiu el ĉi tiuj ujoj vi povas ruli aplikaĵon, aŭ eĉ aron da aplikaĵoj, kiuj kredos, ke ili estas la solaj en la tuta OS, sen eĉ suspekti la ekziston de iu alia sur ĉi tiu maŝino. Ĉi tiu funkcio estas tre utila por lanĉi identajn aplikojn de malsamaj versioj, aŭ simple konfliktajn aplikojn, same kiel por dividi pecojn de aplikaĵo en tavolojn. Ĉi tiu tavola rolantaro povas poste esti skribita en bildon, kiu povas esti uzata, ekzemple, por deploji aplikaĵon. Tio estas, instalante ĉi tiun bildon kaj deplojante la ujojn kiujn ĝi enhavas, vi ricevas pretan medion por ruli vian aplikaĵon! En la unuaj paŝoj, vi povas uzi ĉi tiun ilon kaj por informaj celoj kaj por akiri tre realajn avantaĝojn dividante la aplikan logikon en malsamajn tavolojn. Sed indas diri ĉi tie, ke ne ĉiuj bezonas dokerigon, kaj ne ĉiam. Dokerigo estas pravigita en kazoj kie la aplikaĵo estas "fragmentita", dividita en malgrandajn partojn, ĉiu respondeca por sia propra tasko, la tiel nomata "mikroserva arkitekturo".
Krome, krom havigi la medion, ni devas certigi kompetentan disfaldiĝon de la aplikaĵo, kiu inkluzivas ĉiajn kodajn transformojn, instaladon de bibliotekoj kaj pakaĵoj rilataj al aplikaĵo, funkciadon de testoj, sciigojn pri ĉi tiuj operacioj, ktp. Ĉi tie ni devas atenti tian koncepton kiel "Kontinua Integriĝo" (CI - Kontinua Integriĝo). La ĉefaj iloj en ĉi tiu areo nuntempe estas Jenkins (CI-programaro skribita en Java eble ŝajnas iomete komplika komence), Travis C.I. (skribite en Ruby, subjektiva, iom pli simpla Jenkins, tamen, iom da scio en la kampo de deploja agordo daŭre estas postulata), Gitlab CI (skribita sur Ruby kaj Iru).
Do, parolinte pri la medio en kiu via aplikaĵo funkcios, estas tempo finfine rigardi kiajn ilojn ofertas al ni la moderna mondo por krei ĉi tiujn aplikaĵojn.
Ni komencu per la bazaĵoj: backend (backend) – servila parto. La elekto de lingvo, aro de bazaj funkcioj kaj antaŭdifinita strukturo (kadro) ĉi tie estas determinita ĉefe de personaj preferoj, sed tamen, ĝi estas menciinda por konsidero (la opinio de la aŭtoro pri lingvoj estas sufiĉe subjektiva, kvankam kun aserto. al senantaŭjuĝa priskribo):
- Python estas sufiĉe amika lingvo por nesperta uzanto, ĝi pardonas kelkajn erarojn, sed ĝi ankaŭ povas esti sufiĉe strikta kun la programisto, por ke li ne faru ion malbonan. Jam sufiĉe matura kaj signifoplena lingvo, kiu aperis en 1991.
- Go - lingvo de Guglo, estas ankaŭ sufiĉe amika kaj oportuna, ĝi estas sufiĉe facile kompili kaj akiri ruleblan dosieron sur ajna platformo. Ĝi povas esti simpla kaj agrabla, aŭ ĝi povas esti kompleksa kaj serioza. Freŝa kaj juna, aperis relative lastatempe, en 2009.
- Rust estas iom pli aĝa ol sia antaŭa kolego, publikigita en 2006, sed ankoraŭ estas sufiĉe juna kompare kun siaj samuloj. Celita al pli spertaj programistoj, kvankam ĝi ankoraŭ provas solvi multajn malaltnivelajn taskojn por la programisto.
- Java estas veterano de komerca evoluo, lanĉita en 1995, kaj estas unu el la plej ofte uzataj lingvoj en entreprena aplikaĵo-disvolviĝo hodiaŭ. Kun ĝiaj bazaj konceptoj kaj peza aranĝo, la rultempo povas fariĝi sufiĉe malfacila por komencanto.
- ASP.net estas aplikaĵa evoluplatformo liberigita de Microsoft. Por skribi funkciecon oni ĉefe uzas la lingvon C# (prononcu C Sharp), kiu aperis en 2000. Ĝia komplekseco estas komparebla al la nivelo inter Java kaj Rust.
- PHP, origine uzita por HTML-antaŭprocesado, nuntempe, kvankam ĝi tenas absolutan gvidadon en la lingvomerkato, ekzistas tendenco al malkresko en uzo. Ĝi havas malaltan enirsojlon kaj facilecon por skribi kodon, sed samtempe, kiam oni disvolvas sufiĉe grandajn aplikaĵojn, la funkcieco de la lingvo eble ne sufiĉas.
Nu, la fina parto de nia aplikaĵo - la plej palpebla por la uzanto - Antaŭa finaĵo (frontend) - estas la vizaĝo de via aplikaĵo; ĝuste kun ĉi tiu parto la uzanto rekte interagas.
Sen eniri detalojn, la moderna fasado staras sur tri kolonoj, kadroj (kaj ne tiom), por krei uzantinterfacojn. Sekve, la tri plej popularaj estas:
- ReactJS ne estas kadro, sed biblioteko. Fakte, la kadro diferencas de sia fiera titolo nur pro la manko de iuj funkcioj "el la skatolo" kaj la bezono instali ilin permane. Tiel, ekzistas pluraj varioj de la "preparado" de ĉi tiu biblioteko, formante unikajn kadrojn. Ĝi povas esti iom malfacila por komencanto, pro iuj bazaj principoj, kaj sufiĉe agresema aranĝo de la konstrumedio. Tamen, por rapida komenco, vi povas uzi la pakaĵon "create-react-app".
- VueJS estas kadro por konstrui uzantinterfacojn. De ĉi tiu triunuo, ĝi prave prenas la titolon de la plej uzebla kadro; por disvolviĝo en Vue, la baro al eniro estas pli malalta ol tiu de la aliaj menciitaj fratoj. Krome, li estas la plej juna inter ili.
- Angular estas konsiderata la plej kompleksa el ĉi tiuj kadroj, la sola kiu postulas TypeScript (aldonaĵo por Javascript-lingvo). Ofte uzata por konstrui grandajn entreprenajn aplikojn.
Resumante tion, kio estis skribita supre, ni povas konkludi, ke nun deploji aplikaĵon estas radikale malsama ol kiel ĉi tiu procezo daŭrigis antaŭe. Tamen, neniu malhelpas vin fari la "deplojon" laŭ la malnova maniero. Sed ĉu la malmulte da tempo ŝparita ĉe la komenco valoras la grandegan nombron da eraroj, kiujn programisto, kiu elektas ĉi tiun vojon, devos paŝi? Mi kredas, ke la respondo estas ne. Pasigante iom pli da tempo familiarigante vin kun ĉi tiuj iloj (kaj vi ne bezonas pli ol tio, ĉar vi devas kompreni ĉu vi bezonas ilin en via nuna projekto aŭ ne), vi povas ludi ĝin, signife reduktante, ekzemple , kazoj de fantomaj eraroj depende de la medio kaj kiuj aperas nur sur la produktadservilo, nokta analizo de kio kaŭzis la servilkraŝon kaj kial ĝi ne komenciĝos, kaj multe pli.
fonto: www.habr.com