Tegenwoordig is het niet genoeg om een webapplicatie te kunnen ontwikkelen. Een belangrijk aspect is de configuratie van de uitroltools, monitoring, evenals het beheer en de administratie van de omgeving waarin het draait. Het tijdperk van handmatige uitrol verdwijnt in de vergetelheid; zelfs voor kleine projecten kunnen automatiseringstools aanzienlijke voordelen opleveren. Bij handmatige uitrol vergeten we vaak om iets over te dragen, een bepaald detail te overwegen, een vergeten test uit te voeren; deze lijst kan vrij lang zijn.
Dit artikel kan nuttig zijn voor degenen die de basisprincipes van webapplicatieontwikkeling onder de knie willen krijgen en meer willen leren over de belangrijkste termen en conventies.
Bij het bouwen van applicaties kunnen we het proces in twee delen splitsen: alles wat verband houdt met de applicatiecode en alles wat verband houdt met de omgeving waarin deze code wordt uitgevoerd. De applicatiecode is op zijn beurt ook verdeeld in servercode (de code die op de server draait, vaak: bedrijfslogica, autorisatie, gegevensopslag, enz.) en clientcode (de code die op de machine van de gebruiker draait: vaak de interface en de bijbehorende logica).
Laten we beginnen met de omgeving.
De basis voor het functioneren van elke code, systeem of software is het besturingssysteem. Hieronder bespreken we de meest populaire systemen die op de hostingmarkt worden aangeboden en geven we een korte beschrijving.
Windows Server ā dat is de Windows die we kennen, maar dan in een servervariant. Bepaalde functionaliteiten die beschikbaar zijn in de gewone clientversie van Windows zijn hier niet aanwezig, zoals bepaalde statistiekverzamelingsdiensten en soortgelijke software; wel zijn er hulpprogramma's voor netwerkbeheer en basissoftware voor uitrol. servers (web, ftp, ā¦). Over het algemeen ziet Windows Server eruit als gewone Windows, werkt als gewone Windows, maar kost 2 keer zo veel als zijn gewone tegenhanger. Houd er echter rekening mee dat de uiteindelijke kosten voor u, hoewel ze kunnen stijgen, niet kritiek zijn, omdat u de applicatie waarschijnlijk op een dedicated/virtuele server zult uitrollen. Aangezien het Windows-platform een dominant aandeel heeft op de markt voor desktopbesturingssystemen, zal de servereditie de meest vertrouwde zijn voor de meeste gebruikers.
Unix-vergelijkbare systemen. Traditioneel werk in deze systemen gaat niet uit van een gebruikelijk grafisch interface, waarbij de gebruiker slechts een console als bedieningselement heeft. Voor een onervaren gebruiker kan het werken in dit formaat een uitdaging vormen, vooral het gebruik van de vrij populaire teksteditor Vim, de vraag die hiermee samenhangt heeft in 6 jaar al meer dan 1,8 miljoen views verzameld. De belangrijkste distributies (edities) van deze familie zijn: Debian - een populaire distributie, waarin de versies van de pakketten voornamelijk gericht zijn op LTS (Long Term Support - langdurige ondersteuning), wat zich uit in een behoorlijk grote betrouwbaarheid en stabiliteit van het systeem en de pakketten; Ubuntu - bevat distributies van alle pakketten in hun laatste versies, wat invloed kan hebben op de stabiliteit, maar wel de functionaliteit biedt die met nieuwe versies wordt geleverd; Red Hat Enterprise Linux - OS, gepositioneerd voor commercieel gebruik, is betaald, maar omvat ondersteuning van softwareleveranciers, enkele proprietary pakketten en stuurprogramma-pakketten; CentOS - opensource variatie van Red Hat Enterprise Linux, kenmerkt zich door het ontbreken van proprietary pakketten en ondersteuning.
Voor degenen die zich nog in deze materie aan het verdiepen zijn, zou mijn aanbeveling zijn systemen Windows Server, ofwel Ubuntu. Als we Windows bekijken, dan is het in de eerste plaats de vertrouwdheid van het systeem, Ubuntu - meer tolerantie voor updates, en bijvoorbeeld, minder problemen bij het opstarten van projecten met technologieƫn die nieuwe versies vereisen.
Dus, nadat we de OS hebben bepaald, gaan we verder met de set tools die het mogelijk maken om de applicatie of delen daarvan op de server te deployen (installeren), te updaten en de status te monitoren.
De volgende belangrijke beslissing is het hosten van uw applicatie en de server ervoor. Op dit moment zijn er 3 meest voorkomende manieren:
- Zelf de server hosten - de meest budgetvriendelijke optie, maar dan moet u een statisch IP bij de provider aanvragen, zodat uw resource zijn adres in de loop van de tijd niet verandert.
- Een Dedicated Server (VDS) huren - en zelf verantwoordelijk zijn voor de administratie en schaalbaarheid van de lasten
- Betaal een abonnement op een cloudhostingdienst die vaak de mogelijkheid biedt om de functionaliteit gratis uit te proberen, waar de betalingsmodel gebaseerd is op gebruikte middelen. Enkele van de meest prominente aanbieders in deze sector zijn: Amazon AWS (bieden een gratis jaar gebruik aan, maar met een maandlimiet), Google Cloud (bieden $300 tegoed aan dat gedurende een jaar kan worden besteed aan clouddiensten hosting), Yandex. Cloud (bieden 4000 roebel voor 2 maanden), Microsoft Azure (bieden gratis toegang tot populaire diensten voor een jaar, plus 12.500 roebel voor diensten gedurende ƩƩn maand). Op deze manier kunt u elk van deze aanbieders uitproberen zonder een cent uit te geven, maar wel een idee krijgen van de kwaliteit en het niveau van de geleverde diensten.
Afhankelijk van de gekozen weg, verandert verder alleen het feit wie grotendeels verantwoordelijk is voor een bepaald gebied van het beheer. Als u zelf host, moet u begrijpen dat elke storing met elektriciteit, internet, de server zelf en de software die daarop draait volledig op uw schouders valt. Toch is dit meer dan voldoende voor opleiding en testen.
Als u echter geen extra machine heeft die als server kan dienen, wilt u misschien de tweede of derde mogelijkheid overwegen. Het tweede geval is identiek aan de eerste, met als enige uitzondering dat u de verantwoordelijkheid voor de beschikbaarheid van de server en de bijbehorende prestaties op de provider legt. Serverbeheer en software blijven nog steeds onder uw controle.
Ten slotte is er de optie om capaciteit van cloudproviders te huren. Hier kunt u geautomatiseerd beheer instellen voor vrijwel alles, zonder al te veel in technische details te duiken. Bovendien kunt u in plaats van ƩƩn machine meerdere gelijktijdig draaiende instanties hebben, die bijvoorbeeld verantwoordelijk kunnen zijn voor verschillende delen van de applicatie, terwijl de kosten niet sterk afwijken van het bezit van een dedicated server. Daarnaast zijn er tools voor orkestratie, containerisatie, automatische uitrol, continue integratie en veel meer! Enkele van deze dingen zullen we hieronder bekijken.
In het algemeen lijkt de serverinfrastructuur als volgt: we hebben een zogenaamde "orkestrator" ("orkestratie" - het proces van het beheren van meerdere serverinstantie's), die de omgevingswijzigingen op de serverinstantie beheert, een virtualisatielaag (optioneel, maar vaak gebruikt) die de applicatie in geĆÆsoleerde logische lagen splitst, en software voor Continue Integratie - die het mogelijk maakt om de geplaatste code bij te werken via "scripts".
Dus, orkestratie stelt u in staat om de statussen van servers te bekijken, om updates van de serveromgeving aan te brengen of terug te draaien, enzovoorts. In het begin zal dit aspect u waarschijnlijk niet raken, omdat om te orkestreren, u meerdere servers nodig heeft (waarbij ƩƩn mogelijk is, maar waarom zou je dat willen?), en om meerdere servers te hebben, moet er vraag naar zijn. Van de beschikbare tools is Kubernetes de bekendste, ontwikkeld door Google.
De volgende stap is virtualisatie op het niveau van het besturingssysteem. Momenteel is de term "dockerisatie" wijdverspreid, wat voortkomt uit het gereedschap Docker, die geïsoleerde containers functionaliteit bieden die draaien onder één besturingssysteem. Wat betekent dat: in elk van deze containers kan een applicatie of zelfs een set applicaties worden uitgevoerd, die denken dat ze de enige zijn in het hele besturingssysteem, zonder te vermoeden dat er anderen bestaan op dezelfde machine. Deze functie is zeer nuttig voor het draaien van dezelfde applicaties in verschillende versies, of gewoon conflicterende applicaties, evenals voor het splitsen van applicatiecomponenten in lagen. Deze lagen kunnen vervolgens worden vastgelegd in een afbeelding, die bijvoorbeeld kan worden gebruikt voor het inzetten van de applicatie. Dit betekent dat door deze afbeelding te installeren en de containers die deze bevat uit te rollen, je een kant-en-klare omgeving voor je applicatie krijgt! In de beginfase kun je deze tool gebruiken voor zowel verkennende doeleinden als voor echte voordelen, door de logica van de applicatie over verschillende lagen te verspreiden. Maar het is belangrijk te zeggen dat dockeren niet voor iedereen en niet altijd nodig is. Dockeren is gerechtvaardigd wanneer een applicatie 'gefractioneerd' is, opgedeeld in kleine delen die elk verantwoordelijk zijn voor hun eigen taak, ook wel een 'microservices-architectuur' genoemd.
Bovendien, naast het bieden van een omgeving, moeten we ook zorgen voor een goede inzet van de applicatie, inclusief alle mogelijke transformaties van de code, installatie van gerelateerde bibliotheken en pakketten, het draaien van tests, meldingen over deze operaties, enzovoorts. Hier moeten we aandacht besteden aan het concept van 'Continue Integratie' (CI ā Continue Integratie). De belangrijkste tools in dit gebied zijn momenteel Jenkins (een CI-software geschreven in Java, die aanvankelijk wat ingewikkeld kan lijken), Travis CI (geschreven in Ruby, subjectief iets eenvoudiger dan Jenkins, maar het vereist nog steeds enige kennis van het instellen van deployments), Gitlab CI (geschreven in Ruby en Go).
. Dus, na te hebben gesproken over de omgeving waarin je applicatie zal draaien, is het tijd om eindelijk te kijken naar welke tools de moderne wereld ons biedt voor het creƫren van deze applicaties.
Laten we beginnen met de basis: Backend (backend) ā serverzijde. De keuze van de taal, de set van basisfuncties en de vooraf gedefinieerde structuur (framework) wordt hier voornamelijk bepaald door persoonlijke voorkeuren, maar het is de moeite waard om te vermelden voor overweging (de mening van de auteur over de talen is behoorlijk subjectief, hoewel het pretendeert objectief te beschrijven):
- Python ā een vriendelijke taal voor de onervaren gebruiker, vergeeft sommige fouten, maar kan ook streng zijn voor de ontwikkelaar, zodat hij geen slechte dingen doet. Het is een goed doordachte programmeertaal, ontstaan in 1991.
- Go ā een taal van Google, eveneens gebruiksvriendelijk en handig, relatief eenvoudig te compileren en een uitvoerbaar bestand te krijgen op elk platform. Kan eenvoudig en aangenaam zijn, maar ook complex en serieus. Nieuw en jong, relatief recent ontstaan in 2009.
- Rust ā iets ouder dan de vorige collega, verschenen in 2006, nog steeds vrij jong in vergelijking met zijn broeders. Gericht op meer ervaren ontwikkelaars, hoewel het nog steeds probeert veel laag-niveau taken voor de programmeur op te lossen.
- Java ā een veteraan in commerciĆ«le ontwikkeling, verschenen in 1995, een van de meest gebruikte talen voor het ontwikkelen van bedrijfsapplicaties op dit moment. Met zijn basisconcepten en zware configuratie van de runtime-omgeving kan het behoorlijk complex zijn voor beginners.
- ASP.net ā een platform voor het ontwikkelen van applicaties, uitgebracht door Microsoft. Voor het schrijven van functionaliteit wordt voornamelijk de taal C# (uitgesproken als C-sharp) gebruikt, die in 2000 is verschenen. Qua complexiteit te vergelijken met het niveau tussen Java en Rust.
- PHP ā oorspronkelijk gebruikt voor het preprocessen van HTML, behoudt momenteel nog steeds absolute leiderschap op de markt van programmeertalen, maar er is een trend naar een afname van het gebruik. Staat bekend om de lage instapdrempel, de eenvoud van het schrijven van code, maar kan in de ontwikkeling van grotere applicaties onvoldoende functionaliteit bieden.
En het laatste deel van onze applicatie ā het meest tastbare voor de gebruiker ā Frontend (fronend) ā is het gezicht van uw applicatie, deze is de directe interactie tussen de gebruiker en de applicatie.
Zonder in details te treden, staat moderne frontend op drie pijlers van frameworks (en niet zozeer), voor het maken van gebruikersinterfaces. Derhalve zijn de drie meest populaire:
- ReactJS - is geen framework, maar een bibliotheek. Eigenlijk verschilt het van de trotse titel van framework alleen door het ontbreken van bepaalde functies 'uit de doos', en de noodzaak om deze handmatig te installeren. Er zijn dus verschillende variaties van deze bibliotheek, die eigenzinnige frameworks vormen. Voor een beginner kan het moeilijk zijn vanwege bepaalde basisprincipes en de vrij agressieve instellingsomgeving. Toch kan voor een snelle start gebruik worden gemaakt van het 'create-react-app' pakket.
- VueJS - is een framework voor het bouwen van gebruikersinterfaces. Van deze drie verdient het terecht de titel van meest gebruiksvriendelijke framework, met een lagere instapdrempel voor ontwikkeling in Vue dan de andere genoemde broers. Bovendien is het de jongste onder hen.
- Angular - wordt beschouwd als het moeilijkste van de genoemde frameworks, het enige dat vereist is dat er TypeScript (een uitbreiding bovenop de Javascript taal) aanwezig is. Vaak gebruikt voor het bouwen van grote enterprise-applicaties.
Samenvattend kan worden geconcludeerd dat het nu implementeren van een applicatie radicaal verschilt van hoe dat proces eerder verliep. Toch staat niets een 'deploy' op de oude manier in de weg. Maar is het de iets bespaarde tijd aan het begin waard - de enorme hoeveelheid hobbels waar de ontwikkelaar die deze weg kiest overheen moet stappen? Ik vind van niet. Door wat meer tijd te besteden aan het leren van deze tools (en dat is meer dan genoeg, want je moet begrijpen of je ze nodig hebt in je huidige project of niet), kun je die tijd terugwinnen door bijvoorbeeld het aantal spookfouten, die afhankelijk zijn van de omgeving en alleen op de productie server optreden, en nachten van zoeken naar wat de serververoorzaker van de server is, en waarom deze niet opstart, aanzienlijk te verminderen, en nog veel meer.
Bron: habr.com
