Hva Proxmox-webgrensesnittet gjør bra, og hvor du til slutt åpner en andre skjerm

Det innebygde grensesnittet er ikke Proxmox' svake punkt. Det er presist, fullstendig og ærlig. Friksjonen sitter ett bestemt sted: spørsmål der svaret bor på flere skjermer samtidig.

AtlasPVE ·

Denne artikkelen svarer på

  • er proxmox webgrensesnitt bra
  • proxmox grensesnitt begrensninger
  • hvorfor er proxmox vanskelig for nybegynnere
  • trenger jeg et annet proxmox grensesnitt
  • proxmox gui vs third party panel

Det er verdt å si det rett ut, fordi det motsatte ofte antas: Proxmox' webgrensesnitt er bra. Det viser nesten alt systemet kan, gjemmer ikke tilstand bak vennlige sammendrag, og det lyver ikke for deg. Mange kjører seriøs infrastruktur uten noe annet, og de nøyer seg ikke.

Å være rettferdig om det er ikke høflighet. Kan du ikke si hva et verktøy gjør bra, kan du sannsynligvis heller ikke si presist hvor det er upraktisk, og det er den andre setningen som er nyttig.

Hva det gjør bra

Det er fullstendig. Nesten hver evne har en plass i grensesnittet. Det finnes ingen stor mengde ting som bare går via filredigering, og det er sjeldnere i denne kategorien enn det høres ut.

Det later ikke som. Er en verdi ukjent, ser den ukjent ut. Feiler en oppgave, er feilen synlig med utdataene sine. Grensesnitt som glatter over dette er behagelige helt til øyeblikket du trenger sannheten.

Det ligger tett på systemet under. Det du ser svarer til virkelige objekter, så det du lærer i grensesnittet lar seg flytte til kommandolinjen og tilbake. Verktøy som finner opp sin egen abstraksjon lærer deg verktøyet i stedet for systemet.

Det er raskt og alltid der. Ingen agent å installere, ingen ekstra tjeneste å holde i live, ingenting nummer to som kan gå i stykker.

Hvor friksjonen faktisk sitter

Ikke på én bestemt skjerm. I spørsmålene der svaret er spredt over flere.

Spør: "hvis denne disken ryker i natt, hvilke maskiner følger med?" Grensesnittet kan svare. Du åpner lagringen, noterer hva som ligger der, åpner hver maskin, sjekker diskene og holder mellomresultatet i hodet. Fire skjermer og en tankemessig sammenkobling, og neste gang gjør du det på nytt.

Spør: "gjennom hvilken bro når denne maskinen egentlig omverdenen?" Samme form. Maskin, bro, fysisk port, og sammenkoblingen skjer i hukommelsen din.

Spør: "hva vil denne endringen berøre før jeg bruker den?" Her kan grensesnittet bare delvis hjelpe, for svaret er ikke lagret noe sted: det må utledes ved å følge relasjoner framover.

Dette er ikke manglende funksjoner. Hver nødvendige opplysning finnes og stemmer. Kostnaden ligger i sammenstillingen, og den betales hver gang spørsmålet stilles, ikke én gang.

Hvorfor den kostnaden er usynlig helt til den ikke er det

En rolig ettermiddag er fire skjermer ingen byrde. Det føles som vanlig administrasjon, for det er det.

Det blir dyrt i nøyaktig to situasjoner. Under et avbrudd, når sammenkoblingen gjøres under tidspress og en feil sammenkobling gir et selvsikkert galt svar. Og på et ukjent system, der du ennå ikke vet hvilke relasjoner som finnes, altså ikke vet hva du glemte å sjekke.

Derfor melder de som har kjørt én tjener i årevis ofte om ingen friksjon i det hele tatt, mens de som arvet en forrige uke melder om mye. Begge beskriver det samme grensesnittet korrekt.

Hva et andre lag ikke bør gjøre

Det bør ikke erstatte det første. Det innebygde grensesnittet forblir referansen for hva systemet faktisk mener. Alt som motsier det, er per definisjon galt, og et andre lag som oppmuntrer deg til å slutte å se der, er en risiko.

Det bør ikke finne opp sin egen modell. Lærer et andre lag deg begreper som ikke finnes i Proxmox, vedlikeholder du fra da av en oversettelse i hodet, og oversettelser sklir fra hverandre.

Det bør ikke skjule feil. Et lag som melder suksess lettere enn systemet under, er verre enn ingen lag.

Den ærlige måten å bestemme seg på

Ikke spør hvilket grensesnitt som er best. Spør hvilke spørsmål du stiller oftest, og om svarene deres bor på én skjerm eller på fire.

Er de faste spørsmålene dine enkeltobjektspørsmål, start denne maskinen, utvid den disken, sjekk den sikkerhetskopien, da svarer det innebygde grensesnittet direkte, og et andre lag legger til et steg til ingen nytte.

Er de faste spørsmålene dine relasjonsspørsmål, hva avhenger av dette, hva vil dette berøre, hvor kjører dette egentlig, da er det de som koster hver gang, og det er den eneste ærlige grunnen til å legge til noe.

Hva Atlas gjør

Atlas kjører ved siden av Proxmox-grensesnittet, ikke i stedet for det, og sikter nettopp på relasjonsspørsmålene over.

Ressurskjeden tegnes fra en maskin ned til den fysiske disken, og nettkjeden fra en maskin ut til den fysiske porten, slik at sammenkoblingen som før skjedde i hodet, skjer på skjermen. Det er hele forskjellen: samme opplysninger, satt sammen én gang og holdt sammensatt.

Før en endring kjøres, listes ressursene den vil berøre, og dermed blir det tredje spørsmålet noe man leser i stedet for å utlede.

Og det speiler Proxmox i stedet for å erstatte modellen: brukere, roller, grupper og API-tokener er Proxmox' egne, rettigheter spørres Proxmox om ved innlogging, og Atlas bygger ikke noe parallelt begrep du må holde i synk. Det du lærer her, forblir sant der.

Kilder

Proxmox sin egen dokumentasjon. På engelsk, og den har siste ord i denne saken.

Relaterte artikler

Hvordan ser dette ut inne i Atlas?

Gå til produktsiden