Przejdź do treści

SCENARIUSZE / 11TRAINING + DEVELOPMENT

Przykładowe środowiska VM do szkoleń i pracy deweloperskiej

Scenariusze opisują topologie, które powtarzają się w projektach szkoleniowych i deweloperskich. Nie są konfiguracjami gotowymi do skopiowania. Ostateczny projekt zależy od programu, liczby stanowisk, modelu uprawnień i rodzaju danych. Przed uruchomieniem ustalamy wersje toolchainu, zasady sieciowe, licencje, sposób resetu oraz procedurę odbioru lub usunięcia danych.

SCENARIUSZ 01 / KUBERNETES

Środowisko na szkolenie Kubernetes

Topologia laboratorium wynika z zakresu ćwiczeń. Do pracy z Deployment, Service i Ingress wystarcza zwykle wspólny klaster oraz osobny namespace dla każdego uczestnika. Ćwiczenia dotyczące control plane, worker nodes lub awarii klastra wymagają osobnych klastrów albo zestawów VM.

Namespace porządkuje obiekty i wyznacza zakres części polityk, ale nie stanowi samodzielnej granicy bezpieczeństwa. Uczestnicy nadal współdzielą API server, węzły, storage i zasoby cluster-scoped. Dostęp ograniczamy przez RoleBinding, a zużycie CPU, pamięci i liczby obiektów przez ResourceQuota i LimitRange. NetworkPolicy działa tylko wtedy, gdy obsługuje ją użyty plugin CNI.

Przed uruchomieniem sprawdzamy cały przebieg ćwiczeń z konta uczestnika. Test obejmuje dostęp do registry, provisioning PVC, DNS, Ingress, limity zasobów i operacje Helm. Osobno weryfikujemy reset środowiska oraz to, czy uczestnik nie może odczytać obiektów z innych namespace ani utworzyć zasobów cluster-scoped.

Klaster szkoleniowy Kubernetes W wariancie ze wspólnym klastrem uczestnik łączy się przez kubectl, a opcjonalnie także Helm. Control plane zarządza węzłami roboczymi. Izolację laboratoriów uzupełniają RBAC, quota, NetworkPolicy, Ingress i persistent volumes. UCZESTNIK KUBECTL / HELM CLUSTER / TRAINING CONTROL PLANE WORKER 01 PODS / MANY NS WORKER 02 PODS / MANY NS POLICY / ISOLATION RBAC + QUOTA NETWORKPOLICY INGRESS + PVC

Konfiguracja

Każdy uczestnik otrzymuje własny namespace, ServiceAccount, RoleBinding i kubeconfig. ResourceQuota oraz LimitRange wymuszają uzgodnione requests i limits. Wersje Kubernetes, kubectl i Helm odpowiadają materiałom, a obrazy są wcześniej pobrane z właściwego registry. StorageClass, IngressClass i NetworkPolicy włączamy tylko wtedy, gdy występują w scenariuszu.

Zakres techniczny

Zakres może obejmować Deployment, StatefulSet, ConfigMap, Secret, probes, Service, Ingress i PVC. Uczestnicy diagnozują rollout przez Events, logi, stan obiektów Pod i EndpointSlice. W części poświęconej Helm analizują wyrenderowany manifest, nadpisują values i wykonują rollback konkretnego release.

Efekt i ograniczenia

Wspólny baseline usuwa różnice wersji API i konfiguracji klientów. RBAC, quota i NetworkPolicy ograniczają wpływ uczestników na siebie, lecz nie zapewniają izolacji równoważnej osobnemu klastrowi. Zadania wymagające cluster-admin realizujemy wyłącznie w dedykowanym środowisku.

SCENARIUSZ 02 / DOCKER

Maszyny wirtualne na szkolenie z Dockera

Dostęp do socketu Docker Engine pozwala sterować daemonem działającym z uprawnieniami root. Członkostwo w grupie docker należy więc traktować jak uprawnienia administracyjne do hosta. Dedykowana VM oddziela ten zakres dostępu od firmowego endpointu i pozwala wykonywać ćwiczenia z sieciami, volumes oraz capabilities.

VM ujednolica elementy, których Dockerfile nie opisuje: kernel, cgroups, storage driver, DNS i architekturę CPU. Różnice w tych warstwach ujawniają się przy bind mounts, limitach pamięci, natywnych zależnościach i obrazach wieloarchitekturowych. Sama zgodność wersji Docker Engine nie gwarantuje identycznego wyniku ćwiczenia.

Przed startem mierzymy rozmiar obrazów i build context, sprawdzamy porty, wymagany dostęp do registry oraz zapas miejsca na image layers, volumes i logi. Ustalamy też granicę resetu. Jeśli snapshot obejmuje cały dysk VM, kod i artefakty przeznaczone do zachowania muszą wcześniej trafić do repozytorium lub zewnętrznego storage.

Warstwy środowiska Docker Z obrazu bazowego budowane są kontenery aplikacji i bazy danych działające na VM z Docker Engine i Compose. Środowisko obejmuje także cache registry, trwały volume i healthchecki. IMAGE BUILD / RUN CONTAINER APP CONTAINER DB VM / DOCKER ENGINE + COMPOSE RUNTIME CONTROLS REGISTRY CACHE VOLUME / DATA HEALTHCHECK

Konfiguracja

Linux VM ma przypięte wersje Docker Engine i Compose plugin oraz włączony BuildKit. Repozytorium zawiera Dockerfile, compose.yaml, healthchecki i nieprodukcyjne dane startowe. Przed szkoleniem wykonujemy build bez cache, build z warm cache oraz pełny start stacku. Przy większych obrazach używamy lokalnego registry cache.

Zakres techniczny

Ćwiczenia obejmują multi-stage build, cache, build arguments, tagowanie obrazów i proces non-root. W Compose uczestnicy pracują z service discovery, named volumes, bind mounts, healthcheckami i restart policy. Diagnostyka wykorzystuje docker inspect, docker logs, docker stats oraz stan sieci i volumes.

Efekt i ograniczenia

Każdy uczestnik może przebudowywać obrazy, zmieniać sieci i usuwać volumes bez wpływu na pozostałe stanowiska. Reset snapshotu przywraca cały dysk VM, nie pojedyncze zasoby Dockera. Rootless mode stosujemy tylko wtedy, gdy jego ograniczenia nie kolidują z materiałem szkoleniowym.

SCENARIUSZ 03 / ANDROID

Stanowiska na szkolenie z Androida

Powtarzalny build Androida wymaga zgodnych wersji JDK, Android Gradle Plugin, Gradle Wrapper, SDK Platform i Build Tools. Przypinamy je przed szkoleniem i sprawdzamy na projekcie referencyjnym. Aktualizacja Android Studio lub SDK w dniu zajęć nie jest częścią procesu.

Najtrudniejszym elementem stanowiska zdalnego jest Android Emulator. Akceleracja VM wymaga dostępu do rozszerzeń wirtualizacji i odpowiedniego hypervisora. W środowisku uruchomionym wewnątrz innej VM nie zakładamy jej dostępności. Emulator włączamy dopiero po potwierdzeniu działania /dev/kvm i zmierzeniu opóźnień pulpitu zdalnego.

Jeśli akceleracja nie jest dostępna, VM nadal obsługuje edycję kodu, dependency resolution, build i testy JVM. APK uruchamiamy wtedy na uzgodnionym urządzeniu zewnętrznym. Przed zajęciami wykonujemy clean build bez cache prowadzącego, uruchamiamy testy i sprawdzamy dostępność wszystkich artefaktów Maven.

Stanowisko szkoleniowe Android Na jednej maszynie wirtualnej działa Android Studio ze wskazaną wersją SDK, projekt szkoleniowy oraz emulator. Proces uzupełniają cache Gradle, diagnostyka ADB i logcat oraz akceleracja KVM albo urządzenie fizyczne. VM / PER SEAT ANDROID STUDIO SDK / PINNED PROJECT BUILD + TESTS DEPLOY EMULATOR ANDROID BUILD + EXECUTION GRADLE CACHE ADB / LOGCAT KVM / DEVICE

Konfiguracja

Przypinamy JDK, Android SDK Platform, Build Tools, Android Gradle Plugin i Gradle Wrapper. Projekt przechodzi clean build oraz testy na koncie uczestnika. Cache Gradle przygotowujemy dopiero po potwierdzeniu, że build działa również od zera. AVD odpowiada poziomowi API używanemu w materiale.

Zakres techniczny

Zakres obejmuje build variants, dependency resolution, unit tests, analizę manifestu, logcat i pracę z ADB. Instrumented tests oraz deployment APK do AVD realizujemy tylko na stanowiskach z potwierdzoną akceleracją. Bez niej artefakt powstaje w VM, a wykonanie testu odbywa się na urządzeniu zewnętrznym.

Efekt i ograniczenia

Jednakowy toolchain zapewnia porównywalny build output i zachowanie Gradle. Nie gwarantuje natomiast wydajności emulatora. Jeśli infrastruktura nie udostępnia akceleracji VM, nie przedstawiamy AVD jako pełnowartościowego elementu stanowiska i ograniczamy zakres do buildów oraz testów niewymagających urządzenia.

SCENARIUSZ 04 / AI

Sandbox do eksperymentów z AI

Oddzielna VM izoluje runtime, biblioteki i credentials prototypu od komputera dewelopera. Nie rozwiązuje jednak problemu danych wysyłanych do zewnętrznego modelu. Dopuszczalny zakres eksperymentu wynika z klasyfikacji danych, umowy z dostawcą API i polityki organizacji.

Przed pierwszym requestem ustalamy, jakie pola mogą opuścić środowisko, gdzie dostawca zapisuje request i response oraz jaki obowiązuje okres retencji. Notebook korzysta z danych syntetycznych albo wcześniej zatwierdzonego datasetu. Brak trasy do produkcji ogranicza ryzyko przypadkowego pobrania danych, ale nie zastępuje kontroli payloadu wysyłanego do API.

Każdy przebieg zapisuje model ID, wersję promptu, parametry inferencji, evaluation dataset i wynik walidacji. Przy modelach niedeterministycznych porównujemy rozkład wyników z kilku uruchomień, nie pojedynczą odpowiedź. Osobno rejestrujemy latency, token usage, błędy API i zgodność structured output ze schematem.

Sandbox AI odizolowany od produkcji Python z JupyterLab korzysta z danych syntetycznych i ograniczonego dostępu do wskazanego API, bez tras do produkcji. Eksperyment zapisuje użyty model, metryki i evaluation dataset, a credentials pochodzą z osobnego secret store. SANDBOX VM PYTHON JUPYTERLAB TEST DATA GATED ACCESS MODELS API PRODUCTION NO LINK × EXPERIMENT RECORD SECRET STORE EVAL DATASET MODEL + METRICS

Konfiguracja

VM zawiera przypięty Python environment, dependency lockfile, JupyterLab i zatwierdzony dataset. Egress dopuszcza wyłącznie wymagane endpointy API. Credentials nie trafiają do repozytorium ani notebooka. Proces otrzymuje je z secret store albo z pliku o ograniczonych uprawnieniach, zgodnie ze standardem organizacji.

Zakres techniczny

Evaluation dataset zawiera przypadki pozytywne, negatywne i edge cases. Ocena korzysta z jawnych kryteriów oraz wersjonowanego kodu. Oprócz jakości zapisujemy model ID, prompt version, parametry, surową odpowiedź, latency, token usage, error rate i wynik walidacji structured output.

Efekt i ograniczenia

Możemy odtworzyć kod, dataset i parametry eksperymentu. Nie gwarantuje to identycznej odpowiedzi, jeśli dostawca zmieni model lub sposób jego obsługi. Zamknięcie środowiska obejmuje usunięcie VM, rotację kluczy oraz sprawdzenie retencji po stronie dostawcy API.

SCENARIUSZ 05 / APACHE KAFKA

Laboratorium na szkolenie z Apache Kafka

Do ćwiczeń z producerem, consumerem, partycjami i offsetami wystarczy mały klaster. Leader election, ISR i zachowanie zapisu po utracie brokera wymagają co najmniej trzech brokerów oraz świadomie dobranych wartości replication factor, min.insync.replicas i acks.

Trzy brokery uruchomione na jednej VM pozwalają zatrzymywać procesy i obserwować zmianę leadera. Nie jest to jednak test awarii hosta ani availability zone. Jeśli szkolenie dotyczy odporności infrastruktury, brokery oraz KRaft controller quorum rozkładamy na osobnych VM i odseparowanych failure domains.

Konfiguracja klientów Kafki jest częścią laboratorium. Przypinamy wersję biblioteki, serializację, Schema Registry i ACL, a syntetyczny strumień zachowuje typowy rozkład kluczy oraz rozmiar payloadu. Pozwala to pokazać ordering w obrębie partycji, consumer lag i skutki rebalansu bez dostępu do production topics.

Temat Kafki z trzema partycjami Producer publikuje zdarzenia do topic z trzema partycjami. Consumer group odczytuje komunikaty i śledzi offset. Dolna warstwa pokazuje leadera, repliki ISR, consumer lag i rebalance. PRODUCER TOPIC / EVENTS P0 P1 P2 ● OFFSET READ CONSUMER GROUP CLUSTER BEHAVIOUR BROKER 1 / LEADER BROKER 2/3 / ISR LAG + REBALANCE

Konfiguracja

Dla scenariusza utraty brokera uruchamiamy trzy brokery, topic z replication factor 3, min.insync.replicas=2 i producer z acks=all. Każdy uczestnik otrzymuje własny prefix topiców lub ACL. Monitoring pokazuje stan brokerów, leaderów, ISR i consumer groups.

Zakres techniczny

Uczestnicy analizują wpływ message key na partitioning i ordering, manual oraz auto commit, auto.offset.reset, lag i rebalance consumer group. W wariancie wielobrokerowym obserwują leader election, zmiany ISR, odrzucenie zapisu po spadku liczby in-sync replicas oraz recovery brokera.

Efekt i ograniczenia

Laboratorium pokazuje semantykę klientów i protokołu bez używania danych produkcyjnych. Kilka brokerów na jednym hoście nie odwzorowuje awarii maszyny, parametrów storage ani opóźnień sieci między strefami. Wyników z takiej topologii nie używamy do oceny production capacity.

SCENARIUSZ 06 / MONGODB

Środowisko na warsztat z MongoDB

Ten scenariusz dotyczy MongoDB, nie ogólnej kategorii NoSQL. Zakres obejmuje modelowanie dokumentów, aggregation pipeline, operatory aktualizacji i indeksy. Inne bazy nierelacyjne mają odmienne modele spójności, query language i charakterystykę operacyjną.

Decyzję między embedding a references podejmujemy na podstawie ścieżek odczytu i zapisu, cardinality oraz częstotliwości zmian. Wpływa ona na atomowość operacji, rozmiar dokumentu i liczbę requestów. Sam diagram encji nie wystarcza do zaprojektowania modelu dokumentowego.

Seed data odtwarza selektywność pól, rozkład wartości i relacje między kolekcjami. Dopiero wtedy explain("executionStats") daje materiał do porównania COLLSCAN, IXSCAN oraz wartości totalDocsExamined, totalKeysExamined i nReturned. Cold cache i warm cache traktujemy jako osobne warunki testu.

Baza dokumentowa na szkoleniu Uczestnik wysyła zapytanie do MongoDB zawierającego dokumenty i indeksy, a skrypt przywraca stan początkowy. Kontrolowany seed umożliwia porównanie execution stats oraz planów COLLSCAN i IXSCAN. UCZESTNIK QUERY / PLAN DB / MONGODB DOC / ORDERS DOC / USERS INDEXES RESET SCRIPT REPEATABLE QUERY TEST SEED / CARDINALITY EXPLAIN STATS COLLSCAN / IXSCAN

Konfiguracja

Przypinamy wersje MongoDB i mongosh. Uczestnik otrzymuje własną bazę z ograniczoną rolą albo osobną instancję. Idempotentny reset script odtwarza dokumenty, schema validation i indeksy. Replica set uruchamiamy wtedy, gdy ćwiczenia obejmują transactions, change streams lub zachowanie read concern.

Zakres techniczny

Zakres obejmuje embedding i references, schema validation, aggregation pipeline oraz update operators. W planach wykonania porównujemy COLLSCAN, IXSCAN, FETCH i ewentualny SORT. Dla compound indexes analizujemy kolejność pól względem equality, sort i range oraz możliwość wykonania covered query.

Efekt i ograniczenia

Własny dataset i reset pozwalają porównywać plany bez kolizji między uczestnikami. Wynik zależy od rozmiaru i rozkładu danych, stanu cache oraz wersji query engine. Laboratorium służy do analizy mechanizmu, nie do publikowania benchmarków MongoDB.

SCENARIUSZ 07 / ANSIBLE

Izolowane środowisko na szkolenie z Ansible

Każdy uczestnik pracuje z własnym control node i zestawem managed hosts. Playbook może instalować pakiety, zmieniać konfigurację usług i korzystać z privilege escalation bez dostępu do firmowych serwerów. Po ćwiczeniu hosty wracają do wersjonowanego baseline.

Wynik wykonania zależy od połączenia SSH, interpretera Python, konfiguracji sudo i modułów dostępnych na danej platformie. Playbook przygotowany dla Ubuntu może wymagać zmian na Debianie lub systemie używającym innego package managera. Dystrybucję i wersję systemu dobieramy więc do materiału, nie odwrotnie.

Zmiana reguł firewalla, konfiguracji SSH lub network stack może odciąć kanał, którym Ansible zarządza hostem. Takie ćwiczenia wymagają konsoli niezależnej od SSH oraz automatycznego rebuild. Przed szkoleniem sprawdzamy również check mode i diff. Nie wszystkie moduły je obsługują, a diff może ujawnić wartości wymagające ochrony.

Laboratorium Ansible Węzeł kontrolny z Ansible i inventory uruchamia playbooki przez SSH na trzech hostach w prywatnej sieci. Check mode, diff i drugi przebieg weryfikują idempotence, a rebuild odtwarza baseline. CONTROL NODE ANSIBLE + INVENTORY PLAYBOOK / SSH LAB NET / PRIVATE HOST 01 / LINUX HOST 02 / LINUX HOST 03 / LINUX CONTROL LOOP CHECK + DIFF RUN 2 / IDEMPOTENT REBUILD BASELINE

Konfiguracja

Control node ma przypiętą wersję ansible-core, a dwa lub trzy managed hosts działają w prywatnej sieci. Konfiguracja obejmuje inventory, SSH keys, host key verification, Python interpreter i become. Obrazy bazowe oraz procedura rebuild są wersjonowane razem z materiałami.

Zakres techniczny

Zakres obejmuje inventory groups, host_vars, group_vars, variable precedence, templates Jinja2, handlers, roles i Ansible Vault. Uczestnicy korzystają z verbosity, check mode i diff oraz analizują changed_when i failed_when. Idempotence sprawdzają przez drugie uruchomienie bez zmiany danych wejściowych.

Efekt i ograniczenia

Playbook działa na pełnych systemach Linux, dlatego ujawnia problemy z package managerem, systemd, permissions i SSH. Prywatna sieć ogranicza blast radius. Wynik nadal dotyczy konkretnej dystrybucji i wersji usług, więc przed wdrożeniem potrzebny jest test w środowisku zgodnym z docelowym.

SCENARIUSZ 08 / JMETER LUB GATLING

Środowisko do testów wydajnościowych

Load generator działa na innej VM niż system under test i wysyła ruch wyłącznie do wskazanego endpointu. Taki podział pozwala osobno obserwować limity generatora i aplikacji. Wyniki z infrastruktury współdzielonej traktujemy jako dane z laboratorium, nie jako automatyczną prognozę wydajności produkcji.

Test zaczyna się od workload modelu, faz ramp-up, warm-up i steady state oraz warunków przerwania. Liczba virtual users jest parametrem modelu, nie celem samym w sobie. p95 i p99 interpretujemy razem z throughput, error rate oraz saturacją CPU, GC, connection pools, bazy i storage.

Przed właściwym runem sprawdzamy CPU, pamięć, liczbę połączeń i network throughput generatora. JMeter mierzy czas protokołu, nie renderowanie strony ani wykonanie JavaScript w przeglądarce. Do oceny frontend performance potrzebny jest osobny scenariusz browserowy i odpowiednie metryki.

Środowisko testów obciążeniowych Generator JMeter albo Gatling kieruje kontrolowane obciążenie do aplikacji testowej. Monitoring koreluje fazy ramp i steady z p95, error rate oraz wykorzystaniem CPU, garbage collectora i dysku. LOAD GEN JMETER / GATLING LOAD APP UNDER TEST MONITORING / RESPONSE TIME TEST PHASES + SIGNALS RAMP / STEADY P95 + ERROR RATE CPU / GC / I/O

Konfiguracja

Przypinamy wersję JMeter albo Gatling i odpowiadającego im runtime. Czas na obu VM jest zsynchronizowany, a limit ruchu zapisany w konfiguracji testu. Monitoring obejmuje aplikację, connection pool, CPU, pamięć, disk I/O i sieć. Osobny preflight potwierdza zapas zasobów generatora.

Zakres techniczny

Uczestnicy definiują workload model, ramp-up, warm-up, steady state i teardown. Analizują throughput, error rate, p50, p95, p99 i liczbę aktywnych virtual users oraz korelują je z CPU, GC, connection pools i storage. Każdy run zapisuje commit testu, dataset, parametry i czas wykonania.

Efekt i ograniczenia

W tej samej konfiguracji można porównywać regresje i zależności między obciążeniem a saturacją. Bezwzględne wartości throughput i latency nie wyznaczają production capacity, jeśli nie kontrolujemy topologii sieci, storage, noisy neighbor effect i parametrów docelowej infrastruktury.

SCENARIUSZ 09 / TESTOWANIE APLIKACJI

Laboratorium do testów funkcjonalnych i API

Każdy run testowy musi wskazywać konkretny build, na przykład commit SHA lub immutable image tag, oraz znany stan danych. Uczestnicy nie pracują na jednej współdzielonej bazie. Operacja wykonana przez jedną osobę nie może zmieniać preconditions testu uruchamianego przez inną.

Defekty w aplikacji demonstracyjnej wynikają z opisanych wymagań i pozostawiają ślad w UI, odpowiedzi API albo logach. Uczestnik może dzięki temu postawić hipotezę, zebrać request, response i correlation ID, a następnie przygotować minimalny reproduction path. Nie musi odgadywać intencji autora zadania.

Izolację realizujemy przez osobną instancję, schema lub tenant. Reset odtwarza rekordy, konta, role i dane referencyjne, a jego wielokrotne uruchomienie prowadzi do tego samego stanu. Sam mechanizm resetu testujemy przed szkoleniem razem z aplikacją i zestawem test accounts.

Laboratorium testowe Tester sprawdza UI i wysyła żądania HTTP do API. Build ID, seed danych i correlation ID tworzą kontekst reprodukcji, który wraz ze ścieżką odtworzenia trafia do zgłoszenia błędu. TESTER HTTP / API DEMO ENV + TEST DATA APP / UI API BUG REPORTS REPRODUCTION CONTEXT BUILD ID + SEED CORRELATION ID RESET + BUG REPORT

Konfiguracja

Wersję aplikacji wskazuje commit SHA lub immutable image tag. Uczestnik otrzymuje własną instancję, database schema albo tenant z deterministycznym seed data. Materiały zawierają wymagania, OpenAPI spec, konta o różnych rolach i sposób odnalezienia correlation ID w logach.

Zakres techniczny

Zakres obejmuje boundary values, equivalence classes i state transitions w UI oraz API. Dla HTTP analizujemy status codes, headers, validation, authentication, authorization, pagination i idempotency. Zgłoszenie zawiera request, response, timestamp, correlation ID, expected result, actual result i minimalny reproduction path.

Efekt i ograniczenia

Defekt można odtworzyć względem konkretnego build ID i seed data bez dostępu do produkcji. Laboratorium nie odwzorowuje automatycznie integracji zewnętrznych, race conditions ani zachowania pod obciążeniem. Te obszary wymagają test doubles albo osobnej topologii.

SCENARIUSZ 10 / RUST

Maszyny wirtualne na szkolenie z Rusta

Wersja rustc wpływa na dostępne language features, diagnostykę kompilatora i MSRV zależności. Crates korzystające z FFI wymagają dodatkowo konkretnych bibliotek i headerów systemowych. Polecenie „zainstaluj Rust” nie definiuje więc kompletnego stanowiska.

Toolchain zapisujemy w rust-toolchain.toml, a dependency graph stabilizuje Cargo.lock. Feature flags i targets również są częścią konfiguracji projektu. Dzięki temu wszyscy otrzymują te same komunikaty kompilatora i pracują na tej samej wersji zależności.

Przed zajęciami budujemy cały workspace na koncie uczestnika przez cargo build --locked, uruchamiamy testy i Clippy oraz sprawdzamy rustfmt. Osobno weryfikujemy native dependencies dla FFI, OpenSSL i bindingów systemowych. Miri oraz cross-compilation instalujemy tylko wtedy, gdy rzeczywiście występują w programie.

Stanowisko szkoleniowe Rust Projekt jest kompilowany przez przypięte wersje rustc i Cargo, a następnie przechodzi testy. Lockfile, rustfmt, Clippy oraz jawne zależności systemowe utrzymują reprodukowalność toolchainu. VM / IDENTICAL SEAT PROJECT SOURCE CARGO BUILD RUSTC MESSAGES TESTS CARGO TEST REPRODUCIBLE TOOLCHAIN TOOLCHAIN + LOCK FMT + CLIPPY TARGET + NATIVE LIBS

Konfiguracja

rustup instaluje channel lub pełną wersję wskazaną w rust-toolchain.toml, razem z wymaganymi components i targets. Repozytorium zawiera Cargo.lock, jawne feature flags i listę bibliotek systemowych. Build, testy, rustfmt i Clippy przechodzą na koncie uczestnika.

Zakres techniczny

Materiał obejmuje ownership, borrowing, lifetimes, pattern matching, traits i generics w rozwijanym programie. Error handling wykorzystuje Result, operator ? i jawne typy błędów. Weryfikację stanowią unit tests, integration tests i Clippy, a opcjonalnie Miri lub testy współbieżności.

Efekt i ograniczenia

Przypięty toolchain i lockfile stabilizują diagnostykę oraz dependency resolution. Nie wystarczą, jeśli build zależy od pakietów systemowych, architektury targetu lub usług zewnętrznych. Te zależności zapisujemy w obrazie VM i dokumentacji projektu.

SCENARIUSZ 11 / APLIKACJE WEBOWE

Środowisko deweloperskie do aplikacji webowych

Środowisko dla aplikacji webowej musi odtworzyć wersje runtime, bazy i usług pomocniczych używane przez projekt. Sama obecność zależności w obrazie VM nie wystarcza. Repozytorium potrzebuje powtarzalnego bootstrapu, jawnej konfiguracji i procedury zachowania zmian przed wygaśnięciem maszyny.

Pełny stack może obejmować frontend, API, bazę, cache, message broker, object storage, mail catcher i background workers. Dla każdej zależności wskazujemy usługę lokalną albo konkretny sandbox endpoint. Dzięki temu uruchomienie projektu nie zależy od poleceń przekazywanych ustnie przez członków zespołu.

Bootstrap testujemy od czystego checkoutu: instalacja dependencies, migrations, seed, start usług i healthchecki. Produkcyjne secrets nie trafiają do obrazu ani repozytorium. Publiczny podgląd aplikacji ma określony port, czas działania i access control. Dev VM nie zastępuje staging, jeśli różni się topologią lub integracjami.

Kompletny stos aplikacji webowej Deweloper pracuje w prywatnej kopii pełnego stosu: frontend, backend, baza danych i usługi pomocnicze. Migracje, seed, logi, traces oraz commit lub eksport zamykają cykl pracy. DEVELOPER DEV VM / PRIVATE COPY FRONTEND BACKEND API DATABASE SERVICES DELIVERY + OPERATIONS MIGRATION + SEED LOGS + TRACES COMMIT / EXPORT

Konfiguracja

Repozytorium pobieramy przez short-lived credentials. Runtime i package manager są przypięte, lockfiles respektowane, a stack uruchamia Compose albo projektowy bootstrap script. Database migrations i seed są wersjonowane. Mail, object storage i pozostałe dependencies korzystają z usług lokalnych lub jawnie wskazanych sandbox endpoints.

Zakres techniczny

Zmiana end-to-end obejmuje UI, API contract, migration i testy. Diagnostyka korzysta z logów z correlation ID, healthchecków oraz metrics i traces, jeśli aplikacja je wystawia. Review environment można udostępnić przez expose po określeniu portu, czasu działania i access control.

Efekt i ograniczenia

Deweloper otrzymuje pełny stack bez instalowania go na lokalnym komputerze. Przed usunięciem VM commit trafia do repozytorium, a wymagane artefakty są eksportowane. Dev VM nadal różni się od staging pod względem topologii, secrets management, autoscalingu, observability i integracji zewnętrznych.