Aurora Kursy

KursyAnsible od zera do bohatera

Ansible od zera do bohatera

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

od zera do bohatera 20 lekcji ok. 15 h 169 zł

Program

  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. 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. 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 🔒

Konfigurujesz serwery ręcznie po SSH? Każda maszyna jest odrobinę inna, nikt nie pamięta, co i kiedy zostało zmienione, a odtworzenie środowiska po awarii to loteria. Ten kurs uczy innego podejścia: opisujesz pożądany stan w wersjonowanych playbookach, a Ansible doprowadza do niego całą flotę — powtarzalnie i bez niespodzianek. Zaczynamy od fundamentu, którego większość kursów nie tłumaczy porządnie: czym naprawdę jest idempotencja i dlaczego bez niej automatyzacja robi więcej szkody niż pożytku.

Kurs jest nowoczesny — uczymy Ansible takiego, jakim jest dziś, a nie sprzed dekady. Od pierwszej lekcji piszemy FQCN (ansible.builtin.copy, nie copy), korzystamy z kolekcji (collections) i requirements.yml, sprawdzamy jakość playbooków przez ansible-lint, a pod koniec uruchamiamy playbooki w execution environments przez ansible-navigator — dokładnie tak, jak robi się to w środowiskach produkcyjnych w 2026 roku. Po drodze rozbrajamy klasyczne pułapki: precedencję zmiennych, handlery, które się nie odpaliły, oraz taski shell, które łamią idempotencję.

Każdą lekcję ćwiczysz w emulatorze konsoli w przeglądarce: piszesz playbook, uruchamiasz go na symulowanej flocie hostów i widzisz status ok/changed/failed/skipped per task i per host — łącznie z tym, że drugie uruchomienie poprawnego playbooka daje same ok. Każda lekcja kończy się quizem, a cały kurs egzaminem próbnym z 60 pytaniami. Po kursie masz warsztat, z którym utrzymasz konfigurację dziesiątek maszyn w Gicie zamiast w głowie.

Dostęp do kursu

169 zł

Pełny dostęp do wszystkich 20 lekcji, ćwiczeń i sprawdzianów, bezterminowo. Płatność BLIK-iem, przelewem albo kartą — dostęp aktywuje się od razu po zaksięgowaniu.

Kup dostęp — 169 zł Mam kod — załóż konto

Dla zespołu: jeden kod na dowolną liczbę miejsc — rozdajesz go ludziom, zamiast zakładać konta za nich. Napisz na kursy@aurora-tech.pl, ilu osób dotyczy.