Brief techniczny powinien wynikać z programu warsztatu
Lista narzędzi to dopiero początek. Dla każdego ćwiczenia trzeba wskazać system, pełne wersje runtime i bibliotek, usługi, dane, uprawnienia oraz sposób potwierdzenia wyniku. Znaczenie ma również kolejność etapów, ponieważ wpływa na stan, który pozostaje na maszynie.
Brief obejmuje liczbę uczestników, termin, czas dostępu, metodę połączenia, wymagania sieciowe oraz sposób przekazania materiałów. Jeśli środowisko zawiera kilka węzłów lub wspólną usługę, topologię należy opisać osobno. Niejasność na tym etapie wraca później jako różnica między oczekiwaniem prowadzącego a zbudowaną konfiguracją.
Obraz bazowy musi przejść próbę z konta uczestnika
Na jednej VM instaluje się system, narzędzia i dane startowe. Prowadzący uruchamia cały materiał, ale powinien zrobić to z uprawnieniami zwykłego użytkownika. Konto administratora może nie ujawnić problemów z katalogiem, portem, tokenem lub dostępem do usługi.
Test obejmuje także restart maszyny i usług. Konfiguracja, która działa tylko w sesji osoby budującej obraz, nie jest gotowa do powielenia. Po odbiorze obraz otrzymuje wersję i dopiero wtedy powstają stanowiska grupy.
Osobna VM usuwa wzajemny wpływ uczestników
Każda osoba może zmieniać pliki, pakiety, procesy i lokalne dane bez naruszania pracy innych. Jest to ważne przy administracji, kontenerach, bazach i testowaniu aplikacji. Wspólne elementy, takie jak registry, repozytorium Git czy serwer materiałów, powinny mieć własne reguły dostępu i przygotowaną pojemność.
Nie wszystkie scenariusze wymagają pełnej VM na osobę. Wspólny klaster z osobnymi namespace może wystarczyć do wybranych ćwiczeń Kubernetes, a osobne schematy do nauki SQL. Trzeba jednak jawnie wskazać, które zasoby nadal są współdzielone i czego uczestnik nie może zmieniać.
Dostęp przez przeglądarkę ogranicza wymagania lokalne
Graficzny pulpit może działać przez HTTPS w aktualnej przeglądarce. Uczestnik nie instaluje klienta zdalnego pulpitu ani narzędzi szkoleniowych na laptopie. Dla zajęć terminalowych alternatywą jest SSH. Obie metody prowadzą do zasobów działających w chmurze.
Przed zajęciami trzeba sprawdzić połączenie z docelowej sieci, układ klawiatury, zachowanie schowka i ponowne logowanie po przerwie. Firmowe proxy lub filtrowanie adresów mogą wymagać wcześniejszego uzgodnienia. Najlepiej wykryć je podczas krótkiego testu uczestnika, nie w pierwszych minutach warsztatu.
Materiały powinny być dostępne na stanowisku
Repozytorium, pliki danych i instrukcje można umieścić w obrazie albo współdzielonym katalogu. Oryginały pozostają tylko do odczytu, a wyniki trafiają do prywatnych katalogów. Uczestnik nie musi przenosić załączników z lokalnej poczty do zdalnej sesji.
Wersja materiałów powinna odpowiadać wersji obrazu. Jeśli po teście prowadzącego zmienia się plik startowy, trzeba sprawdzić scenariusz ponownie. Dane ćwiczeniowe nie powinny pochodzić bezpośrednio z produkcji, chyba że firma przeprowadziła odpowiedni proces anonimizacji i zatwierdziła ich użycie.
Próba generalna obejmuje również awarię
Oprócz głównej ścieżki warto zatrzymać usługę, zerwać sesję i przywrócić wybraną VM. Prowadzący sprawdza, jakie informacje są potrzebne do diagnozy i ile trwa powrót do pracy. Panel trenera może pokazać status stanowisk oraz umożliwić pomoc, ale procedura musi być zrozumiała także bez niego.
Reset powinien przywracać znany stan bez zmiany maszyn pozostałych uczestników. Snapshot jest przydatny przy zmianach systemowych, a wersjonowany bootstrap przy odtwarzaniu usług i danych. Wybrana metoda zależy od tego, co uczestnik może modyfikować.
Środowisko czasowe musi mieć plan wyjścia
Przed końcem uczestnicy eksportują kod, raporty lub konfigurację. Organizator unieważnia tymczasowe konta i ustala, które materiały mają pozostać dostępne. Po terminie maszyny są wyłączane, a dane usuwane zgodnie z uzgodnioną zasadą.
Proces przygotowania środowiska w Klasie w chmurze obejmuje specyfikację, budowę konfiguracji bazowej, przekazanie dostępu i zamknięcie po okresie rezerwacji. W case studies można porównać topologie dla Kubernetes, Dockera, baz danych, automatyzacji, testów i rozwoju aplikacji.