I dag er det ikke nok at kunne udvikle sin egen webapplikation. En vigtig aspekt er at konfigurere værktøjerne til implementering af applikationen, overvågning samt administration af det miljø, hvori den kører. Tiden med manuel implementering er ved at forsvinde, selv for mindre projekter, hvor automatiseringsværktøjer kan bringe betydelige fordele. Ved manuel implementering glemmer vi ofte at overføre noget, tage højde for en nuance eller køre en glemt test, og denne liste kan fortsætte ret længe.
Denne artikel kan hjælpe dem, der først begynder at forstå grundlæggende webapplikationer og ønsker at få en lille indsigt i de vigtigste termer og konventioner.
Således kan udviklingen af applikationer opdeles i to dele: det, der vedrører applikationskoden, og det, der vedrører det miljø, hvori denne kode udføres. Applikationskoden opdeles også i serverkode (den, der kører på serveren, ofte: forretningslogik, autentifikation, datalagring osv.) og klientkode (den, der kører på brugerens enhed: ofte brugergrænseflade og relateret logik).
Lad os begynde med miljøet.
Grundlaget for enhver kode, system eller software er operativsystemet; derfor vil vi nedenfor se på de mest populære systemer, der findes på hostingmarkedet, og give en kort beskrivelse af dem:
Windows Server – det er den kendte Windows, men i servervarianten. Nogle funktioner, der er tilgængelige i klientversionen af Windows, findes ikke her, såsom nogle tjenester til indsamling af statistik og lignende software, men der er et sæt værktøjer til netværksadministration og grundlæggende software til implementering (web, ftp, …). Alt i alt ligner Windows Server en almindelig Windows, knirker som en almindelig Windows, men koster dobbelt så meget som sin almindelige modpart. Men da du sandsynligvis vil implementere applikationen på en dedikeret/virtuel server, kan den endelige pris for dig stige, men ikke kritisk. Da Windows-platformen dominerer markedet for brugeroperativsystemer, vil dens serverudgave være den mest velkendte for de fleste brugere. servere (web, ftp, …). Generelt set ser Windows Server ud som en almindelig Windows, knirker som en almindelig Windows, men koster dobbelt så meget som sin almindelige modpart. Men da implementeringen af applikationen sandsynligvis vil finde sted på en dedikeret/virtuel server, kan den endelige pris for dig, selv om den kan stige, ikke være kritisk. Da Windows-platformen har en dominerende position på markedet for bruger-OS, vil dens serverversion være den mest velkendte for de fleste brugere.
Unix-lignende system. Traditionelt arbejde i sådanne systemer indebærer ikke et almindeligt grafisk interface og tilbyder brugeren kun en konsol som kontrolelement. For den uerfarne bruger kan arbejde i et sådant format være en udfordring, som det kun kræver at forlade et ret populært tekstredigeringsværktøj. Vim, spørgsmålet vedrørende dette har allerede samlet mere end 1,8 millioner visninger i løbet af 6 år. De vigtigste distributioner (udgaver) af denne familie er: Debian - en populær distribution, hvor pakkeversionerne primært er rettet mod LTS (Long Term Support - langsigtet support), hvilket resulterer i en relativt høj grad af pålidelighed og stabilitet i systemet og pakkerne; Ubuntu - indeholder distributioner af alle pakker i deres nyeste versioner, hvilket kan påvirke stabiliteten, men gør det muligt at bruge funktioner leveret med de nye versioner; Red Hat Enterprise Linux - et operativsystem, der er positioneret til kommerciel brug, er betalt, men inkluderer support fra softwareleverandører, visse proprietære pakker og driverpakker; CentOS - open source variation af Red Hat Enterprise Linux, adskiller sig ved at mangle proprietære pakker og support.
For dem, der blot begynder at udforske dette område, vil min anbefaling være systemer Windows Server, eller Ubuntu. Når vi taler om Windows, er det først og fremmest brugervenligheden af systemet, Ubuntu - mere tolerance over for opdateringer, og i øvrigt f.eks. færre problemer med at køre projekter på teknologier, der kræver de nyeste versioner.
Så snart vi har besluttet os for et operativsystem, lad os gå videre til værktøjssættet, der gør det muligt at deployere (installere), opdatere og overvåge tilstanden af applikationen eller dens dele på serveren.
Det næste vigtige valg vil være - placeringen af din applikation og serveren for den. I øjeblikket er der tre mest udbredte muligheder:
- At hoste (holde) serveren selv — den mest budgetvenlige mulighed, men du bliver nødt til at bestille en statisk IP fra din udbyder, så din ressource ikke ændrer adresse over tid.
- Leje en dedikeret server (VDS) - og selv administrere den og skalere belastningerne.
- Betal for et abonnement (ofte med en gratis prøve på platformens funktioner) på en cloud-hosting, hvor betalingsmodellen forbrug af ressourcer er ret almindelig. De mest prominente aktører inden for dette felt er: Amazon AWS (giver et gratis år med tjenesteydelser, men med en månedlig grænse), Google Cloud (giver 300$ i kredit, som kan bruges i løbet af et år på cloud-tjenester, hosting), Yandex.Облако (giver 4000 rubler i 2 måneder), Microsoft Azure (giver gratis adgang til populære tjenester i et år + 12.500 rubler til enhver tjeneste i løbet af en måned). På denne måde kan du prøve nogen af disse udbydere uden at bruge en øre, men få en idé om kvaliteten og niveauet af de leverede tjenester.
Afhængigt af den valgte vej ændres kun det faktum, hvem der i høj grad har ansvaret for det eller det område af administration. Hvis du hoster selv, skal du forstå, at enhver afbrydelse af elektricitet, internettet, selve serveren og software installeret på den - alt dette hviler fuldstændigt på dine skuldre. Men til læring og testning er dette mere end tilstrækkeligt.
Hvis du ikke har en ekstra maskine, der kan fungere som server, vil du måske vælge den anden eller tredje vej. Det andet tilfælde er identisk med det første, bortset fra, at du overfører ansvaret for serverens tilgængelighed og dens kapaciteter til udbyderen. Administrationen af serveren og software er stadig under din kontrol.
Og endelig er der muligheden for at leje kapaciteter fra cloud-udbydere. Her kan du indstille automatisk styring af næsten hvad som helst, uden at dykke dybt ind i tekniske detaljer. Derudover kan du have flere parallelle instanser i stedet for én maskine, som kan håndtere forskellige dele af applikationen, og som ikke adskiller sig meget i pris fra at eje en dedikeret server. Desuden er der værktøjer til orkestrering, containerisering, automatisk implementering, kontinuerlig integration og meget mere! Nogle af disse ting vil vi se nærmere på nedenfor.
Generelt set ser serverinfrastrukturen således ud: vi har det såkaldte "orkestrator" ("orkestrering" er processen med at styre flere serverinstanser), der håndterer ændringer i miljøet på serverinstansen, en virtualiseringselement (valgfri, men ofte brugt), der muliggør opdeling af applikationen i isolerede logiske lag, og software til kontinuerlig integration - der muliggør opdatering af den udbudte kode via "scripts".
Så orkestreringen giver dig mulighed for at se servernes status, udføre "implementering" eller "tilbagetrækning" af opdateringer til serverens miljø, og så videre. I starten vil dette aspekt næppe vedrøre dig, da det kræver flere servere for at orkestrere noget (man kan bruge én, men hvorfor?), og for at have flere servere skal der være et behov for dem. Blandt værktøjerne inden for dette område er Kubernetes, som er meget omtalt og udviklet. Google.
Det næste trin er virtualisering på OS-niveau. I dag er begrebet "dockerisering" blevet udbredt, hvilket kommer fra værktøjet. Docker, der tilbyder funktionalitet i isolerede containere, der alligevel kører i konteksten af et enkelt operativsystem. Hvad betyder det: I hver af disse containere kan man køre en applikation eller endda et sæt af applikationer, som vil tro, at de er de eneste i hele OS'et, uden at være klar over, at der findes andre på den samme maskine. Denne funktion er meget nyttig til at køre identiske applikationer i forskellige versioner eller blot konfliktende applikationer, samt til at adskille dele af applikationen i lag. Denne snapshot af lagene kan senere gemmes i et billede, som kan bruges til eksempelvis at deployere applikationen. Med andre ord, ved at installere dette billede og udpakke de containere, det indeholder, får du et klar til at køre miljø for din applikation! I de tidlige faser kan du bruge dette værktøj både til læring og til at få reel værdi ved at opdele logikken af applikationen på forskellige lag. Men det skal siges, at dockerisering ikke er nødvendigt for alle, og ikke altid. Dockerisering er berettiget i tilfælde hvor applikationen er 'fragmenteret', opdelt i små dele, hvor hver del tager sig af sin egen opgave, en såkaldt 'mikroservice-arkitektur'.
Derudover, ud over at sikre miljøet, skal vi også sikre en ordentlig deployment af applikationen, som inkluderer alle mulige transformationer af koden, installationer af tilknyttede biblioteker og pakker, kørsel af tests, meddelelser om disse operationer osv. Her skal vi være opmærksomme på et begreb som 'Continuous Integration' (CI – Continuous Integration). De vigtigste værktøjer i dette område i øjeblikket er Jenkins (et CI-værktøj skrevet i Java, som kan virke lidt kompliceret i starten), Travis CI (skrevet i Ruby, subjektivt set lidt nemmere end Jenkins, men alligevel kræver det en smule viden om opsætning af deployment), Gitlab CI (skrevet i Ruby og Go).
Så, efter at have talt om miljøet, som din applikation skal arbejde i, er det tid endelig at se, hvilke værktøjer den moderne verden tilbyder os til at skabe disse applikationer.
Lad os starte med grundlaget: Backend (backend) – den server-side. Valg af sprog, sæt af grundlæggende funktioner og forudbestemt struktur (rammeværk) bestemmes primært af personlige præferencer, men det er stadig værd at nævne til overvejelse (forfatterens mening om sprog er ret subjektiv, selvom den påstår at være objektiv):
- Python – et sprog, der er ret venligt for den uerfarne bruger, tilgiver nogle fejl, men kan også være strengt over for udvikleren, så de ikke laver alvorlige fejl. Det er et relativt modent og gennemtænkt programmeringssprog, der blev introduceret i 1991.
- Go – et sprog fra Google, som også er ret venligt og bekvemt, nemt at kompilere og få en eksekverbar fil til enhver platform. Det kan være simpelt og behageligt eller komplekst og seriøst. Frisk og ungt, introduceret i 2009.
- Rust – lidt ældre end sin kollega, udgivet i 2006, stadig relativt ung i forhold til sine søskende. Fokuseret på mere erfarne udviklere, selvom det stadig forsøger at løse mange lavniveau opgaver for programmøren.
- Java – en veteran inden for kommerciel udvikling, der blev introduceret i 1995, en af de mest anvendte sprog til udvikling af virksomhedsapplikationer på nuværende tidspunkt. Med sine grundlæggende koncepter og tunge opsætning kan det blive ret komplekst for nybegyndere.
- ASP.net – en platform til applikationsudvikling, udgivet af Microsoft. Til at skrive funktionalitet bruges primært sproget C# (udtales C-sharp), som blev introduceret i 2000. Dens kompleksitet er sammenlignelig med niveauet mellem Java og Rust.
- PHP – oprindeligt brugt til preprocessing af HTML, i dag, selvom det stadig dominerer markedet for sprog, er der en tendens til faldende brug. Den har en lav tærskel for adgang, enkelhed i kodning, men samtidig kan sprogets funktionalitet vise sig at være utilstrækkelig til større applikationer.
Og den sidste del af vores applikation – den mest håndgribelige for brugeren – Frontend (frontend) – er ansigtet på din applikation, det er denne del, brugeren interagerer direkte med.
Uden at gå i detaljer, står moderne frontend på tre søjler, rammer (og ikke så meget) til opbygning af brugergrænseflader. Derfor er de tre mest populære:
- ReactJS – er ikke en ramme, men et bibliotek. Det adskiller sig fra det stolte kaldenavn ramme kun ved fraværet af nogle funktioner "out of the box" og nødvendigheden af at installere dem manuelt. Der findes således flere variationer af "forberedelsen" af dette bibliotek, der danner særprægede rammer. For en nybegynder kan det være lidt svært på grund af nogle grundlæggende principper og en ret aggressiv opsætning af bygge-miljøet. Men for en hurtig start kan man bruge "create-react-app" pakken.
- VueJS – en ramme til opbygning af brugergrænseflader. Blandt denne trio får den fortjent titlen som den mest brugervenlige ramme, idet indgangsbarrieren for udvikling i Vue er lavere end for de øvrige nævnte. Derudover er den den yngste blandt dem.
- Angular – betragtes som den sværeste af de nævnte rammer, den eneste der kræver TypeScript (en overbygning på Javascript-sproget). Anvendes ofte til opbygning af store virksomhedsapplikationer.
Sammenfattende kan man konkludere, at oprettelsen af en applikation nu er radikalt forskellig fra, hvordan denne proces foregik tidligere. Ingen forhindrer dog i at udføre "deployment" på den gamle måde. Men er lidt sparet tid ved starten – alle de mange forhindringer, som udvikleren vælger denne vej, skal træde i? Jeg mener, svaret er "nej". Ved at bruge lidt mere tid på at sætte sig ind i disse værktøjer (og det er ikke meget, for du skal blot forstå, om de er nødvendige for dit nuværende projekt eller ej), kan du tage tiden tilbage ved ofte at reducere tilfælde af spøgelsesfejl, som afhænger af miljøet og kun viser sig på produktionsserveren, natlige opklaringer af, hvad der førte til servernedbrudetet, og hvorfor den ikke starter, og meget andet.
Kilde: habr.com
