Ansible Roles i Galaxy — tworzenie i używanie ról
Opublikowano: 10 kwietnia 2026 · Kategoria: VPS / Automatyzacja
Pisanie wszystkich zadań w jednym playbooku działa na początku, ale szybko staje się nieczytelne. Ansible Roles rozwiązują ten problem przez standardowy podział na moduły: każda rola odpowiada za jeden aspekt konfiguracji (np. Nginx, PHP-FPM, MySQL) i ma predefiniowaną strukturę katalogów. Role można reużywać między projektami, wersjonować w Git i dzielić się nimi przez Ansible Galaxy. Ten artykuł pokazuje jak tworzyć własne role, korzystać z gotowych z Galaxy oraz testować je za pomocą Molecule.
Struktura katalogów roli
Każda rola Ansible ma identyczną strukturę katalogów. Ansible automatycznie ładuje pliki z
tych katalogów, więc wystarczy je wypełnić — nie trzeba ich jawnie importować. Utwórz
szkielet poleceniem ansible-galaxy init:
# Utwórz szkielet roli ansible-galaxy init nginx-role # Wygenerowana struktura: # nginx-role/ # ├── tasks/ # │ └── main.yml # Lista zadań (WYMAGANE) # ├── handlers/ # │ └── main.yml # Handlery (np. reload nginx) # ├── templates/ # │ └── nginx.conf.j2 # Szablony Jinja2 # ├── files/ # │ └── index.html # Statyczne pliki # ├── vars/ # │ └── main.yml # Zmienne wewnętrzne (wysoki priorytet) # ├── defaults/ # │ └── main.yml # Domyślne wartości (nadpisywalne) # ├── meta/ # │ └── main.yml # Metadane, zależności od innych ról # └── tests/ # ├── inventory # Test inventory # └── test.yml # Prosty test playbook
Przykład roli LEMP — Nginx + PHP-FPM
Poniżej kompletny przykład roli instalującej Nginx z podstawową konfiguracją. Zwróć uwagę na
użycie zmiennych z defaults/, szablonu Jinja2 i handlera do przeładowania
serwisu:
# defaults/main.yml — domyślne wartości (użytkownik może je nadpisać)
nginx_port: 80
nginx_server_name: "localhost"
nginx_root: "/var/www/html"
nginx_user: "www-data"
nginx_worker_processes: "auto"
---
# tasks/main.yml — lista zadań
- name: Zainstaluj Nginx
ansible.builtin.apt:
name: nginx
state: present
update_cache: yes
tags: [nginx, install]
- name: Skopiuj konfigurację z szablonu
ansible.builtin.template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: '0644'
notify: Reload nginx
tags: [nginx, config]
- name: Upewnij się że Nginx jest uruchomiony i włączony przy starcie
ansible.builtin.service:
name: nginx
state: started
enabled: yes
tags: [nginx]
---
# handlers/main.yml — handlery wywoływane przez notify
- name: Reload nginx
ansible.builtin.service:
name: nginx
state: reloaded
- name: Restart nginx
ansible.builtin.service:
name: nginx
state: restarted
---
# templates/nginx.conf.j2 — szablon Jinja2
user {{ nginx_user }};
worker_processes {{ nginx_worker_processes }};
events {
worker_connections 1024;
}
http {
server {
listen {{ nginx_port }};
server_name {{ nginx_server_name }};
root {{ nginx_root }};
index index.php index.html;
}
} Ansible Galaxy — gotowe role z repozytorium
Ansible Galaxy (galaxy.ansible.com) to publiczne repozytorium ról. Zamiast
pisać rolę dla MySQL od zera, możesz użyć sprawdzonej roli jak
geerlingguy.mysql od Jeff Geerling — maintainera z ponad 100 rolami. Poniżej workflow
pobierania i używania ról z Galaxy:
# Pobierz rolę z Galaxy ansible-galaxy install geerlingguy.nginx ansible-galaxy install geerlingguy.mysql ansible-galaxy install geerlingguy.php # Wylistuj zainstalowane role ansible-galaxy list # Usuń rolę ansible-galaxy remove geerlingguy.nginx # Pobierz z konkretną wersją (tag z GitHub) ansible-galaxy install geerlingguy.nginx,3.2.0 # Pobierz z GitHub (gdy nie ma na Galaxy) ansible-galaxy install git+https://github.com/example/role.git,main
requirements.yml — zarządzanie zależnościami ról
W projektach produkcyjnych nigdy nie instaluj ról ręcznie. Używaj pliku
requirements.yml i commituj go do repozytorium. CI/CD może wtedy automatycznie instalować
zależności przed uruchomieniem playbooka:
# requirements.yml — lista ról z pinowanymi wersjami
---
roles:
- name: geerlingguy.nginx
version: "3.2.0"
- name: geerlingguy.mysql
version: "4.3.1"
- name: geerlingguy.php
version: "5.0.0"
# Rola z własnego Git repo (prywatna rola firmy)
- name: my-company.deploy
src: git+ssh://[email protected]/mycompany/ansible-deploy-role.git
version: "v2.1.0"
# Rola z Ansible Galaxy po nazwie użytkownika.nazwa
- name: geerlingguy.certbot
version: "5.0.1"
collections:
- name: community.general
version: "7.0.0"
- name: ansible.posix
version: "1.5.4"
# Instalacja:
# ansible-galaxy install -r requirements.yml
# ansible-galaxy collection install -r requirements.yml Używanie ról w playbooku
Role możesz dodawać do playbooka na trzy sposoby: przez klucz roles, przez import_role (statyczne, wymagane do tagów) lub przez
include_role (dynamiczne, dobre z pętlami). Oto pełen playbook LEMP:
# site.yml — playbook z rolami
---
- name: Konfiguracja serwera LEMP
hosts: webservers
become: yes
vars:
# Nadpisanie domyślnych wartości ról
nginx_port: 80
mysql_root_password: "{{ vault_mysql_root_password }}"
php_version: "8.2"
pre_tasks:
- name: Aktualizacja apt cache
ansible.builtin.apt:
update_cache: yes
cache_valid_time: 3600
roles:
# Prosta lista ról
- role: geerlingguy.nginx
- role: geerlingguy.php
vars:
php_packages:
- php8.2-fpm
- php8.2-mysql
- php8.2-xml
- role: geerlingguy.mysql
post_tasks:
- name: Weryfikacja — sprawdź status Nginx
ansible.builtin.command: nginx -t
changed_when: false
# Uruchomienie:
# ansible-playbook site.yml -i inventory/production
# ansible-playbook site.yml -i inventory/production --tags nginx
# ansible-playbook site.yml -i inventory/production --check # dry-run Zależności między rolami — meta/main.yml
Plik meta/main.yml pozwala zadeklarować zależności od innych ról. Ansible automatycznie
zainstaluje je przed uruchomieniem Twojej roli. Przydatne gdy np. rola WordPress wymaga wcześniejszego
nginx i php-fpm:
# meta/main.yml — metadane i zależności roli
---
galaxy_info:
author: "twoja-firma"
description: "Rola do instalacji WordPress na LEMP"
license: "MIT"
min_ansible_version: "2.14"
galaxy_tags:
- wordpress
- nginx
- php
dependencies:
# Ta rola wymaga najpierw nginx i php-fpm
- role: geerlingguy.nginx
vars:
nginx_port: 80
- role: geerlingguy.php
vars:
php_version: "8.2"
- role: geerlingguy.mysql Testowanie ról z Molecule
Molecule umożliwia automatyczne testowanie ról Ansible w izolowanym środowisku Docker lub Vagrant. Każdy test weryfikuje że rola działa poprawnie i jest idempotentna (drugie uruchomienie = zero zmian):
# Instalacja Molecule z driverem Docker
pip install molecule molecule-docker
# Inicjalizuj testy w istniejącej roli
cd nginx-role
molecule init scenario --driver-name docker
# Struktura molecule/default/
# ├── molecule.yml # Konfiguracja scenariusza
# ├── converge.yml # Playbook uruchamiający rolę
# └── verify.yml # Playbook z asercjami
# molecule/default/molecule.yml
---
dependency:
name: galaxy
driver:
name: docker
platforms:
- name: ubuntu-22-04
image: geerlingguy/docker-ubuntu2204-ansible
pre_build_image: true
privileged: true
- name: debian-12
image: geerlingguy/docker-debian12-ansible
pre_build_image: true
privileged: true
provisioner:
name: ansible
verifier:
name: ansible
# molecule/default/verify.yml
---
- name: Weryfikacja
hosts: all
tasks:
- name: Sprawdź czy nginx jest zainstalowany
ansible.builtin.package:
name: nginx
state: present
check_mode: yes
- name: Sprawdź czy port 80 jest otwarty
ansible.builtin.wait_for:
port: 80
timeout: 5
# Uruchomienie pełnego cyklu testów
molecule test
# Lub poszczególne kroki:
molecule create # Uruchom kontener
molecule converge # Zastosuj rolę
molecule verify # Sprawdź asercje
molecule idempotence # Sprawdź idempotentność
molecule destroy # Usuń kontener Porównanie metod zarządzania rolami
| Metoda | Kiedy używać | Zalety | Wady |
|---|---|---|---|
| Własna rola (galaxy init) | Specyficzna logika firmy | Pełna kontrola, prywatna | Wymaga utrzymania |
| Galaxy (geerlingguy.*) | Standardowe oprogramowanie | Gotowa, przetestowana, dojrzała | Zewnętrzna zależność |
| import_role (statyczne) | Tagi działają, znana rola | Tagi Ansible działają | Nie działa w pętlach |
| include_role (dynamiczne) | Pętle, warunkowe role | Elastyczne, działa z when/loop | Tagi nie filtrują wewnątrz |
| Prywatne Galaxy | Duże organizacje | Kontrola wersji, audyt | Wymaga infrastruktury |