Czy da się prowadzić Proxmoksa bez wiersza poleceń: uczciwa odpowiedź

Większość pytających chce naprawdę wiedzieć dwie różne rzeczy: czy dam radę i czy coś mnie ominie, jeśli tak zrobię. Obie odpowiedzi są lepsze, niż się spodziewasz, ale pomiędzy nimi jest ważne ostrzeżenie.

Panel nie jest drogą gorszą

Powszechnie zakłada się, że interfejs to uproszczona powłoka, a prawdziwa praca dzieje się w wierszu poleceń. To nieprawda. Panel i wiersz poleceń rozmawiają z tym samym interfejsem: własnym interfejsem programistycznym Proxmoksa. Przycisk naciskany w panelu i polecenie wpisywane w terminalu przechodzą przez te same drzwi.

Praca wykonywana z panelu nie jest więc wersją lekką. To ta sama praca, tylko z innej powierzchni.

Prawie cała codzienna praca jest już w panelu

Tworzenie maszyn, uruchamianie, zatrzymywanie, robienie migawek, robienie kopii zapasowych, definiowanie magazynów, układanie sieci, zakładanie użytkowników i nadawanie uprawnień, wykonywanie aktualizacji. Wszystko to jest w interfejsie, a dla większości z tych rzeczy wiersz poleceń jest już wolniejszy.

Gdzie wiersz poleceń jest naprawdę potrzebny

Takich miejsc jest niewiele, ale nie zero, i uczciwie jest to powiedzieć. Wpadają zwykle w trzy rodziny: gdy komponent psuje się w nieoczekiwany sposób (czytanie dzienników systemowych, sprawdzanie, czemu usługa nie startuje), gdy praca jest masowa (zastosowanie tej samej zmiany do stu maszyn) i gdy używa się nowej albo bardzo specyficznej możliwości, której interfejs jeszcze nie obejmuje.

Zwróć uwagę, co je łączy: wszystkie są poza zwyczajnością. Żadna nie jest częścią codziennej pracy.

Prawdziwym niebezpieczeństwem nie jest niewiedza

To najważniejsze zdanie tego wpisu: niebezpieczeństwem nie jest nieznajomość wiersza poleceń, tylko wklejenie polecenia, którego nie rozumiesz.

Polecenie znalezione w internecie uruchamia się na twojej maszynie z twoimi uprawnieniami i nikt nie patrzy na wynik. Ta baza wiedzy ma dwa konkretne przykłady: jednolinijkę mającą wyciszyć komunikat o subskrypcji, która w istocie rujnuje całą bibliotekę interfejsu, oraz pliki compose, które wyglądają jak konfiguracja, a potrafią oddać kontenerowi całą maszynę.

W żadnym z tych przypadków problemem nie było to, że ktoś nie znał wiersza poleceń. Problemem było uruchomienie czegoś, czego nie znał. Kto nigdy nie dotyka wiersza poleceń, nie wpada w żadną z tych pułapek; wpada w nie ten, kto zna go w połowie.

Jeśli chcesz się uczyć, właściwa kolejność

Nie mówimy, żebyś tego unikał. Ale kolejność ma znaczenie: najpierw ucz się poleceń, które czytają, a dopiero potem tych, które piszą. Polecenia pokazujące stan, czytające dzienniki i wypisujące listy niczego nie psują, a uczą, jak system myśli. Do poleceń piszących przechodź dopiero wtedy, gdy potrafisz przeczytać, co robią.

I jedna reguła: nie uruchamiaj polecenia, którego nie rozumiesz, na maszynie niosącej twoją pracę. Jeśli chcesz eksperymentować, utwórz maszynę do eksperymentów; każdy wpis o kopiach i przywracaniu w tej bazie wiedzy istnieje właśnie po to.

Co robi Atlas

Atlas pracuje po stronie przenoszenia codziennej pracy do panelu, czyli stara się poszerzyć powyższą listę prawie wszystkiego. Ale robiąc to, niczego nie ukrywa: mówi, co operacja zamierza zrobić, a dla operacji bez drogi powrotu mówi to przed operacją.

Ta sama postawa pojawia się w dwóch miejscach wprost związanych z tym wpisem. Skrypty instalacyjne i pliki compose są skanowane przed uruchomieniem, a linie przebijające granicę kontenera są ci pokazywane. Praca dotykająca plików, na przykład wyciszenie komunikatu o subskrypcji, wykonywana jest wewnątrz produktu, a nie ręcznie, i po zapisie plik jest odczytywany i weryfikowany.

Celem nie jest więc ukrycie przed tobą wiersza poleceń. Celem jest to, żebyś nigdy nie musiał wklejać polecenia, którego nie rozumiesz.