Co interfejs webowy Proxmoksa robi dobrze i gdzie w końcu otwierasz drugi ekran

Warto powiedzieć to wprost, bo często zakłada się coś przeciwnego: interfejs webowy Proxmoksa jest dobry. Pokazuje niemal wszystko, co system potrafi, nie chowa stanu za uprzejmymi podsumowaniami i nie kłamie. Wiele osób prowadzi poważną infrastrukturę bez niczego więcej i nie idą na kompromis.

Bycie tu sprawiedliwym to nie uprzejmość. Jeśli nie umiesz powiedzieć, co narzędzie robi dobrze, prawdopodobnie nie umiesz też precyzyjnie powiedzieć, gdzie jest niewygodne, a przydatne jest właśnie to drugie zdanie.

Co robi dobrze

Jest kompletny. Prawie każda możliwość ma swoje miejsce w interfejsie. Nie ma dużego zbioru rzeczy dostępnych tylko przez edycję pliku, a to w tej kategorii rzadsze, niż brzmi.

Nie udaje. Gdy wartość jest nieznana, wygląda na nieznaną. Gdy zadanie zawiedzie, awaria jest widoczna razem ze swoim wyjściem. Interfejsy, które to wygładzają, są przyjemne dokładnie do chwili, gdy potrzebujesz prawdy.

Ściśle odwzorowuje system pod spodem. To, co widzisz, odpowiada prawdziwym obiektom, więc to, czego nauczysz się w interfejsie, przenosi się do wiersza poleceń i z powrotem. Narzędzia wymyślające własną abstrakcję uczą cię narzędzia zamiast systemu.

Jest szybki i zawsze na miejscu. Żadnego agenta do instalacji, żadnej dodatkowej usługi do utrzymania, niczego drugiego, co może się zepsuć.

Gdzie naprawdę jest tarcie

Nie na żadnym pojedynczym ekranie. W pytaniach, których odpowiedź rozłożona jest na kilka.

Zapytaj: "jeśli ten dysk padnie dziś w nocy, które maszyny pójdą z nim?" Interfejs potrafi odpowiedzieć. Otwierasz magazyn, notujesz, co na nim leży, otwierasz każdą maszynę, sprawdzasz jej dyski i trzymasz wynik pośredni w głowie. Cztery ekrany i myślowe złączenie, a następnym razem robisz to od nowa.

Zapytaj: "przez który most ta maszyna faktycznie wychodzi na świat?" Ten sam kształt. Maszyna, most, port fizyczny, a złączenie dzieje się w twojej pamięci.

Zapytaj: "czego dotknie ta zmiana, zanim ją zastosuję?" Tutaj interfejs pomoże tylko częściowo, bo odpowiedź nie jest nigdzie zapisana: trzeba ją wyprowadzić, idąc po zależnościach w przód.

To nie są brakujące funkcje. Każdy potrzebny fakt jest obecny i poprawny. Koszt leży w składaniu, a płaci się go za każdym razem, gdy pytanie pada, nie raz na zawsze.

Dlaczego ten koszt jest niewidoczny, dopóki nie przestanie być

W spokojne popołudnie otwarcie czterech ekranów to nie ciężar. Czuje się jak zwykła administracja, bo nią jest.

Drogi staje się dokładnie w dwóch sytuacjach. W czasie awarii, gdy złączenie robi się pod presją, a błędne złączenie daje pewną siebie błędną odpowiedź. I na nieznanym systemie, gdzie jeszcze nie wiesz, jakie zależności istnieją, więc nie wiesz, czego nie sprawdziłeś.

Dlatego ci, którzy prowadzą jeden serwer od lat, często nie zgłaszają żadnego tarcia, a ci, którzy odziedziczyli serwer w zeszłym tygodniu, zgłaszają go bardzo dużo. Obaj trafnie opisują ten sam interfejs.

Czego druga warstwa robić nie powinna

Nie powinna zastępować pierwszej. Natywny interfejs pozostaje punktem odniesienia dla tego, co system naprawdę myśli. Wszystko, co mu przeczy, jest z definicji błędne, a druga warstwa zachęcająca, by tam już nie zaglądać, jest ryzykiem.

Nie powinna wymyślać własnego modelu. Jeśli druga warstwa uczy cię pojęć nieistniejących w Proxmoksie, od tej chwili utrzymujesz tłumaczenie w głowie, a tłumaczenia się rozjeżdżają.

Nie powinna ukrywać awarii. Warstwa ogłaszająca sukces chętniej niż system pod spodem jest gorsza niż brak warstwy.

Uczciwy sposób decydowania

Nie pytaj, który interfejs jest lepszy. Zapytaj, jakie pytania zadajesz najczęściej i czy ich odpowiedzi mieszkają na jednym ekranie, czy na czterech.

Jeśli twoje stałe pytania dotyczą jednego obiektu, uruchom tę maszynę, powiększ ten dysk, sprawdź tę kopię, natywny interfejs odpowiada wprost, a druga warstwa dokłada krok bez powodu.

Jeśli twoje stałe pytania są pytaniami o zależności, od czego to zależy, czego to dotknie, gdzie to naprawdę działa, to właśnie one kosztują za każdym razem, i to jedyny uczciwy powód, żeby cokolwiek dokładać.

Co robi Atlas

Atlas działa obok interfejsu Proxmoksa, a nie zamiast niego, i celuje dokładnie w powyższe pytania o zależności.

Łańcuch zasobów rysowany jest od maszyny aż po dysk fizyczny, a łańcuch sieciowy od maszyny aż po port fizyczny, więc złączenie, które kiedyś działo się w głowie, dzieje się na ekranie. Na tym polega cała różnica: te same fakty, złożone raz i trzymane w złożeniu.

Zanim zmiana zostanie wykonana, wypisywane są zasoby, których dotknie, dzięki czemu trzecie pytanie z wyprowadzanego staje się czytanym.

I odzwierciedla Proxmoksa zamiast zastępować jego model: użytkownicy, role, grupy i tokeny API są te z Proxmoksa, uprawnienia są pytane u Proxmoksa przy logowaniu, a Atlas nie buduje równoległego pojęcia, które musiałbyś synchronizować. To, czego nauczysz się tutaj, pozostaje prawdą tam.