Hvad Proxmox-webgrænsefladen gør godt, og hvor du ender med at åbne en anden skærm

Den indbyggede grænseflade er ikke Proxmox' svage punkt. Den er præcis, komplet og ærlig. Friktionen sidder ét bestemt sted: spørgsmål, hvis svar bor på flere skærme på én gang.

AtlasPVE ·

Denne artikel besvarer

  • er proxmox webgrænsefladen god
  • proxmox grænseflade begrænsninger
  • hvorfor er proxmox svært for begyndere
  • har jeg brug for en anden proxmox grænseflade
  • proxmox gui vs third party panel

Det er værd at sige lige ud, fordi det modsatte ofte antages: Proxmox-webgrænsefladen er god. Den viser næsten alt, systemet kan, gemmer ikke tilstand bag venlige sammendrag, og den lyver ikke for dig. Mange kører seriøs infrastruktur uden andet, og de slår ikke af på noget.

At være fair om det er ikke høflighed. Kan du ikke sige, hvad et værktøj gør godt, kan du formentlig heller ikke sige præcist, hvor det er ubekvemt, og det er den anden sætning, der er brugbar.

Hvad den gør godt

Den er komplet. Næsten enhver evne har en plads i grænsefladen. Der findes ikke en stor mængde ting, der kun kan gøres ved at redigere en fil, og det er sjældnere i denne kategori, end det lyder.

Den lader ikke som om. Er en værdi ukendt, ser den ukendt ud. Fejler en opgave, er fejlen synlig med sit output. Grænseflader, der glatter det ud, er behagelige lige indtil det øjeblik, du har brug for sandheden.

Den ligger tæt op ad systemet nedenunder. Det, du ser, svarer til rigtige objekter, så det, du lærer i grænsefladen, kan flyttes til kommandolinjen og tilbage. Værktøjer, der opfinder deres egen abstraktion, lærer dig værktøjet i stedet for systemet.

Den er hurtig og altid der. Ingen agent at installere, ingen ekstra tjeneste at holde i live, intet nummer to, der kan gå i stykker.

Hvor friktionen faktisk sidder

Ikke på nogen enkelt skærm. I de spørgsmål, hvis svar er spredt over flere.

Spørg: "hvis denne disk går ned i nat, hvilke maskiner ryger med?" Grænsefladen kan svare. Du åbner lagringen, noterer hvad der ligger på den, åbner hver maskine, tjekker dens diske og holder mellemresultatet i hovedet. Fire skærme og en tankemæssig sammenkobling, og næste gang gør du det forfra.

Spørg: "gennem hvilken bro når denne maskine egentlig ud i verden?" Samme form. Maskine, bro, fysisk port, og sammenkoblingen sker i din hukommelse.

Spørg: "hvad rører denne ændring, før jeg anvender den?" Her kan grænsefladen kun hjælpe delvist, for svaret er ikke gemt nogen steder: det skal udledes ved at følge relationer fremad.

Det er ikke manglende funktioner. Hver nødvendig oplysning findes og passer. Omkostningen ligger i sammenstillingen, og den betales hver gang spørgsmålet stilles, ikke én gang.

Hvorfor den omkostning er usynlig, indtil den ikke er det

En rolig eftermiddag er fire skærme ingen byrde. Det føles som almindelig administration, for det er det.

Det bliver dyrt i præcis to situationer. Under et nedbrud, når sammenkoblingen sker under tidspres, og en forkert sammenkobling giver et selvsikkert forkert svar. Og på et ukendt system, hvor du endnu ikke ved, hvilke relationer der findes, og derfor ikke ved, hvad du glemte at tjekke.

Derfor melder folk, der har kørt én server i årevis, ofte om ingen friktion overhovedet, mens folk, der arvede en i sidste uge, melder om rigtig meget. Begge beskriver den samme grænseflade korrekt.

Hvad et andet lag ikke bør gøre

Det bør ikke erstatte det første. Den indbyggede grænseflade forbliver referencen for, hvad systemet faktisk mener. Alt, der modsiger den, er per definition forkert, og et andet lag, der opmuntrer dig til at holde op med at kigge der, er en risiko.

Det bør ikke opfinde sin egen model. Lærer et andet lag dig begreber, der ikke findes i Proxmox, vedligeholder du fra da af en oversættelse i hovedet, og oversættelser glider fra hinanden.

Det bør ikke skjule fejl. Et lag, der melder succes lettere end systemet nedenunder, er værre end intet lag.

Den ærlige måde at beslutte på

Spørg ikke, hvilken grænseflade der er bedst. Spørg hvilke spørgsmål du stiller oftest, og om deres svar bor på én skærm eller på fire.

Er dine faste spørgsmål enkeltobjektspørgsmål, start denne maskine, udvid den disk, tjek den sikkerhedskopi, så svarer den indbyggede grænseflade direkte, og et andet lag tilføjer et trin til ingen nytte.

Er dine faste spørgsmål relationsspørgsmål, hvad afhænger af det her, hvad kommer det til at røre, hvor kører det egentlig, så er det dem, der koster hver gang, og det er den eneste ærlige grund til at tilføje noget.

Hvad Atlas gør

Atlas kører ved siden af Proxmox-grænsefladen, ikke i stedet for den, og sigter netop mod relationsspørgsmålene ovenfor.

Ressourcekæden tegnes fra en maskine ned til den fysiske disk, og netkæden fra en maskine ud til den fysiske port, så den sammenkobling, der før skete i hovedet, sker på skærmen. Det er hele forskellen: samme oplysninger, sat sammen én gang og holdt sammensat.

Før en ændring køres, listes de ressourcer, den vil røre, hvilket gør det tredje spørgsmål til noget, man læser i stedet for at udlede.

Og den spejler Proxmox i stedet for at erstatte dens model: brugere, roller, grupper og API-tokens er Proxmox' egne, rettigheder spørges Proxmox om ved login, og Atlas bygger ikke et parallelt begreb, du skal holde synkront. Det, du lærer her, forbliver sandt derovre.

Kilder

Proxmox’ egen dokumentation. På engelsk, og den har det sidste ord i dette spørgsmål.

Relaterede artikler

Hvordan ser det ud inde i Atlas?

Gå til produktsiden