For å lage din egen webapplikasjon i vår tid er det ikke nok å kunne utvikle den. Et viktig aspekt er å sette opp verktøy for applikasjonsdistribusjon, overvåking, samt administrasjon og administrasjon av miljøet det opererer i. Ettersom tiden med manuell distribusjon forsvinner i glemselen, selv for små prosjekter, kan automatiseringsverktøy gi konkrete fordeler. Når vi distribuerer "for hånd", kan vi ofte glemme å flytte noe, ta hensyn til denne eller den nyansen, kjøre en glemt test, denne listen kan fortsette i ganske lang tid.
Denne artikkelen kan hjelpe de som bare lærer det grunnleggende om å lage webapplikasjoner og ønsker å forstå litt om de grunnleggende vilkårene og konvensjonene.
Så byggeapplikasjoner kan fortsatt deles inn i 2 deler: alt som er relatert til applikasjonskoden, og alt som er relatert til miljøet der denne koden kjøres. Applikasjonskoden er på sin side også delt inn i serverkode (den som kjører på serveren, ofte: forretningslogikk, autorisasjon, datalagring osv.), og klientkode (den som kjører på brukerens maskin: ofte grensesnittet og relatert logikk med det).
La oss starte med onsdag.
Grunnlaget for driften av enhver kode, system eller programvare er operativsystemet, så nedenfor vil vi se på de mest populære systemene på hostingmarkedet og gi dem en kort beskrivelse:
Windows Server - samme Windows, men i en servervariant. Noe funksjonalitet tilgjengelig i klientversjonen (vanlig) av Windows er ikke til stede her, for eksempel noen tjenester for innsamling av statistikk og lignende programvare, men det er et sett med verktøy for nettverksadministrasjon, grunnleggende programvare for distribusjon av servere (web, ftp, ...). Generelt ser Windows Server ut som vanlig Windows, kvaksalver som vanlig Windows, men det koster 2 ganger mer enn det vanlige motstykket. Men gitt at du mest sannsynlig vil distribuere applikasjonen på en dedikert/virtuell server, er den endelige kostnaden for deg, selv om den kan øke, ikke kritisk. Siden Windows-plattformen har en overveldende plass i OS-markedet for forbrukere, vil serverutgaven være den mest kjente for de fleste brukere.
Unix- lignende system. Tradisjonelt arbeid i disse systemene krever ikke tilstedeværelsen av et kjent grafisk grensesnitt, og tilbyr brukeren kun en konsoll som et kontrollelement. For en uerfaren bruker kan det være vanskelig å jobbe i dette formatet, akkurat hva koster det å avslutte en tekstredigerer som er ganske populær i data Vim, et spørsmål knyttet til dette har allerede fått mer enn 6 millioner visninger på 1.8 år. Hoveddistribusjonene (utgavene) av denne familien er: Debian - en populær distribusjon, pakkeversjoner i den er hovedsakelig fokusert på LTS (Langsiktig støtte – støtte i lang tid), som kommer til uttrykk i ganske høy pålitelighet og stabilitet til systemet og pakkene; Ubuntu – inneholder distribusjoner av alle pakker i deres nyeste versjoner, som kan påvirke stabiliteten, men lar deg bruke funksjonaliteten som følger med nye versjoner; Red Hat Enterprise Linux – OS, posisjonert for kommersiell bruk, er betalt, men inkluderer støtte fra programvareleverandører, noen proprietære pakker og driverpakker; CentOS - åpen kildekode en variant av Red Hat Enterprise Linux, preget av fraværet av proprietære pakker og støtte.
For de som akkurat begynner å mestre dette området, vil min anbefaling være systemer Windows ServerEller Ubuntu. Hvis vi vurderer Windows, så er dette først og fremst kjentheten til systemet, Ubuntu – mer toleranse for oppdateringer, og i sin tur for eksempel færre problemer ved lansering av prosjekter på teknologier som krever nye versjoner.
Så, etter å ha bestemt oss for OS, la oss gå videre til et sett med verktøy som lar deg distribuere (installere), oppdatere og overvåke tilstanden til applikasjonen eller dens deler på serveren.
Den neste viktige avgjørelsen vil være plasseringen av applikasjonen din og serveren for den. For øyeblikket er de vanligste 3 måter:
- Å være vert for (holde) en server på egen hånd er det mest budsjettvennlige alternativet, men du må bestille en statisk IP fra leverandøren din slik at ressursen din ikke endrer adresse over tid.
- Lei en dedikert server (VDS) – og administrer den uavhengig og skaler belastninger
- Betal (ofte gir de deg en sjanse til å prøve plattformens funksjonalitet gratis) for et abonnement på noe skyhosting, der betalingsmodellen for ressursene som brukes er ganske vanlig. De mest fremtredende representantene for denne retningen: Amazon AWS (de gir et gratis år med å bruke tjenestene, men med en månedlig grense), Google Cloud (de gir $ 300 til kontoen, som kan brukes i løpet av året på skyvertstjenester) , Yandex.Cloud (de gir 4000 rubler . i 2 måneder), Microsoft Azure (gi gratis tilgang til populære tjenester i et år, + 12 500 rubler for alle tjenester i en måned). Dermed kan du prøve noen av disse leverandørene uten å bruke en krone, men få en omtrentlig mening om kvaliteten og nivået på tjenesten som tilbys.
Avhengig av den valgte veien, er det eneste som vil endre seg i fremtiden hvem som i stor grad er ansvarlig for dette eller det administrasjonsområdet. Hvis du er vert for deg selv, må du forstå at eventuelle avbrudd i elektrisitet, Internett, selve serveren, programvaren som er distribuert på den - alt dette ligger helt på skuldrene dine. Men for trening og testing er dette mer enn nok.
Hvis du ikke har en ekstra maskin som kan spille rollen som en server, vil du bruke den andre eller tredje måten. Det andre tilfellet er identisk med det første, med unntak av at du flytter ansvaret for serverens tilgjengelighet og dens makt til hosterens skuldre. Administrasjon av serveren og programvaren er fortsatt under din kontroll.
Og til slutt, muligheten til å leie kapasiteten til skyleverandører. Her kan du sette opp automatisert kontroll av nesten hva som helst uten å gå i for mye tekniske detaljer. I tillegg kan du i stedet for én maskin ha flere parallelle kjørende instanser, som for eksempel kan stå for ulike deler av applikasjonen, samtidig som det ikke skiller mye i kostnad fra å eie en dedikert server. Og også, det er verktøy for orkestrering, containerisering, automatisk distribusjon, kontinuerlig integrasjon og mye mer! Vi skal se på noen av disse tingene nedenfor.
Generelt ser serverinfrastrukturen slik ut: vi har en såkalt "orkestrator" ("orkestrering" er prosessen med å administrere flere serverforekomster), som håndterer miljøendringer på en serverforekomst, en virtualiseringsbeholder (valgfritt, men ganske ofte brukt), som lar deg dele opp applikasjonen i isolerte logiske lag, og Continuous Integration-programvare – som tillater oppdateringer til vertskode gjennom "skript".
Så, orkestrering lar deg se statusen til servere, rulle ut eller rulle tilbake oppdateringer til servermiljøet, og så videre. Til å begynne med er det usannsynlig at dette aspektet vil påvirke deg, siden for å orkestrere noe, trenger du flere servere (du kan ha en, men hvorfor er dette nødvendig?), og for å ha flere servere trenger du dem. Blant verktøyene i denne retningen er det mest populære Kubernetes, utviklet av Google.
Det neste trinnet er virtualisering på OS-nivå. I dag har konseptet "dockerisering" blitt utbredt, som kommer fra verktøyet Docker, som gir funksjonaliteten til beholdere isolert fra hverandre, men lansert i sammenheng med ett operativsystem. Hva betyr dette: i hver av disse beholderne kan du kjøre en applikasjon, eller til og med et sett med applikasjoner, som vil tro at de er de eneste i hele OS, uten engang å mistenke eksistensen av noen andre på denne maskinen. Denne funksjonen er veldig nyttig for å starte identiske applikasjoner av forskjellige versjoner, eller ganske enkelt motstridende applikasjoner, samt for å dele deler av en applikasjon i lag. Denne lagstøpen kan senere skrives inn i et bilde, som for eksempel kan brukes til å distribuere en applikasjon. Det vil si at ved å installere dette bildet og distribuere containerne det inneholder, får du et ferdig miljø for å kjøre applikasjonen din! I de første trinnene kan du bruke dette verktøyet både til informasjonsformål og for å få svært reelle fordeler ved å dele applikasjonslogikken i forskjellige lag. Men det er verdt å si her at ikke alle trenger dockerisering, og ikke alltid. Dockerisering er berettiget i tilfeller der applikasjonen er «fragmentert», delt opp i små deler, hver ansvarlig for sin egen oppgave, den såkalte «microservice-arkitekturen».
I tillegg, i tillegg til å tilby miljøet, må vi sørge for en kompetent distribusjon av applikasjonen, som inkluderer alle typer kodetransformasjoner, installasjon av applikasjonsrelaterte biblioteker og pakker, kjørende tester, varsler om disse operasjonene, og så videre. Her må vi ta hensyn til et slikt konsept som "Kontinuerlig integrasjon" (CI – Kontinuerlig integrasjon). Hovedverktøyene på dette området for øyeblikket er Jenkins (CI-programvare skrevet i Java kan virke litt komplisert i starten), Travis C.I. (skrevet i Ruby, subjektiv, noe enklere Jenkins, men noe kunnskap innen distribusjonskonfigurasjon er fortsatt nødvendig), Gitlab CI (skrevet på Ruby og Go).
Så etter å ha snakket om miljøet applikasjonen din vil fungere i, er det på tide å endelig se på hvilke verktøy den moderne verden tilbyr oss for å lage akkurat disse applikasjonene.
La oss starte med det grunnleggende: Backend (backend) – serverdel. Valg av språk, sett med grunnleggende funksjoner og forhåndsdefinert struktur (rammeverk) her bestemmes hovedsakelig av personlige preferanser, men likevel er det verdt å nevne for vurdering (forfatterens mening om språk er ganske subjektiv, men med en påstand til en objektiv beskrivelse):
- Python er et ganske vennlig språk for en uerfaren bruker, det tilgir noen feil, men det kan også være ganske strengt med utvikleren slik at han ikke gjør noe dårlig. Allerede et ganske modent og meningsfylt språk, som dukket opp i 1991.
- Go - et språk fra Google, er også ganske vennlig og praktisk, det er ganske enkelt å kompilere og få en kjørbar fil på hvilken som helst plattform. Det kan være enkelt og hyggelig, eller det kan være komplekst og alvorlig. Frisk og ung, dukket opp relativt nylig, i 2009.
- Rust er litt eldre enn sin forrige kollega, utgitt i 2006, men er fortsatt ganske ung sammenlignet med jevnaldrende. Rettet mot mer erfarne utviklere, selv om den fortsatt prøver å løse mange lavnivåoppgaver for programmereren.
- Java er en veteran innen kommersiell utvikling, introdusert i 1995, og er et av de mest brukte språkene i bedriftsapplikasjonsutvikling i dag. Med sine grunnleggende konsepter og tunge oppsett kan kjøretiden bli ganske utfordrende for en nybegynner.
- ASP.net er en applikasjonsutviklingsplattform utgitt av Microsoft. For å skrive funksjonalitet brukes hovedsakelig C#-språket (uttales C Sharp), som dukket opp i 2000. Dens kompleksitet er sammenlignbar med nivået mellom Java og Rust.
- PHP, opprinnelig brukt til HTML-forbehandling, er for tiden, selv om det har absolutt lederskap på språkmarkedet, en trend mot en nedgang i bruk. Den har en lav inngangsterskel og enkel å skrive kode, men samtidig, når man utvikler ganske store applikasjoner, kan det hende at funksjonaliteten til språket ikke er nok.
Vel, den siste delen av søknaden vår - den mest håndgripelige for brukeren - Frontend (frontend) – er ansiktet til applikasjonen din; det er med denne delen at brukeren samhandler direkte.
Uten å gå i detaljer, står den moderne frontend på tre pilarer, rammer (og ikke så mye), for å lage brukergrensesnitt. Følgelig er de tre mest populære:
- ReactJS er ikke et rammeverk, men et bibliotek. Faktisk skiller rammeverket seg fra sin stolte tittel bare i fravær av noen funksjoner "ut av esken" og behovet for å installere dem manuelt. Dermed er det flere varianter av "forberedelsen" av dette biblioteket, og danner unike rammer. Det kan være litt vanskelig for en nybegynner, på grunn av noen grunnleggende prinsipper, og ganske aggressivt oppsett av byggemiljøet. For en rask start kan du imidlertid bruke "create-react-app"-pakken.
- VueJS er et rammeverk for å bygge brukergrensesnitt. Av denne treenigheten tar den med rette tittelen på det mest brukervennlige rammeverket; for utvikling i Vue er inngangsbarrieren lavere enn for de andre nevnte brødrene. Dessuten er han den yngste blant dem.
- Angular regnes som den mest komplekse av disse rammene, den eneste som krever Loggfila (tillegg for Javascript-språk). Brukes ofte til å bygge store bedriftsapplikasjoner.
Ved å oppsummere det som ble skrevet ovenfor, kan vi konkludere med at distribusjon av en applikasjon nå er radikalt forskjellig fra hvordan denne prosessen gikk før. Imidlertid er det ingen som hindrer deg i å gjøre "distribusjonen" på gammeldags måte. Men er den lille tiden spart i starten verdt det enorme antallet feil som en utvikler som velger denne veien må tråkke på? Jeg tror svaret er nei. Ved å bruke litt mer tid på å gjøre deg kjent med disse verktøyene (og du trenger ikke mer enn det, fordi du må forstå om du trenger dem i ditt nåværende prosjekt eller ikke), kan du spille det ut, og redusere f.eks. , tilfeller av spøkelsesfeil avhengig av miljøet og som bare vises på produksjonsserveren, nattlig analyse av hva som førte til serverkrasj og hvorfor den ikke starter, og mye mer.
Kilde: www.habr.com