Menu
Szybki wybór
Hosting Domeny VPS SSL Kalkulator Porównania FAQ
Aktywne kody
Wszystkie kody rabatowe

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

Najczęstsze pytania

Co to jest rola w Ansible i po co jej używać? +
Rola (role) w Ansible to ustandaryzowany sposób grupowania zadań, handlerów, zmiennych, szablonów i plików w jedną logiczną jednostkę. Zamiast pisać wszystko w jednym długim playbooku, dzielisz konfigurację na role: np. nginx, php-fpm, mysql. Role są reużywalne między projektami, można je wersjonować i udostępniać przez Ansible Galaxy. Dzięki predefiniowanej strukturze katalogów każdy member zespołu od razu wie gdzie szukać konkretnego pliku.
Czym jest Ansible Galaxy i jak z niego korzystać? +
Ansible Galaxy to publiczne repozytorium ról pod adresem galaxy.ansible.com. Zawiera tysiące gotowych ról od społeczności i firm (np. geerlingguy.nginx, geerlingguy.mysql). Używasz go przez CLI: `ansible-galaxy install geerlingguy.nginx` pobiera rolę do ~/.ansible/roles/. W projekcie zaleca się plik requirements.yml z listą ról i ich wersjami, a `ansible-galaxy install -r requirements.yml` instaluje wszystkie naraz. Dla projektów CI/CD to niezbędne.
Jak przebiega testowanie ról Ansible z Molecule? +
Molecule to framework do testowania ról Ansible. Tworzy izolowane środowisko (Docker lub VM), uruchamia rolę, a potem weryfikuje wynik przez testy (domyślnie Testinfra lub Goss). Workflow: `molecule create` uruchamia kontener, `molecule converge` stosuje rolę, `molecule verify` sprawdza asercje (np. czy port jest otwarty), `molecule destroy` sprząta. CI/CD integruje Molecule przez GitHub Actions lub GitLab CI.
Jaka jest różnica między defaults a vars w roli Ansible? +
defaults/main.yml zawiera domyślne wartości zmiennych o najniższym priorytecie — każda zmienna zdefiniowana przez użytkownika je nadpisze. Używaj defaults dla opcji konfigurowalnych przez użytkownika (np. nginx_port: 80). vars/main.yml ma wyższy priorytet i jest trudniejszy do nadpisania — używaj go dla zmiennych wewnętrznych roli, które nie powinny być zmieniane przez konsumenta (np. ścieżki systemowe specyficzne dla dystrybucji).
Jak tworzy się własną rolę za pomocą ansible-galaxy init? +
Polecenie `ansible-galaxy init moja-rola` tworzy szkielet katalogów: tasks/, handlers/, templates/, files/, vars/, defaults/, meta/, tests/. Plik meta/main.yml definiuje metadane roli (autor, licencja, zależności). tasks/main.yml to główny plik zadań — możesz tam importować inne pliki tasks przez `import_tasks` lub `include_tasks`. Po napisaniu roli możesz opublikować ją w Ansible Galaxy przez `ansible-galaxy role import` z konta GitHub.

Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.