Tjekliste til oprettelse og publicering af webapplikationer

For at skabe din egen webapplikation i vor tid, er det ikke nok at kunne udvikle den. Et vigtigt aspekt er opsætning af værktøjer til applikationsimplementering, overvågning samt styring og administration af det miljø, det opererer i. Efterhånden som æraen med manuel implementering forsvinder i glemmebogen, selv for små projekter, kan automatiseringsværktøjer give håndgribelige fordele. Når vi implementerer "i hånden", kan vi ofte glemme at flytte noget, tage højde for denne eller den nuance, køre en glemt test, denne liste kan fortsættes i ret lang tid.

Denne artikel kan hjælpe dem, der netop er ved at lære det grundlæggende i at skabe webapplikationer og ønsker at forstå lidt om de grundlæggende vilkår og konventioner.

Så byggeapplikationer kan stadig opdeles i 2 dele: alt, der vedrører applikationskoden, og alt, der vedrører det miljø, hvor denne kode udføres. Applikationskoden er til gengæld også opdelt i serverkode (den der kører på serveren, ofte: forretningslogik, autorisation, datalagring osv.) og klientkode (den der kører på brugerens maskine: ofte grænsefladen og tilhørende logik med den).

Lad os starte med onsdag.

Grundlaget for driften af ​​enhver kode, system eller software er operativsystemet, så nedenfor vil vi se på de mest populære systemer på hostingmarkedet og give dem en kort beskrivelse:

Windows Server - samme Windows, men i en servervariant. Nogle funktioner, der er tilgængelige i klientens (almindelige) version af Windows, er ikke til stede her, for eksempel nogle tjenester til indsamling af statistik og lignende software, men der er et sæt hjælpeprogrammer til netværksadministration, grundlæggende software til udrulning af servere (web, ftp, ...). Generelt ser Windows Server ud som almindelig Windows, kvaksalvere som almindelig Windows, dog koster den 2 gange mere end dens almindelige modstykke. Men i betragtning af at du højst sandsynligt vil implementere applikationen på en dedikeret/virtuel server, er de endelige omkostninger for dig, selvom de kan stige, ikke kritiske. Da Windows-platformen indtager en overvældende plads på forbrugernes OS-marked, vil dens serverudgave være den mest kendte for de fleste brugere.

Unix- lignende system. Traditionelt arbejde i disse systemer kræver ikke tilstedeværelsen af ​​en velkendt grafisk grænseflade, der kun tilbyder brugeren en konsol som kontrolelement. For en uerfaren bruger kan det være svært at arbejde i dette format, bare hvad koster det at forlade en teksteditor, der er ret populær i data vim, et spørgsmål relateret til dette har allerede fået mere end 6 millioner visninger på 1.8 år. De vigtigste distributioner (udgaver) af denne familie er: Debian - en populær distribution, pakkeversioner i den er primært fokuseret på LTS (Langsigtet support – støtte i lang tid), hvilket kommer til udtryk i en ret høj pålidelighed og stabilitet af systemet og pakkerne; Ubuntu – indeholder distributioner af alle pakker i deres seneste versioner, hvilket kan påvirke stabiliteten, men giver dig mulighed for at bruge den funktionalitet, der følger med nye versioner; Red Hat Enterprise Linux – OS, placeret til kommerciel brug, er betalt, men inkluderer support fra softwareleverandører, nogle proprietære pakker og driverpakker; CentOS - open source en variation af Red Hat Enterprise Linux, karakteriseret ved fraværet af proprietære pakker og support.

For dem, der lige er begyndt at mestre dette område, vil min anbefaling være systemer Windows ServerEller Ubuntu. Hvis vi betragter Windows, så er dette primært kendskabet til systemet, Ubuntu – mere tolerance over for opdateringer og til gengæld f.eks. færre problemer ved igangsætning af projekter om teknologier, der kræver nye versioner.

Så efter at have besluttet os for OS, lad os gå videre til et sæt værktøjer, der giver dig mulighed for at implementere (installere), opdatere og overvåge tilstanden af ​​applikationen eller dens dele på serveren.

Den næste vigtige beslutning vil være placeringen af ​​din applikation og serveren til den. I øjeblikket er de mest almindelige 3 måder:

  • Hosting (holde) en server på egen hånd er den mest budgetvenlige mulighed, men du bliver nødt til at bestille en statisk IP fra din udbyder, så din ressource ikke ændrer sin adresse over tid.
  • Lej en dedikeret server (VDS) – og administrer den selvstændigt og skaler belastninger
  • Betal (ofte giver de dig en chance for at prøve platformens funktionalitet gratis) for et abonnement på noget cloud-hosting, hvor betalingsmodellen for de anvendte ressourcer er ret almindelig. De mest fremtrædende repræsentanter for denne retning: Amazon AWS (de giver et gratis år med at bruge tjenesterne, men med en månedlig grænse), Google Cloud (de giver $300 til kontoen, som kan bruges i løbet af året på cloud-hostingtjenester) , Yandex.Cloud (de giver 4000 rubler . i 2 måneder), Microsoft Azure (giver gratis adgang til populære tjenester i et år, + 12 rubler for alle tjenester i en måned). Således kan du prøve enhver af disse udbydere uden at bruge en krone, men få en omtrentlig mening om kvaliteten og niveauet af den leverede service.

Afhængigt af den valgte vej er det eneste, der vil ændre sig i fremtiden, hvem der i vid udstrækning er ansvarlig for dette eller hint administrationsområde. Hvis du er vært for dig selv, skal du forstå, at eventuelle afbrydelser i elektricitet, internettet, selve serveren, softwaren installeret på den - alt dette ligger helt på dine skuldre. Men til træning og test er dette mere end nok.

Hvis du ikke har en ekstra maskine, der kan spille rollen som en server, vil du gerne bruge den anden eller tredje måde. Det andet tilfælde er identisk med det første, med den undtagelse, at du flytter ansvaret for serverens tilgængelighed og dens magt over på hosterens skuldre. Administrationen af ​​serveren og softwaren er stadig under din kontrol.

Og endelig muligheden for at leje kapaciteten hos cloud-udbydere. Her kan du opsætte automatiseret kontrol af næsten alt uden at gå for mange tekniske detaljer. Derudover kan du i stedet for én maskine have flere parallelt kørende instanser, som for eksempel kan stå for forskellige dele af applikationen, samtidig med at de ikke adskiller sig meget i omkostninger fra at eje en dedikeret server. Og der er også værktøjer til orkestrering, containerisering, automatisk implementering, kontinuerlig integration og meget mere! Vi vil se på nogle af disse ting nedenfor.

Generelt ser serverinfrastrukturen sådan ud: Vi har en såkaldt "orkestrator" ("orkestrering" er processen med at administrere flere serverinstanser), som styrer miljøændringer på en serverinstans, en virtualiseringscontainer (valgfrit, men ganske ofte brugt), som giver dig mulighed for at opdele applikationen i isolerede logiske lag, og Continuous Integration-software – der tillader opdateringer til hostet kode gennem "scripts".

Så orkestrering giver dig mulighed for at se status for servere, udrulle eller rulle tilbage opdateringer til servermiljøet og så videre. I første omgang er det usandsynligt, at dette aspekt vil påvirke dig, da for at orkestrere noget, du har brug for flere servere (du kan have en, men hvorfor er det nødvendigt?), og for at have flere servere har du brug for dem. Blandt værktøjerne i denne retning er det mest populære Kubernetes, udviklet af Google.

Det næste trin er virtualisering på OS-niveau. I dag er begrebet "dockerisering" blevet udbredt, hvilket kommer fra værktøjet Docker, som giver funktionaliteten af ​​containere, der er isoleret fra hinanden, men lanceret i sammenhæng med ét operativsystem. Hvad betyder det: I hver af disse beholdere kan du køre en applikation eller endda et sæt applikationer, som vil tro, at de er de eneste i hele OS, uden overhovedet at have mistanke om eksistensen af ​​en anden på denne maskine. Denne funktion er meget nyttig til at starte identiske applikationer af forskellige versioner, eller blot modstridende applikationer, samt til at opdele dele af en applikation i lag. Denne lagstøbning kan senere skrives ind i et billede, som for eksempel kan bruges til at implementere en applikation. Det vil sige, at ved at installere dette image og implementere de containere, det indeholder, får du et færdigt miljø til at køre din applikation! I de første trin kan du bruge dette værktøj både til informationsformål og for at få meget reelle fordele ved at opdele applikationslogikken i forskellige lag. Men det er værd at sige her, at ikke alle har brug for dockerisering, og ikke altid. Dockerisering er berettiget i tilfælde, hvor applikationen er "fragmenteret", opdelt i små dele, der hver er ansvarlige for sin egen opgave, den såkaldte "microservice-arkitektur".

Derudover skal vi ud over at levere miljøet sikre en kompetent udrulning af applikationen, som omfatter alle former for kodetransformationer, installation af applikationsrelaterede biblioteker og pakker, kørende test, meddelelser om disse operationer og så videre. Her skal vi være opmærksomme på sådan et koncept som "Kontinuerlig Integration" (CI – Kontinuerlig Integration). De vigtigste værktøjer på dette område i øjeblikket er Jenkins (CI-software skrevet i Java kan virke lidt kompliceret i starten), Travis CI (skrevet i Ruby, subjektiv, noget enklere Jenkinsdog kræves der stadig en vis viden inden for implementeringskonfiguration), Gitlab CI (skrevet på Ruby og Go).

Så efter at have talt om det miljø, som din applikation vil fungere i, er det tid til endelig at se på, hvilke værktøjer den moderne verden tilbyder os til at skabe netop disse applikationer.

Lad os starte med det grundlæggende: Bagende (backend) – serverdel. Valget af sprog, sæt af grundlæggende funktioner og foruddefinerede struktur (ramme) her bestemmes hovedsageligt af personlige præferencer, men ikke desto mindre er det værd at nævne til overvejelse (forfatterens mening om sprog er ret subjektiv, dog med en påstand til en objektiv beskrivelse):

  • Python er et ret venligt sprog for en uerfaren bruger, det tilgiver nogle fejl, men det kan også være ret strengt med udvikleren, så han ikke gør noget dårligt. Allerede et ret modent og meningsfuldt sprog, som dukkede op i 1991.
  • Go - et sprog fra Google, er også ret venligt og praktisk, det er ret nemt at kompilere og få en eksekverbar fil på enhver platform. Det kan være enkelt og behageligt, eller det kan være komplekst og seriøst. Frisk og ung, dukkede op relativt for nylig, i 2009.
  • Rust er lidt ældre end sin tidligere kollega, udgivet i 2006, men er stadig ret ung i forhold til sine jævnaldrende. Henvender sig til mere erfarne udviklere, selvom det stadig forsøger at løse mange opgaver på lavt niveau for programmøren.
  • Java er en veteran inden for kommerciel udvikling, introduceret i 1995, og er et af de mest almindeligt anvendte sprog i virksomhedsapplikationsudvikling i dag. Med sine grundlæggende koncepter og tunge opsætning kan køretiden blive ret udfordrende for en nybegynder.
  • ASP.net er en applikationsudviklingsplatform udgivet af Microsoft. Til skrivefunktionalitet bruges hovedsageligt C#-sproget (udtales C Sharp), som dukkede op i 2000. Dens kompleksitet kan sammenlignes med niveauet mellem Java og Rust.
  • PHP, der oprindeligt blev brugt til HTML-forbehandling, er i øjeblikket, selv om det har den absolutte førerposition på sprogmarkedet, en tendens i retning af et fald i brugen. Det har en lav indgangstærskel og let at skrive kode, men samtidig er sprogets funktionalitet måske ikke nok, når man udvikler ret store applikationer.

Nå, den sidste del af vores ansøgning - den mest håndgribelige for brugeren - frontend (frontend) – er ansigtet på din applikation; det er med denne del, at brugeren interagerer direkte.

Uden at gå i detaljer, står den moderne frontend på tre søjler, rammer (og ikke så meget), til at skabe brugergrænseflader. Følgelig er de tre mest populære:

  • ReactJS er ikke en ramme, men et bibliotek. Faktisk adskiller rammen sig kun fra sin stolte titel i mangel af nogle funktioner "ud af kassen" og behovet for at installere dem manuelt. Der er således flere variationer af "forberedelsen" af dette bibliotek, der danner unikke rammer. Det kan være lidt svært for en nybegynder på grund af nogle grundlæggende principper og en ret aggressiv opsætning af byggemiljøet. For en hurtig start kan du dog bruge pakken "create-react-app".
  • VueJS er en ramme til opbygning af brugergrænseflader. Af denne treenighed tager den med rette titlen som den mest brugervenlige ramme; for udvikling i Vue er adgangsbarrieren lavere end for de andre nævnte brødre. Desuden er han den yngste blandt dem.
  • Angular betragtes som den mest komplekse af disse rammer, den eneste der kræver maskinskrift (tilføjelse til Javascript-sprog). Bruges ofte til at bygge store virksomhedsapplikationer.

Ved at opsummere det, der blev skrevet ovenfor, kan vi konkludere, at implementeringen af ​​en applikation nu er radikalt forskellig fra, hvordan denne proces forløb før. Der er dog ingen, der forhindrer dig i at udføre "implementeringen" på den gammeldags måde. Men er den lille tid, der spares i starten, det enorme antal fejl værd, som en udvikler, der vælger denne vej, bliver nødt til at træde på? Jeg tror, ​​at svaret er nej. Ved at bruge lidt mere tid på at sætte dig ind i disse værktøjer (og du behøver ikke mere end det, fordi du skal forstå, om du har brug for dem i dit nuværende projekt eller ej), kan du udspille det, og reducere f.eks. , tilfælde af spøgelsesfejl afhængigt af miljøet, og som kun vises på produktionsserveren, natlig analyse af, hvad der førte til servernedbrud, og hvorfor det ikke starter, og meget mere.

Kilde: www.habr.com

Tilføj en kommentar