Stanowisko do pracy z Dockerem obejmuje więcej niż polecenie docker version
Program szkolenia powinien wskazywać wersję Docker Engine, Compose, Buildx i używanych dodatków. Znaczenie ma również system hosta, kernel, cgroups i sterownik storage. Dwa komputery z podobnym klientem mogą zachowywać się inaczej, jeśli jeden korzysta z natywnego Linuxa, a drugi z warstwy wirtualizacji.
Osobna VM z Linuxem upraszcza ten model. Każdy uczestnik otrzymuje ten sam daemon, system plików i konfigurację sieci. Polecenia z materiału prowadzą wtedy do porównywalnych rezultatów, a prowadzący nie musi obsługiwać kilku wariantów Docker Desktop.
Obrazy i zależności trzeba przygotować przed zajęciami
Grupa pobierająca jednocześnie duże obrazy może obciążyć łącze i natrafić na limity publicznego registry. Obrazy bazowe używane w ćwiczeniach warto pobrać wcześniej albo udostępnić przez kontrolowane repozytorium. Ich tagi powinny wskazywać konkretne wersje, nie zmienny latest.
Ćwiczenie z budowania obrazu nadal powinno wykonywać rzeczywistą pracę. Wstępne przygotowanie nie oznacza dostarczenia gotowego rezultatu, lecz usunięcie zależności od przypadkowej dostępności sieci. Jeśli materiał wymaga pakietów, należy sprawdzić repozytoria i cache w warunkach podobnych do dnia szkolenia.
Zasoby dysku kończą się szybciej, niż pokazuje rozmiar projektu
Warstwy obrazów, cache buildu, wolumeny i logi rosną podczas kolejnych prób. Profil VM powinien uwzględniać kilka buildów oraz dane używane przez usługi. Przed zajęciami warto wykonać cały scenariusz i sprawdzić rzeczywiste zużycie przez docker system df.
Automatyczne czyszczenie uruchomione w niewłaściwym momencie może usunąć artefakty potrzebne do porównania. Lepiej zaplanować punkty porządkowania między ćwiczeniami i wyjaśnić, co usuwa dane polecenie. Uczestnik powinien rozróżniać zatrzymany kontener, obraz, cache i wolumen.
Sieci i wolumeny potrzebują obserwowalnego scenariusza
Przy Compose można przygotować aplikację, bazę i usługę pomocniczą, a następnie pokazać rozwiązywanie nazw, publikowanie portów i komunikację wewnątrz sieci. Warto celowo wprowadzić błędny port lub healthcheck, aby uczestnik użył logów, inspekcji i stanu usług do diagnozy.
Wolumen powinien zawierać dane, których utrata jest widoczna po ponownym uruchomieniu. Dzięki temu różnica między zapisem w warstwie kontenera a trwałym storage nie pozostaje abstrakcyjna. Reset ćwiczenia musi jawnie określać, czy zachowuje wolumeny, czy usuwa je razem ze środowiskiem.
Dostęp do daemona oznacza szerokie uprawnienia
Użytkownik należący do grupy docker ma w praktyce możliwość uzyskania wysokich uprawnień na hoście. Dlatego laboratorium powinno działać na prywatnych, czasowych VM, a nie na współdzielonym serwerze z ważnymi danymi. Uczestnicy nie powinni otrzymywać poświadczeń do produkcyjnego registry ani klastra.
Sekrety używane przez przykładową aplikację muszą być fikcyjne lub mieć ograniczony zakres. Nie należy zapisywać ich w obrazie ani warstwie buildu. To dobra okazja, aby pokazać różnicę między argumentem buildu, zmienną środowiskową i mechanizmem przeznaczonym do przekazywania sekretów.
Kubernetes wymaga osobnego projektu laboratorium
Znajomość obrazów i kontenerów pomaga w nauce Kubernetes, ale klaster wprowadza control plane, węzły, storage, DNS, Ingress i model uprawnień. Dodanie lokalnego klastra do końcówki warsztatu z Dockera nie zawsze daje wystarczająco dużo czasu na zrozumienie tych elementów.
Jeżeli Kubernetes jest częścią programu, trzeba zdecydować, czy uczestnicy pracują we wspólnym klastrze z osobnymi namespace, czy na oddzielnych klastrach. Każdy wariant ma inne wymagania dotyczące zasobów i izolacji. Przykładową topologię opisuje scenariusz szkolenia Kubernetes.
Obraz bazowy powinien przejść cały materiał przed powieleniem
Test obejmuje build bez korzystania z prywatnego cache prowadzącego, uruchomienie Compose, healthchecki, komunikację sieciową, zapis w wolumenie i czyszczenie. Wszystkie czynności należy wykonać z konta uczestnika. Dopiero potem konfiguracja staje się podstawą dla grupy.
Gotowe maszyny na szkolenie IT pozwalają oddzielić swobodę pracy z daemonem od firmowych laptopów. Po warsztacie warto zachować Dockerfile, pliki Compose i notatki, a same VM oraz tymczasowe poświadczenia usunąć w uzgodnionym terminie.