I de sidste otte år har vi med særlig opmærksomhed set udviklingen af webøkosystemer som Ruby og Ruby on Rails, som er et af de bedste værktøjer til backend-infrastruktur som vi bruger på begge Web- og mobilapp-udvikling.
Otte år er lang tid i enhver teknologis liv på en uendelig udviklingsproces. Af den grund har vi set projekter bygget i det næsten glemte Skinner 3.1 på toppen af Rubin 1.9, uden søgeordsargumenter eller sikre navigationsoperatører, til de nyeste Skinner 5.2.2 på Rubin 2.5.3. Tilføj nu flere forskellige versioner af ædelstene og et strejf af pakkens afhængigheder - oven på forskellige operativsystemer - og vi får et utal af projektmiljøer.
I sådanne scenarier bliver det en kritisk og presserende opgave at oprette et udviklingsmiljø, der tillader replikering af betingelserne for at gengive en fejl, eller endda have en hurtig måde at kontrollere projektets aktuelle tilstand for at estimere indsatsen ved at introducere en ny funktion.
Skift mellem projekter med forskellige konfigurationer og miljøer bliver sværere, og overgangen til gamle projekter for at levere en hot-fix bliver til en frygtelig og frustrerende opgave.
Dette skyldes, at opsætningen af gamle projekter tager længere tid end tiden til at gengive, rette og implementere en ny hot-fix.
Det er ikke sjovt.Det er ikke sundt.Det er ikke effektivt.
Det blev tydeligt, at der var behov for at bevare udviklingsmiljøet på en bærbar og begrænset måde, hvilket muliggjorde en mere jævn overgang mellem projekter.
Det er da Vagrant trådte ind i aktion.
Vagrant er et populært open source virtual machine deklarations- og styringsværktøj fra Hashicorp. Dens popularitet kommer fra det enkle Ruby syntaks, der beskriver en ressource fra basisbillede, ressourceallokeringsfunktionen og andre mindre klargøringskonfigurationer, f.eks. hvordan den monterer en delt mappe eller hook-provisions-scripts for at forberede udviklingsmiljøet.
Det leveres også med en række udbydere, der kan støtte Vagrant på flere platforme, med oprettelsen af en lokal virtuel maskine på VirtualBox, VMware og Hyper-V.
Derudover blev det udvidet af samfundet til at understøtte populære hostingtjenester såsom Amazon-webtjenester eller DigitalOcean, så de kan arbejde som udbydere og abstrahere hele oprettelses- og ledelsesprocessen for Dråber og EC2-forekomster.
På denne måde kan udviklere simulere og koordinere flere node-arkitekturer gennem en velkendt grænseflade. Og den bedste del? Alle specifikationer udføres på en enkelt tekstfil, som nemt kan samles i et projekt og holdes under versionskontrol, klar til betaling.
Vagrant tilbyder en hurtig og ren måde at interagere med udviklingsmiljøer på ved hjælp af et operativsystem svarende til iscenesættelse og produktion. Dette øger applikationernes modstandsdygtighed og gør dem mindre tilbøjelige til fejl, der forbliver skjult i udviklingsmiljøer. Men i sig selv er Vagrant ikke det bedste værktøj til at levere en virtuel maskine.
Under hensyntagen til dette, Ansibel var vores foretrukne våben til at levere de virtuelle maskiner. Det kræver ikke nogen form for agent, der kører på den virtuelle maskine, som andre alternativer såsom Chef og Marionet ville og gør det meste af sit arbejde igennem Skub, via SSH.
Dens specifikationer er udført i YAML, hvilket gør det ret læseligt og let at forstå, så enhver hurtigt kan inddrage hver instruktion og ændre et provisionsscript, så det passer til nye behov, såsom at tilføje et ekstra systembibliotek til en ny perle. Den overordnede struktur af scripts muliggør også et klart overblik over de ændringer, der introduceres, hvilket hjælper med at medføre de nye afhængigheder, der tilføjes under kodegennemgang og sikkerhedsrevisioner. Det er noget let at gå glip af, når man evaluerer et almindeligt shell-script med lange kommandoer, der ligner et endeløst lasttog.
Med Vagrant, Ansibles scripts er bare almindelig tekst, der kan gemmes sammen med projektet under versionskode.
Ligesom hvad der sker med enhver anden innovation, Vagrant og Ansibles introduktionen kan møde forskellige grader af modstand ved dens vedtagelse. Udviklere, der kun er tildelt et projekt i længere perioder, værdsætter muligvis ikke fuldt ud denne nødvendighed eller værdsætter dens portabilitet, og det er forståeligt.
Men efterhånden som udviklere hopper fra projekt til projekt og tinker med forskellige ting dagligt, vil de få en bedre forståelse af, hvor værdifuldt Vagrant er. Det er ikke et ualmindeligt scenarie at rette noget på en gammel Python projekt om morgenen, skift til Ruby vedligeholdelse om eftermiddagen og pille med Node.js Den næste dag, for eksempel.
Vagrant tillader effektivt at ændre projektets kontekst.
Ansibel alone er et kraftfuldt provisioneringsværktøj, der effektivt interagerer med flere VPS og kan bruges til at implementere ændringer i store klynger. Mens en massiv brug af Ansibel at administrere store klynger er ikke forudsigelig i den nærmeste fremtid, ved at vedtage det konsekvent, kan man genbruge de allerede byggede Ansible-scripts til opsætning af udviklingsvirtuelle maskiner og klargøre VPS der vil være vært for både iscenesættelses- og produktionsmiljøer.
Det er for det meste tilpasset bedste praksis for udvikling, da det bygger gode og fleksible provisions-scripts, der kan opfylde mere end blot klargøring af en virtuel maskine og genbruge dem, når du forsøger at udrulle applikationen til flere miljøer.
Mens Vagrant kan bruges som et værktøj til at oprette og administrere VPS til udvikling eller endda til at skabe iscenesættelses- og produktionsmiljøer er der andre værktøjer, der kan bruges til at nå de samme mål, såsom Terraform.
Men det er en helt ny historie til en anden dag...
Fandt du denne artikel interessant? Du kan måske også lide disse!
Din daglige webudvikler, der kan lide at gemme sig i backend. Javascript og Ruby er min marmelade. Jeg fumler stadig med Docker, og mine bygninger går i stykker ret ofte.
People who read this post, also found these interesting:
.webp)
