Automation | przeqpiciel's site

Ansible w praktyce - piszemy playbooki

przeqpiciel — Sat, 04 Jul 2026 00:00:00 +0000

Wstęp

W poprzednim wpisie o Ansible przygotowaliśmy sobie warsztat: instalacja przez pipx, układ katalogów projektu, plik inventory i pierwsza rola common. Wszystko ładnie, tylko że rola instalująca vim i htop to trochę jak kupić wiertarkę i powiesić na niej ręcznik. Czas w końcu coś tym Ansible zrobić.

W tym wpisie napiszemy wspólnie trzy playbooki, których sam regularnie używam w homelabie. Każdy z nich przy okazji nauczy Cię jednego z mechanizmów, które w poprzedniej części tylko zapowiedziałem: pracy z faktami i warunkami, pętli oraz szablonów Jinja2. Na koniec pokażę Ci jeszcze Ansible Vault, czyli co zrobić z hasłami, żeby nie leżały w repozytorium w plaintext, oraz kilka flag ansible-playbook, które nie raz uratowały mnie przed zrobieniem sobie krzywdy.

Zakładam, że masz już strukturę projektu z poprzedniego wpisu. Jeśli nie - zajrzyj tam najpierw, to dosłownie kilka minut.

Playbook 1: Aktualizacja wszystkich serwerów

Zacznijmy od czegoś, co każdy z nas robi (a przynajmniej powinien robić) regularnie. Ile razy logowałeś się po kolei na każdą maszynę tylko po to, żeby wklepać apt update && apt upgrade? U mnie, przy kilku VM-kach na Proxmoxie i paru VPS-ach, potrafiło to zjeść pół wieczoru. A przecież dokładnie od tego mamy Ansible.

Tworzymy plik playbooks/update.yml:

# playbooks/update.yml
---
- name: Update and upgrade all servers
 hosts: all
 become: yes
 serial: 1

 tasks:
 - name: Update apt cache and upgrade packages
 ansible.builtin.apt:
 update_cache: yes
 upgrade: dist
 autoremove: yes

 - name: Check if reboot is required
 ansible.builtin.stat:
 path: /var/run/reboot-required
 register: reboot_required

 - name: Reboot server if required
 ansible.builtin.reboot:
 msg: "Reboot wykonany przez Ansible po aktualizacji pakietów"
 reboot_timeout: 600
 when: reboot_required.stat.exists

Rozbierzmy to na części, bo dzieje się tutaj kilka ciekawych rzeczy:

serial: 1 - instruuje Ansible, aby przechodził przez hosty pojedynczo, zamiast aktualizować wszystkie naraz. Po co? Wyobraź sobie, że nowa wersja jakiegoś pakietu okazuje się zepsuta. Bez serial położysz wszystkie maszyny jednocześnie. Z serial: 1 problem zauważysz po pierwszej i zdążysz przerwać. Na produkcji ta jedna linijka to różnica między “mieliśmy chwilową degradację” a “mieliśmy awarię”.
upgrade: dist - odpowiednik apt dist-upgrade, czyli aktualizacja z możliwością instalacji nowych zależności. Do wyboru masz też safe (odpowiednik zwykłego apt upgrade) oraz full.
register: reboot_required - zapisuje wynik zadania do zmiennej. Moduł stat sprawdza, czy istnieje plik /var/run/reboot-required - to właśnie ten plik systemy Debianowe tworzą, kiedy aktualizacja (najczęściej jądra) wymaga restartu.
when: reboot_required.stat.exists - warunek. Zadanie rebootu wykona się tylko wtedy, kiedy plik istnieje. To jest właśnie duet register + when, którego będziesz używać nieustannie: jedno zadanie coś sprawdza, drugie reaguje na wynik.
reboot - moduł, który restartuje maszynę i - co najlepsze - sam czeka, aż wróci do życia i będzie osiągalna po SSH. reboot_timeout: 600 daje jej na to 10 minut.

ℹ️

Zwróć uwagę na pełne nazwy modułów, np. ansible.builtin.apt zamiast samego apt jak w poprzednim wpisie. Obie formy działają, ale pełna nazwa (FQCN - Fully Qualified Collection Name) jest obecnie rekomendowana przez dokumentację i jednoznacznie wskazuje, skąd pochodzi moduł. Warto się przyzwyczajać od początku.

Uruchamiamy:

ansible-playbook playbooks/update.yml

I to tyle. Od dziś aktualizacja całego homelabu to jedno polecenie i można iść zrobić herbatę.

Playbook 2: Użytkownicy i klucze SSH, czyli pętle

Drugi scenariusz z życia. Dokładnie z taką sytuacją miałem do czynienia, kiedy po którejś reinstalacji maszyny okazało się, że na trzech serwerach mam użytkownika ze swoim kluczem SSH, na dwóch nie mam, a na jednym jest klucz ze starego laptopa, którego nie widziałem od roku. Spójność konfiguracji, mówili.

Zamiast klepać useradd po serwerach, opiszmy stan docelowy w zmiennych. Do pliku inventory/group_vars/all.yml dodajemy listę:

# inventory/group_vars/all.yml
---
managed_users:
 - name: przeq
 groups: sudo
 ssh_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... przeq@laptop"
 - name: deploy
 groups: ""
 ssh_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... deploy@ci"

Plik w group_vars/all oznacza, że zmienne będą dostępne dla wszystkich hostów z inventory. Gdybyś chciał innych użytkowników tylko na serwerach z grupy web, tworzysz analogicznie group_vars/web.yml - tak jak opisywałem układ katalogów w poprzedniej części.

Teraz playbook playbooks/users.yml:

# playbooks/users.yml
---
- name: Manage users and SSH keys
 hosts: all
 become: yes

 tasks:
 - name: Ensure users exist
 ansible.builtin.user:
 name: "{{ item.name }}"
 groups: "{{ item.groups }}"
 append: yes
 shell: /bin/bash
 state: present
 loop: "{{ managed_users }}"

 - name: Ensure SSH keys are present
 ansible.posix.authorized_key:
 user: "{{ item.name }}"
 key: "{{ item.ssh_key }}"
 state: present
 loop: "{{ managed_users }}"

Nowością jest tutaj loop. Ansible wykona zadanie tyle razy, ile elementów ma lista managed_users, a w każdej iteracji bieżący element będzie dostępny jako item. Dlatego w parametrach odwołujemy się do item.name czy item.ssh_key. Jedna definicja zadania, dowolna liczba użytkowników - dopisanie kolejnego to jedna pozycja na liście w group_vars, a nie kolejna sesja SSH.

Warto też zwrócić uwagę na append: yes w module user. Bez tego parametru Ansible ustawiłby użytkownikowi dokładnie te grupy, które podałeś, usuwając go ze wszystkich pozostałych. Z append: yes grupy są dopisywane. Ten parametr potrafi zaoszczędzić nieprzyjemnych niespodzianek.

⚠️

Moduł authorized_key pochodzi z kolekcji ansible.posix. Jeśli instalowałeś Ansible przez pipx install ansible tak jak w poprzednim wpisie, masz ją już na pokładzie. Jeśli jednak wybrałeś minimalny pakiet ansible-core, doinstalujesz ją poleceniem ansible-galaxy collection install ansible.posix.

Zanim uruchomisz playbook na ostro, sprawdź co się wydarzy:

ansible-playbook playbooks/users.yml --check --diff

O tych dwóch flagach więcej pod koniec wpisu, ale już teraz zdradzę: to najlepsi przyjaciele początkującego (i nie tylko początkującego).

Playbook 3: Szablony Jinja2, czyli MOTD z faktami

Trzeci playbook będzie najprostszy, ale nauczy Cię mechanizmu, na którym opiera się połowa prawdziwych zastosowań Ansible: szablonów. Szablon to plik z dziurami, które Ansible wypełnia zmiennymi. A skoro tak, to wykorzystamy do tego zmienne, które Ansible zbiera zupełnie za darmo - tak zwane fakty.

Fakty (facts) to informacje o hoście, które Ansible zbiera na początku każdego playbooka: nazwa hosta, wersja systemu, adresy IP, ilość RAM i dziesiątki innych. Możesz je podejrzeć poleceniem:

ansible web1 -m setup

Przygotujmy szablon wiadomości powitalnej, którą zobaczysz po zalogowaniu na serwer. Tworzymy plik playbooks/templates/motd.j2:

##################################################
# {{ ansible_facts['hostname'] }}
# System: {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}
# IP: {{ ansible_facts['default_ipv4']['address'] }}
#
# Maszyna zarządzana przez Ansible.
# Zmiany wprowadzone ręcznie zostaną nadpisane!
##################################################

I playbook playbooks/motd.yml, który go rozpropaguje:

# playbooks/motd.yml
---
- name: Deploy MOTD banner
 hosts: all
 become: yes

 tasks:
 - name: Template MOTD file
 ansible.builtin.template:
 src: templates/motd.j2
 dest: /etc/motd
 owner: root
 group: root
 mode: '0644'

Po uruchomieniu playbooka każda maszyna dostanie swój własny, spersonalizowany baner - z własnym hostname, wersją systemu i adresem IP. Ten sam szablon, różne wyniki na każdym hoście. Dokładnie tak samo działa generowanie konfiguracji nginx, konfiguracji agenta Zabbix czy czegokolwiek innego - różnica polega tylko na tym, że zamiast faktów podstawiasz swoje zmienne z group_vars albo defaults roli.

A ostatnia linijka szablonu to nie żart. Jeżeli plik jest zarządzany przez Ansible, to Ansible jest jedynym miejscem, w którym się go edytuje. Ręczna poprawka na serwerze zniknie przy następnym uruchomieniu playbooka - i dobrze, na tym polega utrzymywanie spójności.

ℹ️

Gdy szablonujesz konfigurację usługi (a nie zwykły plik jak MOTD), pamiętaj o dwóch rzeczach z poprzedniego wpisu: dodaj notify wskazujący handler restartujący usługę oraz - jeśli program to umożliwia - parametr validate, np. validate: 'nginx -t -c %s'. Dzięki temu Ansible odrzuci zepsutą konfigurację, zanim ta trafi na swoje miejsce.

Ansible Vault, czyli co z hasłami

Prędzej czy później w Twoich zmiennych pojawi się coś wrażliwego: hasło do bazy, token API, cokolwiek. Trzymanie tego w repozytorium otwartym tekstem to proszenie się o kłopoty. Odpowiedzią Ansible jest Vault - wbudowane szyfrowanie plików ze zmiennymi.

Zanim utworzymy zaszyfrowany plik, mała zmiana organizacyjna. Chcemy trzymać zmienne jawne i zaszyfrowane osobno, a Ansible pozwala zamiast pojedynczego pliku group_vars/all.yml użyć katalogu group_vars/all/ i wczytać z niego wszystkie pliki. Uwaga: nie można mieć obu naraz - plik all.yml i katalog all/ obok siebie skończą się błędem. Dlatego najpierw przenosimy dotychczasowe zmienne:

mkdir inventory/group_vars/all
mv inventory/group_vars/all.yml inventory/group_vars/all/vars.yml

Teraz tworzymy zaszyfrowany plik obok:

ansible-vault create inventory/group_vars/all/vault.yml

Ansible zapyta o hasło, a następnie otworzy edytor. Wpisujemy zmienne jak do każdego innego pliku:

vault_grafana_admin_password: "SuperTajneHaslo123"

Po zapisaniu plik na dysku wygląda tak:

$ANSIBLE_VAULT;1.1;AES256
36613831356362376361643230623232616139383564383936633463323...

Możesz go spokojnie commitować do repozytorium - bez hasła nikt go nie odczyta. W playbookach używasz zmiennej normalnie, natomiast przy uruchamianiu dodajesz flagę:

ansible-playbook playbooks/site.yml --ask-vault-pass

Do edycji zaszyfrowanego pliku służy ansible-vault edit, a do podejrzenia ansible-vault view.

⚠️

Przyjęła się konwencja, aby zmienne z Vault poprzedzać prefixem vault_. Kiedy w playbooku widzisz {{ vault_grafana_admin_password }}, od razu wiesz, gdzie szukać jej definicji i że jest wrażliwa. Drobiazg, a przy większym projekcie robi ogromną różnicę.

Flagi, które uratują Ci skórę

Na koniec obiecany zestaw flag ansible-playbook, których używam praktycznie przy każdym uruchomieniu:

--check - tryb “na sucho”. Ansible przechodzi przez wszystkie zadania i raportuje, co by zmienił, ale niczego nie dotyka. Idealne przed pierwszym uruchomieniem nowego playbooka.
--diff - pokazuje różnice w modyfikowanych plikach, w formacie znanym z git diff. W duecie z --check dostajesz pełny podgląd zmian, zanim się na nie zgodzisz.
--limit web1 - ogranicza wykonanie do wskazanego hosta lub grupy, niezależnie od tego, co playbook ma w hosts. Nowy playbook testuję zawsze najpierw na jednej, najmniej ważnej maszynie.
--tags users - wykonuje tylko zadania oznaczone danym tagiem. Tagi dodajesz do zadania parametrem tags: ['users']. Przy dużym playbooku oszczędza to mnóstwo czasu, bo nie musisz przechodzić przez wszystko, żeby poprawić jedną rzecz.
--syntax-check - błyskawiczna weryfikacja składni playbooka, bez łączenia się z hostami. YAML bywa złośliwy w kwestii wcięć, więc warto odpalać ją nawykowo.

Mój typowy cykl pracy z nowym playbookiem wygląda więc tak:

ansible-playbook playbooks/users.yml --syntax-check
ansible-playbook playbooks/users.yml --check --diff --limit web1
ansible-playbook playbooks/users.yml --limit web1
ansible-playbook playbooks/users.yml

Od składni, przez próbę generalną na jednej maszynie, aż po całą infrastrukturę. Nudno? Może trochę. Ale jeszcze nigdy tym sposobem nie położyłem sobie całego homelabu naraz, a zdarzało mi się to w czasach, kiedy flagi --check używałem wyłącznie od święta.

Podsumowanie

W tym wpisie przeszliśmy od teorii do praktyki:

Playbook aktualizujący wszystkie serwery z kontrolowanym restartem (register, when, serial)
Zarządzanie użytkownikami i kluczami SSH z jednej listy zmiennych (loop, group_vars)
Szablony Jinja2 wypełniane faktami hosta (template, facts)
Szyfrowanie wrażliwych zmiennych z Ansible Vault
Flagi --check, --diff, --limit i --tags, czyli siatka bezpieczeństwa przy każdym uruchomieniu

Te trzy playbooki możesz potraktować jako szkielet i rozbudowywać o własne potrzeby - dorzucić instalację agenta Zabbix do monitoringu, konfigurację WireGuard czy cokolwiek, co do tej pory klepałeś ręcznie. Zasada jest zawsze ta sama: opisujesz stan docelowy, a Ansible martwi się resztą.

W kolejnych krokach warto zerknąć na przenoszenie playbooków do ról (o strukturze ról pisałem w części pierwszej), a docelowo na uruchamianie ich automatycznie z CI. Ale to już materiał na osobny wpis.

Powodzenia w automatyzacji!

Jak zacząć z Ansible

przeqpiciel — Sun, 25 Jan 2026 00:00:00 +0000

Wstęp

Czy zdarzyło Ci się zarządzać wieloma serwerami i ręcznie konfigurować każdy z nich? Możliwe, że już słyszałeś o narzędziach do automatyzacji, ale nie wiedziałeś od czego zacząć. W tym artykule pokażę Ci, jak rozpocząć przygodę z Ansible - jednym z najpopularniejszych narzędzi do automatyzacji konfiguracji i zarządzania infrastrukturą.

Ansible to potężne narzędzie, które pozwala na zarządzanie wieloma serwerami jednocześnie, bez konieczności instalowania agentów na docelowych maszynach. Wystarczy, że masz dostęp SSH do swoich serwerów, a Ansible zrobi resztę. W moim przypadku, kiedy zarządzałem kilkoma serwerami VPS i musiałem na każdym z nich wykonać te same czynności, Ansible okazał się prawdziwym zbawieniem.

Co to jest Ansible?

Ansible to narzędzie do automatyzacji infrastruktury IT, które pozwala na:

Konfigurację serwerów - instalację pakietów, konfigurację usług, zarządzanie plikami
Wdrażanie aplikacji - automatyzację procesu deploymentu
Orkiestrację - zarządzanie wieloma serwerami jednocześnie
Zarządzanie konfiguracją - utrzymanie spójności konfiguracji na wielu maszynach

Główną zaletą Ansible jest to, że działa w modelu “agentless” - nie wymaga instalacji żadnego oprogramowania na docelowych serwerach. Wystarczy Python (który jest domyślnie dostępny na większości systemów Linux) i dostęp SSH.

Ansible używa języka YAML do definiowania zadań, co czyni go bardzo czytelnym i łatwym do zrozumienia. Nawet jeśli nie jesteś programistą, po krótkim czasie będziesz w stanie tworzyć własne playbooki.

Po co używać Ansible?

Wyobraź sobie sytuację: masz pięć serwerów i musisz na każdym z nich:

Zainstalować podstawowe pakiety (curl, git, vim)
Skonfigurować firewall
Zainstalować i skonfigurować nginx
Dodać użytkownika z odpowiednimi uprawnieniami

Bez Ansible, musiałbyś zalogować się na każdy serwer osobno i wykonać te same polecenia pięć razy. Z Ansible, tworzysz jeden plik konfiguracyjny (playbook), który wykonasz raz, a wszystkie serwery zostaną skonfigurowane automatycznie.

Dodatkowe korzyści:

Idempotencja - możesz uruchomić playbook wielokrotnie, a Ansible upewni się, że stan końcowy jest zawsze taki sam
Dokumentacja - Twój playbook jest jednocześnie dokumentacją tego, co zostało skonfigurowane
Wersjonowanie - możesz trzymać konfigurację w Git i śledzić zmiany
Testowanie - możesz testować konfigurację na środowisku testowym przed wdrożeniem na produkcję

Instalacja Ansible z użyciem pipx

Istnieje kilka sposobów instalacji Ansible. W tym artykule pokażę instalację za pomocą pipx, które jest rekomendowanym sposobem dla użytkowników, którzy chcą mieć Ansible zainstalowany lokalnie, bez wpływu na systemowe pakiety Pythona.

pipx to narzędzie, które instaluje aplikacje Pythona w izolowanych środowiskach, co zapobiega konfliktom zależności. Jeśli nie masz jeszcze pipx zainstalowanego, możesz go zainstalować na Ubuntu/Debian:

# Instalacja pipx na Ubuntu/Debian
sudo apt update
sudo apt install pipx
pipx ensurepath

Po zainstalowaniu pipx, możesz zainstalować Ansible:

# Instalacja Ansible za pomocą pipx
pipx install ansible

Po instalacji, możesz zweryfikować, że Ansible działa poprawnie:

# Sprawdzenie wersji Ansible
ansible --version

Powinieneś zobaczyć coś podobnego do:

ansible [core 2.15.x]
 config file = None
 configured module search path = ['/home/user/.local/share/ansible/plugins/modules']
 ansible python module location = /home/user/.local/pipx/venvs/ansible/lib/python3.x/site-packages/ansible
 ansible collection location = /home/user/.local/share/ansible/collections
 executable location = /home/user/.local/bin/ansible
 python version = 3.x.x
 jinja version = 3.x.x
 libyaml = True

Proponowany układ projektu

Zgodnie z oficjalną dokumentacją Ansible, zalecany jest następujący układ katalogów dla projektu:

ansible-project/
├── ansible.cfg # Konfiguracja Ansible
├── inventory/ # Definicje hostów
│ ├── hosts.yml # Plik z definicjami serwerów
│ └── group_vars/ # Zmienne dla grup hostów
│ └── all.yml
├── playbooks/ # Playbooki
│ └── site.yml # Główny playbook
├── roles/ # Role Ansible
│ ├── common/
│ ├── security/
│ └── nginx/
└── requirements.yml # Zależności (role z Ansible Galaxy)

Stwórzmy ten katalog krok po kroku:

# Utworzenie struktury katalogów
mkdir -p ansible-project/{inventory/group_vars,playbooks,roles}
cd ansible-project

Następnie stwórzmy podstawowy plik ansible.cfg:

# ansible.cfg
[defaults]
inventory = inventory/hosts.yml
roles_path = roles
host_key_checking = False
retry_files_enabled = False

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

Teraz stwórzmy podstawowy plik inventory inventory/hosts.yml:

# inventory/hosts.yml
all:
 children:
 web:
 hosts:
 web1:
 ansible_host: 192.168.1.10
 ansible_user: ubuntu
 web2:
 ansible_host: 192.168.1.11
 ansible_user: ubuntu
 db:
 hosts:
 db1:
 ansible_host: 192.168.1.20
 ansible_user: ubuntu

ℹ️

Zastąp adresy IP i użytkowników własnymi wartościami. Jeśli używasz kluczy SSH, upewnij się, że są one dodane do agenta SSH lub użyj opcji ansible_ssh_private_key_file w inventory.

Tworzenie roli za pomocą ansible-galaxy init

Role w Ansible to sposób na organizację i ponowne wykorzystanie zadań. Zamiast pisać wszystkie zadania w jednym playbooku, możesz stworzyć role, które można używać w różnych projektach.

Ansible Galaxy to narzędzie, które pomaga w tworzeniu nowych ról. Użyjmy go do stworzenia przykładowej roli common:

# Przejście do katalogu roles
cd roles

# Utworzenie nowej roli za pomocą ansible-galaxy
ansible-galaxy init common

To polecenie utworzy następującą strukturę:

roles/common/
├── defaults/
│ └── main.yml # Domyślne zmienne roli
├── files/ # Pliki statyczne do kopiowania
├── handlers/
│ └── main.yml # Handlery (np. restart usługi)
├── meta/
│ └── main.yml # Metadane roli
├── tasks/
│ └── main.yml # Główne zadania roli
├── templates/ # Szablony Jinja2
├── tests/
│ ├── inventory
│ └── test.yml
└── vars/
 └── main.yml # Zmienne roli (wyższy priorytet niż defaults)

Teraz stwórzmy prostą rolę common, która zainstaluje podstawowe pakiety. Edytujmy plik roles/common/tasks/main.yml:

# roles/common/tasks/main.yml
---
- name: Update apt cache
 apt:
 update_cache: yes
 cache_valid_time: 3600

- name: Install basic packages
 apt:
 name:
 - curl
 - git
 - vim
 - htop
 - wget
 state: present

- name: Ensure timezone is set to Europe/Warsaw
 timezone:
 name: Europe/Warsaw

Możemy również zdefiniować zmienne w roles/common/defaults/main.yml:

# roles/common/defaults/main.yml
---
common_packages:
 - curl
 - git
 - vim
 - htop
 - wget

timezone: Europe/Warsaw

I zaktualizować tasks/main.yml, aby używał tych zmiennych:

# roles/common/tasks/main.yml
---
- name: Update apt cache
 apt:
 update_cache: yes
 cache_valid_time: 3600

- name: Install basic packages
 apt:
 name: "{{ common_packages }}"
 state: present

- name: Ensure timezone is set
 timezone:
 name: "{{ timezone }}"

Teraz stwórzmy prosty playbook playbooks/site.yml, który użyje tej roli:

# playbooks/site.yml
---
- name: Configure all servers
 hosts: all
 become: yes
 roles:
 - common

Możesz teraz przetestować swoją rolę:

# Test połączenia z hostami
ansible all -m ping

# Uruchomienie playbooka (dry-run)
ansible-playbook playbooks/site.yml --check

# Uruchomienie playbooka
ansible-playbook playbooks/site.yml

Złote Zasady Tworzenia Ról (Best Practices)

Oto zestaw zasad, które sprawią, że Twoje role będą profesjonalne i łatwe w utrzymaniu.

1. Nazewnictwo ról

Zamiast używać numeracji w nazwach ról (co sugeruje kolejność wykonania), używaj opisowych nazw:

Zamiast:

roles/
├── 00-checks/
├── 01-common/
├── 02-security/
└── 10-nginx/

Stosuj:

roles/
├── common/ # Podstawowe pakiety (curl, git, vim)
├── security/ # Fail2ban, SSH hardening, Firewall
├── nginx/ # Tylko instalacja i konfig serwera WWW
├── app_deploy/ # Logika specyficzna dla Twojej aplikacji
└── monitoring/ # Np. node_exporter

Kolejność wykonania ról definiuj w playbooku, nie w nazwach katalogów.

2. Organizacja playbooków

A kolejność zdefiniuj w pliku playbooks/site.yml:

# playbooks/site.yml
---
- name: Configure all servers
 hosts: all
 become: yes
 roles:
 - common
 - security
 - monitoring

- name: Configure web servers
 hosts: web
 become: yes
 roles:
 - nginx
 - app_deploy

To podejście jest czytelne, elastyczne i zgodne ze standardami branżowymi.

3. Używaj zmiennych

Zamiast hardkodować wartości, używaj zmiennych w defaults/main.yml:

# roles/nginx/defaults/main.yml
---
nginx_user: www-data
nginx_worker_processes: auto
nginx_worker_connections: 1024

4. Idempotencja

Upewnij się, że Twoje zadania są idempotentne - możesz je uruchomić wielokrotnie bez zmiany wyniku:

# Dobrze - idempotentne
- name: Ensure package is installed
 apt:
 name: nginx
 state: present

# Źle - nie idempotentne
- name: Install nginx
 command: apt-get install -y nginx

5. Używaj handlerów do restartowania usług

Zamiast restartować usługi w każdym zadaniu, używaj handlerów:

# roles/nginx/tasks/main.yml
- name: Configure nginx
 template:
 src: nginx.conf.j2
 dest: /etc/nginx/nginx.conf
 notify: restart nginx

# roles/nginx/handlers/main.yml
- name: restart nginx
 systemd:
 name: nginx
 state: restarted

6. Dokumentuj swoje role

Dodaj opis w meta/main.yml:

# roles/common/meta/main.yml
---
galaxy_info:
 role_name: common
 description: Installs common packages and basic configuration
 author: Twoje Imię
 license: MIT
 min_ansible_version: '2.9'

Podsumowanie

W tym artykule dowiedziałeś się:

Czym jest Ansible i dlaczego warto go używać
Jak zainstalować Ansible za pomocą pipx
Jak zorganizować projekt Ansible zgodnie z najlepszymi praktykami
Jak stworzyć własną rolę za pomocą ansible-galaxy init
Złote zasady tworzenia ról

Ansible to potężne narzędzie, które może znacznie uprościć zarządzanie Twoją infrastrukturą. Zacznij od prostych ról i stopniowo rozbudowuj swoją automatyzację. Pamiętaj, że każdy playbook to jednocześnie dokumentacja tego, co zostało skonfigurowane.

W następnych krokach możesz:

Stworzyć role dla konkretnych usług (nginx, PostgreSQL, Redis)
Poznać zaawansowane funkcje Ansible (templates, loops, conditionals)
Zintegrować Ansible z CI/CD
Używać Ansible Vault do przechowywania wrażliwych danych

Powodzenia w automatyzacji!