Udgivet: 18. februar 2025 af PerfGrid
Pulse: Uge 8, 2025
Hej! Godt at se dig!
Vi starter en ny serie kaldet Pulse. Idéen? At give dig et indblik i alt, hvad der foregår, hvad enten det er nye funktioner i vores eget kontrolpanel, infrastrukturopdateringer eller bare nyttige tips og tricks, vi har samlet op undervejs. Hvis vi støder på noget interessant, vil vi sandsynligvis dele det.
Hvor ofte vil vi poste? Ærligt talt er vi ikke helt sikre endnu, det kan være ugentligt, månedligt eller når vi har noget, vi føler er værd at dele. Nogle indlæg vil være hurtige opdateringer om små ændringer, mens andre måske vil være dybdegående undersøgelser af emner, der fanger vores opmærksomhed.
At drive et hostingfirma betyder, at vi skal håndtere meget; software, infrastruktur, udfordringer og de lejlighedsvise hovedpiner. Pulse er hvor vi vil dele det hele med dig.
Hvad har vi lavet i den seneste uge?
I løbet af den seneste uge har vi foretaget nogle få infrastrukturændringer samt ændringer til hosting-panel.net, vores eget kontrolpanel, der driver Grid Hosting.
PHP 8.4 udrulning
Vi startede faktisk denne udrulning i slutningen af januar, men vi afsluttede endelig denne udrulning i går aftes den 16. februar.
I slutningen af januar foretog vi en infrastruktur-bred implementering af PHP 8.4 til vores Grid Hosting-planer. Måden, vi gør dette på, er faktisk ret enkel. Al vores infrastruktur styres af Ansible, og tilføjelse af en ny version er et spørgsmål om at tilføje php84 til vores PHP-liste og sikre, at de forskellige pakker, vi installerer til PHP-udvidelser, allerede er tilgængelige for PHP 8.4. For kontrolpanelet er det nogenlunde samme ændring, vi vedligeholder en konfigurationsfil, som vi opdaterer med listen over understøttede versioner samt standard PHP-versionen, som nye domæner oprettes med.
Når vi har de PHP-moduler tilgængelige, som vi har brug for, tager implementering af PHP 8.4 til Grid Hosting normalt 20-30 minutter.
For cPanel er disse opdateringer lidt anderledes, det styres gennem en cPanel-funktion kaldet EasyApache4. Efter vi har installeret versionen og pakkerne, skal vi anvende nogle php.ini-specifikke regler og sikre, at alle websteder, der i øjeblikket er aktive, forbliver på den gamle version (f.eks. PHP 8.3), da vi ændrer standardversionen på hver eneste server.
Det er lidt mere omstændeligt, og frigivelse af PHP 8.4 til cPanel tager normalt lidt længere tid.
Årsagen til, at vi normalt venter et par måneder efter den officielle udgivelse, skyldes faktisk sikkerhed.
Alle PHP-versioner, vi kører, har en PHP-udvidelse kaldet i360, det er en tæt integration med Imunify360 fra CloudLinux. Hvad den gør, er at hjælpe Imunify360 med at blokere forskellige mulige sikkerhedshuller i realtid ved effektivt at inspicere den kode, der udføres. Imunify360 tager normalt lidt tid til at frigive denne i360-pakke til nyere PHP-versioner, hvilket betyder, at vi normalt også venter på, at dette modul frigives.
Grid Hosting: DNS-editor får en mindre forbedring
Denne funktion blev efterspurgt af en af vores kunder, der tilfældigvis administrerer mange domæner og ligeledes ofte skal udføre lignende ændringer på tværs af et sæt domæner.
Grid Hosting fungerer ved normalt at bruge domæne-ID'et fra databasen som en del af URL'en, såsom /domains/dns/132 - dette er normalt fint for de fleste mennesker; der kan dog være tilfælde, hvor du kører en WordPress multisite-installation med lad os sige perfgrid.dk, perfgrid.com, perfgrid.nl osv. - og du skal anvende en DNS-ændring på alle 3 domæner. Det ville simpelthen være lettere bare at kunne skrive /domains/dns/perfgrid.dk eller /domains/dns/perfgrid.com - vi har nu gjort dette til en mulighed.
Selvom det er en lille funktion, giver det stadig en lille forbedring af livskvaliteten for dem, der foretager ændringer på tværs af domæner.
Det betyder, i stedet for dette:
Kan vi nu gøre dette:
Konsekvenserne af en ny mindre funktion
Fra et programmeringsperspektiv viser det sig faktisk at være mindre ligetil, end man skulle tro.
Vi bruger Laravel til vores panel, næsten alt i Laravel udføres normalt med noget, der kaldes route binding, du udfører effektivt en automatiseret SQL-forespørgsel afhængigt af det ID, der er angivet i URL'en.
Så for eksempel, hvis vi har ID 132 i URL'en, vil dette udføre en SQL-forespørgsel såsom SELECT * FROM tbldomain WHERE id=132 AND userId=1;
Dog hvis du vil kunne bruge både ID'et eller domænet for eksempel, kan du ikke længere bruge route binding på samme måde. Hvad du kan gøre, er at overskrive resolveRouteBinding i din model for at udføre din yderligere logik.
Men hvad vi lærte, er, at dette har interessante konsekvenser, da route binding ikke kun for eksempel tillader, at et ID angives, men faktisk kan du angive en komplet eksisterende model, og den vil stadig blive fundet korrekt.
Hvad vi faktisk endte med at gøre, var simpelthen ikke at bruge resolveRouteBinding og i stedet laver nogle ekstra tjek på selve DNS-siden, da dette har en mindre effekt på generelle forespørgsler og funktioner i systemet.
