Zacznij od ćwiczeń, nie od liczby vCPU
Specyfikacja sprzętowa bez programu mówi niewiele. Edytor i kilka poleceń Git mają inne wymagania niż lokalny klaster, kompilacja dużego projektu czy analiza danych. Dla każdego modułu warto zapisać, jakie procesy działają równocześnie, ile danych powstaje i czy uczestnik zmienia konfigurację systemu.
Na tej podstawie można dobrać CPU, pamięć, dysk i topologię. Trzeba uwzględnić moment największego obciążenia, gdy cała grupa wykonuje ten sam krok. Profil sprawdzony na jednej maszynie może wymagać korekty przy równoległym pobieraniu obrazów, kompilacji lub imporcie danych.
Powtarzalność wymaga konfiguracji bazowej
Każde stanowisko powinno zawierać tę samą wersję systemu, runtime, bibliotek i materiałów. Konfigurację najlepiej opisać w sposób możliwy do ponownego zbudowania, a następnie przejść cały scenariusz na czystej kopii. Ręczne poprawki wykonane już po powieleniu obrazu tworzą różnice trudne do zauważenia.
Warto przypiąć wersje zależności, zachować lockfile i określić źródła pakietów. Jeśli warsztat potrzebuje dostępu do internetu, trzeba sprawdzić repozytoria oraz limity. Jeśli ma działać bez sieci zewnętrznej, wszystkie artefakty muszą znaleźć się w obrazie, cache lub lokalnym repozytorium.
Sposób połączenia powinien pasować do urządzeń uczestników
Pulpit zdalny w przeglądarce upraszcza udział z firmowego laptopa, ponieważ nie wymaga instalowania klienta. Dobrze sprawdza się przy IDE i aplikacjach graficznych. SSH zużywa mniej pasma i pasuje do zajęć terminalowych. Obie metody mogą prowadzić do tej samej VM.
Decyzję trzeba zweryfikować w docelowej sieci. Znaczenie mają porty, proxy, filtrowanie adresów, układ klawiatury i zachowanie sesji po przerwie. Krótki test techniczny przed szkoleniem jest bardziej miarodajny niż deklaracja, że organizacja „zezwala na przeglądarkę”.
Izolacja zależy od rodzaju zmian
Osobna VM dla każdego uczestnika jest właściwa, gdy ćwiczenia zmieniają usługi, pakiety, sieć lub dane. Przy wspólnym klastrze można rozdzielić namespace i role, ale uczestnicy nadal współdzielą węzły oraz zasoby globalne. W laboratorium bazodanowym osobny schemat może wystarczyć do SQL, natomiast administracja serwerem wymaga własnej instancji.
Środowisko powinno być odseparowane od produkcji, a ruch sieciowy ograniczony do potrzeb scenariusza. Dostęp root na prywatnej, czasowej VM może być uzasadniony, lecz nie powinien automatycznie oznaczać dostępu do innych stanowisk, panelu zarządzania lub firmowych sekretów.
Materiały i dane trzeba zaprojektować razem ze stanowiskiem
Pliki startowe powinny być dostępne wewnątrz laboratorium i tylko do odczytu. Każdy uczestnik potrzebuje własnego katalogu na wyniki. Dane produkcyjne należy zastąpić zbiorem syntetycznym lub zanonimizowanym, który zachowuje przypadki ważne dla ćwiczenia.
Instrukcja musi wskazywać stan początkowy, pierwsze polecenie, oczekiwany rezultat i sposób odzyskania stanowiska. Duża liczba narzędzi nie rekompensuje braku tej ścieżki. Uczestnik powinien wiedzieć, od czego zacząć bez szukania informacji w kilku kanałach.
Wsparcie oraz reset są częścią wyboru
Przy większej grupie prowadzący potrzebuje sposobu identyfikacji stanowiska, sprawdzenia stanu usług i udzielenia pomocy za zgodą uczestnika. Panel trenera może skrócić diagnozę, ale nie zastępuje procedury. Trzeba rozróżnić problem z dostępem, awarię obrazu i błąd będący częścią ćwiczenia.
Reset powinien działać na pojedynczej VM i prowadzić do sprawdzonego stanu. Snapshot przyspiesza powrót po zmianach systemowych, natomiast wersjonowany bootstrap lepiej pokazuje, z czego składa się konfiguracja. Mechanizm należy przetestować wielokrotnie przed wejściem grupy.
Porównuj koszt całego wydarzenia, nie samą cenę maszyny
Tanie stanowisko, które wymaga kilku godzin ręcznej konfiguracji i wsparcia w dniu zajęć, może kosztować więcej niż gotowe środowisko czasowe. Do porównania należy włączyć przygotowanie obrazu, testy, dystrybucję dostępów, rezerwę zasobów, wsparcie, backup, eksport wyników i bezpieczne wyłączenie.
Stałe laboratorium ma sens przy częstym użyciu oraz zespole odpowiedzialnym za utrzymanie. Przy pojedynczym warsztacie lub zmiennym programie korzystniejsze może być środowisko rezerwowane na określony czas. W przykładowych scenariuszach widać, jak topologia zmienia się między Kubernetes, Dockerem, bazami danych, testami i rozwojem aplikacji.
Krótki pilotaż zamyka najwięcej niewiadomych
Jedna VM i jedno konto uczestnika wystarczą, aby sprawdzić materiał, połączenie, zasoby oraz reset. Pilotaż powinien wykonać ktoś, kto nie budował konfiguracji. Taka osoba szybciej zauważy brakującą instrukcję, ukryte poświadczenie lub zależność obecną tylko na komputerze autora.
Po próbie można świadomie wybrać model środowiska i zakres usługi. Klasa w chmurze przygotowuje zarówno zestawy identycznych VM dla grup, jak i pojedyncze sandboxy. Różnica wynika z liczby użytkowników, sposobu wsparcia i cyklu pracy, nie wyłącznie z parametrów maszyny.