Gátlisti til að búa til og birta vefforrit

Til þess að búa til eigið vefforrit á okkar tímum er ekki nóg að geta þróað það. Mikilvægur þáttur er að setja upp verkfæri fyrir dreifingu forrita, eftirlit, sem og stjórnun og stjórnun umhverfisins sem það starfar í. Þegar tímum handvirkrar dreifingar hverfur í gleymsku, jafnvel fyrir lítil verkefni, geta sjálfvirkniverkfæri haft áþreifanlegan ávinning. Þegar við sendum „með höndunum“ getum við oft gleymt að færa eitthvað, taka tillit til þessa eða hinna blæbrigða, keyra gleymt próf, hægt er að halda þessum lista áfram í nokkuð langan tíma.

Þessi grein gæti hjálpað þeim sem eru bara að læra undirstöðuatriðin í að búa til vefforrit og vilja skilja aðeins grunnhugtök og venjur.

Svo er samt hægt að skipta byggingarforritum í 2 hluta: allt sem tengist forritskóðanum og allt sem tengist umhverfinu þar sem þessi kóði er keyrður. Forritskóðanum er aftur á móti einnig skipt í netþjónskóða (sá sem keyrir á netþjóninum, oft: viðskiptarökfræði, heimild, gagnageymslu osfrv.), og biðlarakóða (sá sem keyrir á vél notandans: oft viðmótið og tengd rökfræði við það).

Byrjum á miðvikudeginum.

Grunnurinn að rekstri hvers konar kóða, kerfis eða hugbúnaðar er stýrikerfið, svo hér að neðan munum við skoða vinsælustu kerfin á hýsingarmarkaðnum og gefa þeim stutta lýsingu:

Windows Server - sama Windows, en í afbrigði miðlara. Einhver virkni sem til er í biðlaraútgáfunni af Windows (venjulegri) Windows er ekki til staðar hér, til dæmis sum þjónusta til að safna tölfræði og svipuðum hugbúnaði, en það er sett af tólum fyrir netstjórnun, grunnhugbúnað til að dreifa netþjónum (vefur, ftp, ...). Almennt séð lítur Windows Server út eins og venjulegur Windows, quacks eins og venjulegur Windows, hins vegar kostar hann 2 sinnum meira en venjulegur hliðstæða hans. Hins vegar, í ljósi þess að þú munt líklegast dreifa forritinu á sérstakan / sýndarþjónn, er endanlegur kostnaður fyrir þig, þó að hann gæti aukist, ekki mikilvægur. Þar sem Windows vettvangurinn skipar yfirgnæfandi sess á OS markaði fyrir neytendur, mun netþjónaútgáfa hans vera sú kunnugasta fyrir flesta notendur.

Unix-svipað kerfi. Hefðbundin vinna í þessum kerfum krefst ekki tilvistar kunnuglegs grafísks viðmóts, sem býður notandanum aðeins upp á leikjatölvu sem stjórnhluta. Fyrir óreyndan notanda getur verið erfitt að vinna á þessu sniði, bara hvað kostar að hætta í textaritli sem er nokkuð vinsæll í gögnum Vim, spurning sem tengist þessu hefur þegar fengið meira en 6 milljónir áhorfa á 1.8 árum. Helstu dreifingar (útgáfur) þessarar fjölskyldu eru: Debian - vinsæl dreifing, pakkaútgáfur í henni beinast aðallega að LTS (Langtíma stuðningur - stuðningur í langan tíma), sem kemur fram í nokkuð miklum áreiðanleika og stöðugleika kerfisins og pakka; ubuntu – inniheldur dreifingu allra pakka í nýjustu útgáfum þeirra, sem getur haft áhrif á stöðugleika, en gerir þér kleift að nota virknina sem fylgir nýjum útgáfum; Red Hat Enterprise Linux – OS, staðsett til notkunar í atvinnuskyni, er greitt, þó felur í sér stuðning frá hugbúnaðarframleiðendum, sumir sérpakkar og ökumannspakkar; CentOS - opinn uppspretta afbrigði af Red Hat Enterprise Linux, sem einkennist af skorti á sérpakka og stuðningi.

Fyrir þá sem eru að byrja að ná tökum á þessu sviði, þá væri ráðleggingin mín kerfi Windows ServerEða ubuntu. Ef við lítum á Windows, þá er þetta fyrst og fremst kunnugleiki kerfisins, ubuntu – meira umburðarlyndi gagnvart uppfærslum, og aftur á móti, til dæmis, færri vandamál þegar sett eru af stað verkefni um tækni sem krefjast nýrra útgáfur.

Svo, eftir að hafa ákveðið stýrikerfið, skulum við halda áfram að setja af verkfærum sem gera þér kleift að dreifa (setja upp), uppfæra og fylgjast með stöðu forritsins eða hluta þess á þjóninum.

Næsta mikilvæga ákvörðun verður staðsetning forritsins þíns og netþjónsins fyrir það. Í augnablikinu eru algengustu 3 leiðirnar:

  • Að hýsa (halda) netþjóni á eigin spýtur er kostnaðarvænasti kosturinn, en þú verður að panta fasta IP frá þjónustuveitunni þinni svo að auðlindin þín breyti ekki heimilisfangi sínu með tímanum.
  • Leigðu sérstakan netþjón (VDS) – og stjórnaðu honum sjálfstætt og skalaðu álag
  • Borgaðu (oft gefa þeir þér tækifæri til að prófa virkni vettvangsins ókeypis) fyrir áskrift að einhverri skýhýsingu, þar sem greiðslulíkanið fyrir auðlindirnar sem notaðar eru er nokkuð algengt. Mest áberandi fulltrúar þessarar áttar: Amazon AWS (þeir gefa ókeypis ár til að nota þjónustuna, en með mánaðarlegum takmörkunum), Google Cloud (þeir gefa $300 á reikninginn, sem hægt er að eyða á árinu í skýhýsingarþjónustu) , Yandex.Cloud (þeir gefa 4000 rúblur . í 2 mánuði), Microsoft Azure (gefa ókeypis aðgang að vinsælum þjónustu í eitt ár, + 12 rúblur fyrir hvaða þjónustu sem er í einn mánuð). Þannig geturðu prófað hvaða af þessum veitendum sem er án þess að eyða eyri, en fá áætlaða skoðun um gæði og þjónustustig sem veitt er.

Það fer eftir valinni leið, það eina sem mun breytast í framtíðinni er hver ber að mestu ábyrgð á þessu eða hinu stjórnsýslusviði. Ef þú hýsir sjálfan þig, þá verður þú að skilja að allar truflanir á rafmagni, internetinu, þjóninum sjálfum, hugbúnaðinum sem er notaður á honum - allt þetta liggur algjörlega á þínum herðum. Hins vegar, fyrir þjálfun og próf, er þetta meira en nóg.

Ef þú ert ekki með auka vél sem getur gegnt hlutverki netþjóns, þá viltu nota aðra eða þriðju leiðina. Annað tilvikið er eins og hið fyrra, með þeirri undantekningu að þú færir ábyrgðina á framboði netþjónsins og krafti hans yfir á herðar hýsingaraðilans. Umsjón netþjónsins og hugbúnaðarins er enn undir þinni stjórn.

Og að lokum, möguleikinn á að leigja getu skýjaveitenda. Hér geturðu sett upp sjálfvirka stjórn á nánast hverju sem er án þess að fara út í of mikil tæknileg smáatriði. Að auki, í stað einnar vélar, geturðu haft nokkur samhliða keyrslutilvik, sem geta td verið ábyrg fyrir mismunandi hlutum forritsins, á sama tíma og það er ekki mikill munur á kostnaði frá því að eiga sérstakan netþjón. Og líka, það eru verkfæri fyrir hljómsveit, gámavæðingu, sjálfvirka dreifingu, stöðuga samþættingu og margt fleira! Við skoðum nokkur af þessum hlutum hér að neðan.

Almennt séð lítur innviði netþjónsins svona út: við erum með svokallaðan „orchestrator“ („orchestrator“ er ferlið við að stjórna nokkrum netþjónstilvikum), sem stjórnar umhverfisbreytingum á netþjónstilviki, sýndarvæðingaríláti (valfrjálst, en alveg oft notað), sem gerir þér kleift að skipta forritinu í einangruð rökrétt lög, og Continuous Integration hugbúnaður – sem gerir uppfærslum á hýstum kóða í gegnum „forskriftir“.

Svo, skipulagning gerir þér kleift að sjá stöðu netþjóna, rúlla út eða afturkalla uppfærslur á netþjónaumhverfinu og svo framvegis. Í fyrstu er ólíklegt að þessi þáttur hafi áhrif á þig, þar sem til að skipuleggja eitthvað þarftu nokkra netþjóna (þú getur haft einn, en hvers vegna er þetta nauðsynlegt?), og til að hafa nokkra netþjóna þarftu þá. Meðal verkfæra í þessa átt er vinsælasta tækið Kubernetes, þróað af Google.

Næsta skref er sýndarvæðing á stýrikerfisstigi. Nú á dögum hefur hugtakið „dockerization“ orðið útbreitt, sem kemur frá tólinu Docker, sem veitir virkni gáma sem eru einangraðir hver frá öðrum, en hleypt af stokkunum í samhengi við eitt stýrikerfi. Hvað þýðir þetta: í öllum þessum gámum geturðu keyrt forrit, eða jafnvel sett af forritum, sem trúa því að þau séu þau einu í öllu stýrikerfinu, án þess að gruna tilvist einhvers annars á þessari vél. Þessi aðgerð er mjög gagnleg til að ræsa eins forrit af mismunandi útgáfum, eða einfaldlega misvísandi forrit, sem og til að skipta hluta af forriti í lög. Þessa lagafsteypu er síðar hægt að skrifa inn í mynd, sem hægt er að nota til dæmis til að dreifa forriti. Það er að segja, með því að setja upp þessa mynd og dreifa gámunum sem hún inniheldur færðu tilbúið umhverfi til að keyra forritið þitt! Í fyrstu skrefunum geturðu notað þetta tól bæði í upplýsingaskyni og til að fá mjög raunverulegan ávinning með því að skipta forritsrökfræðinni í mismunandi lög. En það er þess virði að segja hér að ekki allir þurfa hafnarvæðingu, og ekki alltaf. Skipulagning er réttlætanleg í þeim tilfellum þar sem forritið er „brotið“, skipt í litla hluta, sem hver ber ábyrgð á sínu verkefni, svokallaðan „örþjónustuarkitektúr“.

Auk þess, auk þess að útvega umhverfið, þurfum við að tryggja hæfa dreifingu forritsins, sem felur í sér alls kyns kóðabreytingar, uppsetningu á forritatengdum bókasöfnum og pakka, keyrslupróf, tilkynningar um þessar aðgerðir, og svo framvegis. Hér þurfum við að borga eftirtekt til hugtaks eins og „Stöðug samþætting“ (CI – Continuous Integration). Helstu verkfærin á þessu sviði í augnablikinu eru Jenkins (CI hugbúnaður skrifaður í Java kann að virðast svolítið flókinn í upphafi), Travis C.I. (skrifað í Ruby, huglægt, nokkuð einfaldara Jenkins, þó er enn þörf á nokkurri þekkingu á sviði uppsetningaruppsetningar), Gitlab CI (skrifað á Ruby og Go).

Svo, eftir að hafa talað um umhverfið sem forritið þitt mun virka í, er kominn tími til að skoða loksins hvaða verkfæri nútímaheimurinn býður okkur til að búa til einmitt þessi forrit.

Byrjum á grunnatriðum: Bakendi (bakendi) – miðlarahluti. Val á tungumáli, mengi grunnaðgerða og fyrirfram skilgreindri uppbyggingu (rammi) hér ræðst aðallega af persónulegum óskum, en engu að síður er vert að nefna það til athugunar (álit höfundar um tungumál er nokkuð huglægt, þó með fullyrðingu að óhlutdrægri lýsingu):

  • Python er frekar vinalegt tungumál fyrir óreynda notanda, það fyrirgefur sum mistök, en það getur líka verið frekar strangt við forritarann ​​svo hann geri ekki neitt slæmt. Nú þegar nokkuð þroskað og þroskandi tungumál, sem birtist árið 1991.
  • Go - tungumál frá Google, er líka frekar vinalegt og þægilegt, það er frekar auðvelt að setja saman og fá keyranlega skrá á hvaða vettvang sem er. Það getur verið einfalt og notalegt, eða það getur verið flókið og alvarlegt. Ferskur og ungur, birtist tiltölulega nýlega, árið 2009.
  • Rust er aðeins eldri en fyrri samstarfsmaður hans, kom út árið 2006, en er enn frekar ungur miðað við jafnaldra sína. Miðar að reyndari forriturum, þó að það reyni enn að leysa mörg verkefni á lágu stigi fyrir forritarann.
  • Java er öldungur í viðskiptaþróun, kynnt árið 1995, og er eitt algengasta tungumálið í þróun fyrirtækjaforrita í dag. Með grunnhugtökum og þungri uppsetningu getur keyrslutíminn orðið ansi krefjandi fyrir byrjendur.
  • ASP.net er forritaþróunarvettvangur gefinn út af Microsoft. Til að skrifa virkni er C# tungumálið (borið fram C Sharp), sem kom fram árið 2000, aðallega notað. Flækjustig þess er sambærilegt við stigið á milli Java og Rust.
  • PHP, sem upphaflega var notað fyrir HTML forvinnslu, er í augnablikinu, þó að það hafi algjöra forystu á tungumálamarkaðnum, þróun í átt að samdrætti í notkun. Það hefur lágan aðgangsþröskuld og auðvelt að skrifa kóða, en á sama tíma, þegar verið er að þróa frekar stór forrit, getur virkni tungumálsins ekki verið nóg.

Jæja, síðasti hluti umsóknar okkar - sá áþreifanlegasti fyrir notandann - Viðmót (framenda) – er andlit forritsins þíns; það er við þennan hluta sem notandinn hefur bein samskipti.

Án þess að fara í smáatriði, stendur nútíma framhliðin á þremur stoðum, ramma (og ekki svo mikið), til að búa til notendaviðmót. Samkvæmt því eru þrír vinsælustu:

  • ReactJS er ekki rammi heldur bókasafn. Raunar er ramminn aðeins frábrugðinn stoltum titli þar sem sumar aðgerðir eru „úr kassanum“ og þörfin á að setja þær upp handvirkt. Þannig eru til nokkur afbrigði af „undirbúningi“ þessa bókasafns, sem mynda einstaka ramma. Það getur verið svolítið erfitt fyrir byrjendur, vegna nokkurra grundvallarreglna og nokkuð árásargjarnrar uppsetningar á byggingarumhverfinu. Hins vegar, til að byrja fljótt, geturðu notað „create-react-app“ pakkann.
  • VueJS er rammi til að byggja upp notendaviðmót. Af þessari þrenningu tekur hún með réttu titilinn notendavænasta umgjörðin; fyrir þróun í Vue er aðgangshindrunin lægri en hinir nefndu bræður. Þar að auki er hann yngstur þeirra.
  • Angular er talinn flóknasta þessara ramma, sá eini sem krefst vélritun (viðbót fyrir Javascript tungumál). Oft notað til að smíða stór fyrirtækisforrit.

Með því að draga saman það sem var skrifað hér að ofan getum við ályktað að nú sé innleiðing forrits gjörólík því hvernig þetta ferli fór fram áður. Hins vegar er enginn að hindra þig í að gera „dreifinguna“ á gamla mátann. En er sá litli tími sem sparast í upphafi þess virði hinnar miklu mistaka sem verktaki sem velur þessa leið þarf að stíga á? Ég tel að svarið sé nei. Með því að eyða aðeins meiri tíma í að kynna þér þessi verkfæri (og þú þarft ekki meira en það, vegna þess að þú þarft að skilja hvort þú þarft á þeim að halda í núverandi verkefni eða ekki), geturðu spilað það út, dregið verulega úr t.d. , tilvik um draugavillur eftir umhverfinu og sem birtast aðeins á framleiðsluþjóninum, næturgreining á því hvað leiddi til þess að netþjónninn hrundi og hvers vegna hann byrjar ekki, og margt fleira.

Heimild: www.habr.com

Bæta við athugasemd