Aurora Kursy

Kursy DevOps · Docker i observability · egzaminy próbne

Nie oglądasz kursu.
Naprawiasz zepsuty system.

Każde ćwiczenie to maszyna z prawdziwym problemem: usługa nie wstaje, exporter milczy, alert budzi bez powodu. Wpisujesz polecenia, system reaguje, zadanie zalicza się dopiero wtedy, gdy naprawdę działa.

Zobacz kursy Przeczytaj lekcję za darmo
  • 152 lekcji
  • 79 ćwiczenia w konsoli
  • 168 pytań sprawdzających
  • 146 h materiału
sre@monitoring — ćwiczenie 1/7

To nie jest nagranie — wpisz polecenie i sprawdź.

Dlaczego to działa, a filmiki nie

Maszyna, nie nagranie

Emulowany system plików, usługi systemd, gniazda i procesy. Działa ls, grep, systemctl, ss, sed, potoki i przekierowania. Zadanie zalicza się po efekcie w systemie, nie po wpisaniu właściwej komendy — do celu prowadzi tyle dróg, ile na produkcji.

Symulatory zamiast teorii

Suwakiem ustawiasz for i widzisz, kiedy alert nie powstanie wcale. Piszesz szablon Alertmanagera i od razu masz gotowe powiadomienie obok.

Z wdrożeń, nie z dokumentacji

Każda pułapka w tym kursie kosztowała kiedyś kogoś noc. Kardynalność, która położyła serwer. Alert, który odpalił punktualnie przy awarii, której nikt nie zauważył.

Egzamin próbny na koniec

60 pytań, 90 minut, próg 75% — format prawdziwej certyfikacji. Wynik dostajesz z rozbiciem na obszary, więc wiesz, co powtórzyć. Kurs observability pokrywa przy tym obszary egzaminu PCA.

Kto to pisze

Grzegorz Wołyniec

DevOps / SRE · Aurora-Tech

Z technologią jestem związany od 2000 roku; komercyjnie — od 2018, jako inżynier DevOps i SRE, a od kilku lat również jako konsultant. Projektuję, wdrażam i utrzymuję infrastrukturę produkcyjną, ze specjalizacją w konteneryzacji, orkiestracji Kubernetes, GitOps i observability.

Pracowałem w środowiskach o realnej skali: platformy wirtualizacyjne rzędu dwóch tysięcy maszyn z automatycznym provisionowaniem, infrastruktura obsługująca miliony wiadomości na dobę, klastry produkcyjne utrzymywane w trybie ciągłym dla kilku zespołów deweloperskich naraz. Zbudowany przeze mnie system monitoringu został wyróżniony nagrodą firmową. Obecnie prowadzę Aurora-Tech i odpowiadam za klastry Kubernetes, platformy CI/CD oraz monitoring w środowiskach korporacyjnych.

Kursy powstają wprost z tej praktyki. Dokumentację każdy przeczyta sam — tutaj znajdziesz to, czego w niej nie ma: przypadki brzegowe, koszt złych decyzji architektonicznych i awarie, które naprawdę się zdarzają. Alert, który zadziałał zgodnie z konfiguracją i przemilczał incydent. Kardynalność metryk, która wysyciła serwer. Kontener zatrzymany przez limit pamięci, bez śladu w logach aplikacji.

Materiał jest aktualizowany na bieżąco. Jeśli znajdziesz w nim błąd merytoryczny — zgłoś go. Poprawka trafia do kursu, a Ty dostajesz informację zwrotną.

  • od 2000z technologią; komercyjnie w DevOps od 2018
  • ~2 000maszyn wirtualnych pod opieką
  • mln / dobęwiadomości przez utrzymywaną infrastrukturę
  • 300 / 15 minhypervisorów przez automatyczne provisionowanie
Napisz do mnie

Konteneryzacja i orkiestracja

Docker, Kubernetes (k3s, k0s, RKE2, OpenShift), Helm, Harbor

CI/CD i infrastruktura jako kod

GitLab CI, ArgoCD i GitOps, Terraform / OpenTofu, Ansible

Observability

Prometheus, VictoriaMetrics, Grafana, Loki, Alertmanager

Platforma i bezpieczeństwo

Vault, External Secrets, cert-manager, Cilium, sieci i Linux

Co jest w środku

Observability od zera

Prometheus, PromQL, własne eksportery, Loki i Alloy — z przygotowaniem do egzaminu PCA

Program i zapis
Rozwiń program — 15 lekcji, ok. 16 h
  1. Po co w ogóle metryki Monitoring kontra observability, cztery złote sygnały i dlaczego zielony dashboard bywa kłamstwem. Bezpłatny podgląd
  2. Ile dziewiątek obiecałeś? SLI, SLO i SLA, budżet błędów, tempo spalania oraz trzeci filar: ślady
  3. Prometheus: target, scrape, relabeling Model pull, metryka up, relabeling i kardynalność, która potrafi położyć Prometheusa. ćwiczenie
  4. Skąd Prometheus wie, kogo odpytywać file_sd, kubernetes_sd i pięć ról, etykiety __meta_*, honor_labels, cała ścieżka od SD do bazy
  5. Alerty, które nie budzą o trzeciej w nocy Objawy zamiast przyczyn, parametr for, runbooki, wyciszanie zależności i testowanie reguł. ćwiczenie
  6. PromQL I: naucz się mówić do bazy Typy danych, matchery etykiet, zakresy, offset, staleness i HTTP API
  7. PromQL II: rate, czyli fizyka liczników Liczniki i mierniki, rate/irate/increase, resety, predict_linear i changes
  8. PromQL III: agregacje i algebra wektorów Operatory agregacji, *_over_time, dopasowanie wektorów, group_left, bool, and/or/unless
  9. PromQL IV: histogramy, czas i chirurgia etykiet histogram_quantile, histogramy natywne, time()/timestamp(), subquery, label_replace
  10. Własny exporter: metryki z rzeczy, która ich nie ma Cztery typy metryk, format tekstowy, gotowy exporter w Pythonie na prawdziwym przykładzie sterowania pompą i pięć błędów, które zobaczysz na produkcji. ćwiczenie
  11. Pushgateway: kiedy pull nie ma jak Joby wsadowe, klucz grupy, honor_labels i cztery pułapki, przez które to boli
  12. Dashboard, który czyta się w pięć sekund Dobór panelu do sygnału, zmienne i powtarzanie, $__rate_interval, RED i USE
  13. Loki i Alloy: logi obok metryk, w jednym miejscu Dlaczego Loki nie jest Elasticsearchem, konfiguracja Alloya do metryk i logów naraz, LogQL, skok z wykresu do logów i retencja, która naprawdę kasuje.
  14. Produkcja: kiedy Prometheus zaczyna boleć Skąd bierze się pamięć, jak znaleźć metrykę zabójcę, recording rules, retencja, wysoka dostępność bez klastra i lista kontrolna przed wdrożeniem.
  15. Szablony powiadomień: alert, który da się przeczytać Skąd szablon bierze dane, trzy pułapki (kropka w pętli, ciche puste pola, białe znaki) i symulator, w którym widzisz powiadomienie przed wysłaniem na produkcję.

Docker od zera do bohatera

Kontenery bez magii — od procesu w ps po produkcję

Program i zapis
Rozwiń program — 19 lekcji, ok. 21 h
  1. Kontener to nie mała wirtualka Namespaces, cgroups, wspólny kernel i dowód w `ps` — czym kontener naprawdę jest Bezpłatny podgląd ćwiczenie
  2. docker run — i co się właściwie stało pull/create/start, cykl życia, cmentarzysko po `docker ps -a`, cztery flagi i pułapka `stop` ćwiczenie
  3. Obraz to cebula: warstwy, tagi i to, co naprawdę pobierasz Warstwy współdzielone, `latest` bez magii, tagi kontra digesty, sprzątanie obrazów ćwiczenie
  4. Dockerfile od pierwszej linijki FROM, WORKDIR, COPY, RUN, CMD, kontekst budowania i .dockerignore ćwiczenie
  5. Cache, który buduje w 3 sekundy albo w 10 minut Jak działa cache, co go unieważnia i dlaczego kolejność instrukcji to pieniądze ćwiczenie
  6. Odchudzanie: multi-stage, alpine i pułapki musl Budowanie wieloetapowe, wybór bazy, musl kontra glibc, distroless bez powłoki ćwiczenie
  7. ENTRYPOINT vs CMD, PID 1 i sygnały, które nie dochodzą Forma exec kontra shell, problem PID 1, procesy zombie, --init i graceful shutdown ćwiczenie
  8. Dane, które przeżyją kontener Warstwa zapisu, wolumeny nazwane, bind mounty, tmpfs, UID/GID i pułapka prune ćwiczenie
  9. Sieci: czemu kontener widzi świat, a ty nie widzisz kontenera Domyślny bridge kontra sieć użytkownika, DNS po nazwach, -p kontra EXPOSE, sieć host ćwiczenie
  10. Zmienne, sekrety i to, czego nie wolno zapiec w obraz ARG kontra ENV, pierwszeństwo konfiguracji, sekrety w warstwach i jak ich unikać ćwiczenie
  11. Docker Compose: cały stack jednym plikiem services, networks, volumes, up/down/ps/logs i wielkie kłamstwo depends_on ćwiczenie
  12. Healthchecki i restart policy: kontener, który sam wstaje z kolan HEALTHCHECK, stany zdrowia, service_healthy jako naprawa depends_on, polityki restartu ćwiczenie
  13. Debugowanie: pięć minut do diagnozy logs, inspect, exec, stats, events — i katalog typowych awarii z objawami ćwiczenie
  14. Rejestry: od Docker Huba po własny Harbor Limity Huba, login/tag/push, digest w produkcji, retencja i quoty ćwiczenie
  15. Kontener, który zjadł cały serwer cgroups jako narzędzie, --memory i --cpus, OOM killer, kod 137 i jego dwóch podejrzanych ćwiczenie
  16. Bezpieczeństwo minimum: nie root, nie latest, nie docker.sock USER, read-only, capabilities, przypięte wersje i dlaczego socket oddaje hosta ćwiczenie
  17. Dzień z życia: dysk pełny w piątek o 16:50 system df, prune i czym grozi, rotacja logów, aktualizacja obrazu po ludzku ćwiczenie
  18. Poza Dockerem: OCI, Podman i co cię czeka w Kubernetes Standard OCI, containerd i runc, Podman, dockershim i mapa drogowa do KCNA
  19. BONUS · Portainer i inne GUI: wygoda za cenę klucza do hosta Poza główną ścieżką: po co panel, dlaczego wymaga socketa i jak go postawić, nie oddając serwera ćwiczenie

Bash od zera do bohatera

Od strachu przed czarnym oknem do produkcyjnych skryptów, które nie budz¹ Ciê o 3 w nocy.

Program i zapis
Rozwiń program — 20 lekcji, ok. 18 h
  1. Terminal: pierwszy kontakt bez strachu Czym jest shell, czym bash i dlaczego DevOps żyje w terminalu. Pierwsze polecenia: pwd, ls, cd, ścieżki bezwzględne i względne oraz mapa systemu plików Linuksa (/etc, /var/log, /tmp). Bezpłatny podgląd ćwiczenie
  2. Pliki i katalogi: tworzenie, kopiowanie i kasowanie bez kosza Operacje na plikach: touch, mkdir, cp, mv, rm oraz flagi -r i -f. Dlaczego rm nie ma kosza i jak jedna literówka w ścieżce skraca karierę. ćwiczenie
  3. Czytanie i polowanie na pliki: cat, head, tail, less, find Podgląd plików bez edytora: cat, head, tail i less. Szukanie plików w drzewie katalogów przez find, lokalizowanie poleceń przez which i szybkie miary z wc. ćwiczenie
  4. Trzy strumienie: stdin, stdout, stderr i przekierowania Każdy proces ma trzy strumienie i można nimi sterować: >, >>, 2>, 2>&1, /dev/null oraz tee. Fundament pracy z logami i pierwsza rzecz, którą psują początkujący. ćwiczenie
  5. Potoki: linia produkcyjna z małych poleceń Potok | podaje wyjście jednego polecenia na wejście drugiego. sort, uniq, cut i wc składają się w klasyczne jednolinijkowce analizy logów, które każdy SRE pisze z pamięci. ćwiczenie
  6. grep i wyrażenia regularne: igła w stogu logów grep jako podstawowe narzędzie śledcze: flagi -i, -v, -n, -r, -c oraz podstawy wyrażeń regularnych — kotwice, klasy znaków, kwantyfikatory i alternatywa. ćwiczenie
  7. sed i awk: chirurgia strumienia tekstu sed wykonuje masowe podmiany i usuwanie linii (s///, d), awk tnie tekst na pola i liczy. Duet, który zastępuje ręczną edycję dziesiątek plików konfiguracyjnych. ćwiczenie
  8. Zmienne i cudzysłowy: najdroższe spacje w historii Przypisania bez spacji wokół =, odwołania ${VAR}, różnica między ' a " oraz word splitting. Niecytowana zmienna to najczęstsza przyczyna skryptów, które "działały u mnie". ćwiczenie
  9. Kody wyjścia i warunki: if, test, [ ] kontra [[ ]] Każde polecenie zwraca kod wyjścia — $?, && i || sterują przepływem. Konstrukcja if z test/[ ] i [[ ]]: testy istnienia plików, porównania liczb i napisów oraz klasyczne błędy składni. ćwiczenie
  10. Pętle: for, while read i bezpieczne iterowanie Pętla for po listach i globach oraz while read -r do czytania plików linia po linii. Klasyk do rozbrojenia: dlaczego for f in $(ls) psuje się na pierwszej spacji w nazwie. ćwiczenie
  11. Funkcje: przestań kopiować, zacznij wywoływać Definiowanie funkcji, argumenty pozycyjne wewnątrz funkcji, zmienne local, różnica między return a echo. Budowa własnej mini-biblioteki pomocniczej. ćwiczenie
  12. Argumenty skryptu: $@, shift i getopts Skrypt jako narzędzie CLI: $0, $1..$9, $#, różnica między "$@" a $*, przesuwanie shift oraz parsowanie flag przez getopts z czytelnym komunikatem użycia. ćwiczenie
  13. Substytucja poleceń, substytucja procesów i here-docs Substytucja poleceń $( ) wstawia wynik polecenia do zmiennej, substytucja procesów <( ) podaje go jak plik, a here-doc generuje wieloliniowe pliki — z interpolacją albo bez (EOF w cudzysłowie). ćwiczenie
  14. Glob kontra regex i tablice: kiedy * nie znaczy to samo Wzorce glob (*, ?, [..]) rozwija shell, a regex interpretują grep i sed — mylenie ich kończy się pustymi wynikami albo przetworzeniem złych plików. Do tego tablice: ${arr[@]}, indeksy i iterowanie. ćwiczenie
  15. set -euo pipefail: skrypt, który wie, kiedy przestać Domyślnie bash brnie dalej po błędzie, nadpisując dane po drodze. Tryb strict: set -e, -u i -o pipefail — wraz z pułapkami (kody w potokach, || true, zachowanie w warunkach). ćwiczenie
  16. Sygnały i trap: sprzątanie po sobie nawet po Ctrl+C SIGINT, SIGTERM i kill, czyli jak umierają procesy. Przechwytywanie sygnałów przez trap i sprzątanie plików tymczasowych oraz locków w trap ... EXIT, żeby przerwany skrypt nie zostawiał pola minowego. ćwiczenie
  17. Debugowanie: set -x, shellcheck i bashizmy kontra POSIX bash -n łapie błędy składni, set -x pokazuje wykonanie krok po kroku (z czytelnym PS4), a shellcheck wyłapuje klasyki zanim to zrobi produkcja. Do tego bashizmy kontra POSIX sh — czyli czemu skrypt padł na Alpine. ćwiczenie
  18. Cron: automatyzacja, która działa, gdy śpisz Składnia crontab i dlaczego cron ma inne środowisko niż Twój terminal (okrojony PATH, brak TTY). Logowanie wyników zadań i ochrona przed nakładającymi się uruchomieniami. ćwiczenie
  19. Bezpieczeństwo skryptów: wstrzyknięcia, cytowanie i pułapki rm -rf Wstrzyknięcia przez niecytowane zmienne i eval, pusta zmienna w rm -rf "$DIR/", bezpieczne pliki tymczasowe z mktemp i ograniczone zaufanie do PATH. Rozdział napisany kosztem cudzych nocy. ćwiczenie
  20. Skrypt, któremu ufasz o 3 w nocy: dobre praktyki produkcyjne Checklista produkcyjna: tryb strict, logowanie, idempotencja, dry-run, czytelne kody wyjścia i komunikat użycia. Powtórka całego materiału i przygotowanie do egzaminu próbnego. ćwiczenie

Python dla DevOps od zera do bohatera

Skrypty, automatyzacja, API i własne narzędzia CLI — Python jako narzędzie pracy administratora, nie język aplikacji webowych

Program i zapis
Rozwiń program — 20 lekcji, ok. 22 h
  1. Dlaczego Python w DevOps i pierwszy skrypt Kiedy Bash przestaje wystarczać i dlaczego kolejnym krokiem jest Python, a nie Perl czy Go. Interpreter, python3 kontra python, uruchamianie skryptu, shebang i prawa wykonywania. Piszesz i uruchamiasz pierwszy skrypt — od razu w konsoli, tak jak będziesz pracować naprawdę. Bezpłatny podgląd ćwiczenie
  2. Zmienne, typy i f-stringi: wszystko z zewnątrz jest tekstem Typy int, float, str, bool i None, konwersje oraz f-stringi do budowania komunikatów. Pułapka numer jeden w skryptach: zmienne środowiskowe i argumenty zawsze przychodzą jako string, więc porównanie "8080" == 8080 po cichu daje False i skrypt podejmuje złą decyzję. ćwiczenie
  3. Listy, słowniki, zbiory, krotki — i kiedy które Cztery podstawowe struktury danych z kryterium wyboru: lista gdy kolejność, słownik gdy klucz-wartość, zbiór gdy unikalność i różnice, krotka gdy rekord, który ma się nie zmieniać. Do tego dict.get() zamiast KeyError o trzeciej w nocy i test przynależności in, który na liście robi się wolny. ćwiczenie
  4. Pętle, warunki i comprehensions for, while, range, enumerate i zip — czyli iterowanie bez liczników z C. List i dict comprehensions: kiedy skracają kod, a kiedy robią z niego szaradę. Pułapka produkcyjna: usuwanie elementów z listy w trakcie iterowania po niej gubi co drugi element i nie zgłasza żadnego błędu. ćwiczenie
  5. Funkcje: argumenty, *args/**kwargs i pułapka mutowalnego domyślnego Argumenty pozycyjne, nazwane, wartości domyślne oraz *args i **kwargs — czyli jak pisać funkcje, które da się wygodnie wołać. Gwóźdź programu: def f(hosts=[]) tworzy JEDNĄ listę współdzieloną między wywołaniami, przez co funkcja pamięta dane z poprzednich uruchomień. Klasyk, który wychodzi dopiero na produkcji. ćwiczenie
  6. Moduły i pakiety: skrypt rośnie, kod się dzieli import, rozbijanie skryptu na moduły, pakiet z __init__.py oraz idiom if __name__ == "__main__" — dzięki któremu plik da się i uruchomić, i zaimportować w testach. Pułapka: plik nazwany json.py albo requests.py przykrywa bibliotekę i wszystko sypie się komunikatem, który nie wskazuje winnego. ćwiczenie
  7. Środowiska i zależności: uv — oraz pip i venv, które jeszcze spotkasz Dlaczego zależności wymagają izolacji i przypiętych wersji, a potem narzędzie, którym robi się to w 2026: uv — jedno polecenie ogarnia środowisko, pakiety, wersje Pythona i lockfile, w ułamku czasu pip. Do tego pip i venv jako starszy sposób, który zastaniesz w istniejących projektach i CI: musisz czytać oba. Pułapki: sudo pip w systemowym Pythonie i zależności bez wersji, przez które na serwerze działa inny kod niż u ciebie. ćwiczenie
  8. Pliki i pathlib: czytanie, pisanie i ścieżki bez sklejania stringów open z blokiem with, jawne encoding="utf-8", czytanie dużego loga linia po linii zamiast read() ładującego 2 GB do pamięci. pathlib zamiast sklejania ścieżek plusami: łączenie ukośnikiem, glob, exists, mkdir(parents=True). Ścieżki, które działają niezależnie od katalogu, z którego uruchomiono skrypt. ćwiczenie
  9. Kontrakt skryptu: argumenty, kody wyjścia, stdout i stderr sys.argv, sys.exit i konwencja kodów wyjścia, na której opiera się cron, CI i każdy pipeline. Dane wynikowe idą na stdout, komunikaty diagnostyczne na stderr — pomieszanie ich psuje każdy potok z grep i jq. Do tego os.environ i dlaczego skrypt kończący się kodem 0 mimo błędu to cicha katastrofa w automatyzacji. ćwiczenie
  10. Wyjątki: obsługa błędów bez zamiatania pod dywan try, except, else, finally i łapanie konkretnych wyjątków zamiast wszystkiego naraz. Dlaczego goły except oraz except: pass to najdroższe linie w historii automatyzacji — skrypt raportuje sukces, choć nic nie zrobił. Czytanie tracebacka jak mapy oraz własne wyjątki, gdy narzędzie ma swoje klasy błędów. ćwiczenie
  11. subprocess: uruchamianie poleceń bez shell=True subprocess.run z listą argumentów, check=True, capture_output i timeout — pełna kontrola nad poleceniem systemowym. Pułapka bezpieczeństwa: shell=True ze zmienną od użytkownika to gotowe wstrzyknięcie polecenia; pokazujemy atak i wersję odporną. Plus kiedy shell faktycznie jest potrzebny i jak wtedy nie zrobić sobie krzywdy. ćwiczenie
  12. JSON i YAML: dane i configi bez niespodzianek json.load i json.dumps z indent do czytelnych diffów oraz YAML po stronie wczytywania configów. Pułapki: yaml.load wykonuje obiekty z niezaufanego pliku — zawsze safe_load; a niecytowane wartości typu no, on czy off YAML po cichu zamienia w bool, co położyło niejeden config (tzw. problem Norwegii). ćwiczenie
  13. requests: API, timeouty i retry GET i POST, nagłówki, token w Authorization, response.json() i raise_for_status. Pułapka, przez którą wisiał niejeden cron: requests bez timeoutu domyślnie czeka w nieskończoność. Retry z wykładniczym backoffem na błędy 5xx i sieciowe — ale nigdy ślepo na 4xx — oraz Session do wielu wywołań. ćwiczenie
  14. Wyrażenia regularne: logi, które nie parsują się same re.search, re.match, re.findall, grupy nazwane i surowe stringi r"...". Pułapki: zachłanne .* pożerające pół linii, niewyescapowana kropka w adresie IP dopasowująca za dużo, różnica między match a search. I uczciwa granica: kiedy wystarczy split, a kiedy regex naprawdę jest właściwym narzędziem. ćwiczenie
  15. datetime i czas: UTC albo płacz Naiwny kontra świadomy datetime, timezone.utc, epoch, parsowanie ISO 8601 i arytmetyka na timedelta. Pułapki: porównanie czasu naiwnego ze świadomym rzuca wyjątek, serwery w różnych strefach przesuwają logi o godziny, a przestawienie zegara na czas letni psuje harmonogramy liczone na czasie lokalnym. ćwiczenie
  16. logging zamiast print Poziomy DEBUG, INFO, WARNING, ERROR, format z timestampem i nazwą modułu, logger per moduł i logi diagnostyczne na stderr. Dlaczego print w narzędziu produkcyjnym to dług: nie da się go wyciszyć, nie ma poziomów ani czasu, a miesza się z danymi wynikowymi. Sterowanie gadatliwością bez zmiany kodu. ćwiczenie
  17. argparse: z tego skryptu korzysta już cały zespół Argumenty pozycyjne i opcje, typy i wartości domyślne, subkomendy jak w git oraz automatyczny --help, którego nie trzeba utrzymywać ręcznie. Wzorce dojrzałego narzędzia: --dry-run pokazujący co by się stało i --verbose podpięty pod logging. Moment, w którym skrypt zaczyna wyglądać jak narzędzie. ćwiczenie
  18. Dekoratory i type hints: podstawy, które podnoszą jakość Dekorator jako funkcja opakowująca funkcję: retry, mierzenie czasu, proste cache — z functools.wraps, żeby nie zgubić nazwy i docstringa. Type hints w sygnaturach: co dają w edytorze, Optional dla wartości, których może nie być, oraz sprawdzanie typów narzędziem mypy lub szybszym ty. Bez teorii typów — tyle, ile realnie podnosi jakość narzędzi. ćwiczenie
  19. pytest i ruff: jakość, która łapie wpadkę przed produkcją Struktura testów, goły assert, parametrize dla wielu przypadków, tmp_path do testów na plikach i monkeypatch do udawania odpowiedzi API bez sieci. Co testować w narzędziu DevOps — parsowanie, decyzje, przypadki brzegowe — a czego nie ma sensu. Do kompletu ruff: linter i formatter w jednym, który zastąpił black, flake8 i isort — ruff check wyłapuje błędy w milisekundy, zanim zrobi to produkcja. ćwiczenie
  20. Projekt końcowy: eksporter metryk, któremu ufa zespół Składamy cały kurs w jedno narzędzie: zbieranie danych z systemu, parsowanie, wystawienie metryk w formacie Prometheusa, argparse, logging, obsługa błędów, zależności przypięte lockfilem uv i testy. Na koniec rozliczenie tematu kursu: co odróżnia skrypt jednorazowy od narzędzia, któremu ufa zespół — przewidywalne kody wyjścia, idempotencja, --dry-run, logi zamiast printów, testy i README, dzięki którym narzędzie przeżyje twój urlop. ćwiczenie

Ansible od zera do bohatera

Automatyzacja i zarządzanie konfiguracją — od ręcznego SSH do idempotentnej floty serwerów

Program i zapis
Rozwiń program — 20 lekcji, ok. 15 h
  1. Zarządzanie konfiguracją i idempotencja — dlaczego ręczne SSH to dług Czym jest configuration drift i serwery-płatki śniegu, których nikt nie umie odtworzyć. Deklaratywne opisywanie stanu zamiast listy kroków. Idempotencja jako kontrakt: to samo polecenie uruchomione sto razy daje ten sam stan. Dlaczego skrypt bashowy w pętli po SSH to nie jest zarządzanie konfiguracją i co dokładnie znaczą statusy ok, changed, failed i skipped. Bezpłatny podgląd
  2. Architektura Ansible — agentless, SSH, model push Control node i managed nodes: dlaczego na serwerach nie instaluje się żadnego agenta i wystarczy SSH plus Python. Model push kontra pull i konsekwencje obu. Różnica między ansible-core a paczką ansible z kolekcjami — to rozróżnienie wróci przy collections. Instalacja przez pipx, plik ansible.cfg i jego kolejność wyszukiwania (pułapka: config z katalogu bieżącego wygrywa z globalnym).
  3. Inventory — mapa Twojej floty Inventory statyczne w INI i YAML, grupy i grupy grup (children), zmienne przypisane do hostów i grup, katalogi host_vars i group_vars. Grupa specjalna all oraz localhost implicit. Inventory dynamiczne: pluginy (aws_ec2, proxmox) i po co istnieją, gdy flota żyje. Diagnostyka: ansible-inventory --list i --graph zanim cokolwiek uruchomisz.
  4. Polecenia ad-hoc i moduły — FQCN od pierwszego dnia Pierwszy kontakt z wykonaniem: ansible all -m ansible.builtin.ping. Czym jest moduł i dlaczego moduły są idempotentne z natury (deklarujesz stan, moduł decyduje, czy jest coś do zrobienia). FQCN — Fully Qualified Collection Names: dlaczego piszemy ansible.builtin.copy zamiast copy i co się psuje przy krótkich nazwach, gdy w grze jest wiele kolekcji. Przegląd modułów pierwszej potrzeby: package, service, copy, file, user.
  5. Pierwszy playbook — YAML bez niespodzianek Anatomia playbooka: play, hosts, become, lista tasków, name jako dokumentacja. Pułapki YAML, na których wykłada się każdy początkujący: wcięcia spacjami (nigdy tabulatorami), łańcuchy zaczynające się od {{ }} wymagają cudzysłowów, yes/no/on/off interpretowane jako boolean, liczby z zerem wiodącym. Uruchamianie: ansible-playbook, czytanie wyniku per task i per host, PLAY RECAP. Bezpłatny podgląd
  6. Zmienne i precedencja — kto tu w końcu wygrywa Definiowanie zmiennych: vars w playu, vars_files, group_vars, host_vars, zmienne z inventory, extra vars (-e). Precedencja ma formalnie 22 poziomy, ale w praktyce trzeba pamiętać kilka reguł: defaults roli przegrywają prawie ze wszystkim, host_vars biją group_vars, a -e bije wszystko. Pułapka group_vars dla grup nadrzędnych i potomnych. Debugowanie zmiennych przez ansible.builtin.debug zamiast zgadywania.
  7. Facts — co Ansible wie o Twoich hostach Zbieranie faktów przy starcie playa: skąd bierze się ansible_facts, przegląd najużyteczniejszych (ansible_os_family, ansible_distribution, ansible_default_ipv4, ansible_processor_vcpus). Kiedy wyłączyć gather_facts: false dla szybkości i co wtedy przestaje działać. Moduł ansible.builtin.setup z filtrem. Custom facts: pliki w /etc/ansible/facts.d jako sposób, by host sam mówił o sobie (np. wersja wdrożonej aplikacji).
  8. Warunki when — taski, które wiedzą, kiedy się wykonać Składnia when: surowe wyrażenie Jinja2 bez klamerek (częsty błąd: when: "{{ var }}"). Łączenie warunków listą (AND) i operatorem or. Testy: is defined, is not defined, porównania z faktami. Status skipped w wynikach i dlaczego to nie błąd. Warunek na wyniku poprzedniego taska przez register — pierwsze spotkanie ze zmiennymi rejestrowanymi.
  9. Pętle loop — jeden task, wiele elementów loop z listą prostą i listą słowników, zmienna item, dostęp item.name / item.state. Czytelność wyników przez loop_control z label. Pętla po słowniku przez filtr dict2items. Dlaczego with_items to składnia legacy i jak przepisać ją na loop. Pułapka: pętla po tasku package bywa wolniejsza niż podanie listy pakietów bezpośrednio w name — moduł umie przyjąć listę.
  10. Handlery i notify — restart tylko wtedy, gdy trzeba Po co istnieją handlery: usługę restartujemy tylko, gdy konfiguracja faktycznie się zmieniła. Mechanika, którą trzeba znać na pamięć: handler odpala się dopiero na końcu playa, tylko raz, i tylko jeśli task, który go notyfikował, zakończył się jako changed. Pułapki: playbook padł przed końcem — handler nie ruszył (ratunek: --force-handlers), literówka w nazwie handlera wykrywana dopiero w trakcie. Wymuszenie natychmiastowego uruchomienia przez ansible.builtin.meta: flush_handlers i temat listen.
  11. Szablony Jinja2 — generowanie configów per host Moduł ansible.builtin.template: jeden szablon .j2, różne pliki wynikowe na każdym hoście. Interpolacja zmiennych i faktów, filtry (default, upper, join, to_nice_yaml), warunki i pętle wewnątrz szablonu. Konwencja komentarza ansible_managed w nagłówku — sygnał 'nie edytuj ręcznie'. Pułapka: brak filtra default przy niezdefiniowanej zmiennej wywala cały task, a validate przy configach usług ratuje przed wdrożeniem zepsutego pliku.
  12. Role — reużywalne klocki zamiast tysiąclinijkowego playbooka Standardowa struktura roli: tasks, handlers, templates, files, defaults, vars, meta — i po co ta konwencja (Ansible sam wie, gdzie szukać). Generowanie szkieletu przez ansible-galaxy role init. Różnica defaults kontra vars w roli (precedencja wraca!). Wywołanie roli z playa i przekazywanie parametrów. Ansible Galaxy jako źródło gotowych ról — oraz zasada: przeczytaj kod roli, zanim wpuścisz ją na swoje serwery.
  13. Tags i sterowanie wykonaniem — uruchamiaj tylko to, co trzeba Tagowanie tasków i całych ról, uruchamianie wycinka przez --tags i wykluczanie przez --skip-tags. Tagi specjalne always i never. Pułapka: przy --tags taski bez pasującego tagu są pomijane w całości — łatwo pominąć task przygotowujący zmienne, od którego zależy reszta. Zawężanie hostów przez --limit, wznawianie od miejsca awarii przez --start-at-task i listowanie planu przez --list-tasks.
  14. Obsługa błędów — failed_when, changed_when, block/rescue Kiedy Ansible uznaje task za failed i jak to przedefiniować przez failed_when (np. narzędzie zwraca kod 2 przy 'nic do zrobienia'). changed_when jako uczciwe raportowanie zmian. Dlaczego ignore_errors to prawie zawsze zamiatanie problemu pod dywan. Struktura block/rescue/always: transakcyjne podejście do grupy tasków. Kontrola awarii na skalę floty: any_errors_fatal i max_fail_percentage.
  15. Sekrety pod kontrolą — ansible-vault Hasła i klucze nie mają prawa leżeć plaintextem w repozytorium. ansible-vault create/encrypt/edit/view, szyfrowanie pojedynczej wartości przez encrypt_string, uruchamianie z --ask-vault-pass i --vault-password-file. Vault-id, gdy środowisk i haseł jest więcej. Praktyki: co szyfrować (wartości, nie całe pliki z nazwami zmiennych — inaczej grep nic nie znajdzie), skąd brać hasło vault w CI i dlaczego commit sekretu do Gita to incydent, a nie wpadka.
  16. Idempotencja w praktyce — dlaczego command i shell psują wszystko ansible.builtin.command i ansible.builtin.shell zawsze raportują changed, bo Ansible nie wie, co zrobiła Twoja komenda — po dziesięciu takich taskach raport przestaje cokolwiek znaczyć. Różnica między command a shell i dlaczego shell to większe ryzyko. Naprawa w trzech krokach: parametry creates/removes, uczciwe changed_when na podstawie wyniku, a docelowo zamiana na dedykowany moduł. Zasada: command/shell to ostatnia deska ratunku, nie domyślne narzędzie.
  17. Check mode i --diff — zobacz zmiany, zanim je wdrożysz Uruchomienie z --check: Ansible raportuje, co by się zmieniło, nie zmieniając niczego. --diff pokazuje różnice w plikach linia po linii — duet --check --diff to standardowy rytuał przed wdrożeniem na produkcję. Ograniczenia, o których trzeba wiedzieć: taski command nie wykonują się w check mode (chyba że check_mode: false), a task zależny od wyniku poprzedniego może w symulacji skłamać. Weryfikacja stanu po wdrożeniu przez ansible.builtin.assert.
  18. ansible-lint — jakość playbooków, zanim zobaczy je produkcja ansible-lint jako strażnik standardów: wymusza FQCN, nazwy tasków, jawne stany modułów, changed_when przy command/shell, wykrywa składnię legacy i ryzykowne konstrukcje. Profile od basic do production — jak podnosić poprzeczkę stopniowo w istniejącym projekcie. Czytanie wyników: reguła, ważność, ścieżka. Wyjątki przez noqa tylko z komentarzem dlaczego. Lint w CI jako bramka: playbook, który nie przechodzi lintu, nie idzie dalej.
  19. Collections i execution environments — koniec z „u mnie działa" Ansible po podziale monolitu: ansible-core zawiera tylko ansible.builtin, reszta modułów żyje w kolekcjach (community.general, ansible.posix, amazon.aws). Deklarowanie zależności w requirements.yml i instalacja przez ansible-galaxy collection install. Execution environments: obraz kontenera z ansible-core, kolekcjami i zależnościami Pythona — identyczne środowisko na laptopie i w CI. Budowanie przez ansible-builder, uruchamianie przez ansible-navigator run — nowy interfejs obok klasycznego ansib
  20. Organizacja dużego projektu i praktyki produkcyjne Layout repozytorium, który skaluje się z flotą: osobne inventory per środowisko (prod/staging), group_vars i host_vars przy inventory, katalog roles, requirements.yml, ansible.cfg w repo. Rolling update przez serial i bezpiecznik max_fail_percentage — aktualizacja floty bez wyłączania wszystkiego naraz. Pipeline produkcyjny: ansible-lint, syntax-check, --check --diff na stagingu, wdrożenie z najnowszego zielonego pipeline'u. Podsumowanie zasad: idempotencja zawsze, FQCN wszędzie, sekrety w vault

Terraform i OpenTofu od zera do bohatera

Infrastructure as Code, której nie boisz się zrobić apply — OpenTofu-first, Terraform-aware, zgodnie z rynkiem 2026

Program i zapis
Rozwiń program — 20 lekcji, ok. 26 h
  1. Czym jest Infrastructure as Code i po co ci ona Dlaczego klikanie infrastruktury w konsoli nie skaluje się i prędzej czy później kończy awarią, której nikt nie umie odtworzyć. Podejście deklaratywne kontra imperatywne: opisujesz stan docelowy, narzędzie samo wylicza kroki. Pierwsze spotkanie z pojęciem dryfu — rzeczywistość, która odjechała od kodu. Mapa narzędzi IaC i miejsce Terraforma/OpenTofu na niej. Bezpłatny podgląd
  2. Terraform kontra OpenTofu: jedna składnia, dwa narzędzia Historia, którą musisz znać na rozmowie rekrutacyjnej: zmiana licencji Terraforma na BSL w 2023, fork OpenTofu pod Linux Foundation, przejęcie HashiCorp przez IBM. Dlaczego w 2026 OpenTofu to bezpieczny domyślny wybór dla nowych projektów i co realnie różni oba narzędzia (szyfrowanie state, tempo wydań), a co jest identyczne (CLI, HCL, providery). Instalacja obu narzędzi i zarządzanie wersjami.
  3. Pierwszy zasób: init, plan, apply Struktura projektu: blok terraform, required_providers, blok provider, pierwszy blok resource. Cykl życia konfiguracji: tofu init (co powstaje w katalogu .terraform i po co jest plik lock), tofu plan, tofu apply, tofu destroy. Adres zasobu jako jego tożsamość. Pierwszy zasób powstaje, żyje w stanie i ginie — kontrolowanie tego cyklu to fundament wszystkiego dalej.
  4. HCL: bloki, argumenty i typy danych Anatomia HCL: bloki, etykiety, argumenty, bloki zagnieżdżone. Typy: string, number, bool, list, map, object i kiedy którego używać. Komentarze, konwencje nazewnicze, układ plików w katalogu (main.tf, variables.tf, outputs.tf — konwencja, nie wymóg). Narzędzia higieny kodu: tofu fmt i tofu validate jako pierwsza linia obrony przed literówką, która poszłaby na produkcję.
  5. Zmienne i outputy: parametryzacja konfiguracji Blok variable: type, default, description, validation. Skąd zmienna bierze wartość i w jakiej kolejności: default, terraform.tfvars, pliki -var-file, zmienne środowiskowe TF_VAR_, flaga -var — precedencja, którą trzeba znać, bo błędne założenie o niej to klasyczny sposób na apply z niewłaściwą wartością. Blok output: eksponowanie wartości na zewnątrz, flaga sensitive.
  6. Wyrażenia, funkcje i tofu console Interpolacja i referencje między zasobami. Operator warunkowy, for-expressions na listach i mapach, operator splat. Najczęściej używane funkcje wbudowane: format, join, lookup, merge, try. Polecenie tofu console jako laboratorium do testowania wyrażeń bez dotykania infrastruktury. Wzmianka o funkcjach definiowanych przez providery — nowość dostępna w OpenTofu i Terraformie, z różnicami w tempie adopcji.
  7. Providers, resources i data sources Provider jako wtyczka tłumacząca HCL na API świata: rejestr providerów, ograniczenia wersji (~>, >=), plik .terraform.lock.hcl i dlaczego commituje się go do repo. Różnica między rejestrem OpenTofu a Terraform Registry — i dlaczego dla użytkownika jest w praktyce niewidoczna. Data sources: czytanie istniejącego świata zamiast hardkodowania wartości. Alias providera dla wielu instancji.
  8. Czytanie planu: najważniejsza umiejętność w IaC Plan to jedyna zapora między tobą a skasowaną produkcją. Symbole +, -, ~ oraz -/+ (destroy and replace) i fraza forces replacement — miejsce, w które patrzysz zawsze. Wartości known after apply. Zapisywanie planu do pliku flagą -out i po co to CI/CD. Flaga -detailed-exitcode. Zasada niepodlegająca negocjacji: nieprzeczytany plan to nieznana liczba zasobów do skasowania. Bezpłatny podgląd
  9. Zależności: graf, kolejność i depends_on Skąd narzędzie wie, co stworzyć najpierw: zależności niejawne wynikające z referencji między zasobami i graf skierowany budowany z kodu. Kolejność przy tworzeniu i odwrotna przy niszczeniu. Argument depends_on — kiedy jest naprawdę potrzebny (zależność niewidoczna w argumentach), a kiedy jest objawem złego projektu. Cykle zależności i jak czytać błąd o nich.
  10. State: anatomia świętego pliku Plik terraform.tfstate od środka: serial, lineage, atrybuty zasobów — w tym sekrety zapisane plaintext. State jako jedyna pamięć narzędzia: mapowanie między kodem a światem. Dlaczego ręczna edycja stanu to proszenie się o katastrofę i jakie polecenia istnieją zamiast niej: tofu state list, tofu state show, tofu show. Co się dzieje, gdy stan zginie — i dlaczego to nie jest pytanie teoretyczne.
  11. Remote state, blokady i szyfrowanie stanu Stan lokalny kończy się w momencie, gdy do repo dołącza druga osoba. Backendy zdalne i migracja stanu. State locking: co się dzieje, gdy dwa apply ruszą równocześnie bez blokady, i jak działa force-unlock (oraz kiedy jego użycie to błąd). Natywne szyfrowanie state w OpenTofu (blok encryption) — funkcja, której Terraform nie ma i sztandarowy argument za OpenTofu w 2026.
  12. Dryf: gdy rzeczywistość odjeżdża od kodu Skąd bierze się dryf: ręczna poprawka o 3 w nocy, automat skalujący, awaria po stronie dostawcy. Mechanizm refresh i tryb tofu plan -refresh-only jako bezpieczny audyt bez ryzyka zmian. Dwa świadome wyjścia z dryfu: zaakceptować rzeczywistość (poprawić kod i przyjąć stan) albo ją nadpisać (apply przywracający stan z kodu). Regularny plan jako audyt infrastruktury — praktyka, która wyłapuje ręczne zmiany, zanim zaskoczą przy wdrożeniu.
  13. Pętle: count i for_each — kiedy które Meta-argumenty count z indeksem numerycznym i for_each z mapą lub setem: adresowanie instancji, składnia referencji. Klasyczna pułapka, która skasowała niejedną produkcję: usunięcie elementu ze środka listy przy count przesuwa indeksy i plan chce wymienić wszystkie kolejne zasoby. Dlaczego for_each z kluczami tekstowymi jest odporny na ten problem i powinien być domyślnym wyborem. Konwersja istniejącej konfiguracji z count na for_each.
  14. Moduły: pisanie, użycie i rejestr Moduł jako funkcja dla infrastruktury: katalog z variables, main i outputs. Wywołanie modułu, przekazywanie wejść, odczyt wyjść, adresy module.*. Źródła: ścieżka lokalna, rejestr publiczny, git — i wersjonowanie, bez którego moduł współdzielony staje się tykającą bombą. Kompozycja root module z modułów. Kiedy moduł to przesada i jedna warstwa abstrakcji za dużo.
  15. Środowiska dev/stage/prod: workspaces i alternatywy Polecenie tofu workspace: osobny stan na workspace przy wspólnym kodzie, referencja terraform.workspace w konfiguracji. Kiedy workspaces wystarczają (środowiska bliźniacze), a kiedy są pułapką: prod w tym samym backendzie co dev, jeden błędny workspace przed apply. Alternatywy używane w poważnych zespołach: osobne katalogi i osobne backendy per środowisko plus pliki tfvars. Twarda zasada: zawsze wiesz, w które środowisko celujesz, zanim zatwierdzisz.
  16. Sekrety: czego nigdy nie commitować Trzy miejsca, którymi sekret wycieka z IaC: kod w repo, pliki tfvars i — najczęściej zapominane — state, w którym Terraform trzyma wartości plaintext. Flaga sensitive na zmiennych i outputach oraz jej granice (maskuje wyjście, nie zawartość stanu). Co należy do .gitignore. Dostarczanie sekretów przez zmienne środowiskowe i menedżery sekretów (Vault, SOPS — wzmianka). Szyfrowanie state w OpenTofu jako domknięcie ostatniej warstwy.
  17. Import: obejmij kodem to, co wyklikane Realia brownfield: w większości firm infrastruktura istniała na długo przed IaC. Polecenie tofu import kontra deklaratywne bloki import (od wersji 1.5) — dlaczego bloki wygrywają: przechodzą code review i są powtarzalne. Generowanie konfiguracji z istniejących zasobów przez tofu plan -generate-config-out. Pułapka importu: zasób w stanie z niedopasowaną konfiguracją to plan, który chce „naprawiać” produkcję. Definicja ukończonego importu: plan bez zmian.
  18. Refaktoryzacja: moved, removed i state mv bez ofiar Zmiana nazwy zasobu albo przeniesienie go do modułu to dla planu destroy plus create — chyba że powiesz narzędziu, iż to ten sam zasób. Bloki moved: deklaratywne, wersjonowane, przechodzą review. Polecenie tofu state mv: ręczne, natychmiastowe, bez śladu w repo — i przez to ryzykowne w zespole. Blok removed i tofu state rm: wyjęcie zasobu spod zarządzania bez niszczenia go. Żelazna zasada refaktoryzacji: po każdym kroku plan ma pokazywać zero zmian.
  19. CI/CD dla IaC: plan w PR, apply za bramką Wzorzec, który stosuje każdy dojrzały zespół: pipeline uruchamia fmt, validate i plan przy pull requeście, plan jako artefakt (-out) trafia do review, a apply wykonuje się wyłącznie z zatwierdzonego pliku planu, za ręczną bramką i tylko z chronionej gałęzi. Problem stale plan: świat zmienił się między planem a apply. Flaga -detailed-exitcode do wykrywania zmian w automatach. Przegląd narzędzi klasy TACOS: Atlantis, Spacelift, env0 — wzmianka, gdzie kończy się goły pipeline.
  20. Pułapki produkcyjne i dobre praktyki: apply bez strachu Katalog rzeczy, które naprawdę kasują produkcję: niezauważone forces replacement na bazie danych, apply w złym workspace, kaskada count, destroy odpalone w złym katalogu. Obrona w warstwach: lifecycle prevent_destroy i create_before_destroy, ignore_changes, ograniczanie blast radius przez dzielenie stanu na mniejsze niezależne części, flaga -target jako narzędzie awaryjne, nie codzienne. Checklist produkcyjny kursu i przygotowanie do egzaminu próbnego.

SSH od zera do bastionu

Klucze, tunele i konfiguracja, dzięki którym przestajesz wpisywać hasła i zaczynasz pracować jak inżynier.

Program i zapis
Rozwiń program — 20 lekcji, ok. 14 h
  1. SSH: zdalna powłoka bez tajemnic Czym jest SSH i co dzieje się między klientem a serwerem: szyfrowany kanał, uwierzytelnienie serwera (fingerprint) i uwierzytelnienie użytkownika. Pierwsze logowanie hasłem, prompt zdalnej maszyny, `exit`. Bezpłatny podgląd ćwiczenie
  2. known_hosts: dlaczego SSH pyta „are you sure?” Fingerprint serwera, plik `~/.ssh/known_hosts` i ostrzeżenie REMOTE HOST IDENTIFICATION HAS CHANGED. Kiedy to atak, a kiedy po prostu reinstalacja maszyny — i jak wtedy postąpić bez kasowania całego pliku. ćwiczenie
  3. Para kluczy: prywatny zostaje, publiczny jedzie `ssh-keygen -t ed25519`: co powstaje, czym różni się `id_ed25519` od `id_ed25519.pub` i dlaczego ed25519 wyparł RSA. Passphrase — kiedy ma sens, a kiedy przeszkadza. Fingerprint klucza. ćwiczenie
  4. authorized_keys: jak serwer Cię rozpoznaje `ssh-copy-id` i co dokładnie robi: dopisuje klucz publiczny do `~/.ssh/authorized_keys` na serwerze. Ręczna alternatywa, wiele kluczy w pliku, oddzielne klucze dla różnych maszyn. ćwiczenie
  5. Uprawnienia: 600, 700 i „UNPROTECTED PRIVATE KEY FILE” Dlaczego OpenSSH odmawia użycia klucza z prawami 644 i czemu serwer po cichu ignoruje `authorized_keys` w katalogu zapisywalnym dla grupy. Właściwe tryby: 700 dla `~/.ssh`, 600 dla klucza prywatnego. ćwiczenie
  6. ssh-agent: hasło do klucza raz na sesję Po co agent, gdy klucz ma passphrase: `ssh-agent`, `ssh-add`, `ssh-add -l`. Czas życia kluczy (`-t`), agent w systemd/keychain i dlaczego `ssh-add` bez agenta nic nie robi. ćwiczenie
  7. ~/.ssh/config: koniec z długimi komendami Aliasy hostów: `Host`, `HostName`, `User`, `Port`, `IdentityFile`. Wildcardy i `Host *`, kolejność dopasowań, `ServerAliveInterval`. Jedno `ssh prod` zamiast komendy na pół ekranu. ćwiczenie
  8. ProxyJump: przez bastion do maszyn bez publicznego IP Serwery w sieci prywatnej dostępne tylko przez bastion: `ssh -J`, dyrektywa `ProxyJump` w configu i czym różni się od starego `ProxyCommand`. Dlaczego to bezpieczniejsze niż trzymanie klucza na bastionie. ćwiczenie
  9. scp: kopiowanie w obie strony Składnia `scp źródło cel` z adresem zdalnym, kopiowanie katalogów (`-r`), port (`-P` — wielką literą!) i najczęstszy błąd: pomylona kolejność argumentów. Kiedy scp wystarcza, a kiedy jest złym narzędziem. ćwiczenie
  10. rsync przez SSH: kopiuje tylko to, co się zmieniło `rsync -avz` po kanale SSH, znaczenie ukośnika na końcu ścieżki, `--delete`, `--dry-run` przed każdą groźną synchronizacją. Dlaczego rsync bije scp przy dużych katalogach i wznawianiu transferu. ćwiczenie
  11. Tunel lokalny -L: baza słuchająca na localhost serwera `ssh -L 5432:localhost:5432 user@host` — co oznacza każdy człon i skąd patrzy „localhost". Dostęp do usług zamkniętych na interfejsie pętli zwrotnej bez otwierania ich na świat. ćwiczenie
  12. Tunel zdalny -R: wpuść świat do siebie (ostrożnie) `ssh -R` odwraca kierunek: port na serwerze prowadzi do usługi u Ciebie. Zastosowania (pokaz aplikacji z laptopa, webhook w developmencie) i `GatewayPorts` — dlaczego domyślnie tunel widać tylko z samego serwera. ćwiczenie
  13. SOCKS (-D) i multiplexing: proxy oraz szybsze łączenie `ssh -D 1080` jako proxy SOCKS5 dla przeglądarki. Do tego `ControlMaster`/`ControlPersist`: jedno połączenie współdzielone przez wiele sesji — zauważalne przyspieszenie przy Ansible i skryptach. ćwiczenie
  14. PuTTY i PuTTYgen: klucze w świecie Windows Generowanie klucza w PuTTYgen, format `.ppk` kontra OpenSSH, wklejanie klucza publicznego do `authorized_keys`, zapisywanie sesji i Pageant jako odpowiednik ssh-agenta. Ze zrzutami ekranu krok po kroku.
  15. MobaXterm i OpenSSH w Windows: wybierz jedno i rób to dobrze MobaXterm: sesje, wbudowany SFTP, przechowywanie kluczy. OpenSSH wbudowany w Windows (`ssh` w PowerShellu, `%USERPROFILE%\.ssh`) i konwersja kluczy `.ppk` ↔ OpenSSH przez PuTTYgen oraz `ssh-keygen`.
  16. sshd_config: co serwer w ogóle akceptuje Najważniejsze dyrektywy: `PermitRootLogin`, `PasswordAuthentication`, `PubkeyAuthentication`, `AllowUsers`, `Port`. Przeładowanie usługi i żelazna zasada: nie zamykaj sobie drzwi, dopóki druga sesja nie potwierdzi, że działa. ćwiczenie
  17. Hardening: klucze zamiast haseł, fail2ban, zmiana portu Co realnie podnosi bezpieczeństwo (klucze, brak roota, ograniczenie użytkowników, fail2ban), a co jest tylko teatrem (sama zmiana portu). Logi prób logowania i czytanie ich ze zrozumieniem. ćwiczenie
  18. Gdy nie działa: -v, -vvv i czytanie komunikatów `ssh -vvv` linia po linii: który klucz został zaproponowany, czy serwer go odrzucił, gdzie kończy się negocjacja. Rozróżnianie `Connection refused`, `Connection timed out`, `Permission denied (publickey)` i `Host key verification failed`. ćwiczenie
  19. Klucze w automatyzacji: CI, deploy keys i agent forwarding Klucz bez passphrase w CI/CD — kiedy to konieczne i jak ograniczyć szkody (`command=` i `from=` w authorized_keys, deploy keys tylko do odczytu). Agent forwarding (`-A`) i dlaczego nie wolno go włączać na cudzym serwerze. ćwiczenie
  20. Projekt: bastion, klucze i tunel do bazy Powtórka całości w jednym zadaniu: konfiguracja klienta z aliasami i przeskokiem przez bastion, uwierzytelnianie kluczem z agenta, tunel do bazy w sieci prywatnej i utwardzony serwer. Przygotowanie do egzaminu próbnego. ćwiczenie

Własne AI na własnej karcie

Od pierwszego modelu uruchomionego w przeglądarce po wyciśnięcie maksimum z karty, którą masz albo dopiero kupujesz.

Program i zapis
Rozwiń program — 18 lekcji, ok. 14 h
  1. Model w Twojej przeglądarce — teraz Uruchamiasz prawdziwy model bez instalowania czegokolwiek i widzisz prędkość na swoim sprzęcie. Bezpłatny podgląd
  2. Co to w ogóle jest ten model Plik z liczbami. Skąd się biorą nazwy 7B i 27B i co z nich wynika dla Ciebie.
  3. Pierwszy model na Twojej karcie Silnik, pobranie modelu, pierwsze pytanie. Koniec lekcji to działająca instalacja lokalna.
  4. Ile naprawdę masz pamięci Karta ma 12 GB, do dyspozycji masz mniej. Co zjada pulpit i jak to odzyskać.
  5. Kwantyzacja: jak 27 miliardów mieści się w 24 GB Po co obcina się liczby, co się przy tym traci i gdzie leży granica sensu.
  6. Co się zmieści na Twojej karcie Wagi plus kontekst plus reszta. Liczymy budżet pamięci dla Twojego sprzętu.
  7. Kupujesz kartę? Od budżetowej do zawodowej Co dostaniesz za 1500, 2500, 5000 i 10 000 zł. Używane karty i czego przy nich szukać.
  8. Nie wstaje: czytanie komunikatów Pięć najczęstszych błędów i co naprawdę znaczą. Brak pamięci rzadko znaczy kup lepszą kartę.
  9. Rozmowa też zajmuje pamięć Dlaczego model wstaje, a wywala się po dwudziestu minutach. Dobieranie długości kontekstu.
  10. Działa, ale wolno Co tu właściwie trwa: liczenie pytania czy pisanie odpowiedzi. I co da się z tym zrobić.
  11. Wzrok, głos i inne dodatki Model patrzący na obrazki potrzebuje drugiego modelu obok. Ile to kosztuje i kiedy odpuścić.
  12. Zmierz u siebie i nie skłam sobie Własny pomiar i trzy sposoby, żeby wyszedł nieprawdziwy. Dlaczego cudze benchmarki są bezużyteczne.
  13. Formaty i silniki: co daje ile Ten sam model, inny format i inny silnik. Kiedy różnica to 40 procent, a kiedy 160.
  14. Długa pamięć czy kilka rozmów naraz Ta sama pamięć karty: albo bardzo długi kontekst, albo kilka sesji równolegle.
  15. Kilka modeli, jeden komputer Przełączanie bez ręcznego ubijania, zwalnianie karty na czas gry, model do kodu obok modelu do rozmowy.
  16. Podłącz to do czegoś Model w edytorze kodu, w oknie czatu i w skrypcie. Jeden wspólny sposób dostępu zamiast pięciu.
  17. Po co w ogóle lokalnie Prywatność, koszty, brak limitów. Uczciwie też o tym, czego lokalnie nie zrobisz lepiej.
  18. Co dalej Dokąd to rośnie i jak nie utknąć na konfiguracji sprzed roku.

Dla kogo to jest

Wchodzisz w DevOps

Umiesz Linuksa na tyle, żeby poruszać się w konsoli. Reszty nauczysz się tutaj: od pierwszego kontenera i pierwszej metryki po system, który sam wstaje z kolan.

Idziesz po certyfikat

Egzaminy próbne w formacie prawdziwej certyfikacji (PCA, dalej KCNA). Ćwiczenia w konsoli są bliżej egzaminu niż przeklikiwanie testów ABCD.

Nosisz pager

Masz już monitoring, ale budzi bez powodu albo milczy, kiedy trzeba. Lekcje o `for`, kardynalności i szablonach powiadomień są dokładnie o tym.

Zacznij od bezpłatnej lekcji

Pierwsza lekcja jest otwarta — przeczytaj ją i sprawdź, czy ten sposób tłumaczenia Ci odpowiada. Reszta kursu kosztuje 120 zł, dostęp bezterminowy.

Czytaj pierwszą lekcję Zobacz pełny program