Om in onze tijd een eigen webapplicatie te maken, is het niet voldoende om deze te kunnen ontwikkelen. Een belangrijk aspect is het opzetten van tools voor de implementatie van applicaties, monitoring en het beheren en administreren van de omgeving waarin deze actief is. Nu het tijdperk van handmatige implementatie in de vergetelheid raakt, kunnen automatiseringstools zelfs voor kleine projecten tastbare voordelen opleveren. Bij de inzet “met de hand” kunnen we vaak vergeten iets te verplaatsen, rekening houden met deze of gene nuance, een vergeten test uitvoeren, deze lijst kan nog een hele tijd worden voortgezet.
Dit artikel kan degenen helpen die net de basisbeginselen van het maken van webapplicaties leren en iets willen weten over de basistermen en conventies.
Het bouwen van applicaties kan dus nog steeds in 2 delen worden verdeeld: alles wat te maken heeft met de applicatiecode, en alles wat te maken heeft met de omgeving waarin deze code wordt uitgevoerd. De applicatiecode is op zijn beurt ook onderverdeeld in servercode (degene die op de server draait, vaak: bedrijfslogica, autorisatie, gegevensopslag, enz.) en clientcode (degene die op de machine van de gebruiker draait: vaak de interface en de bijbehorende logica).
Laten we beginnen met woensdag.
De basis voor de werking van elke code, systeem of software is het besturingssysteem. Hieronder zullen we de populairste systemen op de hostingmarkt bekijken en deze een korte beschrijving geven:
Windows Server - hetzelfde Windows, maar in een servervariant. Sommige functionaliteit die beschikbaar is in de clientversie (normale) van Windows is hier niet aanwezig, bijvoorbeeld sommige services voor het verzamelen van statistieken en soortgelijke software, maar er is een reeks hulpprogramma's voor netwerkbeheer, basissoftware voor het inzetten van servers (web, ftp, ...). Over het algemeen lijkt Windows Server op gewone Windows, kwakzalvers als gewone Windows, maar het kost twee keer meer dan zijn reguliere tegenhanger. Aangezien u de applicatie echter hoogstwaarschijnlijk op een dedicated/virtuele server gaat implementeren, zijn de uiteindelijke kosten voor u, ook al kunnen deze stijgen, niet van cruciaal belang. Omdat het Windows-platform een overweldigende plaats inneemt op de markt voor consumentenbesturingssystemen, zal de servereditie voor de meeste gebruikers het meest bekend zijn.
Unix-soortgelijk systeem. Traditioneel werk in deze systemen vereist niet de aanwezigheid van een vertrouwde grafische interface, die de gebruiker alleen een console als bedieningselement biedt. Voor een onervaren gebruiker kan het werken in dit formaat moeilijk zijn. Wat zijn de kosten van het afsluiten van een teksteditor die behoorlijk populair is in data? Vim, een vraag die hiermee verband houdt, is in 6 jaar tijd al meer dan 1.8 miljoen keer bekeken. De belangrijkste distributies (edities) van deze familie zijn: Debian - een populaire distributie, pakketversies daarin zijn voornamelijk gericht op LTS (Ondersteuning op lange termijn – ondersteuning voor een lange tijd), wat zich uit in een vrij hoge betrouwbaarheid en stabiliteit van het systeem en de pakketten; Ubuntu – bevat distributies van alle pakketten in hun nieuwste versies, wat de stabiliteit kan beïnvloeden, maar u in staat stelt de functionaliteit te gebruiken die bij nieuwe versies wordt geleverd; Red Hat Enterprise Linux – besturingssysteem, gepositioneerd voor commercieel gebruik, wordt betaald, maar omvat ondersteuning van softwareleveranciers, enkele eigen pakketten en stuurprogrammapakketten; CentOS - open source een variant van Red Hat Enterprise Linux, gekenmerkt door de afwezigheid van eigen pakketten en ondersteuning.
Voor degenen die net beginnen dit gebied onder de knie te krijgen, zou mijn aanbeveling systemen zijn Windows ServerOf Ubuntu. Als we naar Windows kijken, dan is dit vooral de bekendheid van het systeem, Ubuntu – meer tolerantie voor updates, en op zijn beurt bijvoorbeeld minder problemen bij het lanceren van projecten op het gebied van technologieën waarvoor nieuwe versies nodig zijn.
Dus, nadat we een besluit hebben genomen over het besturingssysteem, gaan we verder met een reeks tools waarmee u de status van de applicatie of de onderdelen ervan op de server kunt implementeren (installeren), bijwerken en controleren.
De volgende belangrijke beslissing is de plaatsing van uw applicatie en de server daarvoor. Op dit moment zijn de meest voorkomende 3 manieren:
- Het zelf hosten (behouden) van een server is de meest budgetvriendelijke optie, maar u zult een statisch IP-adres moeten bestellen bij uw provider, zodat uw bron in de loop van de tijd niet van adres verandert.
- Huur een Dedicated Server (VDS) – en beheer deze zelfstandig en schaal de belasting
- Betaal (ze geven je vaak de kans om de functionaliteit van het platform gratis uit te proberen) voor een abonnement op een of andere cloudhosting, waarbij het betalingsmodel voor de gebruikte bronnen vrij gebruikelijk is. De meest prominente vertegenwoordigers van deze richting: Amazon AWS (ze geven een jaar gratis gebruik van de services, maar met een maandelijkse limiet), Google Cloud (ze geven $ 300 aan het account, dat gedurende het jaar kan worden besteed aan cloudhostingservices) , Yandex.Cloud (ze geven 4000 roebel voor 2 maanden), Microsoft Azure (geven een jaar lang gratis toegang tot populaire services, + 12 roebel voor alle services gedurende een maand). U kunt dus elk van deze aanbieders uitproberen zonder een cent uit te geven, maar wel een geschatte mening krijgen over de kwaliteit en het niveau van de geboden dienstverlening.
Afhankelijk van het gekozen pad is het enige dat in de toekomst zal veranderen wie grotendeels verantwoordelijk is voor dit of dat bestuursgebied. Als u zelf host, moet u begrijpen dat eventuele onderbrekingen in de elektriciteit, het internet, de server zelf, de software die erop is geïmplementeerd - dit allemaal volledig op uw schouders ligt. Voor training en testen is dit echter ruim voldoende.
Als je geen extra machine hebt die de rol van server kan spelen, dan wil je de tweede of derde manier gebruiken. Het tweede geval is identiek aan het eerste, met het verschil dat je de verantwoordelijkheid voor de beschikbaarheid van de server en de macht ervan op de schouders van de host legt. Het beheer van de server en de software ligt nog steeds onder uw controle.
En tot slot de mogelijkheid om capaciteit van cloudaanbieders te huren. Hier kunt u geautomatiseerde controle over vrijwel alles instellen zonder al te veel technische details in te voeren. Bovendien kunt u in plaats van één machine meerdere parallel lopende instances hebben, die bijvoorbeeld verantwoordelijk kunnen zijn voor verschillende delen van de applicatie, terwijl de kosten niet veel verschillen van het bezit van een dedicated server. En er zijn ook tools voor orkestratie, containerisatie, automatische implementatie, continue integratie en nog veel meer! We zullen hieronder enkele van deze dingen bekijken.
Over het algemeen ziet de serverinfrastructuur er als volgt uit: we hebben een zogenaamde ‘orkestrator’ (‘orkestratie’ is het proces waarbij meerdere serverinstances worden beheerd), die omgevingsveranderingen op een serverinstance beheert, een virtualisatiecontainer (optioneel, maar behoorlijk vaak gebruikt), waarmee u de applicatie in geïsoleerde logische lagen kunt verdelen, en Continuous Integration-software, waardoor updates van gehoste code via ‘scripts’ mogelijk zijn.
Met orkestratie kunt u dus de status van servers zien, updates voor de serveromgeving uitrollen of terugdraaien, enzovoort. In eerste instantie is het onwaarschijnlijk dat dit aspect je zal beïnvloeden, omdat je, om iets te kunnen orkestreren, meerdere servers nodig hebt (je kunt er een hebben, maar waarom is dit nodig?), En om meerdere servers te hebben, heb je ze nodig. Van de tools in deze richting is Kubernetes de meest populaire, ontwikkeld door Kopen Google Reviews.
De volgende stap is virtualisatie op OS-niveau. Tegenwoordig is het concept van ‘dockerization’ wijdverspreid geworden, wat voortkomt uit de tool havenarbeider, dat de functionaliteit biedt van containers die van elkaar zijn geïsoleerd, maar gelanceerd in de context van één besturingssysteem. Wat betekent dit: in elk van deze containers kun je een applicatie draaien, of zelfs een reeks applicaties, die zullen geloven dat zij de enige zijn in het hele besturingssysteem, zonder zelfs maar het bestaan van iemand anders op deze machine te vermoeden. Deze functie is erg handig voor het starten van identieke applicaties van verschillende versies, of eenvoudigweg conflicterende applicaties, en voor het verdelen van delen van een applicatie in lagen. Deze laagcast kan later in een image worden geschreven, die bijvoorbeeld kan worden gebruikt om een applicatie te implementeren. Dat wil zeggen, door deze image te installeren en de containers die deze bevat te implementeren, krijgt u een kant-en-klare omgeving voor het uitvoeren van uw applicatie! In de eerste stappen kunt u deze tool zowel voor informatieve doeleinden gebruiken als om zeer reële voordelen te behalen door de applicatielogica in verschillende lagen te verdelen. Maar het is de moeite waard om hier te zeggen dat niet iedereen dockerisatie nodig heeft, en niet altijd. Dockerisatie is gerechtvaardigd in gevallen waarin de applicatie ‘gefragmenteerd’ is, opgedeeld in kleine delen, die elk verantwoordelijk zijn voor hun eigen taak, de zogenaamde ‘microservice-architectuur’.
Bovendien moeten we, naast het bieden van de omgeving, zorgen voor een competente implementatie van de applicatie, inclusief allerlei codetransformaties, installatie van applicatiegerelateerde bibliotheken en pakketten, het uitvoeren van tests, meldingen over deze bewerkingen, enzovoort. Hier moeten we aandacht besteden aan een concept als ‘continue integratie’ (CI – Continue integratie). De belangrijkste tools op dit gebied op dit moment zijn Jenkins (CI-software geschreven in Java lijkt in het begin misschien een beetje ingewikkeld), Travis CI (geschreven in Ruby, subjectief, iets eenvoudiger Jenkinsenige kennis op het gebied van implementatieconfiguratie is echter nog steeds vereist), Gitlab-CI (geschreven op Ruby en gaan).
Dus nu we het hebben gehad over de omgeving waarin uw applicatie zal werken, is het tijd om eindelijk te kijken naar welke tools de moderne wereld ons biedt om juist deze applicaties te creëren.
Laten we beginnen met de basis: backend (backend) – servergedeelte. De taalkeuze, de reeks basisfuncties en de vooraf gedefinieerde structuur (framework) worden hier voornamelijk bepaald door persoonlijke voorkeuren, maar toch is het de moeite waard om ter overweging te vermelden (de mening van de auteur over talen is behoorlijk subjectief, hoewel met een claim naar een onpartijdige beschrijving):
- Python is een redelijk vriendelijke taal voor een onervaren gebruiker, het vergeeft wat fouten, maar kan ook behoorlijk streng zijn tegenover de ontwikkelaar zodat hij niets slechts doet. Al een redelijk volwassen en betekenisvolle taal, die in 1991 verscheen.
- Go - een taal van Google, is ook heel vriendelijk en handig, het is vrij eenvoudig te compileren en een uitvoerbaar bestand op elk platform te krijgen. Het kan eenvoudig en plezierig zijn, of het kan complex en serieus zijn. Fris en jong, relatief recent verschenen, in 2009.
- Rust is iets ouder dan zijn vorige collega, uitgebracht in 2006, maar is nog steeds vrij jong vergeleken met zijn soortgenoten. Gericht op meer ervaren ontwikkelaars, hoewel het nog steeds veel taken op laag niveau voor de programmeur probeert op te lossen.
- Java is een veteraan op het gebied van commerciële ontwikkeling, geïntroduceerd in 1995, en is tegenwoordig een van de meest gebruikte talen bij de ontwikkeling van bedrijfsapplicaties. Met zijn basisconcepten en zware opzet kan de looptijd behoorlijk uitdagend worden voor een beginner.
- ASP.net is een applicatie-ontwikkelingsplatform uitgegeven door Microsoft. Voor het schrijven van functionaliteit wordt voornamelijk de taal C# (uitgesproken als C Sharp), die in 2000 verscheen, gebruikt. De complexiteit is vergelijkbaar met het niveau tussen Java en Rust.
- PHP, oorspronkelijk gebruikt voor HTML-voorverwerking, is momenteel weliswaar een absolute leider op de taalmarkt, maar er is een trend richting een afnemend gebruik. Het heeft een lage instapdrempel en het gemak bij het schrijven van code, maar tegelijkertijd is de functionaliteit van de taal bij het ontwikkelen van vrij grote applicaties mogelijk niet voldoende.
Welnu, het laatste deel van onze applicatie - het meest tastbare voor de gebruiker - Frontend (frontend) – is het gezicht van uw applicatie; met dit onderdeel communiceert de gebruiker rechtstreeks.
Zonder in details te treden: de moderne frontend steunt op drie pijlers, raamwerken (en niet zozeer) voor het creëren van gebruikersinterfaces. Dienovereenkomstig zijn de drie meest populaire:
- ReactJS is geen raamwerk, maar een bibliotheek. Eigenlijk verschilt het raamwerk alleen van zijn trotse titel door het ontbreken van enkele functies “out of the box” en de noodzaak om ze handmatig te installeren. Er zijn dus verschillende varianten van de “voorbereiding” van deze bibliotheek, die unieke raamwerken vormen. Het kan een beetje moeilijk zijn voor een beginner, vanwege enkele basisprincipes en de behoorlijk agressieve opzet van de bouwomgeving. Voor een snelle start kunt u echter het “create-react-app” -pakket gebruiken.
- VueJS is een raamwerk voor het bouwen van gebruikersinterfaces. Van deze drie-eenheid krijgt het terecht de titel van het meest gebruiksvriendelijke raamwerk; voor ontwikkeling in Vue is de toegangsdrempel lager dan die van de andere genoemde broers. Bovendien is hij de jongste onder hen.
- Angular wordt beschouwd als het meest complexe van deze raamwerken, het enige dat dit vereist getypte tekst (add-on voor Javascript-taal). Vaak gebruikt om grote bedrijfsapplicaties te bouwen.
Samenvattend wat hierboven is geschreven, kunnen we concluderen dat het implementeren van een applicatie nu radicaal anders is dan hoe dit proces voorheen verliep. Niemand houdt u echter tegen om de “implementatie” op de ouderwetse manier uit te voeren. Maar is de weinige tijd die in het begin wordt bespaard het enorme aantal fouten waard dat een ontwikkelaar die dit pad kiest, zal moeten betreden? Ik geloof dat het antwoord nee is. Door wat meer tijd te besteden aan het vertrouwd raken met deze tools (en meer dan dat heb je niet nodig, omdat je moet begrijpen of je ze nodig hebt in je huidige project of niet), kun je het uitspelen, waardoor je bijvoorbeeld aanzienlijk minder , gevallen van spookfouten, afhankelijk van de omgeving en die alleen op de productieserver voorkomen, nachtelijke analyse van wat tot de servercrash heeft geleid en waarom deze niet wil opstarten, en nog veel meer.
Bron: www.habr.com